2011 PCI Breach Research

There is a very good article regarding research into 2011 breach statistics by Trustwave over at InfoWorld Security Central.  A great source for much IT & Security information, by the way.  According to the article, hackers infiltrated 312 businesses making off with customer payment-card information.  Their primary access point was through 3rd-party vendor remote-access apps, or VPNs setup for remote systems maintenance.  Seventy six percent!  These external ingress paths introduced security deficiencies that were exploited by attackers.

The vast majority of the 312 companies were retailers, restaurants or hotels, and they came to Trustwave for incident response help after one of the payment-card organizations traced stolen cards back to their businesses, demanding a forensics investigation within a matter of days.  Only 16% of the 312 companies detected the breach on their own!

The businesses hit claimed to be compliant with Payment Card Industry (PCI) security standards, when in reality there were gaps.  The remote-access provisions were poorly protected by simple, re-used, shared, and seldom changed passwords.

I will leave the most scary statistics, how long the attackers were able to maintain their ownership of the networks in these cases, for you to seek out yourself on the second page of the article.  It is not a happy number!

The lesson to take away from this article is, PCI compliance is the bare minimum that an organization should do, and DOES NOT equate to comprehensive security.  A PCI-DSS pass score does not ensure actual compliance either.  It is a good starting point to ensure that the bare minimum, common sense, security controls are implemented at a single point of time, but good security practices must spread out from the center.  If your security efforts don’t include other servers and the workstations that access them AND the Internet, you are not managing security, you are faking it for compliance sake.  Russian roullette with a fully loaded gun.

Adobe Sandboxes Flash in Firefox

I am happy to post that Adobe has released beta code for sandboxing Flash content within Firefox.  Sandboxing is an excellent way to isolate ancillary code from the operating system and other applications.  I have been using it for years to keep my browser and its myriad vulnerabilities isolated after experimenting with it in malware analysis.  It just makes sense to contain the raft of cruft that tends to come in from an uncontroled, but necessary network, like the Internet.

It is not a foolproof method for containing all malware or avoiding malicious content, but it cuts down significantly on the impact of what mal-content can do by restricting its reach, and it increases the cost, package size, and effort required on the part of the bad guys to get through an additional layer of defense.  Every defensive layer that they have to identify and circumvent presents another opportunity to discover and analyze their attack code…

Adobe used elements of Google’s Chrome sandboxing technology in its Reader code after a flurry of vulnerability announcements and high profile attacks targeting the application.  Adobe says that since its launch in November 2010, they have not seen a single successful exploit in the wild against Adobe Reader X, where they initially offered sandboxing technology.

The new code currently supports Firefox 4.0 or later running on Windows 7 or Vista.  Adobe promises wider browser protection soon.  More details will be given at the CanSecWest security conference in Vancouver, BC next month.  I sure would like to attend this conference.  Maybe I will meet some of you there?!

UPDATE:  ComputerWorld reports that IE is next on Adobe’s list to “sandbox” its popular Flash Player within browsers, Adobe’s head of security said today.

Secure Coding Practices

Here is a list of Secure Coding Standards links from Source Code Auditing, Reversing, Web Security, re-posted here for my own easy reference.  Code review is admittedly not (currently) my strong suit.  I have done some old school reverse engineering in the lab back in the day, and messed around with static and behavioral analysis, even done some 3D game programming, but I am still a n00b.

• http://community.corest.com/~gera/InsecureProgramming/
• https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
• https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637
• https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
• CERT Oracle Secure Coding standard for Java
• http://www.viva64.com/en/a/0065/ (A Collection of Examples of 64-bit Errors in Real Programs)
• http://www.viva64.com/en/a/0042/ (Seven Steps of Migrating a Program to a 64-bit System)
• http://www.viva64.com/en/l/      (Lessons on development of 64-bit C/C++ applications)
• http://www.oracle.com/technetwork/java/seccodeguide-139067.html (Secure Coding Guidelines for the Java Programming Language, Version 4.0)
• http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html
• Apple’s Secure Coding standard
• https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/coding/305-BSI.html
• Klocwork’s CERT C and C++ Secure Coding Standard
• https://www.securecoding.cert.org/confluence/display/seccode/Klocwork+Cross+Reference
• http://grouper.ieee.org/groups/plv/
• https://www.owasp.org/index.php/Secure_Coding_Principles
• http://developer.klocwork.com/klocwork-university/security-innovation/secure-coding
• http://www.saferc.com/
• http://stackoverflow.com/questions/4780410/secure-c-coding-practices
• http://www.bits.org/publications/pr/BITSSoftwareAssurance020112.pdf  50-page guide for a mature, strategic secure software dev program.

