Two for the price of one

For me, the penny dropped when I realised that the Logjam paper sets out two strategies. The first is a cryptanalytic attack that uses pre-computation to speed up the process of cracking a Diffie-Hellman (DH) key exchange. The second is a protocol attack that allows weaker export-grade versions of DH-based cipher suites to be selected, so long as they are supported by the server. A man-in-the-middle attacker who can make use of the second technique can downgrade vulnerable connections, which helps the first attack by forcing the use of weaker cryptography. But an attacker doesn’t have to rely on the downgrade trick for an attack on the security of the connection to succeed. It all depends on what the attacker wants to achieve and what position they are in.

Attack scenarios

If the attacker wants to modify the data in transit then the attack must be performed in real time. The attacker must be a man-in-the-middle and have access to sufficient computing resources to perform the necessary cryptanalysis in a short space of time. To ease the cryptanalysis, if the attacker can downgrade the connection to using a 512-bit prime, then so much the better. That’s only possible if the server supports export-grade DH cipher suites. In the opinion of the Logjam authors, any 512-bit prime should be considered vulnerable but a 768-bit, and certainly a 1024-bit, DH prime would require a serious amount of effort to attack.

In contrast, decrypting (but not modifying) the secure traffic from a connection that begins with a DH key exchange can be done passively in slower time: the attacker can capture the traffic and run the cryptanalysis offline. In this case, the attacker must contend with whatever strength of DH prime was selected during the TLS negotiation, which is unlikely to be 512-bit. For passive attacks, cipher suite preference is therefore more important: if the server prefers a common cipher suite that isn’t based on the standard DH key exchange (e.g. AES256-SHA) then a passive attack is very unlikely to succeed.

Client-side fixes

As with a number of previous TLS bugs, browsers have applied plasters to the sores to try to mitigate the impact. Although the downgrade attack exploited a weakness in the TLS protocol rather than an implementation flaw, refusing to accept 512-bit DH primes is a quick and effective solution. But taking that strategy all the way up to 1024-bit primes is dangerous in terms of user experience – users could start complaining that sites are suddenly inaccessible. So the success of client-side “patching” will depend on the vendors, the minimum size of DH prime their browser accepts and the user’s update regime.

Common primes

Another factor to consider is the prime itself. The Logjam paper noted that servers tend to re-use it – and, not only that, but the same primes are in circulation across different implementations. The pre-computation work for the cryptanalysis is based on a single DH prime so it’s in the attacker’s interest to do the number crunching for primes that are most widely used. A server that uses a common prime is thus more of a target. But what are these common primes? The Logjam paper itself makes explicit reference to two 512-bit primes. A number of larger primes can be found by inspecting the JavaScript behind the server test page on the Logjam site. You can test for a dozen common primes by adding a bit of code to the file apps/s_cb.c before compiling OpenSSL. Since version 1.0.2 the default output includes a line, when appropriate, beginning “Server Temp Key”, e.g.

Insert the following lines after the line that outputs the bit length, which is BIO_printf(out, "DH, %d bits\n", EVP_PKEY_bits(key)); (line 519 for the current version 1.0.2d):

if (EVP_PKEY_bits(key) > 1024)
   break;
const char *common[12]; // common primes from https://weakdh.org/imperfect-forward-secrecy.pdf, https://weakdh.org/docheck.js
common[0] = "9FDB8B8A004544F0045F1737D0BA2E0B274CDF1A9F588218FB435316A16E374171FD19D8D8F37C39BF863FD60E3E300680A3030C6E4C3757D08F70E6AA871033";
common[1] = "D4BCD52406F69B35994B88DE5DB89682C8157F62D8F33633EE5772F11F05AB22D6B5145B9F241E5ACC31FF090A4BC71148976F76795094E71E7903529F5A824B";
common[2] = "E9E642599D355F37C97FFD3567120B8E25C9CD43E927B3A9670FBEC5D890141922D2C3B3AD2480093799869D1E846AAB49FAB0AD26D2CE6A22219D470BCE7D777D4A21FBE9C270B57F607002F3CEF8393694CF45EE3688C11A8C56AB127A3DAF";
common[3] = "D67DE440CBBBDC1936D693D34AFD0AD50C84D239A45F520BB88174CB98BCE951849F912E639C72FB13B4B4D7177E16D55AC179BA420B2A29FE324A467A635E81FF5901377BEDDCFD33168A461AAD3B72DAE8860078045B07A7DBCA7874087D1510EA9FCC9DDD330507DD62DB88AEAA747DE0F4D6E2BD68B0E7393E0F24218EB3";
common[4] = "BBBC2DCAD84674907C43FCF580E9CFDBD958A3F568B42D4B08EED4EB0FB3504C6C030276E710800C5CCBBAA8922614C5BEECA565A5FDF1D287A2BC049BE6778060E91A92A757E3048F68B076F7D36CC8F29BA5DF81DC2CA725ECE66270CC9A5035D8CECEEF9EA0274A63AB1E58FAFD4988D0F65D146757DA071DF045CFE16B9B";
common[5] = "E6969D3D495BE32C7CF180C3BDD4798E91B7818251BB055E2A2064904A79A770FA15A259CBD523A6A6EF09C43048D5A22F971F3C20129B48000E6EDD061CBC053E371D794E5327DF611EBBBE1BAC9B5C6044CF023D76E05EEA9BAD991B13A63C974E9EF1839EB5DB125136F7262E56A8871538DFD823C6505085E21F0DD5C86B";
common[6] = "C9BBF5F774A8297B0F97CDDA3A3468C7117B6BF799A13D9F1F5DAC487B2241FE95EFB13C2855DFD2F898B3F99188E24EDF326DD68C76CC85537283512D46F1953129C693364D8C71202EABB3EBC85C1DF53907FBD0B7EB490AD0BC99289686800C46AB04BF7CDD9AD425E6FB25592EB6258A0655D75E93B2671746AE349E721B";
common[7] = "CD5C22FAEA0C53C39E602242C088FA0EA31586F472E9B04606AEDFB35F56C4948095F687B388575FA1700DB3D02253025A523AC76E9646F755A12338653AE071CB64F185591C34C6673FAC9B78DC4D71E53F3A5CCA6326F89C5400FBF8272A76367C630E234A905E4E558CDA968A46A136AD3088DD295F934EC36ADB5F69C3F3";
common[8] = "92402435C3A12E44D3730D8E78CADFA78E2F5B51A956BFF4DB8E56523E9695E63E32506CFEB912F2A77D22E71BB54C8680893B82AD1BCF337F7F7796D3FB968181D9BA1F7034ABFB1F97B3104CF3203F663E81990B7E090F6C4C5EE1A0E57EC174D3E84AD9E72E6AC7DA6AEA12DF297C131854FBF21AC4E879C23BBC60B4F753";
common[9] = "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE649286651ECE65381FFFFFFFFFFFFFFFF";
common[10] = "D6C094AD57F5374F68D58C7B096872D945CEE1F82664E0594421E1D5E3C8E98BC3F0A6AF8F92F19E3FEF9337B99B9C93A055D55A96E425734005A68ED47040FDF00A55936EBA4B93F64CBA1A004E4513611C9B217438A703A2060C2038D0CFAAFFBBA48FB9DAC4B2450DC58CB0320A0317E2A31B44A02787C657FB0C0CBEC11D";
common[11] = "B10B8F96A080E01DDE92DE5EAE5D54EC52C99FBCFB06A3C69A6A9DCA52D23B616073E28675A23D189838EF1E2EE652C013ECB4AEA906112324975C3CD49B83BFACCBDD7D90C4BD7098488E9C219A73724EFFD6FAE5644738FAA31A4FF55BCCC0A151AF5F0DC8B4BD45BF37DF365C1A65E68CFDA76D4DA708DF1FB2BC2E4A4371";

