The hacker responsible for taking down HackingTeam has published a post mortem on how the hack was performed. It's relatively straightforward and there are some lessons that can be learned from it.
Why is this significant?
There's nothing earth shattering in the post - it's pretty much what you would expect. But we rarely get a first hand account of how an attack was conducted and forensic evidence is almost never complete. Organizations should examine this walkthrough and consider how their organizations would stand up in the face of a similar attack.
Entry point
The attacker notes that because Hacking Team had very little publicly exposed infrastructure, he had three choices for a remote exploit:
When working with customers at Rendition Infosec, we regularly find that too much faith is placed in vendors to obtain quality third party security assessments. All too often, the hardware and software these vendors are peddling to unsuspecting victims is plagued with obvious security vulnerabilities. In some cases, no third party assessments have been performed at all prior to selling to the customer. Of course, this fact is almost never disclosed - in fact, I've never seen a sales brochure proudly proclaim "shop with us, we've never had a third party security assessment of our software."
Sometimes vendors will tell you that they have performed internal security assessments. While these are better than nothing, they are hardly unbiased. Again, in my experience with Rendition Infosec, well over a third of claimed "internal security assessments" are found to have been performed by the same development team that created the software in the first place. Ever tried to proofread your own term paper? How well did that work? Yeah, that's what I thought. It's even more ridiculous to think that developers can audit their own code for security flaws.
Pivot
Now that access was gained, the attacker wants to pivot through the device. but most tools aren't available in embedded systems. The attacker notes that he built a custom firmware image with a number of extra tools for pivoting and exfiltrating data.
Without getting into the specifics of the tools and techniques the attacker used, a takeaway here is that monitoring embedded devices is critically important for good network security hygiene. Many monitoring strategies have good coverage for core Windows and Linux endpoints, but completely ignores things like routers, switches, multi function devices, and other appliances with network connections. But these appliances are unfortunately usually the weakest link in our network infrastructure.
Organizations wishing to avoid repeating Hacking Team's mistakes should take inventory of their embedded devices and baseline normal network traffic to the devices. Only when you know what normal looks like can you discover deviations from the baseline. These deviations may be misconfigurations or they may be attackers using your network devices to pivot mercilessly through the network.
Stay tuned
Same bat time, same bat channel. Tune back in and we'll talk about a few more lessons learned from the Hacking Team breach walkthrough.
Why is this significant?
There's nothing earth shattering in the post - it's pretty much what you would expect. But we rarely get a first hand account of how an attack was conducted and forensic evidence is almost never complete. Organizations should examine this walkthrough and consider how their organizations would stand up in the face of a similar attack.
The attacker notes that because Hacking Team had very little publicly exposed infrastructure, he had three choices for a remote exploit:
look for a 0day in Joomla, look for a 0day in postfix, or look for a 0day in one of the embedded devices. A 0day in an embedded device seemed like the easiest option, and after two weeks of work reverse engineering, I got a remote root exploit.Security researchers know how poorly most software/firmware for embedded devices is built, so it's no surprise that this was the route the attacker chose.
When working with customers at Rendition Infosec, we regularly find that too much faith is placed in vendors to obtain quality third party security assessments. All too often, the hardware and software these vendors are peddling to unsuspecting victims is plagued with obvious security vulnerabilities. In some cases, no third party assessments have been performed at all prior to selling to the customer. Of course, this fact is almost never disclosed - in fact, I've never seen a sales brochure proudly proclaim "shop with us, we've never had a third party security assessment of our software."
Sometimes vendors will tell you that they have performed internal security assessments. While these are better than nothing, they are hardly unbiased. Again, in my experience with Rendition Infosec, well over a third of claimed "internal security assessments" are found to have been performed by the same development team that created the software in the first place. Ever tried to proofread your own term paper? How well did that work? Yeah, that's what I thought. It's even more ridiculous to think that developers can audit their own code for security flaws.
Pivot
Now that access was gained, the attacker wants to pivot through the device. but most tools aren't available in embedded systems. The attacker notes that he built a custom firmware image with a number of extra tools for pivoting and exfiltrating data.
Without getting into the specifics of the tools and techniques the attacker used, a takeaway here is that monitoring embedded devices is critically important for good network security hygiene. Many monitoring strategies have good coverage for core Windows and Linux endpoints, but completely ignores things like routers, switches, multi function devices, and other appliances with network connections. But these appliances are unfortunately usually the weakest link in our network infrastructure.
Organizations wishing to avoid repeating Hacking Team's mistakes should take inventory of their embedded devices and baseline normal network traffic to the devices. Only when you know what normal looks like can you discover deviations from the baseline. These deviations may be misconfigurations or they may be attackers using your network devices to pivot mercilessly through the network.
Stay tuned
Same bat time, same bat channel. Tune back in and we'll talk about a few more lessons learned from the Hacking Team breach walkthrough.
thanks Jake
ReplyDelete