Category Archives: Attack Types


SSL Poodle Check Added to NTOSpider

This week’s “big hack” everyone is yapping about is the POODLE flaw in Secure Socket Layer (SSL 3.0). The hack is a bad one, when the attacker can get man-in-the-middle to set it up, but the need for MitM does limit the scope of this exploit.

Adding the check for POODLE’s downgrade flag to our NTOSpider scanner was trivial as we already perform SSL Strength Analysis, but the real challenge is how to score this. Quite frankly just allowing SSL 3.0 is inherently bad, and POODLE just makes it worse. I can see an argument for making it high risk to have SSL 3.0 enabled, but then does POODLE make it “Super-High”?

As with my recent post about the 8 lessons learned from Shellshock, I encourage caution with this weekly hype cycle for each new “big hack.” It’s reminiscent of “The Boy Who Cried Wolf” – we’ll see how that will turn out for us.


NTOSpider 6.4 Now Available!

We are excited to announce a host of enhancements to NTOSpider that will further assist you in testing more of your applications in less time. Our mission is and has always been to create the most automated and accurate assessment possible even on the most modern applications. And, in this release, we further expand NTOSpider’s ability to effectively test modern web and mobile applications.

The following are some of the highlights of NTOSpider 6.4:

  • Web service authentication to further automate testing of web services and mobile applications.
  • Automatic update tool to enable users to automatically download new versions of NTOSpider.
  • Crawler improvements to further expand coverage of Web 2.0 applications and improved performance on very large sites.
  • Added and improved attack modules to include additional vulnerabilities in automated coverage, including Shellshock or BASH Bug.
  • Improved UI features including user defined attack policies and macro debugging.

New and Enhanced Features

  • Web Service Authentication – Expanded ability to test web services with the ability to handle the authentication and session management solutions used by many web services. Including: comprehensive OAuth, HMAC, integrated NONCE support and user defined solutions.
  • Improved Web 2.0/3.0 and HTML5 crawling – Improved automated crawling of heavy Javascript (AJAX) web sites and popular frameworks such as jQuery.
  • Enhanced performance – Performance improvements include increased scan speed and reduced memory consumption especially for very large sites.
  • Auto-updater – NTOSpider finally has a configurable automatic update mechanism that enables users to choose between three options that give the user flexibility and control over upgrades.
  • User Defined Attack Policy – Simplifies selections of attacks.
  • Macro debugger – UI feature to help user replay and debug MACRO recordings.
  • Attack modules – The following attack modules have been added or improved.
    • Shellshock (aka The BASH Bug)
    • CORS (Cross-Origin Resource Sharing)
    • XPath Injections
    • LDAP Injection
    • XML External Entity
    • Server Side Include (SSI) Injection
    • Expression Language Injection
    • ASP.NET ViewState Validation

For complete details review the release notes.

For more information or to request a free trial of NTOSpider visit:


Shellshock Bash Bug – 8 Important Lessons

While Shellshock has been all over Twitter and talked about on prominent news outlets, I’m still shocked that there is comparatively less press coverage than there was for Heartbleed which was a bonafide “big story.” This is unfortunate because in some ways the Shellshock exploit is more devastating, but there are actually some good reasons for the lesser coverage, and all of them are things we should learn from.

1. Name Game Confusion
Some call it Shellshock, or the Shellshock Bug, some call it the “BASH Bug” and sadly, some in the Heartbleedpress call it the “Bug known as BASH” (see video []). Heartbleed was a cool name, and even had a cool logo that was able to capture the imagination very quickly. Maybe we need to make sure we pick cool names and create cool logos before we alert the media of a major new vulnerability.

2. Explanation of the Threat
When dealing with Heartbleed it was easy to explain that the exploit allowed an attacker to extract unencrypted information. With Shellshock, I have seen people trying to explain the exploit in terms that are meaningless to normal people.

Reporter: “The BASH Bug gives an attacker shell access to a system”
Audience: “Oh, interesting. What’s for dinner?”

We need to use simple terms anyone can understand.

Reporter: “Shellshock gives an attacker remote control of a system”
Audience: “Oh, $#@! get my IT guy on the phone!”

We are wasting our time trying to explain what BASH is or what a shell is. Come on people!

Know your audience, and speak at their level. @Lifehacker does a good job of this!

3. The Boy Who Cried Wolf
We (the security community) made such fuss about Heartbleed and we basically told the world that the internet was on fire. The problem was that most of the internet was patched within a week or two and life went on as normal. The fire was well contained by the awareness campaign which is a good thing. But we had gone a little overboard and wasted our goodwill with the press.

