HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

China, Google and Web Security

Google recently announced that its China based location was the victim of an attack that targeted and compromised a critical internal system used to track the email accounts of those on China’s watch list. The system was designed to comply with government warrants for information concerning Chinese human rights activists. Some suspect China of targeting this specific system to circumvent the official warrant process in order to collect data on other Chinese citizens .



More alarmingly, this attack was not exclusively directed at Google. In all, at least 34 companies including Yahoo, Symantec, Northrop Grumman, Dow Chemical, Washington-based think tanks, and assorted human rights advocacy groups were compromised by the spear phishing attack .


At first rumored to be another Adobe flaw, closer examination by McAfee Labs revealed that the attack (code named “Aurora”) was actually a sophisticated zero-day vulnerability exploit against Microsoft’s Internet Explorer .


What should be most worrisome is not the zero-day in all versions of IE, but the new crop of “advanced persistent threats” that are siphoning money and intellectual property. These APTs are professionally organized, have extensive funding and employ smart people. The result: triple encrypted shell code which downloads multiple encrypted binaries used to drop an encrypted payload on a target machine which then establishes an encrypted SSL channel to connect to a command and control network . This is serious stuff.


Only a few years ago the majority of web-based attacks seemed to be launched by individuals or small groups to collect credit card information. These attacks had seriously consequences, but the magnitude of the losses and the organization of the black market economy were still child’s play by today’s standards.


Current threats from the Eastern bloc are directed at massive monetary gain - probably in the area of tens of millions of dollars . China appears hell bent on stealing state secrets and intellectual property from both governments and private business alike. The stakes are much higher, and the bad guys are much more capable of pulling off the heist.




We have known for a long time that phishing scams have been very effective at exploiting random samples of unsuspecting users. However, the focused targeting of private business is a newer, more sophisticated and lucrative threat. These spear fishing attacks are intensely researched and aimed at top level executives, and will become more common as time passes.


In a directly related point, consider the curious appearance of a new website called iiScan. This service offers to scan your web application for vulnerabilities - for FREE. Just sign up and point their software to your website, and they will, ‘figure out’ how vulnerable to an attack you might be. After the scan is done, they will email you a PDF based report to your email account.


Placing trust is such services has been discussed before, especially concerning cloud security.  It doesn’t take much to imagine all the things that could go wrong in this scenario, even if IE didn’t have multiple zero-day exploits, and a proof of concept embedded malicious PDF exploit had not just been released.


 It might very well turn out that NOSEC Technologies Co., Ltd. (the company behind iiScan) may be legitimate, or at least may have started out that way. Even if they are not actively attacking websites, it shouldn’t take long for them to become a high profile target for either private hackers, or for the Chinese government itself. What would be a better target than a database full of public websites and their known vulnerabilities? These sites, if not already compromised by iiScan, could be used as command and control drones, payload hosts, pieces of a distributed file-system, or merely SPAM relay channels.


Education and Armament


Everyday adds more proof that web application threats are being crafted by motivated professional organizations with deep pockets. Security needs to be taken very seriously, practiced diligently, and all users need be paranoid when surfing the web. This is especially important because the media is very cautious to report all the gory details of the real impact of cybercrime .


Installing preventative software is a good idea, too. Some of the latest tools and devices may help to prevent drive-by malware, spear phishing payloads, etc. Install Firefox and use plug-ins that flag suspected malware host sites. Use a personal web proxy, and restrict evil IPs. You can get the most comprehensive list of Korean and Chinese blocks (including iptables, htaccess files, dns zones, etc) from this page. Above all, stop clicking on those emails from your least technical friends that include an attached PowerPoint or PDF file to deliver a punch line. The villains take the Internet very seriously, and so should you.


UPDATE (1/19/2010):


Thanks to the Full-disclosure list (Marc, Smasher, Dan) for pointing out that the exploit was not nearly as sophisticated as McAfee has led us to believe.