char *prime;
prime = BN_bn2hex(key->pkey.dh->p);
BIO_printf(out, "---> DH prime: %s\n", prime);
int i;
for (i = 0; i < 12; i++) {    if (!strcmp(prime, common[i])) {        BIO_puts(out, "---> Warning - common prime!\n");
       break;
   }
}

So you should have something like:

Now you’ll get output such as:

Remember that you may need to employ the -cipher DH parameter to force OpenSSL to use a DH-based cipher suite. If export-grade as well as stronger DH suites are supported then you’ll also have to use something like -cipher EXP on a second connection to ensure you test the commonality of both primes.

The problem

The application used a bespoke session management cookie. I’ll call it MYSESSIONID. On login, it wasn’t renewed. I couldn’t push a session cookie onto the victim in a classic session fixation attack. However, I had XSS in an unauthenticated page – but not the login page. The filtering in place used a combination of removal and encoding. Characters that were stripped out included:

+ ; ( ) ? < >

Characters that were allowed included:

" ' = [ ] / , .

So even though MYSESSIONID wasn’t protected with the HttpOnly flag, I just couldn’t construct a payload to steal it. Instead I looked to set one of my own. Here’s a breakdown of the attack:

1. Get a valid cookie

The application did not accept arbitrary session management cookies so the attacker sends a request to get a valid one. In this case, simply having no MYSESSIONID wasn’t enough, the cookie had to be present but an invalid value did the trick:

Cookie: MYSESSIONID=aaaaaaaaaaaaaaaaaaa:xx01

returned

Set-Cookie: MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01; Path=/; Domain=.example.com

2. The XSS

The malicious link looked something like this (the highlighted bits are explained below):

https://www.example.com/app/folder/page?vuln=foo"%0adocument.cookie%3d"MYSESSIONID%3dNDnQrZ6JsMHyJTBCw8n:xx01:%0dpath%3d/app/

When clicked, the XSS flaw wrote the following to the return page inside a JavaScript code block:

var a = "foo"
document.cookie="MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
path=/app/";

The %0a at the front of the XSS payload was used to start a new line and this was sufficient to act as a statement terminator after var a = "foo" (semi-colons were being stripped). But in order to inject a path attribute (discussed below) I did need a semi-colon in the cookie string. By running every character through a Burp Intruder attack, I saw which characters were allowed, which were stripped and which were returned encoded. By inserting :%0d into the XSS payload :
 was returned – yes, %0d was encoded but %0a (used above) came back fine! Being inside a string inside a JavaScript block 
 wasn’t seen as an HTML entity by the browser and thus wasn’t interpreted. This provided the semi-colon needed to create a path attribute.

The colon at the front was used because it looked like the session cookie was delimited in that way. That “xx01″ might refer, for example, to an internal server for load-balancing. Anyway, whatever it did, the application tolerated the unusual suffix to the session cookie. So that explains the :%0d appended to the cookie value in the XSS payload. Now for the path%3d/app/…

3. The victim logins in

So, at this point, the attacker has set the MYSESSIONID cookie on the victim to be NDnQrZ6JsMHyJTBCw8n:xx01:&#13 via a reflected XSS attack. Now the victim goes to the login page at https://www.example.com/app/login or is bounced there by navigating to a part of the site that enforces authentication. At login two MYSESSIONID cookies are passed up. This is because one had been set earlier in a Set-Cookie response header the first time the victim hit the site, even if that was by visiting the XSS’ed page. The genuine MYSESSIONID has a path of / and a domain of .example.com. If I had set a cookie by XSS with no attributes my cookie would have had a path of /app/folder/ (to match the path of the page which set the cookie) and a domain of www.example.com (to match the domain of said page). This would mean my cookie would never be sent up to /app/login for authentication, hence the need to set a path as part of the XSS.

Furthermore, when two MYSESSIONID values were sent up, the application took the first value so I had to make sure my cookie was first. By setting a path of /app/, it trumped the real MYSESSIONID for having a better path match to /app/login. Thus it was listed first in the POST request with the credentials and became authenticated:

Cookie: MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
 MYSESSIONID=4GRc4jiKNeQIfsqh2:xx01