4. Overstatement of the Threat
Let me start by saying, that when exploited, Shellshock is bad bad news. A Shellshock exploit is worse than a Heartbleed exploit because it’s not only allowing data to be leaked, but also allows remote control of a server and could allow an attacker to make a trusted site become evil.

I see statements out there saying that 70% or even 90% of internet connected systems are vulnerable to Shellshock and that it is much worse than Heartbleed. While there may be some truth to that, and a high percentage of internet servers are indeed “vulnerable” we need to break that down a little because a very small percentage are exploitable.

5. Vulnerable Does Not Mean Exploitable
A server might have this BASH bug which can be tested on the system with a simple test command. However, to exploit this, you need to have a service open that calls BASH. The problem is that most service ports are blocked by firewalls. In most cases, there are only a few ports open to the internet that could be vulnerable, such as DNS, DHCP, SMTP/IMAP/POP3 and HTTP/HTTPS. I have seen some exploitable examples of DNS and DHCP services that shell out to BASH scripts to handle IP assignments based on user, as well as some SMTP that shell out to SPAM filtering tools. I’m sure there are many more, but these are examples and they are limited. Jose Pagliery from CNN Money explains it quite well – the world isn’t on fire, but there is a serious problem in this video.

6. What About Web Servers?
Of course this is one of the big questions because web servers are much more widely exposed to the ShellshockBASH bug. In many cases, the only ports a server will expose to the internet are 80/443 which are the HTTP/HTTPS ports. There are situations where a web server has CGI support enabled, even though it has not been the default configuration for quite some time. But if it is, then it is possible that it might have a CGI script that executes BASH. This could happen, but it’s fairly rare these days because most CGI scripts I see are written in languages such as PERL and are not exploitable with ShellShock. So, if all the moons have aligned so far and there is a BASH CGI script in use, the admins can disable the script or patch the system to remove the vulnerability.

So lets go back to the claims that 70-90% of the internet connected servers are “vulnerable”. From that we subtract the ones that have no ports open to the internet. We then remove the ones that only expose services that are not exploitable because they don’t shell out for any reason. In the end, I think we end up with a much smaller percentage, lets say 5%-10% of the servers on the internet that are vulnerable to the Bash Bug are actually exploitable.

7. Remains A Very Serious Security Issue
Even if only 5% of the servers on the internet are exploitable that still constitutes a very serious problem. It may not get as many headlines as saying 70-90% are vulnerable, but it is more accurate and helps to maintain our credibility to the wider public.

Keep in mind, that 5% of the servers on the internet being exploitable is still a VERY LARGE number of servers, and from those exploitable systems, an attacker could then attack other servers and services not exposed directly to the internet.

8. Shellshock’s Lasting Impact
I want to state once again that I strongly feel like this BASH bug is very serious, which is why I have been disappointed by the coverage about it. I also think it will be with us for a long time, because unlike the big servers powering the internet, which will get patched, many appliance type devices will never get patched such as common home WiFi & router devices, and IP enabled devices that fall into the “Internet of Things” category.

We did a great job during Heartbleed, and I believe the publicity actually helped mitigate the threat because every IT person was made aware and systems were patched quickly. It also served as something like a shark alert at the beach and many people stayed away for a few days while “the internet got fixed.”

Shellshock has not been handled as well, and I think systems that could easily be patched won’t, because we failed in the awareness campaign. I have run into many people and friends in the IT space that had not heard about it as recently as last night!

I hope we do better next time.


The Bash Bug, In a Nut-Shellshock

As you probably know by now, a bug, named Shellshock or “The Bash Bug” has been discovered in a version of Bash, which is a command shell tool. The bug leaves millions of websites and computers open to attack. The bug can be executed in just a few lines of code and enables Hackers to use the command shell remotely to execute malicious injections without admin privileges into vulnerable sites, possibly bringing them down or worse.

The bug is documented as CVE-2014-6271 and CVE-2014-7169.

Some say the damage potential for this bug is so massive, it’s being compared to Heartbleed – and, it may even be more pervasive than Heartbleed. But, others say that its been around for a long time and the damage will be minimal. Security insiders are tweeting all sorts of sarcastic comments and jokes about the bug while some publications warn of gloom and doom. While the damage will remain to be seen, it’s fairly safe to say that this bug is keeping security professionals and developers busy.

Everyone's missing the CIA link here. BASH =. Bourne Again SHell, named after Jason Bourne of the Treadstone Project. It's a CIA backdoor.

Man, is it just me, or does the Internet feel like a monumental shit show lately? Ugh

