Application security

Cracked Web Applications Leak Credentials and Data

If you've been paying attention to vulnerabilities in web applications, you've certainly heard of attacks involving SQL injections, cross-site scripting, and poor session management. Thanks to the efforts of groups like OWASP (http://www.owasp.org), many responsible software vendors and open source project leaders now treat these types of vulnerabilities seriously, and issue patches and hot fixes to remove them from production code soon after discovery.

However, there are many other exploits that threaten Internet-facing applications. This article covers a common exploit not listed in the OWASP Top 10 Application Security Risks (https://www.owasp.org/index.php/Top_10_2013-Main), but is nonetheless used to steal credentials and data from Internet-facing applications today.

Stealing Credentials and Data by Modifying Web Applications

It USED to be Harder to Steal Information with Modified Applications

In the "old days," distributed applications were deployed using a client-server model that used pre-compiled binary code on desktops and servers. These applications could be cracked by experienced programmers, but the people who cracked these applications were more often looking for ways to circumvent licensing (or insert a self-replicating virus) than steal credentials or data. Furthermore, if a crack was intended to steal credentials or data, the hacker often had to be "within the walls" because the targeted application usually ran over a LAN or WAN than the Internet.

Web Applications are Easy to Modify

With the rise of web-based applications, the threat model changed. Most web-based applications now use human-readable web pages written in PHP, ASP, C#, Perl, CGI, Ruby or other web scripting languages. Many others depend on human-readable templates or configuration files that control how the application works.

The switch from all-binary applications to mostly-scripted applications significantly lowered the bar of technological prowess for would-be hackers. Today, a nefarious individual with introductory-level web application skills can cut-and-paste code from the Internet into a sign-in page to write out all credentials to a secret log file. In a client-server world, the same trick would have required mastery of assembly code.

Information Stolen by Exploited Web Applications is Easy to Retrieve

The switch from LAN/WAN applications to Internet-facing applications also freed hackers from having to be present in the building to exploit their targets. Now hackers can "spear-fish" known users of an application, pose as tech support in social engineering exploits, seed false downloads, or use other backdoors and Trojans to plant their exploits on target computers. Once their exploits are planted, hackers may then use hard-to-detect channels to retrieve their ill-gotten gains, such as a new parameter to an exploited web page that downloads the secret log of credentials and data their exploit created.

Examples of Exploits

How a Hacker Might Apply and Use Exploited Code

"BankingWebApp" is a web application written as a C#-based application in Microsoft Visual Studio. It generates binary DLLs that contain much of the program logic but exposes individual *.aspx pages for each separate page in the application. User sign in is handled by "signon.aspx."

Here's a sample scenario: A hacker with a local copy of BankingWebApp discovers that a target bank runs BankingWebApp by reading an online support forum. They insert code into a hacked version of signon.aspx that writes all incoming usernames and passwords to a secret log file. They also insert code into the same file that displays the contents of the secret log file on the web page when a special parameter is added to the URL (e.g., "&debug=1337").

The hacker then contacts an individual at the target bank through the support forum and convinces them to download and apply the hacker's exploit. Once the hacker's exploit is in place, it gathers several hundred sets of customer credentials a day. After a month, the hacker executes a single "debug=1337" transaction against the publically-accessible signon.aspx to download thousands of valid credentials, and proceeds to use or sell the credentials to criminal elements.

Real-World Instances of Exploit

It is difficult to locate real-world instances of this type of exploit in major commercial applications through Google searches, but you can readily find examples of this type of exploit in popular content management systems (CMS) such as Joomla, DotNetNuke and WordPress.

However, you may want to perform a visual inspection of your own Internet-facing web applications before ruling them immune to this type of exploit. If your web application relies on directories full of "*.aspx", "*.asp", "*.php", "*.pl", "*.cgi" files, and those files are legible in Notepad on Windows (or vi on *nix), your web application may be vulnerable to this kind of attack. (Check with your vendor if unsure.)

Most Vulnerable Applications

Web Applications that Rely on General-Purpose Web Servers

Applications that depend on a general-purpose web server such as Microsoft IIS, Apache HTTPS, Apache Tomcat or Nginx are most vulnerable to this type of attack. By design, general-purpose web servers allow several different web applications to share the same web server, and it is the responsibility of each individual web application to be a good citizen of the commons (e.g., not taking too many resources, not destroying another application's data, etc.).

Web Applications that Run Human-Readable Code

Web applications that entirely rely on human-readable scripts tend to be more vulnerable than web applications that obfuscate or compile their code. However, applications that partially hide code in this way, such as binary DLLs used in many ASP.NET applications, may still be vulnerable to redirection in human-readable intermediate files or web filters, such as IIS's ISAPI filter mechanism.

Detecting and Mitigating Web Application Modifications

Use File Integrity Monitoring Tools

The best defense against maliciously modified code is to automatically scan your web applications for unauthorized changes. In the case of custom or internally-developed web applications, this may be your only defense. Fortunately, there are several "file integrity monitoring" tools that perform this exact function.

Your file integrity check application should check all the static content (images, stylesheets, JavaScript files, etc.) and code used by your web application. It should be configured to check a few times a day (at least), keep a trusted signature off the target machine in case the hacker is smart enough to recalibrate the local signature, and can be turned off and recalibrated cleanly during your planned outage.

Note that some commercial web applications such as the web interface on SolarWinds Serv-U FTP Server include their own built-in file integrity checks. When evaluating new web applications, it may pay to ask about included file integrity features up front.

Use Anti-Virus Software to Watch for Exploit Delivery Vehicles

You cannot rely on any anti-virus package to detect modified web applications. By and large, antivirus packages look for binary signatures of known viruses in executables, or look for unusual operating-system behavior in applications, such as injecting code into operating system executables.

However, you can use anti-virus software to detect and prevent the installation of the backdoors, Trojan horses, and viruses that allow hackers to modify your web applications. Without those, hackers must rely on vectors such as open RDP sessions (usually protected behind VPNs these days) or the ability of authorized personnel to follow instructions from an untrusted source to corrupt your application.

Train Authorized Personnel to Use Change Control Procedures

If you deny hackers the ability to install virus and Trojans in your network, the next most likely vector into your systems will be through your people. Social engineering schemes can be devised to gain the trust of employees through shared user forums, or to bluster an employee through an urgent inbound phone call "from corporate" or a specific Fortune 500 vendor. "Spear phishing" schemes can also be developed to target specific email addresses in your company with official-looking upgrade notices or security alerts.

The hackers' goal in all of these schemes is to convince someone on your staff to download the hacker's exploit from an unofficial site and then apply it to a production system. And if a solitary staffer can do all that without telling anyone else, that would be ideal from a hacker's perspective.

Your defense against this attack vector flows directly from the hackers' goal. Any change control policy worth its name already contains two elements that inhibit these kinds of attacks.

First, good change control policies require at least two different people to approve and apply changes. If you take away the ability for people to act in isolation, you take away the ability for them to independently make poor decisions. This is the same concept behind separation of duties in accounting; while the temptation to make a bad decision – to steal money – will always be great, the means to actually carry out bad decisions is greatly reduced when two people must make the same bad decision to proceed.

Second, change control often dedicates the use of separate test and production systems, and specific tests that must be performed on the test system before code is promoted into production. While the technical aspects of running exploited code on a test system will probably not uncover the exploit itself, a hacker must usually be willing to invest more time, and thus increase their chances of being detected, if exploited code must be shepherded through a test environment first.

Beware of Third-Party Contributions, Even to Major Packages

Hackers who cannot rely on Trojans or poorly trained personnel still have one significant vector to exploit if their targeted web application accepts third-party contributions: targeting the add-ons rather than the core packages.

In some cases, hackers will try to serve downloads to popular packages on their own sites. In other cases, they can get the original package authors to serve the exploits as official add-ons or translated editions of the original software. In the most extreme cases, some hackers have actually replaced the official downloads with their own exploited packages, but this type of exploitation rarely lasts for long.

The best defense against these types of exploits is to communicate with the provider of your software application before applying add-ons or translated editions to understand whether or not the code that makes up those elements is supported and blessed by the sponsoring organization. If it is not, and another reputable organization does not stand behind the code, it may be best to forgo the add-on or switch to a different application.

Watch your FTP or SFTP Access

In many of the cases where a popular CMS has been hacked at a particular site, it was because the web site operator left no password or an easily-guessed password on an FTP or SFTP account associated with that site. If you use FTP or SFTP to remotely manage your web site, make sure that all accounts use strong passwords, use FTPS or SFTP instead of FTP to protect your credentials from snooping, and consider the use of strong authentication through the use of SSH keys (with SFTP) or SSL client certificates (with FTPS).

You should also disable unnecessary FTP accounts, use IP lockouts to head off brute force (password guessing) attacks, consider limiting access to a limited number of IP addresses, and check your logs for login attempts that appear to be zeroing in on particular usernames.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Conclusion

Changing the code behind existing web applications is a time-intensive but effective way for hackers to harvest authentication credentials and data. However, you can detect and defend against these types of attacks by using the right mix of file integrity check utilities, antivirus software, and change control policy. You can also limit your exposure by avoiding add-ons and translations from third parties, and being careful with the way you use remote file transfer technology.