In contrast, the domain of a cookie does not govern precedence in a standardised way, it varies between browser. From memory I think my cookie (with a more specific domain match) was sent up first by IE but second by Chrome and Firefox. It’s not something you want to rely on. Neither could I overwrite the cookie because for that to happen the name, path and domain must match. That would mean having to change both attributes from their defaults but in this case I could only change one. This is because I’d need a second semi-colon to set a second attribute and in doing so, using the encoding trick above, the first attribute would be spoilt, e.g. I’d get

var a = "foo"
document.cookie="MYSESSIONID=NDnQrZ6JsMHyJTBCw8n:xx01:
path=/app/
domain=.example.com";

Developing this proof-of-concept for this specific injection point was quite fiddly and took some persistence but it was worth it. For all of their filtering – and because they did not change the session cookie after authentication – this was a nice practical attack using an unauthenticated XSS. One take-away thought then: be sure to probe the XSS defences in full because you never know what might come back and how it could be of help!

SSLv3 support with block ciphers (in CBC mode) supported

All SSL/TLS tools check for SSLv3 support. You can do this manually with:

openssl s_client -ssl3 –connect <host>:443

This confirms SSLv3 support but obviously it only reports 1 cipher suite. This is where the tools come in. However, remember that POODLE only affects block ciphers in cipher block chaining (CBC) mode (which I’ll just abbreviate to “block ciphers” now, as I believe all the block ciphers that can run under SSLv3 operate in CBC mode). So review the list of supported cipher suites: if the server only supports RC4 ciphers then don’t report POODLE as an issue (instead report SSLv3, which is still old and creaky, and RC4!).

Server preference

Even if the server supports block ciphers, it may prefer RC4-based ciphers so the likelihood of exploitation is going to be negligible. I recently wrote up what to do if you find that your tools disagree over which cipher suite is preferered.

TLS_FALLBACK_SCSV

I also recently posted in detail about how the TLS_FALLBACK_SCSV remediation worked. In short it’s a signal to the server from the client that it is connecting with a lower protocol version than it supports. If the server supports something better, then that should have been negotiated during the earlier connection attempts, so the server can abort the connection as being suspicious.

With the release of OpenSSL v1.0.1j it’s easy to test for TLS_FALLBACK_SCSV support:

openssl s_client -ssl3 -fallback_scsv -connect <host>:443

This is telling the server than I’d like to connect using SSLv3 – but grudgingly. I’m using -ssl3 in the context of POODLE but TLS_FALLBACK_SCSV offers wider protection than this (checking support for it will continue to be worthwhile long after we’ve forgotten about POODLE.) Below you can see the fake cipher suite value advertising the fallback (which Wireshark couldn’t decode into something meaningful as it didn’t recognise the new cipher suite value 0×5600 at the time):

If the OpenSSL connection succeeds as usual (as shown below – a cipher suite has been chosen) then the server doesn’t support TLS_FALLBACK_SCSV.

If the connection fails with the new inappropriate_fallback alert then the server does support TLS_FALLBACK_SCSV:

Enabling TLS_FALLBACK_SCSV is all very well but it does depend on client support too – so if the server has SSLv3 enabled with block ciphers supported (and preferred) then it’s not out of the woods. A few browsers do already support it – Chrome 33 (Feb 2014), Firefox 35 (Jan 2015), Opera 25 (Oct 2014) – so it’s better than nothing, and of course support for it among browsers will only improve. Acknowledging TLS_FALLBACK_SCSV support is therefore worthwhile – both today and in the future. A client may even feel aggrieved if they’ve gone to the trouble of enabling TLS_FALLBACK_SCSV but get no credit for it in their pentest report!

How is a cipher suite chosen?

Quick overview: the connection starts with a Client Hello in which the client advertises which cipher suites it supports in order of preference (most preferred first). This list will be tailored according to any local configuration, as well as to the SSL/TLS protocol version the client is hoping to use, which is also advertised in the Client Hello:

The protocol version is the highest the client supports – unless the browser has gone down the fallback route, which is the mechanism abused by POODLE to make the SSLv3 attack more practical. Cipher suites can vary with protocol version simply because older protocols can’t always meet the needs of newer cipher suites. For example, only TLSv1.2 supports cipher suites that use SHA-256 for message integrity.

In receipt of the Client Hello, the server now has two options: it can either (a) opt for the client’s most preferred cipher suite that it too supports, or (b) ignore the client’s preference and opt for the cipher suite nearest the top of its own list that the client supports. For example, say the client has sent up a list of cipher suites which we’ll just call 1,2,3,4,5,6,7 and the server supports 8,3,4,2,6. In the case of (a) the server’s order is unimportant and it chooses 2; in the case of (b) the server chooses 3. The choice the server makes is returned in the Server Hello message:

Something to note in the above example is that, in the case of the server having a preference, you would never find out that cipher suite 8 is in fact the preferred choice because it isn’t supported by the client and thus it’s never offered in the Client Hello. Server preference is thus not only dictated by the server: it depends on what the client knows too.

Conflicting results

On my last test I had a conflict between SSLyze and SSLscan over which cipher suite was preferred over SSLv3. SSLyze thought it was RC4-SHA (I’m using the OpenSSL notation here)…

…whereas SSLscan went for DES-CBC3-SHA:

Manually testing for preference

To resolve this was simple. I ran:

openssl s_client -ssl3 -connect <host>:443

OpenSSL reported that DES-CBC3-SHA had been chosen. Just to be sure – which I explain below – I let the two cipher suites in question compete with one another using the -cipher switch, which allows you to put specific cipher suites in the Client Hello. OpenSSL orders them exactly how you list them according to the scheme set out in man ciphers. So I ran:

openssl s_client -ssl3 -cipher DES-CBC3-SHA:RC4-SHA -connect <host>:443

and then switched the order of the cipher suites:

openssl s_client -ssl3 -cipher RC4-SHA:DES-CBC3-SHA -connect <host>:443.

In both cases DES-CBC3-SHA was chosen so I was confident that SSLscan was right.

Why did SSLyze get it wrong this time?