Anyone heard any good puns with the word "bash" lately?

Technically, no one is safe from Shellshock, it exposes everyone from home users to global corporations. Both Rapid7 and NIST vulnerability database score this vuln a 10 out of 10 and unfortunately its pretty easy to execute. Experts are urging IT professionals to patch their version of Bash ASAP, but keep in mind that there isn’t one solution. IT security experts and developers will need to issue patches for their individual solutions (ex. Apple, RedHat, etc.). For example:

  • Linux vendor RedHat has issued ModSecuritiy rules that block the Bash bug, but warns that the patch is not complete.
  • Security researchers are worried about the bu’s potential impact on Apple Mac computers, which uses the Bash software which the bug exploits directly in the form of its command-line program Terminal. Fortunately, patches are available, but Apple users will need to get their hands dirty until a fix is issued.

Shellshock is a mistake in the code of Bash, which is typically installed on non-Windows operating systems such as Mac, Unix and Linux. The bug enables hackers to send commands to a computer remotely and without having admin privileges. The recent vulnerability was discovered by Akamai security researcher, Stephane Chazelas. This Akamai advisory also explains the problem and this OSS-Sec mailing list post has a good explanation as well..

IT security professionals can find code to exploit the Bash bug using CGI scripts to execute code with the same privileges as the web server. The bug can be triggered on a vulnerable system with a simple Wget fetch.

To check if you’re systems are vulnerable, execute the following lines of code in your default shell, which will often be Bash.

env X=”() { :;} ; echo busted” /bin/sh -c “echo completed”
env X=”() { :;} ; echo busted” `which bash` -c “echo completed”

You’ll know you are at risk if you see the word, “busted.” If you don’t see the word “busted,”  then your version of Bash is fixed or your shell is using a different  interpreter.

Users at home should avoid using credit cards or disclosing personal information on-line for the next few days. In addition, its a good idea to update anti-virus software and avoid sketchy websites.

In Jim Reavis’ Cloud Security Alliance blog post, he explains that many large programs on Linux and other UNIX systems use Bash to define environmental variables which are then used while executing other programs.

For more helpful information on the Shellshock bug, check out the following:

iphone image

Mobile Application Security 101

Mobile Applications – Still Insecure

Businesses are racing to meet the demands for mobile applications, yet mobile application security is an afterthought, just as web application security was when web applications started to proliferate.

As an industry, we know so much about securing web applications that applies to mobile, but most organizations are still repeating past mistakes and making new mobile specific mistakes that expose businesses to security incidents.

According to a recent Gartner report, “Most enterprises are inexperienced in mobile application security.  Security testing, if conducted at all, is often done casually — not rigorously — by developers who are mostly concerned with the functionality of applications, not their security.[1]” In this same report, the firm indicates that “through 2015, more than 75% of mobile applications will fail basic security tests.[2]


Don’t Forget Mobile Web Services

There has been so much talk about mobile device and mobile client security, but the key thing to keep in mind when approaching mobile application security is that it’s critical to test both the client as well as the communication to the web service that powers it. For example, if you’re using your Twitter app, the primary logic that resides on the mobile client is display and user authentication. The app must then communicate to a web service in order to get and send Tweets. This web service is the real power of Twitter and where the real security risk lies. Why attack one user, when you can attack that web service that is used by millions?

Even though mobile applications leverage a client-server model, they are built with entirely new technologies that necessitate new processes, technologies and skills.  While mobile application security does drive these new requirements, the overall problem is one that the security industry is already well acquainted with because the vulnerabilities showing up in mobile applications aren’t new at all. We often say that we are “Hacking like it’s 1999” because, the reality is that mobile vulnerabilities are are just the same old vulnerabilities that we have been hunting for over 13 years now: SQL injection, overflow, and client attacks.

These new requirements for mobile testing are driven by the new programming languages used for building mobile clients (Objective-C and Android’s Java variant), the new formats used by back-end web services (JSON and REST) and the new authentication and session management options (OAuth, HMAC, etc). And while those familiar SQL Injection attacks look almost exactly like they did 10 ago, you just can’t find them without understanding how to deliver these attacks within the new structures.

iphone image

SQL Injection Alive and Well

We call the mobile vulns the Where’s Waldo of application security. They’re your old familiar friend, SQL Injection, who looks almost exactly like he did 10 years before – maybe with a few gray hairs – but you just can’t find him as easily because he’s in an all new environment. We simply need to adjust to this new landscape and start looking for our old friend again.

