Posted: October 23rd, 2014 | Filed under: Web and Application Security
What Errors Are
Error messages are a fairly standard part of the web that can provide useful information to developers to resolve issues or indicate to users that there is something wrong with a page. While smart developers and site admins will customize error messages to hide sensitive info, sometimes something as simple as a careless change to a configuration file can expose verbose HTTP errors – including 500-level errors that can contain normally-hidden details of your application. While this is okay for your developers to see – in order to resolve the error – these are not okay for external users to see.
Scenarios in Which You Might See an Error
Of course, errors are not desirable. Errors are more like the ugly blemish that haunt every app at some point and some are more serious than others. Detailed errors can provide contextual information pertaining to things like the server’s directory structure, the SQL queries being run, or the modules and libraries loaded by the application framework. By generating an error response, a hacker now has context for what creates a particular error state and also gains a little bit of extra knowledge about the site.
Why is This Useful?
Even seemingly unimportant or small bits of information can be very useful. With enough time and patience a hacker can use the initial leakage of information to probe further. Based on the knowledge gained from the initial error, they can dig deeper to see what other errors they can elicit. Much like a detective following a lead from a piece of evidence, a hacker can follow the knowledge gained from a piece of information to it’s conclusion. In all likelihood, they’ll come across another valuable piece of information via an error (if errors are completely unsuppressed) which will lead them down another path to explore and investigate. All this probing really puts a site at risk, as it increases the chances that a vulnerable piece of software (plugin, library, framework, etc.) is discovered. If a hacker can pinpoint that you’re using version A of X library with Y known vulnerability, then there is a very clear path to exploitation and causing serious damage.
Recon for Attack – Just like Real War
“Know your enemy” wrote Sun Tzu in the Art of War, and most would agree that it’s unwise to launch an attack on a target without doing some reconnaissance to find points of weakness and points of strength. This principle applies to web technologies as well. Hackers can use error messages to probe and determine areas of weakness within their target. Giving hackers the ability to create errors without penalty is incredibly valuable as it gives them free reign to scout your site and gear up for attack. If areas of weakness or vulnerability are found during the scouting process, then the site can be added to a list of vulnerable sites, which then can be attacked by others in the community. If finding errors is the first line of attack, then hiding those errors should be the first line of defense. By preventing hackers from gathering accurate information about your site or app, you keep them from gaining an upper hand. Suppressing error messages is part of anti-reconnaissance and a solid defense-in-depth strategy.
An Internal Conflict
On the surface, detailed error messages can be useful for developers to debug issues. In fact, in many cases developers like these messages as it makes their jobs easier. Detailed messages often point right to the source of a problem, even indicating which line of code or which method is problematic and in which file. Just as this little snippet of information is invaluable to a developer doing some debugging, this information is useful to a hacker who is trying to cause trouble. Quickly, we can begin to see a conflict arising between a developer and a security professional:
- Dev wants detailed error messages in the app because this makes his/her life easier
- IT wants non-detailed error messages because this makes his/her life easier – and it protects the company
- Without detailed error messages, dev’s job becomes more difficult, and more time/company money is spent debugging code
While the sysadmin-developer divide is nothing new, this is a sensitive area because security is coming into play. That means that security should take precedence, but it doesn’t mean that developers’ jobs need be made more difficult.
Some interesting articles involving information leakage
Five Data Leak Nightmare OWASP on Information Leakage What is information leakage?
Solution with ServerDefender VP
Luckily, this type of recon can be prevented and developers jobs don’t need to be made more difficult. Here at Port80, we spent a lot of time thinking of the best way keep verbose error details out of the hands of hackers. The solution we came up with is very simple: don’t show verbose error messages. Over the last few years we’ve developed a complete web application firewall called ServerDefender VP that offers the ability to handle errors. We developed methods to handle errors in two ways:
- Spot and prevent verbose 500 HTTP errors from being outwardly displayed
- Mask all errors with a generic error message, so all errors will look the same to would-be hackers
We also included the ability to whitelist IP addresses. This means that if a developer needs to debug something, the sysadmin can add their IP to a list of excluded IPs. This tells ServerDefender VP to let those IP addresses bypass the error handling controls, therefore allowing users to browse the site without error messages being suppressed.
How does it work?
These capabilities are default features in ServerDefender VP and are powerful ways to prevent reconnaissance. Here’s what happens when ServerDefender VP encounters a 5xx HTTP error:
- User browses to a page
- An HTTP error is caused and generated
- ServerDefender VP catches the response before it’s posted
- Instead of showing the HTTP error status code, SDVP sends a generic error response. This can be not only a page that discloses no sensitive data, but even a response code that is normalized so that nothing can be inferred from it (e.g., 404 instead of 500).
- The end user now knows something went wrong, and can even be shown a helpful site-customized experience to get them back on track, but not specifically what
This error message can be customized to be anything, but most importantly it ensures that no valuable reconnaissance information is leaked; the error is suppressed by ServerDefender VP and never sent to the client. This error handling technique takes away the first line of attack and means that hackers won’t be able to find clues that make it easier for them to hack you. We’ll leave you with one more piece of advice from Sun-Tzu, that sums up SDVP’s attitude toward data-hugry hackers: “Be extremely mysterious..thereby you can be the director of the opponent’s fate.
No Comments »
Posted: October 17th, 2014 | Filed under: IIS & HTTP
from our friends at Net-Square
A Vulnerability known as POODLE, an acronym for Padding Oracle On Downgraded Legacy Encryption, is making headlines this week. The bug is a vulnerability in the design of SSL version 3.0, which is more than 15 years. However, SSL 3.0 is still widely supported, and nearly 97% of SSL servers are likely to be vulnerable to the bug, according to an October Netcraft Survey.
This vulnerability allows an attacker to intercept plaintext data from secure connections. Since SSLv3 has been quiet famous in the last 15 years it has put literally millions of browsers in jeopardy. As the chart above indicates, this is a vulnerability that has a sweeping impact.
How it happens?
Though users are upgrading to latest SSL versions (TLS 1.0, 1.1, 1.2), many TLS versions are backward compatible with SSL 3.0, hence when web browsers fail at connecting on these newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they may fall back to the older SSL 3.0 connection for a smooth user experience.
The other possibility is, a user is forced to step down to SSL 3.0. If an attacker has successfully performed a Man In The Middle attack MITM and causes connection failures, including the failure of TLS 1.0/1.1/1.2 connections. They can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. Due to this down shift of the protocol the connection becomes vulnerable to the attack, eventually exploiting and intercepting user’s private data.
Google’s Bodo Möller, Thai Duong, and Krzysztof Kotowicz published the complete security advisory which can be found on openssl.org.
To avoid falling prey to attackers exploiting POODLE, avoiding the use of public Wi-Fi hotspots, if user is sending valuable information (using online banking, accessing social networks via a browser, etc.), and noting this is always a risk, but the Poodle vulnerability makes it even more dangerous.
The other recommendation is disabling SSL v3 and all previous versions of the protocol in your browser settings and also on the server side will completely avoid it. SSL v3 is 15 years old now and has been superseded by the more up-to-date and widely supported TSL protocol, supported by most modern web browsers.
DigitCert published a detailed step-by-step guide for disabling SSL 3.0.
Richard Burte also shared the command lines to disable SSL 3.0 on GitHub.
No Comments »
Posted: October 14th, 2014 | Filed under: IIS & HTTP, Web and Application Security
A Russian espionage group is exploiting a zero-day vulnerability in Windows Server 2008 and 2012, iSIGHT Partners reported on Tuesday. Microsoft is currently working on a patch for the vulnerability (CVE-2014-4114), but a number of targets have already been hit.
When exploited, this vulnerability allows an attacker to remotely execute arbitrary code, but requires a specially crafted file and use of social engineering to convince a user to open the file. iSIGHT noted specifically that PowerPoint files were used to exploit the vulnerability.
While there are specific targets that have been named, iSIGHT is also quick to point out that the visibility of the attack is limited and there is potential for broader targeting beyond this group of targets. The known targets include:
- Ukranian government organizations
- A Western European government organization
- Energy sector firms (specifically in Poland)
- European telecommunications firms
- An United States academic organization
The team behind the attacks was dubbed the “Sandworm Team,” based on encoded references in command and control URLs and malware samples that refer to the sci-fi series Dune. iSIGHT reported that it has been monitoring the Sandworm Team since late 2013, and believes they were formed sometime in 2009.
Geopolitical Tensions Creating Targets
The takeaway here seems to be that the attacks do not only target governmental entities. The Sandworm Team has instead targeted entities that are geopolitically relevant in a broader sense: energy, telecommunications, education.
This should serve as a sign of potential threats to come. Private sector businesses that are strategically sensitive in a geopolitical sense might be on some state’s list of targets. This means organizations that share information with, provide services to, or provide infrastructure utilized by governmental organizations may be at risk. State-sponsored attacks will focus on targets with strategic significance which can range from obvious ones like power grids and financial institutions to less obvious targets like research universities.
State-sponsored attacks are on the rise and the targets are becoming broader. Organizations who align themselves with sensitive entities should have a heightened sense of awareness and look to raise their defenses if needed.
We will update this post accordingly as the story continues to develop.
No Comments »
Posted: September 18th, 2014 | Filed under: IIS & HTTP
One of the main goals of spending time and money to implement information security is to make it difficult for hackers to get in and data to get out. When ‘hackers’ compromised Home Depot and stole upwards of 60 million credit card numbers recently, it wasn’t all that difficult.
The breach, which could be the largest in US history, occurred after a piece of malware (possibly the Backoff malware) made its way onto the point of sales at numerous Home Depot stores. When customers swipe their card at checkout, the card data was captured and sent back to a server. If this sounds familiar, that’s because this is the same technique that was used in the Target breach last December.
A line that is being repeated in news and blogs is that the hackers didn’t do anything terribly complicated or anything that required a ton of hacking skill. Lines like this usually only come out of incidents that were caused by carelessness or ineptitude. Hacking a major corporation’s POSs shouldn’t be easy; it should be hard. Stealing 60 million credit card numbers shouldn’t be easy; it should be hard. We don’t yet know all the details behind the breach, but we certainly have learned some takeaways:
- Malware is still a potent threat - Threat signature based antivirus is not capable of detecting new types of viruses or malware. Since antivirus and anti-malware depend on signature databases to detect and eliminate threats, new threats often go unseen until an incident occurs. This leaves a huge blind spot in organization’s security infrastructure. However, this may not have been the case with Home Depot. As reported by ThreatPost, BackOff isn’t a complex Windows Trojan, it’s just re-purposed to run on a Windows-based POS and therefore should be detected by antivirus. This means that Home Depot either did not have antivirus in place or it was not updated – either scenario is bad. That leads us to our next takeaway.
- We don’t learn – This same style attack just occurred to a major U.S. retailer and was all over the news. Everyone knew about this attack – especially IT and security people – and yet the same style of attack was even more successful in the Home Depot incident. The lessons learned from Target should have raised guard enough to at least make sure that antivirus was properly installed on the servers managing the POS machines and updated regularly. Symantec has specifically addressed how its software detects point-of-sale malware, and many antivirus vendors were quick to add signatures for BackOff variants after they were discovered. In this instance, the vendors appear to be doing their part, but Home Depot seems to have failed to protect itself.
- No PINs stolen, but that doesn’t matter - In a report issued by Home Depot they stated: “While the company continues to determine the full scope, scale and impact of the breach, there is no evidence that debit PIN numbers were compromised.” But unfortunately that doesn’t matter. As Brian Krebs reported, the method of PIN reset is so out of date that even a stranger can reset your PIN with enough personal information simply by using the automated voice system:
“Countless banks in the United States let customers change their PINs with a simple telephone call, using an automated call-in system known as a Voice Response Unit (VRU). A large number of these VRU systems allow the caller to change their PIN provided they pass three out of five security checks.”
- Where does cybersecurity insurance come into play? Business Insurance reported that Home Depot has $105M in cyber insurance to cover data breaches. Cyber liability insurance is a growing industry with the threat for seriously damaging data breaches making growing more and more. This begs the question: will organizations lean too heavily on insurance policies rather than implementing better security policies? That isn’t to say that Home Depot did this, but one has to wonder if cyber insurance will provide executives a level of comfort that will detract from investing in proper security.
Every breach that occurs is unfortunate, but it’s also a chance for everyone to learn and avoid potentially critical mistakes in the future. What do you think some of the major takeaways or questions coming out of the Home Depot breach are?
No Comments »
Posted: July 31st, 2014 | Filed under: Web and Application Security
from our partners at Net-Square
Criminals were successful in bypassing an Android-based, two-factor authentication system during their spear phishing and malware attacks. The malicious campaign, known as Operation Emmental was discovered by a security software company earlier this year.
The criminal gang which managed Operation Emmental used phishing attacks to gather bank customer’s personal information and other sensitive data, including:
They used this information to bypass bank authentication systems used by 34 different banks across four countries.
These attacks were first discovered about five months ago and have been actively targeting customers of financial services firms from Switzerland, Austria, Sweden and Japan. All of the targeted banks use a session-based token, sent via SMS, to act as a second factor for authenticating users before they’re allowed to log into their online bank account.
How Operation Emmental Was Executed
It all starts with a fake email that looks like it was sent by a legitimate and well-known entity. Then the cyber criminals serve malware attached to the email as an apparently harmless Control Panel (.cpl) file.
If users execute the malware, which may be disguised as a Windows update tool, the malware changes their system’s settings to point to an attacker-controlled Domain Name System. This allows attackers to secretly observe and control all HTTP traffic. Next, a new root Secure Sockets Layer (SSL) certificate is installed, which looks legitimate and prevents web browsers from warning victims of a bad/insecure cert as it normally would.
The malware deletes itself leaving behind only the altered configuration settings. This makes the attack difficult to spot: when users with infected computers eventually try to access the bank’s website, they are instead pointed to a malicious site that looks and works just like the real bank website.
The next phase of the attack occurs when users log into the fake banking site. Once logged in, users are instructed to download and install an Android app that generates one-time tokens for logging into their bank. In reality, it will intercept SMS messages from the bank and forward them to a command-and-control server or to another mobile phone number.
This means that the cybercriminal not only gets the victims’ online banking credentials through the phishing website, but also the session tokens needed to bank online as well. The criminals end up with full control of the victims’ bank accounts. By stealing the credentials and compromising the authenticated session of the user, it would appear normal to the Bank, as if a user is merely conducting a typical financial transaction. In reality, the user is potentially having their bank account drained without any of the typical banking warning flags going up.
What can you do to protect yourself and your users?
One recommendation comes from the researcher who first discovered this attack. Improve the verification schemes for users and user transactions. If the verification process went beyond multi-factor authentication or session-based tokens via SMS, it could prevent this particular type of campaign.
In addition, banks should warn their customers never to click on links in emails, but instead cut and paste links in the browser bars.
In the remediation report, additional recommendations have stated that banks should implement open source Domain-based Message Authentication, Reporting & Conformance (DMARC) technology. This helps in verifying the email origin and domain names, eventually blocking many types of phishing attacks against customers. DMARC is fundamentally important since it ascertains whether an email of a domain name is spoofed or impersonated.
The lessons learned from Operation Emmental are ones that stretch beyond banking. These concepts can be applied to any type of app with a secure login. If you have any questions about testing or securing your app, please feel free to reach out to us!
No Comments »