Up to now I had tried SSLyze versions 0.9 and 1.0dev and both had reported RC4-SHA as the preferred cipher suite. I then tried an earlier 0.6beta version and found it correctly reported DES-CBC3-SHA. Rather than delve into the code I first took the easy option and fired up Wireshark while running one of the later versions of SSLyze. When enumerating the supported cipher suites, I could see that DES-CBC3-SHA was tested individually; however, when it came to checking for preference, DES-CBC3-SHA was left out of the list in the Client Hello. Obviously the server couldn’t choose it in this case, hence the preference was misreported. I reported this as a bug and Alban Diquet explained that:

The reason why DES-CBC3-SHA isn’t sent within the preference test is that specific servers will not reply at all if the client hello is larger than 255 bytes (due to a bug in a specific brand of load balancers). To reduce the size of the hello, I had to disable some stuff including specific cipher suites.

In this case the server only supported 3 cipher suites over SSLv3 so this misidentification could have been avoided. And this got me thinking…

Algorithm for testing preference

For each supported SSL/TLS protocol version, this is my version 0.1 of a method a tool could use to work out cipher suite preference:

1. Determine which cipher suites are supported individually (i.e. repeatedly send a Client Hello with just one cipher suite and see if it’s accepted).
2. Once you know which suites are supported, send them all up in one Client Hello and see which one is picked. If you’re worried about the buggy load balancers mentioned above then use a subset for now.
3. If the chosen cipher suite is the one that was at the top of the list then there are two alternative explanations: either (a) the server picked the client’s preferred suite as it has no preference of its own, or (b) the server really does prefer that cipher suite and it just happened to be at the top. (This is why I ran more than one test above.) So repeat the test in step 2, this time changing the most preferred cipher suite at the top of the order. If the same cipher suite is chosen then it’s a case of (b) and the server definitely has a preference; otherwise, the first cipher suite should be chosen and it’s case of (a) where the server is happy to be guided by the client’s preference¹.
4. If the cipher suite list has been cut short to appease buggy load balancers, repeat step 2 with the next set of cipher suites. If a preference has been expressed so far, that cipher suite should be included with the next set to allow it to compete.
5. If a preference has been found and you really wanted to go the whole hog, you could determine the order in full by starting again at step 2, missing out the cipher suite previously identified as preferred.

I put some of this to Alban Diquet (as part of the bug report) and he replied “yes I thought of adding the exact check you described but that’s pretty much at the bottom of my TODO list”. I think he was referring to step 3 but, anyway, if you ever have conflicting output from your tools over cipher suite preference, hopefully this posting will help you to resolve the issue.

——————–

¹ Actually, there is a possibility of “no preference” being misreported if you consider a server that supports cipher suite “wildcards” in such as way that there is no preference within a set of cipher suites that match a wildcard. I don’t think any popular implementation features this (hence the footnote) but for the sake of completeness imagine a server that prefers AES-* then RC4-*. The test tool sends up AES-SHA, AES-MD5, RC4-SHA, RC4-MD5 and AES-SHA is chosen. As per step 3, the tool then sends up AES-MD5, RC4-SHA, RC4-MD5, AES-SHA. This time AES-MD5 is chosen, giving the illusion of no server preference but in fact the server does have a preference, it’s just by groups. To cover this, if no server preference has been detected after step 3, repeat step 2 rotating the cipher suite at the top of the list each time; if at any point the cipher suite selected is not the first on the list then the server does have a preference. Admittedly this could add a fair bit of overhead!

What are these timestamps anyway?

Timestamps are an optional addition to the TCP layer to provide information on round-trip times and to help with sequencing – see RFC 1323. The side-effect of supporting TCP timestamps (I’ll drop the IP now) is that in certain situations the uptime of the server can be estimated. The most likely impact of this is that an attacker could try to determine the host’s patch status as certain updates require a reboot.

The report I was re-testing had TCP timestamps as an issue – and you could tell it was a straight Nessus finding. I decided that, if timestamps were indeed enabled, I would at least try to find the uptime and make some comment on it.

Testing with Nessus and Nmap

I ran a Nessus scan and sure enough it reported “TCP/IP Timestamps Supported” but it didn’t state any estimated uptime. I then ran Nmap with -O and -v but it didn’t report anything either. In Nmap’s help for OS detection it states that:

The uptime guess is labeled a “guess” because various factors can make it completely inaccurate. Some operating systems do not start the timestamp counter at zero, but initialize it with a random value, making extrapolation to zero meaningless. Even on systems using a simple counter starting at zero, the counter eventually overflows and wraps around. With a 1,000 Hz counter increment rate, the counter resets to zero roughly every 50 days. So a host that has been up for 102 days will appear to have been up only two days. Even with these caveats, the uptime guess is accurate much of the time for most operating systems, so it is printed when available, but only in verbose mode. The uptime guess is omitted if the target gives zeros or no timestamp options in its SYN/ACK packets, or if it does not reply at all. The line is also omitted if Nmap cannot discern the timestamp increment rate or it seems suspicious (like a 30-year uptime).

I’ve bolded the important bits: firstly, remember to add -v to display any timestamp information; secondly, there are a number of reasons why Nmap might have omitted it. I came across this article which talks about adding the -d switch to debug the time calculation. The output from this article was:

