Information Security News
Fireeye posted a story earlier today outlining a zero day affecting XP and Windows 2003:
Microsoft has followed it up with a matching post:
Microsoft Security Advisory (2914486): Vulnerability in Microsoft Windows Kernel Could Allow Elevation of Privilege:
Note that the temporary fix outlined breaks some windows features, specifically some IPSEC VPN functions.
The real story here isn't the zero day or the workaround fix, or even that Adobe is involved. The real story is that this zero day is just the tip of the iceberg. Malware authors today are sitting on their XP zero day vulnerabilities and attacks, because they know that after the last set of hotfixes for XP is released in April 2014 (which we're now officially calling "WinMageddon"), that their exploits will work forever against hundreds of thousands (millions?) of XP workstations. ( http://windows.microsoft.com/en-us/windows/lifecycle )
If you are still running Windows XP, there is no project on your list that is more important than migrating to Windows 7 or 8. The "never do what you can put off until tomorrow" project management approach on this is on a ticking clock, if you leave it until April comes you'll be migrating during active hostilities.
Researchers have discovered a Linux worm capable of infecting a wide range of home routers, set-top boxes, security cameras, and other consumer devices that are increasingly equipped with an Internet connection.
Linux.Darlloz, as the worm has been dubbed, is now classified as a low-level threat, partly because its current version targets only devices that run on CPUs made by Intel, Symantec researcher Kaoru Hayashi wrote in a blog post published Wednesday. But with a minor modification, the malware could begin using variants that incorporate already available executable and linkable format (ELF) files that infect a much wider range of "Internet-of-things" devices, including those that run chips made by ARM and those that use the PPC, MIPS, and MIPSEL architectures.
"Upon execution, the worm generates IP addresses randomly, accesses a specific path on the machine with well-known ID and passwords, and sends HTTP POST requests, which exploit the vulnerability," Hayashi explained. "If the target is unpatched, it downloads the worm from a malicious server and starts searching for its next target. Currently, the worm seems to infect only Intel x86 systems, because the downloaded URL in the exploit code is hard-coded to the ELF binary for Intel architectures."
I was working with a client recently, working through the move of a Credit Union branch. In passing, he mentioned that they were looking at a new security camera setup, and the vendor had mentioned that it would need a SPAN or MIRROR port on the switch set up. At that point my antennae came online - SPAN or MIRROR ports set up a session where all packets from one switch ports are "mirrored" to another switch port. Needless to say, this is not something you want to do for fun and giggles in a bank!
Anyway, I asked what the SPAN port was for, and the answer was that the camera server is set to capture the packets from the ATMs. Apparently this has full support from the banking service providers and law enforcement, as it allows them to tie a fraudulent/suspect ATM transaction directly to the associated video clip of the person keying it in. No tedious fast forward / reverse on the video, and hoping your timestamps all match up.
OK, but at that point it started to sound bad-bad-bad from a PCI perspective. The question in my mind at that point was - did the banking provider give up their encryption keys to the video company, or is the ATM transaction data not as encrypted as it should be?
So, time to break out wireshark and take a look? The answer to that question would be a resounding NO. It was time to ask for PERMISSION to capture a test transaction. If you've taken SANS SEC504 or SEC560 (or any of several other classes), you know that some days, the biggest difference between a successful security consultant and a potential convict is permission.
A week later, with permission in hand and my client with me, we did couple of $20 withdrawals and caught them "on film". What we found was a 3rd possibility, and if I had thought it through I should have anticipated this result. The transaction was all encrypted as we expected on tcp/3002, or at least obfuscated enough that the encoding wasn't obvious (I'll be digging a bit more into that, stay tuned). But when it came time to print the receipt, the exact character-by-character text of the receipt printout is in clear 8-bit-ASCII text, all in one packet (including the required CRLFs, spaces and tabs) . And when you opt to not print a transaction receipt, that "receipt packet" is still sent.
If you've ever looked closely at an ATM receipt, the date, time, ATM identifier and often the street address will be printed, along with the dollar amounts and specifics of the transaction. But the actual account identifiers are mostly represented by "*" characters, with just enough of the number exposed so that you can verify that things happened as they should. Most of the captured packet below is blurred out (sorry, but it's against my actual account), but you can see some of the text clearly, and it's exactly as printed on the paper receipt.
As a side note, if you ever are in a position to look at a capture of this type though, you might find TCPDUMP easier to work with than Wireshark - Wireshark wants to decode this as IPA (GSM over IP), and of course that means all the decodes are messed up. It's much easier in cases like this to just look at the hex representations of the packets.
So the stuff we really want protected is still protected, but there's enough exposed in that receipt packet that our friends in law enforcement can tie the video to the transaction, with help from the folks on the banking side. A reasonable compromise I think, but take a look at your receipt next time you make an ATM withdrawal.
Are you OK with the data on that slip of paper being sent in the clear?
If you are a QSA, are you still OK with it?
If I've missed anything, or if you've got an opinion (in either direction) on this, please use our comment form to post!
=============== Rob VandenBrink Metaforehttp://httpd.apache.org/download.cgi#apache24(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.