(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

When auditing a company for their malware defense savvy, you are likely used to be presented with colorful pie charts of all the malware that their Anti-Virus (AV) product of choice successfully intercepted. Odds are that your auditee can show statistics for the past five years, and related trends of doom and gloom.

The problem is, we arent really interested in that. Counting what the AV caught is like counting the number of hits on the final drop rule of the Internet firewall: It shows scary numbers, but who cares, given that this is stuff that was STOPPED. Way more interesting is stuff that managed to sneak by and was missed ... but how do we find it?

One approach that I like to use involves Perl Compatible Regular Expressions (PCRE). You likely encountered PCREs before - Perl has one of the most versatile sets of regular expression language that can be used to match any text pattern imaginable. Snort, for example, supports PCREs in its rule language. Amazing Perl, of course, supports PCRE natively. And .. lo and behold, the lowly Unix grep command, on many Unix flavors, supports a grep -P, which gives it alien PCRE powers.

What to do with them powers, you ask? Well, in an audit, obtain the last 10 days or so of proxy server logs. Most companies have them, and be prepared that they are HUGE. Plunk them onto a Unix system of your choice that supports grep -P. Then, if you are reading malware blogs like Kafeines http://malware.dontneedcoffee.com and Brads http://malware-traffic-analysis.net, you have an ample reservoir of URLs for currently active threats. If you speak PCRE, turning these URLs into patterns is no big deal, and provides good fresh intel. If you dont speak PCRE, you (well, should learn!!) can make use of the current events ruleset of Emergingthreats, for example http://rules.emergingthreats.net/open/snort-2.9.0/rules/emerging-current_events.rules. Look for recently added rules that cover trojan activity.

Then, for the analysis, piece the various PCREs together into one big bad*ss PCRE, and run it in a grep -P">[email protected]$ grep -P (http:\/\/[^\x2f]+\/[a-z0-9]{6,}_[0-9]+_[a-f0-9]{32}\.html|\/[a-f0-9]{60,66}(?:\x3b\d+){1,4}|\/\??[a-f0-9]{60,}\x3b1\d{5}\x3b\d{1,3}|\/[0-9a-z]{32}.php\?[a-z]{1,3}=[0-9a-z]{32})">Nov 10 11:43:18 local7.info squid[20791]: time=2014-11-10 11:43:18 rc=TCP_MISS/200 ip= head_type=application/x-shockwave-flash size=10751 req=GET url=214 referrer=http://tblwynx.ddns.net/nrll3fpihn5lzyvnrkk8klq88cnfyapoeivvkbieeeff

Yes, it will take a while, but if you get any hits, like the Fiesta exploit kit hit shown above, I guarantee that it will be highly entertaining to ask the auditee if and whether they noticed anything amiss on the PC on November 10. The fresher your PCRE, the better the results that you will pull out of the log. With a decently up to date PCRE, I have yet to see an auditee who doesnt have several hits in ten days worth of proxy logs.

If you have any cool PCRE malware detection tricks up your sleeve, please share via the comments below!

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

When he was arrested at his Chicago home in 2012 for hacking the website of security think tank Stratfor, the dreadlocked Jeremy Hammond was the FBI's most wanted cybercriminal. Authorities tracked him down with the help of top LulzSec member Hector Xavier Monsegur. But it has never been known how they managed to search his encrypted computer, the lid of which the hacker was able to close as agents armed with assault rifles were raiding his home.

An Associated Press profile of the 29-year-old's life behind bars provides a possible answer. Hammond's password was "Chewy 123."

Hashing algorithms protecting encryption keys are by design extremely slow, making cracking attacks harder to carry out. The more guesses the attacker tries the exponentially longer it will take. As demonstrated in previous Ars articles such as Why passwords have never been weaker—and crackers have never been stronger and Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331”, "Chewy 123" would be among the earlier candidates any experienced cracker would try. And assuming agents performed any research on their then suspect, "Chewy 123" would almost certainly have been near the top of the list. "Chewy," it turns out, was the name of Hammond's cat.

Read 1 remaining paragraphs | Comments


An iPhone 5S, Samsung Galaxy S5, LG Nexus 5, and Amazon Fire Phone were all hijacked by whitehats on the first day of an annual hacking contest that pays hefty cash prizes for exploits bypassing security sandbox perimeters.

Day one of the Mobile Pwn2Own competition at the PacSec conference in Tokyo repeated a theme struck over and over at previous Pwn2Own events. If a device runs software, it can be hacked—regardless of claims made by marketers or fans. Organized by the Hewlett-Packard-owned Zero Day Initiative and sponsored this year by Google and Blackberry, Mobile Pwn2Own awards as much as $150,000 for the most advanced hacks, with a total prize pool of $425,000. In exchange, contestants agree to turn over technical details to the organizer and keep them confidential until the underlying vulnerabilities have been patched.

During the first day, according to this HP blog post, the following hacks took place:

Read 2 remaining paragraphs | Comments


We had a number of users suggesting that we should have labeled MS14-066 as Patch Now instead of just critical. This particular vulnerability probably has the largest potential impact among all of the vulnerabilities patched this Tuesday, and should be considered the first patch to apply, in particular on servers.

Just like OpenSSL implements SSL on many Unix systems, SCHANNEL is the standard SSL library that ships with Windows. Expect most Windows software that takes advantage of SSL to use SCHANNEL.

Microsoft stated that this vulnerability will allow remote code execution and that it can be used to exploitservers. Microsoft also assigned this vulnerability an exploitability of 1, indicating that an exploit is likely going to be developed soon. But other then that, very little has been released publicly about the nature of the vulnerability.

There is some conflicting information if the bug was found internally or by a third party. The bulletin states: This security update resolves a privately reported vulnerability [1] . A blog post about the vulnerability states: Internally found during a proactive security assessment. [2] . Finally, Microsofts Acknowledgement page does not list a source for the vulnerability [3]. It is not clear how far outside of Microsoft the vulnerability was known prior to the patch release.

However, as soon as a patch was released, it can be used to learn more about the vulnerability. It is very hard these days to obfuscate a patch sufficiently to hide the nature of a vulnerability.

So what does this mean for you?

My guess is that you probably have a week, maybe less, to patch your systems before an exploit is released. You got a good inventory of your systems? Then you are in good shape to make this work. For the rest (vast majority?): While you patch, also figure out counter measures and alternative emergency configurations.

The most likely target are SSL services that are reachable from the outside: Web and Mail Servers would be on the top of my list. But it cant hurt to check the report from your last external scan of your infrastructure to see if you got anything else. Probably a good idea to repeat this scan if you havent scheduled it regularly.

Next move on to internal servers. They are a bit harder to reach, but remember that you only need one internal infected workstation to expose them.

Third: Traveling laptops and the like that leave your perimeter. They should already be locked down, and are unlikely to listen for inbound SSL connections, but cant hurt to double check. Some odd SSL VPN? Maybe some instant messenger software? A quick portscan should tell you more.

You are doing great if you can get these three groups out of the way by the end of the week. Internal clients are less of an issue, but just like traveling laptops, they may run some software that listens for inbound SSL connections.

Stick with my old advice: Patching is only in part about speed. Dont let speed get in the way of good operations andprocedures. It is at least as important to patch in a controlled, verifiable and reproducible way. Anything else will leave you open to attack due to incomplete patching. Dont forgetto reboot the system or the patch may not take affect.

Microsoft didnt mention any workarounds. But this may change as we learn more about the issue. So make sure that you know how to disable certain ciphers or certain SSL modes of operations. And please take this as an other opportunity to get your inventory of hardware and software sorted out.

Patch Now? Maybe better: Patch first / Patch soon. This vulnerability could turn into a worm like slapper, an OpenSSLworm exploiting Apacheback in the day.

I am not aware of any publicIDS signatures for this problem so far, but it may make sense to check for SSL error even on non-Windows servers to spot possible exploit attempts.

To make things more interesting (confusing?), the Cisco Talos blog states that [w]hile it is covered by only a single CVE, theres actually multiple vulnerabilities, ranging from buffer overflows to certificate validation bypasses. [4] It would be really odd from Microsoft to only use a single CVE number for various vulnerabilities only related by the common library they happen to be found in. But I do give Cisco some credibility here as they are working closely with Microsoft and may have gotten more details from Microsoft then what was published in the bulletin.

Cisco also published a number of Snort rules for MS14-066. If you have a VRT subscription, you should see these rules with an SID from 32404 through 32423.

PLEASE SHARE ANY ATTACK DATA / EXPLOIT SIGHTINGS YOU MAY HAVE ! ( handlers -at- sans.edu or our contact form)


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
CVE-2014-8731 - RCE in phpMemcachedAdmin <=1.2.2
[SECURITY] [DSA 3072-1] file security update
[ESNC-2039348] Multiple Critical Security Vulnerabilities in SAP Governance, Risk and Compliance (SAP GRC)

Infosec industry: Time to put up or shut up
Help Net Security
Infosec industry: Time to put up or shut up. by Brian Honan - CEO BH Consulting - Wednesday, 12 November 2014. The information security industry is one of the most exciting industries to be involved in. It offers many opportunities to exercise one's ...

and more »

Infosec industry: Time to put up or shut up
Help Net Security
Infosec industry: Time to put up or shut up. by Brian Honan - CEO BH Consulting - Wednesday, 12 November 2014. The information security industry is one of the most exciting industries to be involved in. It offers many opportunities to exercise one's ...

and more »
Creative Contact Form 'wp-content/plugins/sexy-contact-form' Arbitrary File Upload Vulnerability
[security bulletin] HPSBST03155 rev.1 - HP StoreFabric H-series switches running Bash Shell, Remote Code Execution
[security bulletin] HPSBGN03191 rev.1 - HP Remote Device Access: Virtual Customer Access System (vCAS) running lighttpd, Remote Disclosure of Information and other Vulnerabilities
[security bulletin] HPSBGN03117 rev.2 - HP Remote Device Access: Virtual Customer Access System (vCAS) running Bash Shell, Remote Code Execution
Missing SSL certificate validation in MercadoLibre app for Android [STIC-2014-0211]
Internet Storm Center Infocon Status