root@tester# nmap -d -v -O victim.com
Starting Nmap 5.51 ( http://nmap.org ) at 2012-09-28 10:07 EDT
Initiating OS detection (try #1) against 1.2.3.4
OS detection timingRatio() == (1348841228.595 – 1348841228.095) * 1000 / 500 == 1.000
Retrying OS detection (try #2) against 1.2.3.4
OS detection timingRatio() == (1348841231.064 – 1348841230.563) * 1000 / 500 == 1.002
...[and more of the same]...

In fact this took me down a dead-end. After some head scratching I realised that those timingRatio() lines don’t relate to the uptime calculation. Timestamp values are whole numbers and there’s no time unit attached to them. According to the RFC the “timestamp clock…must be at least approximately proportional to real time” and it recommends “a timestamp clock frequency in the range 1 ms to 1 sec per tick”. In the output above 1348841228.595, for example, is in fact an Epoch time (seconds since 1 Jan 1970) and is equal to Fri, 28 Sep 2012 14:07:08 GMT. Since GMT=EDT+4 you can see this time is exactly when the scan was run. A comment in Nmap’s source code (osscan2.cc) for the function timingRatio() explains the debug line: “Compute the ratio of amount of time taken between sending 1st TSEQ probe and 1st ICMP probe compared to the amount of time it should have taken. Ratios far from 1 can cause bogus results”. So although Nmap’s online help was giving reasons why the uptime wasn’t being reported, debugging wasn’t telling me why.

Manual testing: hping and Wireshark

One thing I did get from the article above was how to fire off a packet to elicit a TCP timestamp response:

hping3 www.example.com -p 80 -S --tcp-timestamp -c 1
  hping3   a network packet generator and analyser
  -p   an open port on the target
  -S   set the SYN flag
  --tcp-timestamp   add the TCP timestamp option
  -c 1   stop after receiving 1 response packet

Top tip: if you’re using hping in a VM, make sure the network interface isn’t set to NAT on a host that has TCP timestamps disabled (like my Win7 box) – it will waste at least 20 minutes of your life! Anyway, the response to my hping included:

TCP timestamp: tcpts=0

Now I had a theory. The server was responding with a TCP timestamp value, which made Nessus report it, but Nmap didn’t report the uptime because the value was 0. Of course there is a chance that the timestamp could be 0 but certainly not for two consecutive replies. If you do get a non-zero value, by the way, you can run 2 hpings separated by “sleep” to calculate the tick rate and then estimate the uptime:

hping3 www.example.com -p 80 -S --tcp-timestamp -c 1; sleep 5; hping3 www.example.com -p 80 -S --tcp-timestamp -c 1

Taking tcpts[0] to be the first timestamp reply and tcpts[1] to be the second, the uptime in seconds is:

tcpts[0] / ( ( tcpts[1] - tcpts[0] ) / 5 )

Or in words: subtract the first timestamp value from the second, divide by 5 and then divide that result into the first timestamp.

For completeness I thought I’d find the packets in Wireshark:

The timestamp option in a TCP packet contains two values: TSval (the source’s time) and TSecr (an echo of the time the destination last sent). The best filter I found to look for positive timestamps was ip.src == <IP_of_target> && tcp.options.timestamp.tsval && !(tcp.options.timestamp.tsval == 0). The second part ensures that a TSval value is there since the third will return TRUE if the field isn’t there as well as when it’s non-zero. In this case, the filter returned no packets, as expected.

Back to Nessus

The following is a compressed extract of the relevant code from the Nessus plugin tcp_timestamps.nasl (version 1.19, latest at time of writing):

function test(seq) { ...
tsval = tcp_extract_timestamp(pkt["options"]);
if (isnull(tsval)) return NULL;
return make_list(ms, tsval);
}
...
v1 = test(seq:1);
sleep(1); # Bigger sleep values make the test more precise
v2 = test(seq: 2);
dseq = v2[1] - v1[1];
# Disable the uptime computation (unreliable)
if ( TRUE || dseq == 0 || v2[1] < 0)
{
security_note();
}
[else calculate and print uptime]

So Nessus reported the issue just because a TSval field was returned (it wasn't NULL), hence the false positive. For Nessus, an individual timestamp of 0 isn't a concern (which you could argue is justified) but if the difference between two timestamps is 0 then no uptime is computed. However, you can see that the TRUE that precedes this check effectively disables the uptime calculation completely, as the comment notes.

Conclusion

If Nessus reports TCP timestamps, it might not be a valid finding - and even if it is you won't get an uptime; if Nmap doesn't report it, there's probably a good reason. To be absolutely sure, hping can be used for a definitive test (along with Wireshark if you like to see your packets raw). My final word has to be this: I can't believe I've spent this much time on TCP timestamps.

The first thing I wanted to do was prove the negative – that is, if the -legacy_rengotation switch did what it seemed to promise, then without it renegotiation should fail. Using OpenSSL 1.0.1i I connected to a server that was missing the secure renegotiation patch and ran the test (more information here):

# openssl s_client -connect insecure.example.com:443
...
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
...
HEAD / HTTP/1.0
R
RENEGOTIATING
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Primary Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0

It worked. Wait a minute, that shouldn’t have happened! So I tried OpenSSL 1.0.1e and then another vulnerable server – and it always connected. After some digging around I found an article on the OpenSSL site. It stated that:

If the option SSL_OP_LEGACY_SERVER_CONNECT or SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set then initial connections and renegotiation between patched OpenSSL clients and unpatched servers succeeds. If neither option is set then initial connections to unpatched servers will fail.

The option SSL_OP_LEGACY_SERVER_CONNECT is currently set by default even though it has security implications: otherwise it would be impossible to connect to unpatched servers (i.e. all of them initially) and this is clearly not acceptable. Renegotiation is permitted because this does not add any additional security issues: during an attack clients do not see any renegotiations anyway.

There was the small print. So as far as s_client is concerned -legacy_renegotiation makes no difference by default because it will renegotiate with insecure servers anyway. To double-check that -legacy_renegotiation and SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION were in fact related, I took a quick look at the source code for s_client.c and the following lines shone out:

else if (strcmp(*argv,"-legacy_renegotiation") == 0)
  off|=SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION;
else if (strcmp(*argv,"-legacy_server_connect") == 0)
  { off|=SSL_OP_LEGACY_SERVER_CONNECT; }
else if (strcmp(*argv,"-no_legacy_server_connect") == 0)
  { clr|=SSL_OP_LEGACY_SERVER_CONNECT; }

As expected, the first line sees -legacy_renegotiation controlling SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, which we now know has no effect if SSL_OP_LEGACY_SERVER_CONNECT is set. The code also suggests that SSL_OP_LEGACY_SERVER_CONNECT can be controlled with switches, which aren’t listed in the built-in help. Using the switch -no_legacy_server_connect, as the OpenSSL doc states, stops you from connecting to the server at all:

# openssl s_client -no_legacy_server_connect -connect insecure.example.com:443
CONNECTED(00000003)
140264951338664:error:1412F152:SSL routines:SSL_PARSE_SERVERHELLO_TLSEXT:unsafe legacy renegotiation disabled:t1_lib.c:1732:
140264951338664:error:140920E3:SSL routines:SSL3_GET_SERVER_HELLO:parse tlsext:s3_clnt.c:1053:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 63 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)

If you skimmed over the OpenSSL quote above, you may now be thinking “why is it so black and white; why can’t I connect to an unpatched server but s_client refuse renegotiation?” As the OpenSSL doc notes – and if you think back to the attack details – the victim client doesn’t actually initiate a renegotiation, it’s all the attacker’s doing. OpenSSL isn’t leaving you vulnerable by letting you renegotiate to unpatched servers, it’s the very act of connecting to them that leaves you exposed. That’s where the -no_legacy_server_connect switch comes in: it gives you the option of terminating connections to unpatched servers if you don’t want to take any risks (and you can understand why they’ve not made that the default). From a pentest viewpoint, ‑legacy_renegotiation should be avoided when testing for insecure renegotiation.

I pinged Ivan Ristic (of SSL Labs fame) about this for a sanity check, since he was nice enough to get in touch following the release of my cheatsheet. (Quick trailer: it turns out that Ivan is planning to release some of the manual testing aspects from his book Bulletproof SSL and TLS as freeware in the near future.) He agreed that -legacy_renegotiation was something of a red herring as far as manual testing using OpenSSL s_client was concerned – and I think that’s now going to make it into the next version of his book!

The first thing I did was to try to terminate the query as simply as possible with no funny business. So in went search=keyword'-- but back came an error. It turned out that the injection point was inside a doubly nested query as search=keyword'))-- worked, producing the same results as search=keyword. After a bit of faffing about it occurred to me that spaces might be the issue. So I tried search=keyword'and'1'='1 (no spaces in there) and it worked! No error was returned – but it didn’t produce the same results as search=keyword, it returned no results at all. What produced the same results as search=keyword was search=keyword'or'1'='1. Okay, park that for now. I had found the main problem – and it was immediately clear what was going on.

With a developer’s hat on, what would you do if a user ran a search with multiple keywords? The obvious answer would be to split up the search terms with space as a delimiter, run a query on each one and then return all the results together. If that was true then search=keyword' and '1'='1 was running a database query against three terms: keyword', and, '1'='1. The first of these would fail (just like search=keyword' did), as would the last if it got that far. So next I tried search=keyword'/**/and/**/'1'='1 using the inline SQL comment characters and got the same result. Again, using AND returned no results but using OR was like a normal query with search=keyword. I had seen this kind of behaviour once before but I couldn’t remember what the context was, which is why I’ve written it down this time!

AND vs OR

In general, AND within a SQL statement (and thus in SQL injection too) is restrictive, narrowing the result set, whereas OR is inclusive, widening the result set. But, as with all SQL injection, it all depends on the underlying query. So what could be happening here?

Again, with the developer hat on, what else might you do with a user’s search terms? Well, it would be nice if you searched a little more widely, using them as stubs. In fact some of the SQL errors were giving this away (thanks, guys): Incorrect syntax near ‘%’. The % character is, of course, a wildcard used with LIKE. So when I searched for keyword, somewhere in the resulting query was LIKE '%keyword%'. This perfectly explains the AND vs OR behaviour…

When I injected search=keyword'and'1'='1 the resulting query included LIKE '%keyword'and'1'='1%'. So the AND clause I’d added was always evaluating to FALSE and hence no results were returned. Whereas injecting search=keyword'or'1'='1 produced LIKE '%keyword'or'1'='1%'. Even though one half of the OR clause was evaluating to FALSE, overall it returned TRUE when I got a positive hit on the keyword.

Since the injection point was inside a doubly nested query and this was a black box test, I had no idea what the real query was, but this certainly made sense. I tried a few more injections to test the theory just for the hell of it:

1. When I terminated the statement, AND and OR did their “usual” thing. Which is to say that search=keyword'/**/and/**/1=1))-- produced the same result as search=keyword whereas keyword'/**/or/**/1=1))-- produced lots of results. This is because I was now commenting out the final % along with the rest of the statement.
2. When I injected search=keyword'and'1%'='1 I got the same results as if there had been no injection. This was the real proof. Now the resulting query would have included LIKE '%keyword'and'1%'='1%' so my AND clause evaluated to TRUE when I got a positive hit on the keyword.
3. Finally, for what it was worth, search=word'and'1%'='1 produced the same result, showing that a % preceded the injection point.