Another important thing to keep in mind about mobile application security testing is that there ARE tools that automate the process. There just aren’t that many of them that automate the entire process or do it very well.

We see several categories of security vulnerabilities in mobile applications:

More on Mobile Application Security


[1] [2]Gartner Research Document

Gartner, Technology Overview: Mobile Application Security Testing for BYOD Strategies, By Joseph Feiman and Dionisio Zumerle, August 30, 2013.


Mobile application security testing – fast and easy!

Mobile-App-SecMobile application security testing: Four words that, for many security professionals, elicit a nagging feeling that comes from knowing the challenge is imminent if not already present, yet very difficult to tackle.

We at NT OBJECTives understand, and we’ve got your back. Our newest service offering is designed to help busy security teams easily and thoroughly test mobile applications – without intensive training or resource drain.

NTOMobile On-Demand gives NTOSpider customers everything they need to quickly security test mobile applications, including mobile client native code and back-end web services. No need to choose between testing the source code, testing the services or pen testing the mobile app. NTOMobile On-Demand does it all with a comprehensive software solution combined with expert pen testing.

Comprehensive mobile application testing requires both static and dynamic analysis, so we’ve packaged them together, along with expert pen testing, to deliver comprehensive mobile application security testing. By leveraging the power of NTOSpider’s dynamic application security testing capabilities, NTOMobile On-Demand effectively and automatically tests the web services that power mobile back ends and that leverage new technologies like REST, JSON and SOAP. You won’t find another web application security testing solution that delivers better coverage of your custom web service implementations.

Mobile application security testing is a challenge for security teams that don’t have the time or resources to invest in effective training and tools. NTOMobile On-Demand enables security teams to conduct comprehensive mobile application security testing – and obtain the peace of mind that comes from doing what needs to be done.

New Technologies in WebApp Sec

Webcast: SQLInjection Vulnerabilities Hidden in New Places

Why are your applications still suffering from SQL Injection Vulnerabilities?

Even though we know so much about SQL Injection, we have a perfect storm brewing for serious security problems in many modern applications. The perfect storm is brewing because the younger generation of developers who are building these new applications in technologies like JSON, REST, SOAP and AJAX aren’t experienced in security and the security professionals who need to test them aren’t experienced in these formats.


To make matters worse, business managers are under pressure to get these applications out quickly which often results in inadequate security testing. And then we have the scanners. Most scanners were built to scan classic HTML based apps.

Please join me next week on Wednesday, October 16th as I share what I have learned after two years of testing “modern applications.” such as mobile, RIA’s and web services. I will demonstrate that they are susceptible to all the same SQL Injection mistakes of the past.

This webcast is designed for both developers and security professionals who want to learn more about how SQLInjection and other vulnerabilities hide in these modern formats. I will go through each format, review how to understand it and how to find vulnerabilities in it. Finally, I will discuss how to scale testing on these kinds of applications in an automated way.

Join me for this webcast to learn

  • Why SQL Injection is so prevalent in these technologies despite the fact that we have understood SQL Injection for so long.
  • How to understand these newer formats (JSON, REST, SOAP) and find SQL Injection vulnerabilities in nine technologies commonly used in these applications.
  • How you can scale your testing to automatically find these vulnerabilities.

Finally, we’ll discuss how you can scale your testing with automation to automatically find these vulnerabilities.

See more at:

Yahoo Fantasy Football

Mobile Application Security: Think Twice Before Placing Football Bets

Have you heard about the vulnerability in the Yahoo! Fantasy Football app? If Knowshon Moreno’s performance on Monday against the Oakland Raiders got you down, you might want to read this warning to fantasy football players: Don’t place any bets this season until you update your Yahoo! Fantasy Football mobile app. A hacker could be manipulating your lineups, putting injured or poor performing players in the weekly lineup while benching top-seeded players on your team – essentially stacking the odds against you.

Oakland Raiders v Denver Broncos

During vulnerability testing we found that a previous version of the Yahoo! Fantasy Football mobile app is vulnerable to session hijacking (video) – the process of authenticating the user and ensuring an attacker isn’t impersonating a user or eavesdropping on a service. The vulnerability allows an attacker to impersonate another player on message boards and manipulate other players’ lineups.

We acknowledge that at least in this case the vulnerability is relatively benign, you can lose your bet of course, but its not the end of the world. However, it is indicative of a larger problem: the general lack of attention paid to security during development and testing. Some of the most common security mistakes made during mobile web app development are related to session management. In most cases, a single vulnerability isn’t a significant liability, but the more mistakes developers make, the easier it is to attack the app. This is the case with Yahoo’s fantasy football application.

