Format string attacks remain difficult in both software and hackademic exercises as the techniques have not improved since their discovery. This session demonstrates advanced format string attack techniques designed to automate the process from creation to compromise as well as incorporate those techniques into the Metasploit framework. The audience is encouraged to bring a basic understanding of format string attacks in order to leave the presentation with the tools necessary to never write one again.
There are many choices out there when it comes down to validating the security of your external network. The range of services and skill levels available are almost overwhelming when you first set out on your search. You’ll find high school students who charge you for Nmap ouput, veterans of the security industry who write shellcode in assembly as a hobby, and everything in between. You want to make sure your website and mail server aren’t easy pickings for hackers….but where do you start?
Somewhere along the line, you read about a vendor that offers daily, automated scanning. You browse around the website and are impressed; glossy, web 2.0 transitions, pretty graphs, and mesmerizing verbiage. Then you find the price-tag; its less than a third of what you’ve been quoted by other companies. You glance at your dwindling security budget, and then back to the other benefits they offer: PCI certification, website security verification seals, and daily scanning. At this point you are more than interested, and I don’t blame you.
The way it works is simple. You sign up for a scan, feed in your domains names and IP addresses, and hit the giant GO button. Twenty minutes later, you have the scan results in your web portal. If the scan comes back clean, or with no high risk issues – they give you access to a “Site Seal”. This seal goes on your website and shows customers that you passed a scan from a certain vendor, and this assumes a certain level of security. From here on out, the availability of the seal on your website is contingent upon ‘passing’ these scans. If a nasty IIS vulnerability comes out and you don’t patch – you fail the scan and your seal gets taken away.
There are many of these vendors to choose from; Hackersafe, ScanAlert, ControlScan, Shoppersafe, HackResistant, TrustKeeper, Trust-Guard, eSecurity and Comodo, just to name a few. Each of them offer the general vulnerability scanning service, with numerous add-ons. These additions can range from website badges saying you are using a particular vendor, detailed customer service, help with issue remediation, and some even offer insurance if your site ever gets hacked. What’s that old adage about boasting that your site is hack-proof?
Behind the Scenes
This is all great news, but what’s really going on behind the scenes of a scan? What do they really look for? More importantly, what issues and vulnerabilities would they miss? To answer some of my own questions, I created a fake website and signed it up for a number of these scanning vendors. I built a Ubuntu Linux system and installed some common services such as Apache and SSH. I then configured Apache and iptables for debug logging, and used tcpdump to capture all the traffic coming to the web site. During the testing, I allowed connections to my website only from the scanning vendor to eliminate Internet noise. This setup allowed me to get a copy of ALL the data that the scanning vendor sent to the web server. Basically, I had the data to reverse engineer their scan.
Just Give it Some Paint
Going through the raw data, I noticed one thing quickly: I saw a whole lot of Nessus traffic. It’s almost identical to a Nessus scan, right down to the plugin output. Some vendors allow you to enable extra functionality such as Nikto (a default add-in in Nessus) some custom plugins and full port scans. The following shows a quick search of the packet capture file:
$ strings vendor1_scan1.pcap | grep Nessus | sort -u
From: Nessus <sip:xxx.xxx.xxx.xxx:5060>
GET /NessusTest455840692.html HTTP/1.1
print(“Content-Type: text/plainrnrn”, “Nessus=”, 42+42);r
<p>The requested URL /NessusTest455840692.html was not found on this server.</p>
sHarmless Nessus echo test
TRACE /Nessus1233760340.html HTTP/1.1
User-Agent: Mozilla/4.75 [en] (X11; U; Nessus)
Using Nessus isn’t bad at all – we use it internally here at Redspin and love it. It’s a great way to double-check work, or add another layer of testing in a very automated way. The idea is that relying on Nessus alone with no human interaction, no manual poking and prodding, and no validation will likely leave you with a false sense of security. Vulnerability scanning should aid you in your work, not do the bulk of it. What you get is raw scanner output – nobody to go through and validate the issues, check the services it couldn’t enumerate, or worse: go behind it and see what it missed.
Some vendors did full port scans of the target machine. With most of the vendors, you had to specifically enable this option – although it had no bearing on the site seals or PCI compliance. When I enabled full port scans, and then hid some services on random, high ports – they were caught by the scanner. If you pay for any kind of vulnerability assessment that does not offer full port scanning (barring web application assessments), you are wasting your money.
The reporting was decent. The issues and findings that the vulnerability scanner found were formatted and presented in all the portal nicely. They provide all the information you need to configure your scans properly, and provide enough resources for the customer to understand how to fix the issues. I’m sure if you contacted customer support with the majority of these vendors, they would be more than happy to help. In fact, during my use of one of the scanners, I contacted customer support for help. I kept seeing an issue raised about TCP Sequence Prediction on my IIS server, which is impossible since I was using Apache. I sent support an email, and they replied:
“That threat would be tagged as a False Positive, but since it is purely informational it is not necessary. Only urgent, critical, or high threats need to be remediated for PCI Compliance and seal access.”
Seems like they might be more focused on keeping your site “Seal Approved” than actually solving issues. Seals are good for ROI and increasing customer confidence – but when it comes down to it, I’d be more concerned if someone could make off with customer data.
The price spread on these services is huge. One company offers the scanning for 15 dollars a month, while the next offers it for 1,400 dollars a year. Is it worth it? That depends on your company and your network. I doubt your Myspace page needs an audit. If you sell Beanie Babies in a Yahoo store, or if you are the webmaster of The Furby Fan Club, you might be a prime candidate for one of these vendors. Even if you own a high-volume e-commerce site, studies show that a site seal can increase ROI and Sales by up to 10% because the seal instills so much confidence in the customer. If you get 10% more sales just by having this seal on your site – I’d say its well worth it. Just keep in mind: you paid for the seal on your website, not the peace of mind of a hack-proof network.
The Old Rabbit-in-the-Hat Trick
The truth is, scanning vendors do offer a valuable service. They will indeed identify some of the critical, low-hanging fruit on your network. They may find the very outdated Apache install, the default credentials on that router, and might even find a SQL Injection flaw in your web application. What they won’t find is everything else – things that they don’t have an exact scan fingerprint for. Its like putting all your eggs in one basket, except the eggs are remote-root exploits and the basket has a few holes in it.
I’ve done External Assessments for websites that were certified by one of these vendors, and it was a mess. They were getting a clean bill of health from their scanning vendor, but in reality they were a nightmare. They had a PHPMyAdmin install that was very outdated and contained numerous high-impact vulnerabilities (like the ‘I own your database’ kind), but the directory was renamed (to something obvious) – so the scanner didn’t find it. They also had a version of SMTP that was vulnerable to a buffer overflow with proof of concept code available, but it wasn’t in the scan results because it was a very recent exploit. These are two critical, high-impact vulnerabilities that the largest automated scanning vendor missed.
Whats the moral of the story? The basic vulnerability scanning and ROI these services provide can be useful. It comes down to you, the customer, being able to decide what’s best for your business. If your site is a low traffic, brochure-ware setup, or a low-risk e-commerce setup, then maybe a scanning vendor can help you with basic security problems, as well as provide a little boost in ROI / sales. On the other hand, if a website or server is your company’s lifeline, or its critical to your reputation or compliance – you should consider a little more in-depth security assessment.