These days a typical web app pulls in data from background XHR requests, the responses come back in a data format like JSON, and the data is parsed client-side and inserted into the DOM of the page. This means, of course, that the encoding of the data in the response is not sufficient by itself to know whether there’s a potential XSS risk – it depends how the data is finally encoded when inserted into the page. But consider the following:

1. You enter <script>alert(1)</script> hoping for a quick and dirty win – nothing
2. You suspect input validation so you enter something that you hope will pass validation but test encoding, e.g. xss < > test
3. You inspect the page using the browser dev tools and see it has been inserted as xss < > test
4. So the encoding looks good, and you move on -

But wait! Even dangerous DOM manipulation can perform encoding in a text context. For example, innerHTML will observe the rules and, in a text context, will encode < as < and > as > (and & as & in fact), otherwise those characters are inserted/parsed literally. So the encoding seen in step 3 could be explained by this, meaning that the potential for XSS still exists. It’s precisely because jQuery uses innerHTML as part of functions like append() that the documentation is full of caveats about not using data from “untrusted sources”.

Let’s assume the developers haven’t thought about XSS at all. So why did step 1 fail? This is because the spec says “script elements inserted using innerHTML do not execute when they are inserted”. If the first test case had been <img src=x onerror=alert(1)> the XSS would have been revealed in step 1.

Hope that’s of some use!

What is tlslite?

From the source “TLS Lite is an open source python library that implements SSL and TLS”. I’d seen references to it in the original BEAST post written by Thai Duong and an article on TLS Prober by Yngve Pettersen. This gave me some confidence that tlslite would be a good starting point. Obviously it’s not going to be fast but that doesn’t matter. With a SSL/TLS implementation in a high level language, it would be much easier to make the changes required for the sorts of tests I wanted to run, and I thought POODLE_TLS would be a good one to try first.

TLS Prober is in fact where I wanted to be heading. It works on a modified version of tlslite to test for various SSL/TLS bugs. However, the public source code hasn’t been updated since Yngve left Opera in 2013 and thus wouldn’t cover POODLE_TLS. While I could have added that capability, I decided to ignore TLS Prober (for now) and start afresh with the latest tlslite – mainly as it would be a good learning experience.

How to test for POODLE_TLS

I’m not going to re-hash theory that’s already covered elsewhere. Suffice to say that implementations of TLS that are faithful to the RFC shouldn’t be vulnerable to POODLE because the spec states what the contents of the padding bytes should be. Therefore, the way to test for POODLE_TLS is to ignore that rule and see if the connection is terminated by the server. This isn’t the same as performing a full attack but like all testing you have to compromise between accuracy and aggressiveness. I think this test is a good indication. After some rummaging through the source code and a bit of debugging, I found what I wanted.

Changes to tlslite

It seemed a bit crazy to fork the original project as my changes were tiny. I also thought that working through the changes here may be helpful to anyone else who wants to do the same sort of thing.

So to begin with I needed to signal to tlslite that I wanted to send TLS messages with invalid padding. You get things going with tlslite through the TLSConnection class so I changed how that was instantiated. TLSConnection inherits from TLSRecordLayer, which is where the padding code lives, so that needed changing too. Within the “tlslite” folder I made the following changes (obviously line numbers will be version dependent so I’ve added the original code too; my version was 0.4.8):

tlsconnection.py
Line 52 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls=False):
# now i can signal whether or not I want to perform the test
# if you already have tlslite, you can change it safely because check_poodle_tls defaults to False so it’s backward-compatible with any existing code that makes use of tlslite

Line 61 was:
TLSRecordLayer.__init__(self, sock)
Now:
TLSRecordLayer.__init__(self, sock, check_poodle_tls)
# I need to pass that signal on to the parent

tlsrecordlayer.py
Line 102 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls):

After line 103 self.sock = sock added new line:
self.check_poodle_tls = check_poodle_tls

After line 600 paddingBytes = bytearray([paddingLength] * (paddingLength+1)) added new lines:
if self.check_poodle_tls == True:
paddingBytes = bytearray(x ^ 42 for x in paddingBytes[0:-1])
paddingBytes.append(paddingLength)
# change all but the last of the padding bytes to be invalid (just XOR with 42, the answer to everything)
# make the last byte of padding valid = the number of padding bytes

And that’s it! Remember, as it’s Python, that tabs are important and the new code needs to be properly aligned.

POODLE_TLS test script

I then created the test script (available here), which attempts a normal TLS connection first before testing for POODLE using the invalid padding trick. Place the script within the modified tlslite and run it as test_poodle_tls.py <hostname>. Remember, it only tests for POODLE over TLS, not SSLv3.

I’ve noticed that sometimes the normal connection fails and one of the reasons for this is that the server does not support any of the small number of cipher suites offered by tlslite. In this case no conclusion can be drawn – and the script catches that.

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!