The exaggerated sophistication of the attack re-enforces my point about media FUD - ironic in its own way because the media is quick to exaggerate the sophistication of the attacks, yet minimize the damage associated with them. It’s like getting up off the floor after a sucker punch and taunting "That didn't hurt". The reality is that simple attacks are still very effective - our security education and implementation still has a long way to go.


However, the real point of this article was to encourage a little more critical thinking surrounding software security. Putting blind faith in any type of security device (airport scanners, webapp scanners, etc.) is not good security practice.







How to clean up a hacked WordPress installation

Older installations of WordPress have recently experienced a new wave of attacks as they have been increasingly targeted by hackers. These installations are highly susceptible to a variety of attacks. What to do, then, when your installation has been comprimised? Here's a good list from WordPress of the steps to take when your WordPress installation has suffered a successful attack.


The HP Web Security Research Group's own Matt Wood recently wrote some excellent advice for a hacked site, as well. Each of these lists will help you secure your WordPress installations.


Labels: hacked| Wordpress

Advice for a Hacked Site

If Google detects that your website is hosting malware, it is pretty clear your site has been attacked. Attackers are consistently using automated attack tools looking for SQL Injection points, trying to include files remotely, or attempting to determine ssh passwords via guessing. A frightening trend with SQL Injection attacks concerns how an attacker will insert links to javascript content used to serve malicious links that may try and automatically compromise the users of your website.  When this happens, Google will automatically detect this and actively deter users from visiting your  website. Here are some of the  basic recovery steps that need to be taken to ensure all content that was  possibly modified by the attacker will be removed. It is also  important to note this is not legal advice and should not  be used as such. If you are experiencing monetary loss, consider engaging the proper authorities and hiring a consultant  who is certified to handle these situations. The steps below are  simply a very rough set of guidelines on one way that a security  analyst might approach securing a hacked website.




0. Disconnect from the Internet


The last thing you need is to get attacked again while  performing forensic analysis or restoring your       database/website to its former glory. Remove your server from this possibility by disconnecting it from the Internet. If your website was hacked, simply turning off the webserver is probably a sufficient countermeasure.


1. Backups!


You need to backup your entire site and backend database at this point. It is important to perform this step as later you will actually be deleting all your current content and replacing it with a backed-up version. This is recommended to ensure the attacker has not modified anything on your site. For example, the attacker might have installed a backdoor or a dynamic script that would allow shell access to the server.


1b. Save All Logs and Analyze Them


All server logs should be saved from the attacked machine. If your organization has familiarity with web/network based attacks, then spending some time looking through logs would be beneficial as it may help identify the attackers point of entry. This will obviously help in remediating the issues and detecting how widespread the vulnerability may be.


2. Change all Authentication!


If an attacker has been able to modify your database or filesystem, it is very likely he/she has also stolen the   credentials needed to access your website. This includes usernames/passwords needed to login to any private areas on the website, and any usernames/passwords that are also users on the local machine such as the root user or the administrator passwords, especially if any remote administration (like OpenSSH) is used on the website. Don't forget to remove any ssh/rsa private keys either as they can no longer be trusted.


2b. Reinstall OS (optional? maybe)


Pedantic administrators worried about security and not able to pinpoint the vector used to compromise their website wuld completely reimage the webserver, as bots or key-loggers may have been installed. This is most likely a severe case.However, it may be an acceptable precautionary step depending on how sensitive the webserver or content is to the organization.


 3. Restore Previous Backups


You can no longer trust the code or data that your website is serving or using to serve data. Thus you need to restore to a point in which you did trust your code and data. This is probably going to be a painful process, but it will still be better than being consistently hacked multiple times in the future.  If you have no database backup, don't give up. Consider using the OWASP Scrubbr utility. This utility is designed to analyze database records and look for suspicious looking links that will help you identify and remove malicious content. It also has the side affect of helping you pinpoint where your problems may lie. Generally writing to specific fields within the database only occurs on a few pages, so the search for where the input validation needs to occur will be limited.


4. Perform Some Simple Code Audits