sqlmap

One of the things that makes a great tool is the ability to customise it for a particular attack scenario. And sqlmap offers that in abundance. In this case a “tamper” script, which transforms the payloads in some way, worked a treat. One of the built-in tamper scripts is “space2comment” – bingo! In fact running sqlmap with this script allowed it to find the injection point. Without the script, though, sqlmap would have been stuck because, to quote the wiki page, “sqlmap itself does no obfuscation of the payload sent, except for strings between single quotes replaced by their CHAR()-alike representation”.

All this was a good reminder that, when things are getting tough, thinking like a developer can help to turn near-misses into exploitable flaws. Having said that, I’ve seen code in the past that I could never have guessed, when it was clear the developer wasn’t thinking at all!

The slides can be found here.

Cheatsheet

UPDATE 7th September 2014: I’ve now written a table that pulls together the manual checks discussed in the presentation – plus a few more (which will appear in any future presentations). Since tables are a pain in WordPress and I don’t want to risk a plugin at this time of night, you can find a (lazy) HTML table here.

For updates on content and future presentations follow me.

If you know what DirBuster is then you can skip this paragraph. If you don’t, then DirBuster is designed to brute-force directory and file names on web servers, the point being to find content to which there are no links. It’s an OWASP project and you can find it here. While you can run it in a pure brute-force mode, you’ll most likely be using a dictionary to maximise your chances of finding something in the time available. DirBuster comes with a set of dictionaries that were generated by crawling the internet for real directory and file names.

