Day 4: ITSM Vulnerability Assessment techniques
Lesson 4: We've touched on some of the critical-path ways to assess and protect your infrastructure including network segmentation and OS/application sandboxing. Often, the weakest area of technology is what you can't segment or sandbox effectively, which today is why we will be covering web applications.
Part 1: Information assurance vulnerability assessment — Web applications
With all the various web applications across any given infrastructure, it's difficult to know where to start. Consolidation of web servers isn't an easy task -- the thought there is that somehow you could put all of your web applications behind a giant web application firewall such as mod-security in reverse proxy mode.
The questions arise, which is more helpful to balance the risk of our web applications -- web application firewalls, enforcing use of secure frameworks / secure configurations, or secure inspection? Is it some combination of the three? Is there a one-size-fits-all solution?
Of the above, the most secure are likely Static HTML, Java/JSP, and ASP.NET 2.0. PHP and Classic ASP require quite a lot of work to secure, so it may be best to concentrate on these technologies first, in addition to watching out for Flash, JS, and Ajax gotchas.
Recommendation: Install Hardened-PHP wherever possible, and front your PHP applications with CORE GRASP and PHP-IDS. Move applications that require medium or high assurance to a framework such as HDIV, which requires JEE developers (however, can be used with SpringMVC, Struts2, or Struts1 -- in my order of preference). Utilize Anti-XSS libraries to bring all legacy .NET and Java code up to par if HDIV or the latest .NET frameworks cannot be used.
You'll detect a repeatable pattern here when I give a recommendation of how to begin the secure inspection of any application. Start with bytecode or binary analysis and then determine where the applications are most weak. In the case of Classic ASP, utilize tools such as OWASP DN_BOFinder. Java/JEE bytecode-testing is best handled with FindBugs. .NET applications can be tested with FxCop and dotnetids. Bytecodes and binaries can be sent to Veracode for further inspection.
PHP applications usually have source code available, especially since most are of the open-source, off-the-shelf variety. I recently read an excellent post on using PSA3 (one of the best open-source web application tools available) and PHPSecAudit to identify web application vulnerabilities in PHP source code. Beyond these tools, also take a look at the Php Fuzzing Framework (PFF) -- and make your custom functions stand the test under the stress of the PHP interpreter. Commercial scanners such as Chorizo-Scanner also include advanced server-side testing with the Morcilla PHP extension, although you might learn more using CORE GRASP and PHP-IDS during a dynamic/hybrid assessment.
Also be sure to keep an eye on configuration files. Bryan Sullivan has written a few great articles on securing configuration of web applications in a part one and two of a series, in addition to earlier work on.NET configuration files. There is more information available on secure web application configurations in the "Web Application Hacker's Handbook", the "Developers Guide to Web Application Security", and the latest Apache Cookbook, 2nd Edition.
Part 2: Software assurance vulnerability assessment — SQL Injection
I was going to make today's part two lesson about XSS, but decided to change it to SQLi when I saw that 70k websites were owned via an automated botnet attack in the past two days.
Best SQL injection attack tools
SQL Inject-Me, SQL Power Injection Firefox Plugin, sqlmap, sqlninja, SQL Brute, sts-scanner, w3af, Wapiti, HttpBee, OWASP SQLiX, SQL Power Injector standalone, MSSQLScan, Paros, Burp Suite, OWASP WebScarab, ISR-sqlget, Scully, FG-Injector, PRIAMOS, Grabber, Bobcat, Watchfire Exploiter, Syhunt Sandcat, gunzip webfuzzer, mieliekoek.pl, wpoison
Best SQL injection attack helper tools Absinthe, squeeza, SQL Hooker, HackBar, PMD SQL Injection Rules, SQL injection cheat sheets, ExtendedScanner, AppPrint, AppCodeScan, FindBugs, FxCop, RATS, SWAAT, Pixy, Milk, PSA3, PFF, PHPSecAudit, Inspekt, PHP-SAT, Orizon, LAPSE, PQL, SPIKEproxy, ASP-Auditor, PHP-IDS, dotnetids, CORE GRASP, Mod-Security
If you want to check out these tools in order, that is the preferred way to learning. There are quite a lot of tools mentioned here, and quite a lot utilize very different testing methods. Some testing tools such as HttpBee can be distributed, while many others are command line tools. My favorite black-box tools are usually the browser-based tools such as sqlime, sqlpowerinjector.xpi, and HackBar -- but there are many good command line tools such as sqlmap and sqlninja.
More often than not, securing the database and access controls are just as important as making sure that all source code uses parameterized queries if you want to prevent these kinds of attacks. Using declarative controls along with an RBAC system can lower the attack surface. Making sure that command shells and out-of-band channels (RDBMS use of DNS, SNMP, et al) are locked-down should also be top-priority.
I've worked with developers who think that they don't need to use parameterized queries on internal infrastructure. However, because of Web services (SOAP, RPC) and second-order injection (plus other ways to get closer/inside the database) -- it should be realized that all queries need to use prepared statements. Packages such as DBMS_ASSERT from Oracle and Mod-Security from Breach claim protection against SQLi -- however, they are not panaceas and should be checked for what they do and don't protect against.blog comments powered by Disqus