You already have accepted that a hack has occurred, so it makes sense to spend some time looking through critical path code to make sure no obvious mistakes were made.This could mean hiring a consultant to analyze your codebase or utilizing your developers to examine the code by running opensource tools like Nikto on your site. Both would provide beneficial data as to where to suspect malicious activity, and improve your security posture. If you found something suspicious in the logs of your webserver, you should spend some time verifying those specific areas but it is important to note that even though the attacker used door #1, that doesn't mean  door #2 isn't sitting there available right now. Security is an ongoing process and especially after an attack time should be spent securing and analyzing your current codebase. This is important because generally mistakes within webapps are systemic and not just a one off error that only happens in one place within your codebase.


5. Turn the Site Back On


Feeling better, hopefully having identified some issues, it is now time to turn on the web server (hopefully with a clean bill of health).




You're probably thinking to yourself, "this seems like a lot of work, is it really all necessary?". The answer to this question is maybe. Of course this is a nebulous answer to that question, but the actual recovery from an attack might only require a few of the steps listed above. The real trick is in deciding which of those steps are needed (optimization) and the answer to that depends on the type of attack you've encountered. For example, if your site was attacked by just a simple drive-by SQL Injection bot then it is probably sufficient take the following subset of steps.


(1 + 1b) To make sure you have your bases covered and by looking at the logs you can identify the injection points the bots were trying to exploit. (4) Once you've identified the pages being attacked, you (or a consultant) can then verify those pages either have or do not have SQL Injection vulnerabilities. (3) Clean up your database, make sure all offending links can be cleaned, whether this is manually, with your own tool, or using OWASP's Scrubbr.


