PHP Code Scanners

PHP code scanners

Investigating source code for possible security flaws is an important part of a security assessment. Common source code flaws can include trusting untrustworthy input, allowing executable strings in data input, buffer overflows, timing flaws

There are code scanners for C, java and other common languages.

The growth in Web-based applications means that the focus of code flaws has shifted to common Web programming languages.

I've found two tools specifically designed for analyzing PHP code:

- PHP security scanner from http://securityscanner.lostfiles.de/

- Pixy from http://pixybox.seclab.tuwien.ac.at/pixy/

These tools can both provide some useful information, unfortunately both lack certain key functionality, and both look like fully-functioning prototypes that are no longer actively maintained.

The PHP Security Scanner tool requires that you install it under your Apache server's document root. It requires pre-existing MySQL service. In addition, two php modules, Smarty and Pear are required. Both should be installed in the same directory as the tool. Ideally, PHP Security Scanner would include these as part of the install process.

The PHP Security Scanner tool will automatically search for php source files, starting at a given document root. I like this feature - it allows reviewing an entire Web site in one execution. It also has the ability to force include or exclude of specific files via a black/white list filter. I did not review this feature (maybe in the future).

Flaws are found via a regex match - no parsing of PHP code is performed. It looks for "dangerous" operations with a variable (any variable) as an operand.

Results from PHP Security Scanner are displayed as a Web page. While very visually attractive, I question the sanity of displaying your Web server's vulnerabilities using that very same server. Advertising your vulnerabilities on a Web page is not very smart.

Some of the messages shown in the results are a bit generic. The regex patterns and the error messages are stored in a MySQL database, and thus are easily editable.

Pixy actually attempts to parse the PHP syntax, to determine the severity of a code flaw based on its role. Pixy attempts to track the flow of "tainted" (untrustworthy) values through the program using data flow analysis. A paper presented at the IEEE Security and Privacy conference describes the approach in more detail.

Pixy is written in Java, and specifically requires JRE 1.5 or more recent from Sun (it will NOT work with the Gnu version of Java). Installing Sun Java on my Ubuntu test system was more of a pain than I first realized.

The output from Pixy is plain text, not as visually stunning as the HTML from PHP Security Scanner. Interpreting the output seems challenging as well. I consider myself fairly well versed in security and had a tough time figuring out what the messages meant.

SANS loses it

I subscribe to SANS Newsbytes, one of the best mailing lists for security news around. Many of the news articles come with brief commentary by the editors, which usually adds value to the original articles.

I've noticed many recent articles about missing laptops (of course). This is a major security issue that requires a combination of technical and administrative countermeasures.

One measure I've seen SANS advocates indicates they have lost all sense of proportion, and any consideration of the secondary consequences of excessively severe policies. Yes, they are advocating that companies "make automatic termination the consequence of losing the laptop" (comment by Kreitner in May 8 2007 Newsbytes).

Knowing most organizations, I'm sure that terminating an otherwise diligent productive employee for a missing laptop will not faze them in the least. Losing a laptop is a likely consequence of carrying one. Given the nature of business travel, the difficulty of keeping a laptop in your possession at all times, and the determination of thieves, it is inevitable that the most diligent employee will find their laptop missing. Too bad - you lose your job. I assume termination would result that if the laptop were stolen from your vehicle or home as well.

Let's also look at the unintended consequences of such a policy. If my company had a policy of automatic termination for a missing laptop, I would keep my company laptop in a safe at home (after all, theft from autos is common) and use my personal laptop for my day-to-day work. The company asset would be protected, I would not be at risk from termination, and I could get my work done. If the laptop is stolen or lost, I pay the cost. The end consequence is that sensitive information is even less protected than before, because I no longer use a controlled company asset for my work. Other less severe work-arounds include employees using their personal PDAs for work, or just doing without a computer on some business travel. If you need to access email, well you can do that from a kiosk, right? And we all know how secure Webmail from a public kiosk can be.

The sad part about this poor advice from SANS is that many organizations will end up adopting this policy, based on SANS' reputation. They will find their overall security degraded as employees come up with creative ways to keep their laptops theft-free at the expense of greater information security goals.

There is a general point here as well. Severe, draconian punishments may discourage the santcioned behavior, but usually encourage other sorts of mis-behavior that are far worse.

NSA IAM/IEM

I'm moving along with the lecture notes for my class. I've got some more detail on the NIST FISMA criteria. It looks like a perfectly decent security standard on the surface. You start by categorizing your information systems, determine the security controls, document these controls, assess the effectiveness of the controls, lather, rinse and repeat. FISMA gets a lot of criticism, expecially on the SANS mailing list for being an ineffective paperwork drill. This may well be true, but if an agency has absolutely nothing in place, I imagine FISMA would at least provide a framework for future improvements.

I'm also looking at the NSA IAM/IEM process. I was certified in the IAM via SecurityHorizon. It is very puzzling that this process is so minimally documented in any public domain sites or documents. If you do a Google (tm) search on "NSA IAM" the first hits are all training organizations offering certification prep. A security certificaiton methodology so heavily endorsed by the premier Federal government security agency should at least have a standards document available.