Cheer number 1

On a test of a web portal DirBuster found pages at /users/ and /organisations/. The portal was a closed system used by the owner to exchange financial information with many other organisations in (what was supposed to be) an isolated way. Sorry to be vague but you understand why! Navigating to /users/ opened up a whole user management area, with full names, email addresses, roles, last login etc. At /organisations/ there was an organisation management area, from where you could access the same user details from other organisations. Oops. While unauthorised data access was possible, attempts to execute administrative functions failed – but the fact that these functions were exposed was useful in itself because there was no CSRF protection. Moreover it was simple to target an administrator (of any organisation) because you could look them up from the user listings. The only saving grace was that you had to be authenticated – a point I’ll return to later.

Cheer number 2

On a public website for a high-street company, DirBuster found the page /staff/. This revealed a staff discount page where you could go through and order stuff at significant discounts, meaning lost revenue to the client. Of course, this sort of thing has a habit of getting out on to discount sites and the like. The page was available unauthenticated (although since anyone could register for an account, that’s by the bye).

Cheer number 2½: DirBuster also found a page that had a special offer for readers of a particular publication. Not as important this one since it was obviously there for the taking but it clearly wasn’t designed to be available to all.

Cheer number 3

On a test of a web portal, while authenticated, DirBuster found a positive response from /admin. This turned out to be an authorisation flaw and a short time later, after some fuzzing of user IDs, I had some 2,300 usernames and email addresses as well as plaintext passwords for about a third of those accounts. This portal was used by many different organisations – and a user from one of them could log in to another user’s account from another organisation. Oops.

In fact I had a fourth cheer yesterday, where I found a page that allowed me to self-register unauthenticated on (what was supposed to be) a closed site! But “four cheers for DirBuster” sounds a bit naff.

Walk-through

The rest (and majority) of this article is a walk-through of the main DirBuster configuration options. Note that I’m describing a general case in what follows and obviously there may be times when you need to do things differently. That’s an important part of pentesting: adapting your test to suit the target. Having said that, let’s take a look at the starting screen (of version 1.0 RC1, on which this article is based):

Target URL

For the “Target URL” consider HTTP vs HTTPS. HTTP is obviously faster but a website will often redirect some or all requests to the HTTPS equivalent whether the page is actually there or not, which will spoil your results. You can enable “Follow Redirects” from the Options menu but that’s a considerable overhead if it’s happening with every request. If the redirect happens only when the page exists then a HTTP-based scan should be speedier. My personal preference is that if the site is happy delivering HTTP pages over HTTPS, which is normal, I’ll go for HTTPS. Despite the overhead slowing down the request rate, it does tend to rule out excessive redirects since it would be unusual for a HTTPS request to be redirected to a HTTP equivalent. Redirects may also confuse the “fail case”, which DirBuster uses to decide how it knows whether or not a guess is correct, which could lead to false negatives as well as false positives. More on this later.

A similar situation may arise with the domain in that https://site.com/page may always redirect to https://www.site.com/page so use https://www.site.com:443 as your base URL.

Work Method

The default “Auto Switch” mode is probably best for the majority of cases. DirBuster will first try to see if it can get sensible results from HEAD requests, the reason being that the responses will be smaller. Even though it makes a GET request on 200 responses, this will save time when the 404 message (or equivalent) is relatively large. On the site I was looking at when writing this bit, the full HTML 404 response was about 19kB bigger than the disembodied 404 set of headers you’d get with HEAD. A crude bit of testing showed this took on average twice as long to arrive and be processed, adding 200ms to the response time. Given that you’re getting 404s most of the time this could mean a saving, even with the small dictionary, of over 1.4 gigabytes or 4 hours of waiting!

Number Of Threads

Running DirBuster with a high number of threads can slow down the target server, which may not go down too well if you’re testing a live site. You’ll probably find the default (10) to be a little over-enthusiastic, especially as you’ll be running other tests simultaneously. If you examine the number of threads in the DirBuster process (javaw.exe) while it’s running, you’ll see it jump up by more than the number you set in this field. I haven’t looked at the source code but I’m assuming that DirBuster is indeed honouring this field. I imagine that the “number of threads” refers to “Workers” that handle the actual requests and responses over the network while the other threads, for example, manage different queues depending on what you tick at the bottom of the screen.

As an aside, I’ve noticed that when you run a number of scans without re-starting DirBuster, the number of threads at rest tends to increase. I’m not sure if this is an issue that could degrade performance but just bear it in mind. (I did try to contact the project lead, James Fisher, to ask about threading but I got no reply. And it’s not that big a deal to warrant rummaging through the source code!)

I have DirBuster running on another monitor so I can keep an eye on the requests per second and any sudden scrolling, which usually means errors! Bear in mind that, say, 20 requests per second over HTTPS will be working the server harder than 20 requests per second over HTTP. A nice feature is that once the scan is running, you can dynamically change the number of threads.

Dictionary

Assuming you opt for “List based brute force” you’ll now need to choose a dictionary – and for this you need to know whether or not your directories are case sensitive. Although you can often guess this from the server in use, e.g. IIS isn’t case sensitive, it’s always best to check. So test a page that you know to exist, i.e. does /page return the same as /Page? Even when the server is case-sensitive, a look over the site map in your web proxy may show that all the pages you’ve requested are in fact lower case. But don’t go thinking that using the case-sensitive lists will take all that much longer. Clicking “List Info” brings up some statistics on the dictionaries, a portion of which is shown below:

You can see that the case-sensitive lists are nowhere near even twice the size of the lowercase versions, which you might have imagined as a minimum. That’s because the lists are based on real names found by crawling the internet. The file “directory-list-2.3-small.txt” has 87,650 entries while the lowercase version has 81,629 entries so it’s only 6,021 entries longer (about 7% bigger). For the medium-sized lists the numbers are 220,546 vs 207,629 so the case-sensitive version is 12,917 entries longer (about 6% bigger). So using the case-sensitive lists may not involve as big a hit as you might expect. (You can also see from the List Info what the actual difference is between big, medium and little: the entries were found on at least 1, 2 and 3 hosts respectively.)