It is also concerning that the application went public without proper security testing – which would have uncovered the vulnerability. Oftentimes organizations are in a hurry to deliver mobile apps and sacrifice security as a result.

Finally, as a user of mobile apps, it is worth noting that failing to update your mobile apps in a timely manner puts you at unnecessary risk when vulnerabilities have been fixed in later versions.


Four Reasons Security Teams Can’t Stop SQL Injection Vulnerabilities

SQL injection vulnerabilities have threatened application security for years. So why are they still quite common, despite the fact that we, as an industry, should know how to prevent them? Clearly, if eradicating the vulnerability was contingent on understanding how to implement a technical fix, we would’ve done so by now. But the problem is much bigger than that, and it requires a deeper look into web application security testing as a whole. Below, we’ve listed some of the factors that come into play from the security team’s point of view.


  • A lack of resources: Security organizations run lean and mean these days. They simply don’t have the staff, time or technology to dedicate to fixing every vulnerability. Plus, when resources are tight, it can be tempting to take shortcuts, which can easily decrease the level of application security altogether.

  • Not enough time in the day: Security teams are in a race against hackers to find SQL injection vulnerabilities, prioritize them according to severity and remediate them – not for just one, but for hundreds of applications.

  • Humans are fallible: Pen testers are the experts at finding SQL injection vulnerabilities, and they must employ a combination of automated and manual tests. Using one at the expense of the other or using rudimentary technology can leave some vulnerabilities undetected.

  • Lack of control: Because security teams have little control over developers, they often have little influence over development training, policies and coding practices.

It’s evident that security teams have their work cut out for them when it comes to providing effective application security against SQL injection vulnerabilities. Fortunately, they don’t have to face the challenge alone. Together, security specialists and developers should work as a team to prevent future vulnerabilities and eradicate any current ones. Unfortunately, developers do face a host of challenges of their own.

Prevent SQL Innjection Using Parametrized queries

Eight Reasons Why SQL Injection Vulnerabilities Still Exist: A Developer’s Perspective

Knowing how to prevent a SQL injection vulnerability is only half the web application security battle. A multitude of factors come into play when it comes to writing secure code, many of which are out of the developers’ direct control. That’s why common vulnerabilities like SQL injection continue to plague today’s applications, and why application security testing software is so important. These problems can be overcome – with a little insight, organizations can begin to address these challenges directly and better enable developers to remediate SQL injection. Here are the top eight reasons SQL injection vulnerabilities are still rampant:

Prevent SQL Innjection Using Parametrized queries

  • SQL itself is vulnerable. SQL is designed to allow people access to information and is therefore inherently vulnerable, so every developer must know how to prevent SQL injection – not just one or two individuals on your development team.

  • The price of agnosticism. SQL is agnostic, meaning it works across database platforms. The upside to this is that it allows code to be database-server agnostic. But it is also the source of the problem. To prevent most vulnerabilities, developers should use parameterized SQL or stored procedures specific to the database server.

  • One mistake is all it takes. If just one vulnerability is left unsecured, a hacker can have his way. Every single input must be protected. Unfortunately, this is a tall order for any development team, as there can be tens of thousands of potential vulnerabilities on a single website.

  • Inexperienced developers lack training on old vulnerabilities. New generations of developers do not always receive the training and mentoring necessary to understand how to prevent common application vulnerabilities. They must be taught how to prevent exposing SQL injection vulnerabilities by creating comprehensive validation logic on every parameter or input.

  • Seasoned developers lack training on new technologies. Many veteran developers are using new formats and technologies to develop new types of applications. They must understand that SQL injection should still be considered for every input. For example, the application inputs from a mobile interface written in JSON that access the backend database can be as vulnerable to SQL injection as any input on an end-user page.

  • It’s not a priority. Many organizations do not consider fixing web application security vulnerabilities to be as important as they should. As a result, developers are generally more concerned with building new features and fixing bugs that impact user functionality.

  • It requires team effort. In order to eradicate SQL injection vulnerabilities, development and web application security teams must collaborate. Developers need security specialists to keep them informed of new hacking techniques, and security teams need developers to eliminate vulnerabilities.

  • Abandoned legacy applications. With the original application developers retired and the source code difficult to locate, vulnerabilities in legacy applications can be difficult or impossible to patch.

As you can see, educating developers on how to prevent SQL injection vulnerabilities won’t completely solve the problem. Organizations must enable developers to build secure code and make web application security testing a priority. Security teams have their perspective as well. Check out this blog to see the Four Reasons Security Teams Can’t Stop SQLInjection.