Of course it is not always easy to identify what type of malware has been attacking your website. There are services available that will perform this types of analysis for you. You can contact either Armorize (http://hackalert.armorize.com/default.php) or ClickFacts (http://www.clickfacts.com/) who will audit the types of malware being served by your website. Since they have specific knowledge in these areas, they will probably be able to tell you specifically which attack has been used and recommend steps for cleaning up your website.





Labels: hacked| Malware

Uncharted Territories: the personal-corporate-social-web-mashup

Corporate web communications have grown from simple web pages to massive and complex applications. The security department has mostly kept up and maintained a secure perimeter—even when that perimeter included outsourced and vendor systems. Contracts were in place, systems were secured, and life was good—even when the executives had their own blogs.


But just when everyone was getting comfortable again--enter the social web: MySpace, Twitter, and Facebook. People started using them and corporations followed.  Born of this are the corporate MySpace pages, Facebook groups, Facebook fan pages, management’s Twitter accounts, LinkedIn recruiting pages and more…


Did you see what happened there? No? It’s okay, neither did the security department.


So what was it? The customer contact point shifted from the corporate web environment to one controlled by a third-party.


Unlike most arrangements made with third-party vendors, this relationship is likely not covered by any type of contract, agreement or partnership. There is no guarantee for reliability, privacy, security or any type of regulatory controls. Your corporate users/administrators, as well as your customers, are bound by the third-party’s terms of service and policies, not yours, and you are also at their whim with regard to functionality and design.


These are no small issues when you consider the spider-web of laws, regulations and agencies that may cover many large businesses: Sarbanes-Oxley, HIPAA, GLB, etc. The security team, human resources and PR/brand all have a vested interest in keeping your sites and customer information secured, protected and private, and they just lost control of a key piece of the infrastructure.


This is not a completely theoretical risk. Looking at the news for the past few years, it’s easy to come up with examples that could have business, customer or employee impact. Even if no laws were violated or charges filed, in the internet age a negative story can spread like wildfire and damage brand.


Here are a few quick examples:


These are simply a few recent examples, but represent the tip of the iceberg. It’s hard to find news stories of confidential or proprietary corporate information posted to these sites, but you can safely bet it happens.


As marketing and PR types take a bigger interest in these channels to reach additional markets, and more and more users flock to these sites, the corporate presence there is going increase drastically.


So what should a company do? With regard to employees, here are a few suggestions:


  • Remind employees it is their responsibility to safeguard corporate and customer information.
  •  Incorporate messages about social networking into existing employee training and policies, and if applicable, give employees refresher courses.
  • Ensure employees realize the internet isn’t actually anonymous, and that they should behave ethically and in a manner that that doesn’t reflect poorly on themselves or the company.


If the company is creating an official presence on third-party web sites, some additional suggestions come to mind:


  • Determine the proper ownership for these channels—perhaps marketing or public relations—and establish a centralized point of contact.
  • Implement policies, guidelines and/or a code of ethics which clearly determine what information can and cannot be posted, and have a review procedure for anything questionable.
  • Implement policies/procedures for managing accounts and passwords to third-party systems, which include controls for changing passwords after employee attrition, choosing strong passwords, etc.
  • Implement procedures for monitoring the sites on a regular basis to ensure the messages, conversations and the brand “image” are appropriate (this can be contracted to other parties).
  • With the legal department, review the terms and conditions of the web site to look for potential pitfalls with regard to marketing through the site as well as ownership of uploaded content.
  • Thoroughly investigate privacy and security settings on the web site, and determine which should be enabled to best protect the company, customers and the user accounts.
  • If any relationship becomes mission critical or an important piece of the business, pursue contracts with the site operators which attempt to establish things like official support, uptime guarantees, additional security features, etc.   

These may all seem like daunting tasks, but any company with even a partially mature security department and polices should be able to integrate these types of changes fairly easily—in almost every case these are simply extensions, additions or clarifications to things already present in the corporate culture.


Given the immense popularity of these sites and their growth rates, the problem isn’t going away any time soon. Before the next wave of change comes to the internet, social networking policies and changes should be dealt with in a way that respects what employees do in their off-hours, protects the company and provides a new opportunity for corporate growth. The company that sticks its head in the sand may find itself in a nasty situation that could have been easily avoided with a little forethought.

Keep the snakes at bay

Recently, a state agency announced that their site had been compromised by computer hackers. The attackers left a ransom note on the web site claiming that they had captured 8.3 million patient records and 35.6 million prescriptions. The attackers also claimed to have created a password-protected, encrypted backup of the data.  For a mere $10 million the miscreants offered to “gladly send along the password.”

To quote the great philosopher Morpheus, “Welcome to the desert of the real.”

Warnings about security flaws in web applications have been ignored by most for as long as web applications have existed. A small contingent of evangelists, including folks in our own HP Application Security group, have consistently warned about the existence and exploitability of these vulnerabilities.

The U.S. Department of Health and Human Services Inspector General, in a report dated October 27, 2008, stated that “limited actions” by the Centers for Medicare & Medicaid Services (CMS) have “not provided effective oversight or encouraged enforcement of the HIPAA Security Rule by covered entities.” Voluntary compliance (an oxymoron?) was a key problem cited for this lack of effectiveness.

Some suggest that healthcare records simply should not be made available via the public internet. That’s a lot like saying people shouldn’t eat greasy cheeseburgers. It may be true, but it’s not gonna stop.

The first step to understanding the real problem is recognizing that the availability of information, even healthcare information, is a growing part of our everyday lives. You wouldn’t put sharp kitchen knives on the floor where your toddler could reach them, would you? If you did do something this dangerous, would you then punish the toddler for cutting himself?

We need to stop wondering why snakes bite and start wondering what we can do to put a healthy distance between our toes and the snakes.

The federal government has enacted new, strong provisions to begin forcing developers of healthcare management software applications to provide notice of breaches to the medical providers they serve, who can in turn notify the affected individuals. This is a huge step, because in the past HIPAA compliance was a burden borne by the medical providers. If they aren’t notified of the breach, nobody is the wiser…until somebody finds out at the pharmacy that all of their pain prescriptions have already been filled by some nice young gentleman.

Now that software application developers are held accountable for security, I believe we’ll start to see some distance between us and the snakes. By the time these software developers figure out they need a plan for their web application security, they’ll find out HP has been there all along.

Ken Swinney
R&D Group Manager
HP Application Security Center

Diamond heist holds infosec lessons, too

Wired is running the story “The Untold Story of the World's Biggest Diamond Heist” on their site and in the next issue. You may have already read it, since it’s pretty popular on the tubes right now. If you haven’t—while it’s pretty long—it’s an interesting read on physical security, criminals, capers and exploitation of weaknesses.


Below is a fairly spoiler-iffic view on the heist and how I think it relates to the information security world—so if you want all the gory details without my summary, head over to wired.com first.  Here’s a high-level synopsis: in an Italian Job like caper, a group of thieves do the seemingly impossible by robbing a massive vault in Antwerp’s diamond district. This is no ordinary vault—it holds most of the district’s diamonds and other valuables, and has a significant amount of security, including the following (there is also a diagram of this):   


  A 3 ton steel door with:

  • Combination dial (0-99)
  • Keyed lock
  • Seismic sensor (built-in)
  • Locked steel grate
  • Magnetic sensor
  • External security camera

 And inside the vault:

  • Light sensor
  • Security camera
  • Heat/motion sensor

This vault is also located in the basement of a guarded and monitored building, and in the middle of a diamond district that is blanketed with security cameras and has its own specialized police force.   


 Seems impossible to break into, right? Of course not.   


The story, as told by Leonardo Notarbartolo (serving 10 years in jail for his part in the crime), tells of how a small group of men exploited minor weaknesses in the various layers of security, and walked away with an unknown amount of wealth (read the article as to why it’s unknown)… and very nearly got away with it.   


While this isn’t directly web/network/data security related, their tactics, from reconnaissance to exploitation, have a lot of parallels to the computer security realm. The methods they use are the same pen-testers and criminals are using against our networks and applications.   




Notarbartolo used a small “spy” camera to document the building and vault. They studied the monitoring systems, vault, building, surrounding buildings, entrances (conventional and otherwise) and habits of the guards. They sneaked in a small spy camera to capture the vault combination (key logger, anyone?) which went to a transmitter hidden inside a fully functional fire extinguisher.   


Social Engineering

Notarbartolo set himself up as a dealer in the building, and rented a box in the vault. After a time, the guards came to recognize and almost ignore him, which gave him a critical opening to disable a heat detector inside the vault.  



The thieves set up a fake vault to practice in and to look for new weaknesses (pretty sure this was in one of the Ocean’s <insert number here> movies). Professional testers make no secret of the work they do against “fake vaults” (ok, lab systems) looking for 0day vulnerabilities to use in their products and future engagements.  


Exploiting Small Weaknesses

There was no single, major flaw in the security. There was no brute force attack (portions of the movie Heat come to mind). Like gaining access to a less-secure and less important “system” (an adjacent building with a courtyard), they had unmonitored access to the secure building’s exterior. They used a little stealth with a home-made polyester shield to defeat a heat and motion sensor, a piece of aluminum and duct tape to defeat a magnetic sensor, and while they had a duplicate key crafted based on the video tape they’d made (which smacks of SNEAKY), they found the actual key in a nearby room (password under the keyboard, or console access?). Black bags covered video cameras which were expected to show darkened stairways. Hairspray defeated a motion and heat sensor long enough for them to disable it completely.  


All of these tiny weaknesses and crafty exploits combined into a massive heist. The tiny chinks in the armor turned into a significant financial loss for the owners of the lockboxes and their insurers.   



So what lessons can be gleaned from the physical-security weaknesses, and translated into the digital world? Plenty.  


First off, no vulnerability or weakness can be completely ignored. Decisions based on risk and cost can be made, and fixes prioritized, but everything should be discovered, catalogued and tracked—at some point that “minor” flaw could be very important. Knowing every weakness and monitoring for exploit attempts could be critical in stopping a massive breach.  


Secondly, there is no such thing as an unimportant application or system on your perimeter (maybe even your internal network). Just because your Job Listing application doesn’t hold customer data doesn’t mean it isn’t critical to your perimeter security. Even if the app runs on a different web server, what if there is a flaw that gives someone system access? Is the root password the same one as in on your banking systems? Does the system give the attacker access to the same DMZ that your critical data traverses? Is your security staff monitoring the IDS as closely for the “ATM Locator” system as the bank login?  


Thirdly, security is not a one-time effort. Your security efforts may be baked in from planning to implementation, but they don’t stop there. Threats, attacks and techniques are constantly being discovered and are always evolving. Since the criminals knew, it seems possible the manufacturer of the heat and motion sensor knew of the “hairspray exploit” but didn’t bother to warn their customers and issue a “patch”—or maybe they did, and the operators of the vault chose not to implement a fix.  


And lastly, to the best of your ability, you have to think like a criminal. You may even consider hiring someone (permanently or on contract) that can do that pretty well (I won’t debate hiring actual criminals). Would someone used to breaking into vaults ask “Why the heck is the magnetic sensor mounted on the outside of the vault door?”  I’d hope so. Would they have scouted the nearby buildings looking for an attack vector? Perhaps. Would they have questioned the wisdom of having video cameras watching completely dark rooms? Any one of those questions, posed to site security or management, could have triggered a corrective action that might have stopped this entire heist in the planning phase.   


So, the next time you think you have better things to do than fix that minor cross-site scripting issue on that little loan calculator application—reconsider—and wonder if Leonardo Notarbartolo learned any computer hacking skills in prison.


And, I mentioned that Notarbartolo is in jail, which means they didn’t get away clean. Check out the full article as to why… that interesting bit, and a lot of other details and theories that I didn’t get into, make it a good read even after skimming this.


XSS+phishing in Italian bank hack

Netcraft is reporting today about a phishing attack leveraging XSS  against an Italian bank. From the article (emphasis mine)

An extremely convincing phishing attack is using a cross-site scripting vulnerability on an Italian Bank's own website to attempt to steal customers' bank account details. Fraudsters are currently sending phishing mails which use a specially-crafted URL to inject a modified login form onto the bank's login page.

This attack highlights the seriousness of cross-site scripting vulnerabilities on banking websites. It shows that security cannot be guaranteed just by the presence of "https" at the start of a URL, or checking that the browser address bar contains the correct domain name.

Cross-site scripting vulnerabilities on SSL sites also undermine the purpose of SSL certificates - while the attack detailed here injects external content via an IFRAME, it is important to note that a malicious payload could also be delivered solely via the vulnerable GET parameter. In the latter case, any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine.

If this sounds familiar, it should. I gave a talk at Toorcon 2005, the Phuture of Phishing. This focused exclusively on current phishing techniques and defense and how XSS vulnerabilities takes phishing to a completely new level. From the slide 24 of the preso:

  • Current Phishing attacks revolves around deceiving the user into think a website is a different website.
  • Current Phishing defense revolves around:
    • Applications preventing HTML from deliberately hiding functionality or actions of links and script
    • Determining fundamental stats about a site to see if it truly is the site it claims to be
  • But what happens if the phishing site was the actual website?

Exactly! XSS vulnerabilities turns a banks website into the phishing site. SSL certs, reputation systems, DNS checks, blacklists, and other phishing defenses utter fail to handle XSS+phishing.

I'm certainly not the only one banging this drum. Jeremiah Grossman predates me by a few months with a good presentation about XSS+phishing. I've had a friendly battle running with Lance James for a few years now about the role of local malware vs. website XSS in the future of phishing.

This certainly isn't the first XSS+phishing attack reported in the press. It wouldn't be the last. Hopefully attacks like this will raise awareness about the dangers of XSS. Remember, XSS isn't just cookie theft, or just key logging, or just page vandalism; XSS is complete client-side code execution!

Labels: hacked| phishing| XSS
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.