I finally (after many months) received permission to reproduce the PCI documents in my course reader. Unfortunately the reader went to UCLA previously. There is no change of including the printed versions of the PCI standards at least this go-around.

If you are interested in my class, check out UCLA Extension's Web site. I wish they would allow deep linking to a single class, but I am not their Webmaster.

Books on Security Assessment

I'm building the course material for my upcoming UCLA Extension class on security assessment. After searching the reviews at Amazon, Slashdot articles, and archives of the pen test mailing list, I've come up with the following:

• Penetration Testing and Network Defense by Andrew Whitaker and Daniel Newman
• Hacking Exposed, 5th Edition by McClure, Scambray, and Kurtz
• Network Security Assessment, by Chris McNab
• Network Security AssessmentGuarding Your IT Infrastructure by Gregg and Kim
• A Practical Guide to Security Assessments by Sudhanshu Kairab

These are all good books and each would be an excellent addition to the library of an IT auditor, security analyst, or penetration tester.

Gregg and Kim's book is the best introduction to the subject. It gives an overview of the risk assessment process. It focuses on security essentials, then describes the components of a assessment methodology. It is really a management overview, a good text for an intro class or for an IT manager considering hiring an assessment consultant.

Sudhanshu Kairab's book goes into more detail on the business process behind performing an assessment. This is a more detailed methodology for a senior security analyst. The nuts and bolts of managing an assessment project are described, including hints on how to gather information via interviews and how to structure the final report. A good third of the book is appendices covering various security checklists that can guide an assessment project.

The remaining books provide a more in-depth look at technical aspects of security assessment. These include the techniques used in performing a penetration test. Their shelf life is much shorter than the process-based guides, as techniques for security analysis have a very short lifespan. New techniques are developed very quickly, and older vulnerabilites often die just a s quickly. A vulnerability testing tool only needs to be neglected for at most two years before it becomes useless.

Chris McNab's book is part of the O'Reilly family of technical publications. It is well written, easy to follow, and tends to focus on examining UNIX-like systems. Hacking Exposed is the latest of a long dynasty of books from the former E&Y guys. It is very detailed, with chapters on current topics like VoIP hacking, phishing, and browser client attacks. An older version I had (2nd) seemed to be rather Windows-centric in its choice of tools. This current version does not suffer from such an emphasis. Finally, Whitaker and Newman's book, published by Cisco Press, also has a good technical emphasis. It does not seem as up-to-date as Hacking Exposed v5, though becoming out-of-date is a hazard of the genre. Any technical "how to hack" book should be regarded as only a starting point. Once you have mastered the basics, the professional pen tester should attend conferences and use mailing lists such as the pen test list.

Blogger now part of Google empire

I had to set up a Google account to edit my blog. In the process, I found that almost every email account I have is associated with a pre-existing Google account. I have no record of what password I used in setting up this account, and no desire to maintain three unused Google account.

Google does not make it easy to delete accounts once they are set up. Their help page suggests going to a "contact Google" link that does not appear to exist.

I sent a fax right to Google requesting this. I will see if anything happens.

Unused accounts are the space debris of the Internet.

We've got mail

I received a very nice email from Peter Herzog on OSTTMM, letting me know that "the OSSTMM is taught at 14 universities in Europe and 1 in Hong Kong". This approach definitely has its fans. I was sent a copy of version 3 of the OSTTM to distribute to the class. I'll incorporate it into the section on pen testing as I work out the class material.

A new class at UCLA Extension

I've "volunteered" to take on a new class at UCLA Extension. It will be titled "Security Vulnerability Assessment" or something like that. I'm going to teach it over 2 consecutive weekends (fri/sat two weeks in a row) sometime in Spring (mid-April most likely).

Here is my outline so far:

• Overview of information security, including the basic threat model, types of vulnerability, technical security architecture and principles of security management.
• Discussion of the types of security assessment that may be conducted, including general controls audits, technical audits, vulnerability scans, and penetration tests.
• Standards for vulnerability assessment, including AICPA/PCAOB, NIST SP 800-30 and related docs, NSA IAM/IEM, and Payment Card Industry (PCI) standards. I MAY talk a bit about HIPAA. I'm not sure if I should do the OSSTMM. Does anyone actually use OSSTMM aside from the folks who wrote it?
• Some specific review items for most common technical platforms, meaning how to review Windows serves, Linux servers, and overall network security.
• Demonstration of network security tools such as nmap, Nessus and the like.

I'll have a course reader with the slides as well as public domain material. I'll include relevant NIST documents and maybe FFIEC audit programs. I hope to get permission to use PCI documents. I really wish the NSA IAM had public domain documentation. I wish the Web site wasn't broken. It seems the Feds outsource this to training firms, who make a good business cranking out these certs.

I've tried finding similar courses offered elsewhere, but with little luck. Most of the "learn to hack" classes are proprietary, with no description other than the bare minimum. They tend to be entirely tool oriented as well. Classes on IT auditing only cover, well, IT auditing. Classes that touch on security assessment tend to do so as a small subtopic of a bigger intro to security class.