If you have any more, please add it in the comment.

Verisign Repeatedly Breached

Verisign admitted it was hacked repeatedly last year but could not identify what data may have been stolen.  It doesn’t believe the Domain Name System servers were hacked, but it cannot say for sure.  Symantec bought its certificate business in 2010, and says that there was no evidence that the system was affected.  Verisign came clean in an SEC filing, saying that its security team failed to advise management about the attacks until 2011, despite taking action to address the hacks.

Symantec’s VeriSign remains one of the largest providers of Secure Sockets Layer certificates in the world.  Web browsers look for these certificates when connecting users to secure sites, beginning with “https”.  These sites include most banking sites and certificates are also used for some email and other communications portals.

If the SSL infrastructure were compromised, an attacker could create a Google certificate or a Bank of America certificate that would be trusted by any browser in the world, according to an analyst in the MSNBC article.  Symantec’s spokeperson reiterated, “there is no indication that the 2010 corporate network security breach mentioned by VeriSign Inc was related to the acquired SSL product production systems.”

Of course the company claims that they were attacked by “the most sophisticated form of attacks,” including some that are “virtually impossible to anticipate and defend against.”  There’s no evidence that I am aware of to prove or refute that claim.

Important SolarWinds & HP Vulnerabilities

Digital Defense has posted a couple of vulnerabilities in some pretty popular and common products that customers and colleagues may want to be aware of.  I would recommend assessing the relevance of these disclosures to your environments, and taking mitigating action where appropriate.  Consider the potential of insider as well as external attack.  The information and access that either of these two vulnerabilities offers is just too yummy for a malicious or driven attacker to pass up.

1) SolarWinds Storage Manager Server SQL Injection Authentication Bypass

Severity:  High

Vulnerability Description:  The ‘LoginServlet’ page on port 9000 of the SolarWinds Storage Manager Server is vulnerable to a SQL injection within the ‘loginName’ field.  An attacker can leverage this flaw to bypass authentication to the Storage Manager application or to execute arbitrary SQL commands and extract sensitive information from the backend database using standard SQL exploitation techniques.  Additionally, an attacker may be able to leverage this flaw to compromise the database server host operating system.

SolarWinds has not yet provided a patch to address the issue. Digital Defense, Inc. recommends restricting access to the affected port until an update has been produced by the vendor.

2) HP JetDirect Device Page Directory Traversal  (CVE-2011-4785)

Severity:  High

Vulnerability Description:  The HP-ChaiSOE/1.0 embedded web server on certain HP JetDirect printers allows a potential attacker to gain read only access to directories and files outside of the web root.  An attacker can leverage this flaw to read arbitrary system configuration files, cached documents, etc.  Information obtained from an affected host may facilitate further attacks against the host.  Exploitation of this flaw is trivial using common web server directory traversal techniques.

Known Affected:

• HP LaserJet 4650
• HP LaserJet P3015
• HP LaserJet 2430

At this time, HP has been notified of the vulnerability and has released a patch which addresses the issue for HP LaserJet P3015.

https://h20565.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=emr_na-c03140700

Cisco IronPort Vulnerability

Advisory ID: cisco-sa-20120126-ironport

Cisco IronPort Email Security and IronPort Security Management Appliances contain a vulnerability that may allow a remote, unauthenticated attacker to execute arbitrary code with elevated privileges.  Fixed software versions or patches are not yet available.  Configuration workarounds that mitigate this vulnerability are available.

