Tuesday, December 29, 2009
Puffer Machines, El Al, and Defense in Depth
Sunday, November 22, 2009
Not Kind, Not Gentle. The turn of the decade in security.
So, now my predictions for the next ten years: Very early in the next decade, online identity theft and banking fraud will replace drug trafficking as the dominant criminal problem worldwide. Cyber cartels will make more money annually than drug cartels. Exploitation will continue to be focused on content-based delivery – that is, malicious documents & media. This will be coupled with a massive growth in online social networking. Trust, as a human concept, will be exploited as a means to spread malware throughout social networks via your online digital identity. Again, we will adopt new technology at a rate faster than we can secure it. The largest domain of attack will be software running on cellular phones. The phone will truly evolve into a network terminal – a slightly thicker thin client, loaded with more software in the palm of your hand than you could cram into a Windows 95 box in the year 2000. Yep, you guessed it, another garden of carnal delights – these new platforms will arrive unsecured – the development tools to make software will be insecure, and the people writing the code aren’t going to give a bug’s butt about secure coding practices. So, cyber crime is going to get a lot worse. Meanwhile, we are going to see at least one major SCADA based terrorist attack. We may have no idea that a terrorist did it, because the authorities will never admit it if they can plausibly lie, but it will happen. In fact, it may have already happened. Security spending will shift as well. Starting now, and reaching a heyday in about 6 years, security spending will shift towards host based security solutions. First the government, and then commercial enterprises, will realize that netflows and gateway solutions are not going to stop malware – it’s just too hard to predict what software will do without actually running it. And, online social relationships will be an extension of our professional identity - in other words, when an employee sits down at his workstation, his entire social network sits down with him. Network based security cannot hope to analyze complex documents and media, much less who to trust and when. Because everything will be hosted online, blocking content will effectively break the Internet, and looking inside the content will never happen at the network gateway (don’t invest in companies that think they can solve that problem). Concepts like malware-tolerance will become a hard reality, people will realize you can't keep the bad guys out. While the majority of online crime will continue to be in banking fraud, we are going to see industrial espionage and state-sponsored attacks in the press more than once. And, while banking fraud hurts the individual, the scope and damage of espionage is far far greater. Whether its classified state secrets or the recipe for Coke makes no difference, when the criminals out there figure out the value of information, they WILL steal it. The next ten years are not going to be kind or gentle to the security space. The hardest hit are going to be the biggest in the space – AV vendors are going to take the hardest fall. Their signature based solutions don’t work today, but not everyone knows that yet. But over time, that truth will seep farther into the IT space. So, perhaps my biggest prediction is this – AV will lose their place as the #1 security expenditure in the Enterprise. I’m not sure what will replace it exactly, but I do know that people are going to stop throwing good money after bad.
Wednesday, July 22, 2009
Blackhat Training is almost here!
Monday, July 13, 2009
Reverse engineering process-injecting malware
I posted a video demonstrating some RE work with Responder:
Process Injecting Malware
The RE process starts by searching a livebin's symbols for "remote". A livebin is the in-memory version of an EXE as extracted by Responder. It’s not an executable format, but instead represents the exact layout of the PE formatted file once it loads into virtual memory. Section information does not need to be interpreted to remap the binary in this case, as the OS loader has already done that, including remapping and any other modifications that are made to the layout of code and data at runtime. Many malware programs will be packed on disk, but the livebin will contain large unpacked sections that can be analyzed without the RE having to know anything about the packing methods used, as in effect they are already unpacked for you.
The symbol "CreateRemoteThread" is of interest. For process injection malware you will find this API call almost 100% of the time. There are a few other API calls that are used in conjunction. We drag the symbol to the canvas and examine the region around it. Specifically, we see WriteProcessMemory and VirtualAllocEx - this is a dead giveaway that process injection is in use. Usually a malware will inject a thread that points to the function "LoadLibrary" with the first argument being a path to a DLL that was decompressed to disk - typically in a temporary directory. This is part of the malware's installation system.
In the example, we find that a PID is used to locate a process to inject into. We follow this PID and find the argument is used with LEA. In this case, the LEA is like using the address-of operator in 'c' code.
Imagine the following code:
void *myFunctionPointer;
some_function_call( &myFunctionPointer );
The "some_function_call" is getting a reference to myFunctionPointer, and this means it has the ability to initialize or assign a value into myFunctionPointer. The LEA instruction you see in the video is the assembly version of this same operation. We see this, and follow the function to find a loop where ToolHelpSnapshot32 is used. The toolhelp API set is another very suspicious behavior - if you see this in a potential malware you are very likely dealing with something that enumerates other processes on the system. This is usually a step prior to injection (or an attempt to find a virus scanner or firewall exe and kill it).
There is a string comparison in the process hunting loop - so the malware author is attempting to find a process by name. We follow the arguments back up and see that it's searching for "explorer.exe". The steps shown in the video require moderate-level RE skills, but are not daunting. With a little practice you can follow arguments in and out of function calls without losing your place. The trick is simply to remember that arguments are usually a positive base off of EBP, and local variables are a negative offset. "Parameters are Positive" - use that rule to remember.
The is one exception that is likely to drive you crazy - malware written in Delphi (and there is ALOT of that) usually passes parameters in registers. This can be harder to follow, but again if you label the arguments going into the function you can see these labels at the function boundaries so you don't lose your place.
Monday, April 27, 2009
There are no isolated networks anymore
Highly specialized networks, such as those that control power grids, or esoteric equipment, such as MRI scanners, are not typically considered at risk from Internet attacks. Yet, the recent conficker worm was able to infect these things. It is important to understand that just because hardware seems specialized and distant, it can still be connected to a TCP/IP network. Even if the equipment doesn't offer a convenient web-addressable interface to hack, it can still have a protocol and perform I/O.
Almost all modern but specialized equipment has embedded TCP/IP capabilities and the associated ethernet jack. Web and TCP/IP based technology is a good choice for machine interfacing and configuration. Browsers eliminate the need for specialized client software. Non-specialized programmers can write code that works with a HTTP or HTTPS interface to provide remote configuration capability - this equals lower software development costs.
Specialized equipment often contains a remote data terminal (RDT) which is like an embedded board that contains a mini-OS, likely based on a linux variant or even something like VXWorks. Newly emerging technology, like System on a Chip (SoC) is both inexpensive, and easy to interface to. Even when an RDT type function is not available, these devices may stream large volumes of data outbound over TCP/IP, with the port intended to be used in a specialized LAN configuration for image capturing or other functions (think medical equipment like MRI scanners or X-Ray machines that are interfacing to the PACS network).
The overall point is that these machines are connected to a network that talks TCP/IP. And, following the very nature of TCP/IP, it's easy to make connections that are unintended. So, even though the MRI scanner is not supposed to be connected to the Internet, the imaging workstation will need to talk with the database in Radiology which is then connected to the Hospital Information System (HIS), which is connected to the Internet. You now have an MRI scanner that is attached to machines that can browse the Internet. This is how Conficker got into Heart Monitors running an old unpatched Win2K systems.
Even old equipment falls prey to these unintended exploit paths. Especially for older SCADA equipment, there are tons of devices that will interface good old serial ports to ethernet and TCP/IP pathways. To lower costs, SCADA networks have been refitted with remote access that is routable over ethernet and TCP/IP. The protocols are old and weird, but anyone who does their research can attack them. Even when not directly connected to the Internet (and yes, sometimes they are), devices like power relays are just a few hops away from the Internet-facing gateway. These devices really do control power for small northeastern towns in the dead of winter.
A large amount of the risk here is simply that specialized networks are connected to the Internet via unintended means. These unintended connections between the so-called “protected” networks, and the totally unpatched open equipment is something like a void. It’s not well audited. In some cases, the IT staff may even be discouraged from auditing. In one factory a few years back, the IT staff were forbidden from even running port scans to inventory the network. Apparently doing so once crashed a SCADA controlled machine on the factory floor, so management had forbidden the practice hence. To make things worse, it's incredibly easy to bridge networks without thinking about the security implications. An end user can co-fuse two networks just by plugging in a cable incorrectly. A network admin may not have an extra switch so they use the existing one out of convenience. There are countless scenarios where it's easier to think of specialized systems as non-internet devices, thus not a problem for security.
When dealing with network security, you should always think of every networked device as containing an operating system. It would not harm your security to even think of them as embedded windows operating systems that are vulnerable to conficker worms. You should never think of them as non-internet devices.
Wednesday, April 8, 2009
Ongoing SCADA Attacks and Network Probes
Recon-probes are malware implants that only scan ports and inventory the resources in the network, then phone home with the data. In many cases, probes are not targeted (not aimed only at your network, but rather like a shotgun approach) - there is an ongoing effort to simply map everything that sits behind the public gateways. In particular, probes have been launched into the US Infrastructure SCADA networks - think power grids and water plants.
Probes will be less complex than a full-blown botnet agent. One component to be on the lookout for is a TCP/IP-only capability - not something that injects into IE or Explorer, but rather a cleaner implant with a port scanning and sniffing capability. These probes will have a C&C backchannel of some kind, but are likely to store their information on disk for a while, as they don't phone home very often. These are forward probes designed to map your network. They may even query the hard-drive serial number via IOCTL's to the NTFS driver, this is for node identification decoupled from the IP address of the host. There will also be a query to see if the box has multiple interfaces.
If you find a probe operation, immediately assume that secondary attack tools have been brought into the network, perhaps in select subnets or on critical gateway machines. Be especially attentive to any sniffing capability on a collision domain near a gateway, or even on the gateway itself. In some cases, secondary capabilities have been dropped that have the ability to shutdown and destroy the computer. If you have captured a probe, immediately check all embedded registry keys and file paths for potential storage locations for secondary equipment.
Saturday, April 4, 2009
Rich and Greg in Va. – Ghillie Suits, AR-15’s, Russian Ammunition and Chinese Malware
The morning was spent discussing how lame Conficker.C turned out to be and how it was most likely just barrage jam… meaning a smoke screen diversion to throw off the scent for the “real” slow and low pdf attacks that were slipping into financial institutions in droves. Then on Friday morning HBGary was lucky enough to receive a nice excel spear phishing attack. Unlike most companies we love this stuff. This gives us something to do over the weekend. Greg and I also discussed our new global services offerings which will soon appear on our web site.
After breakfast Greg and I went to an undisclosed location in the Northern Virginia area, got suited up with Ghillie-Suits, AR-15’s, and a 1000 rounds of Wolf Performance Ammunition from Russia. Our mission was to get from point A to point B without getting caught by numerous “individuals”. If we weren’t caught and we made it to point B, we were then to shoot the 500 rounds each at targets from 25 yards up to 100 yards. We had up to 4 hours to cover the terrain, get to Point B, shoot our rounds and get back to point A. without getting caught; again the main point was not getting caught. It was a great! We covered a crazy amount of territory in a short period of time climbing through all kinds of thick brush and most of it was straight up hill to reach point B. At one point we we’re within 50 yards of some of the “individuals” but remained completely still and since we were in our Ghillie-Suits we remained completely still and remained undetected, just like a good rootkit. ;) We ultimately made it to Point B., where we celebrated by drinking some water and dropping our packs to load our rifles. We target practice with Russian ammunition because it’s cheap, pretty reliable and readily available.
As the sun was setting, we had already infected a VM with one of the recent boobytrapped PDF documents. Using a snapshot and Flypaper, we extracted several binaries with Responder and discovered a running botnet out of Russia. The PDF document immediately grabs a malware loader executable from a hacked chinese website, including a flash module. Once the loader executes, the main loader contacts a bot controller located in the ukraine, and the subsequent payload that is downloaded loads a kernel mode rootkit and a usermode module that communicates with a single drop point - a single commercial hacked website to store a drop point, and from this scripted location, data being emailed to a completely different and single hacked email account. The bot control software is something called "JRoger BManager v1.5" and in this case, was operated from a Russian language asset. We made heavy use of NetWitness Informer to capture C&C traffic and compressed downloads of infection modules. We are now tracking this threat to learn more.
Here are some pics:
The Bot Controller
Responder graph of the usermode portion of the malware
NetWitness really boils off the fat. You can slice and dice the data from a packet capture in so many ways. Here are shots:
Overall a good day.