Before you even start your attack you could consider putting together a small dictionary of a few directories and files you’ve found, together with some gibberish entries, to use on a test run. If you don’t see the results you expect, review your configuration bearing in mind some of the points from this article. A short test run might save you hours of wasted effort.

Starting options

The “Standard start point” will assume directories end with / and files end with whatever you configure underneath. The “URL Fuzz” option allows you to insert the dictionary entries into the URL in a non-standard way. A good illustration is to discuss why there’s an Apache user enumeration list included in the set of dictionaries (apache-user-enum-2.0.txt). This is because if the userdir module is enabled (more on this here) you can go hunting for usernames based on the fact that the user “bob” will have a folder mapped to http://site.com/~bob/. So in this example the URL to fuzz would be /~{dir}/ where {dir} is a placeholder for the words in the chosen dictionary.

The remaining options are self-explanatory but there are still a few things to consider. Obviously the more options you tick the longer the scan will take. So look first at the style of URL the website uses. For example, you might find that requests to /page produce redirects to /page/ or that both of these return the same response. Either way, don’t run “Brute Force Dirs” together with “Brute Force Files”+”Use Blank Extension” because you’re doing twice the amount of work to get the same result. Conversely if you spot that there doesn’t seem to be much content in directories, i.e. none of the pages end with a / character, then don’t run “Brute Force Dirs”, rely on “Brute Force Files” instead.

If you enable the “Be Recursive” option, remember that DirBuster’s multi-threaded approach means that all those queues of work will be competing for a limited set of Workers. It’s easy to get into a situation where the Workers are looking in sub-folders of no real interest, slowing down the search for better candidates. In a time-limited test you could try looking at just the root content first by disabling this option. Where you go from there can be both manual and automated – and there’s always the option to create a custom dictionary for further scans based on the results of the first scan.

Options Menu

I’ve already mentioned “Follow Redirects” – in general, tick this only if you have to because it has the capacity to slow down the scan. Without this ticked, you’ll see 301 and 302 responses in the final results and you can just manually target the ones of interest later.

Choosing “Debug Mode” will only make a difference if you’re launching DirBuster from a command window that remains open in the background:

The references to Worker[n] are to the threads doing the networking so for n threads that you set you’ll see Workers from [0] to [n-1].

The option “Parse HTML”, which is on by default, instructs DirBuster to read the HTML of files that it discovers, looking for files and folders it then doesn’t have to guess. These can be found, for example, in the href attributes of <a> tags. You might decide this is overkill since DirBuster will quickly begin to download a lot of stuff you’ll see elsewhere during testing e.g. in Burp’s Proxy and Site Map. Overall this may add an overhead for results you simply don’t need – at least not from this tool on the first scan. There’s another possible benefit to disabling this when running authenticated scans, which we’ll come to momentarily.

Advanced Options

I’ll skip the first two tabs, which are self-explanatory, and start with the tab that’s active in the screenshot above…

Http Options

First, DirBuster allows you to add custom headers to your requests so you could, for example, add an authenticated session management cookie. Whoa! Did you say run an automated scanning tool authenticated? Yes I did. After getting a feel of the site you may be comfortable doing this – it can pull out some interesting finds (as shown by the case studies at the start of this article). Anything you find authenticated that you didn’t find unauthenticated is really worth a look. Although the risk of side effects is much lower than running a full-on active web application scanner authenticated across a site, of course I have to say that it’s not without risk! I disable “Parse HTML” and “Be Recursive” as a safety measure.

Underneath is the “Http User Agent” and you can see the default looks nothing like a real User-Agent string. If you’re getting odd results from DirBuster that you’re not seeing in Burp, you could try changing that option, e.g. to “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0″.

Lastly, the option to use a proxy is useful for troubleshooting – as well as learning! You could also take advantage of your upstream proxy’s features to handle more complex cases (adding an overhead, of course).

Scan Options

Here lies the all-important “Fail Case String”, which by default is “thereIsNoWayThat-You-CanBeThere”. The response from this page is used to determine whether or not a guessed page/directory is there so it’s critical for the success of the scan. DirBuster will request this often in fact – for every file type in every directory that it finds. So starting from / with all the scan options enabled (directories, files, recursive and blank), having found /admin/users/, for example, DirBuster will request:

/admin/users/thereIsNoWayThat-You-CanBeThere/
/admin/users/thereIsNoWayThat-You-CanBeThere
/admin/users/thereIsNoWayThat-You-CanBeThere.php

If you’re getting strange results from DirBuster, consider changing this string. It may even be worth getting into the habit of manually testing the fail case string as a directory and page before you start a lengthy scan.

DirBuster Options

The last tab serves as a reminder that most of the Options and Advanced Options discussed above get reset when you re-start DirBuster. Only the proxy settings persist beyond the options listed in this tab, which cover the default number of threads, dictionary and file extensions. These options will be pre-populated when you start DirBuster from fresh. Although you’ll lose many of your options on restart, being forced to reconsider them maybe isn’t such a bad thing.

And finally

It’s worth starting DirBuster relatively early on in the test because it can take a while to complete, and obviously you want some time left over to explore anything interesting it finds. Keep an eye on the results while it’s running to make sure you’re getting something sensible – and that you’re not causing a slew of 500 errors. Version 1.0 RC1 will pause automatically after 20 consecutive errors but that’s client-side errors, not 500 responses. Equally if you’re getting mostly redirects, try to alter your parameters or, as a last resort, enable the “Follow Redirects” option.

Despite – or because of – your efforts to optimise your scan, you can often get a large number of hits. On the reporting side, the CSV option is useful because you get the Location, Response Code and Content Length on one line so you can quickly begin to process this and weed out the cruft.

Finally, note that you can invoke a command line interface by running DirBuster in headless mode. Check out the options with java -jar <DirBuster_jar_file> -h. The parameters don’t comprehensively match the GUI options, though, so if you need a command-line scanner of this type and DirBuster isn’t up to the job, try dirb (on Kali).