Day 9: ITSM Vulnerability Assessment techniques
Lesson 9:Yesterday was a bit of a whirlwind, discussing BGP, Whois/RWhois, and the DOM all in one big post. I'll try and keep it short and sweet today.
Arshan Dabirsiaghi (leader of the OWASP Anti-Samy Project), commented on yesterday's post regarding how web application security scanners are immature. He thinks they are immature because of the technology. Missing elements such as "the input fields being vulnerable to XSS", with results such as "we got kaput from the scanner". He also said, "the loudest people in the room are the scanner marketing companies".
What do you think?
I agree with Arshan that scanner marketing is out of control in their statements about the technology. When one scanner salesperson called me around Christmas-time, 2006, I told him that the technology just wasn't mature enough. I said that I thought it might be by the end of 2007. Well, that time has come and gone, with really not too much more to show for technology improvements.
I was never a fan of these tools in the first place. I believe strongly in using them for verifying the results from automated and manual secure inspection. This precludes reliable exploitation or writing weaponized exploits (as much as I list w3af as a useful tool, I also do disagree in the approach and end goals). In other words, you don't need BeEF or AttackAPI to demonstrate or perform pivoting in the case of an XSS finding. I would rather spend more time looking for more vulnerabilities, refining techniques, and working on the root-cause of the problem -- which is always input validation and input/output encoding.
Part 1: Information assurance vulnerability assessment — Protective measures, file/disk encryption
Millions of records of sensitive or private information have been lost due to missing, stolen, or "borrowed" laptops, tape drives, disks, and other various data-containing hardware.
A search on Etiolated for "Stolen Laptop" claims that 7.5M records are involved over the past few years they've been tracking statistics. It appears to me that a lot of the reported incidents are due to this type of problem.
Yet, businesses do not have standard images on their laptops and other devices. As Vista sells more at the workplace, it is possible that this will change. Vista includes BitLocker, which is a full-disk encryption (FDE) implementation with varying results of success when implemented. Of course, getting access to revocation keys or private keys would make the implementations broken -- this at least makes it so that two things are needed instead of just one.
Any internal threat agent could theoretically copy data off any drive, assuming account access (or escalation of privilege). Again, this is less likely to happen as more than one step is involved. In the future, we'll be looking at other methods to further decrease the likelihood of this scenario occurring without solution prevention (or at least detection).
Recommendation: Hardware vendors that include software should have the default account already setup for FDE if the OS supports it. Hardening guides should be used to verify. If your company/organizations uses standard builds or images, then there are many solutions that can be used for partial or full-disk encryption.
OS vendors could also force FDE on install. This would be really nice.
For Linux laptops and servers, LUKS is the ideal solution. Many will prefer BitLocker on Windows laptops, and Server 2008 should have similar support. For those who haven't upgraded yet, commercial solutions exist -- although I prefer a thin client laptop such as SafeBook.Net.
While Mac OS X has FileVault (and the hardening guides usually recommend using it), you might want to take a look at TrueCrypt support for Mac OS X partial disk encryption.
TrueCrypt is also supported under Windows 2000/XP, although I prefer FreeOTFE. One of the reasons I prefer FreeOTFE is because it is also supported on Windows Mobile devices such as PDA's and PDA phones.
If you want more information on setting up full-disk encryption with LUKS, BitLocker, TrueCrypt, or FreeOTFE -- I suggest books such as Security Power Tools (Chapter 15, which also covers GPG and S/MIME), Windows Vista Annoyances, Ubuntu Hacks (Hack #70), and Network Security Hacks (2nd Edition, Hacks #39 and 33) from O'Reilly Press.
Part 2: Software assurance vulnerability assessment — Cross-site Request Forgeries
Best CSRF attack tools
OWASP CSRFTester, Chris Shiflett's CSRF Redirector, PDP/GNUCITIZEN's CSRF Redirector, CSRF dorks
CSRF can be tested with a variety of different tools. The presentation that goes along with the CSRFTester tool by Eric Sheridan of Aspect Security is an excellent guide. The CSRFTester is a simple Java-based tool.
Some CSRF redirector tools such as the ones by Chris Shiflett and pdp seem to work in similar ways, along for online testing, but be careful what gets logged to these sites! The CSRF dorks spawned out of the sla.ckers.org forums and Ronald picked it up to support a CSRF database project on his website.
My favorite thing about testing CSRF is looking at the level of defenses in use by a web application. Testing CSRF is so easy and simple compared to XSS or SQLi. If CSRF works with no active defenses -- you can also assume that XSS and SQLi are possible in a lot of cases. It clearly shows a sign of no forethought into security. This provides a rough measurement of a web application's security at ground zero.
When I say that CSRF has "levels of defenses" -- this is also a classic example of how "levels of defenses" can be used to measure web application security testing techniques and methods, including web application security scanners. Romain Gaucher has been giving talks about using "levels of defenses" to benchmark scanners. I saw his first presentation at Verify Conference, but recently he has updated his talk and given it at the HICSS conference in Hawaii. He includes a link to his slides in that linked blog post, as well as a link to NIST SAMATE, which has a focus group on web application security scanners.
blog comments powered by Disqus