Cisco IronPort Email Security Appliance (C-Series and X-Series) versions prior to 7.6.0 and IronPort Security Management Appliance (M-Series) versions prior to 7.8.0 are affected by the FreeBSD telnetd remote code execution vulnerability documented by Common Vulnerabilities and Exposures (CVE) identifier CVE-2011-4862.  This one scores a 19 out of 20 on the CVSS score (BASE & TEMPORAL), so you may want to exercise the workaround on this one.

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120126-ironport

 

 

Symantec Recommends Not Using PcAnywhere

Reuters reports that Symantec has taken the rare step of advising customers not to use one of its mainstay products, saying that remote control software product pcAnywhere is at increased risk of getting hacked after details and code were stolen.  Symantec is asking customers to temporarily stop using the product, until it releases an update to the software that will mitigate the risk of an attack. PcAnywhere is also bundled with other titles, like Symantec’s Altiris line of software for managing corporate PCs.

This is a serious step, and I applaud Symantec for coming clean on the risks of this powerful and popular product.  Most vendors woould simply warn users of increased risk and provide workaround and mitigation steps that may or may not be implementable or effective.  I hope that Symantec can release new code quickly, and overcome this unfortunate problem.

Insecure Conference Rooms

The New York Times is reporting that Rapid7 researchers have discovered that they could remotely infiltrate conference rooms in some of the top venture capital, law firms, pharmaceutical and oil companies across North America by simply calling in to unsecured videoconferencing systems found by scanning the internet.

Moore found he was able to listen in on meetings, remotely steer a camera, and zoom in on items in the room to read proprietary information on documents.  Most expensive videoconferencing systems offer encryption, password protection and camera lock down capabiilties, but they found that administrators were setting them up outside of firewalls for convenience, and not properly configuring security features.  Some systems were set up to automatically accept inbound calls, opening the way for anyone to call in and eavesdrop on a meeting.

“These are literally some of the world’s most important boardrooms — this is where their most critical meetings take place — and there could be silent attendees in all of them.”

Time to review your video and conference  call setups, folks.  It would be terrible to find out that privileged client or finiancial information was so easily obtainable AFTER the fact!

Core Security Technologies Breached Again?

Core Security Technologies may be in trouble again.  “snc0pe” claims to have breached their networks for the third time, posting IDs and passwords publicly.  The last time snc0pe hacked Core Security was September 2011, leaving the front page defaced.

Core Security Technologies is a computer and network security company that provides penetration testing and security measurement software products and services.  The company’s research arm, CoreLabs, identifies security vulnerabilities, publishes advisories, and works with vendors to eliminate the exposures they find.

Core is dismissing the attack as insignificant, claiming that it was launched against an 8 year old, unused server that contains no relevant information.

Questions;

• What is an unused server doing connected to the internet?
• What access does it offer to other internal and external resources?
• Just how irrelevant is the information that is stored on it, or accessible using its credentials?

New Exploits Released For SCADA Systems

Wired reports a group of researchers have discovered serious security holes in 6 of the top industrial control systems used in critical infrastructure and manufacturing facilities.  They have also made it easier for hackers to attack systems before they can be patched or otherwise remediated.  They’ve packaged up the exploits in nice little modules for the MetaSploit tool so that any script-kiddie or organized crime team can just point and click.

The vulnerabilities exist in programmable logic controllers made by GE, Rockwell, Schneider Modicon, Koyo Electronics and Schweitzer Engineering Laboratories.  Apparently, the SCADA vendors were not quick enough for the researchers’ liking to acknowledge the vulnerabilities or release patches.  PLCs are used in industrial control systems to control functions in critical infrastructure such as water, power and chemical plants, gas pipelines, nuclear, and manufacturing facilities.

The various vulnerabilities provide backdoors, as well as authentication and encryption by-passes that could allow attackers to gain access to systems, and the ability to send malicious commands in order to crash, halt, and interfere with specific critical processes, such as the opening and closing of valves.

Nice…  Time to examine your SCADA environments and mitigate these vulnerabilities ASAP, and start elevated monitoring.  I don’t believe that this is the way to move vendors forward, but that is just me I suppose.  What do I know?  I wonder if there are any good litigation lawyers out there that might want to monitor the exploitation of some critical infrastructure and take action against those who provide such tools to the masses when harm is done to the public?