Security Hacks

1537 Articles

UEFI-Hacked

Gigabytes The Dust With UEFI Vulnerabilities

April 4, 2017 by 46 Comments

At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.

Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.

The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.

Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.

With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.

Canary For USB Ports

April 4, 2017 by 12 Comments

If you’re a paranoid system admin, [errbufferoverfl] has your back with software that keeps track of whenever someone plugs in or disconnects an USB-based device from a workstation.

Christened USB Canary, [errbufferoverfl’s] tool is written in Python. However, even though Python is cross-platform, USB Canary only works on Linux currently. But, fret not: [errbufferoverfl] is already working on Windows and Mac versions.

Primarily, USB Canary watches USB connectors for any activity and logs anything it sees. Moreover, when a USB device is plugged in or unplugged, USB Canary can alert the owner of the workstation via an SMS message courtesy of the Twilio API, post a message in a Slack channel or even make a noise to alert a nearby sysadmin. Additionally, USB Canary can be configured to only run when the workstation is locked (if you’re not completely paranoid).

[errbufferoverfl’s] USB Canary was born out of dissatisfaction with current workstation monitoring tools. You see, most tools only notify users after someone has logged on. [errbufferoverfl] points out that there are means to automate attacks without logging in, and we can think of many unsavory things that can be done when logged out.

While USB Canary won’t protect you from -220V , it might at least warn of a BadUSB attack. But, for the really paranoid, why not try GoodUSB?

[via bleepingcomputer]

California Looks To Compel IoT Security

April 3, 2017 by 32 Comments

There is a bill going through committee in the state of California which, if passed, would require a minium level of security for Internet of Things devices and then some. California SB 327 Information privacy: connected devices in its original form calls for connected device manufacturers to secure their devices, protect the information they collect or store, indicate when they are collecting it, get user approval before doing so, and be proactive in informing users of security updates:

require a manufacturer that sells or offers to sell a connected device, defined as any device, sensor, or other physical object that is capable of connecting to the Internet, directly or indirectly, or to another connected device, to equip the device with reasonable security features appropriate to the nature of the device and the information it may collect, contain, or transmit, that protect it from unauthorized access, destruction, use, modification, or disclosure, and to design the device to indicate when it is collecting information and to obtain consumer consent before it collects or transmits information, as specified. The bill would also require a person who sells or offers to sell a connected device to provide a short, plainly written notice of the connected device’s information collection functions at the point of sale, as specified. The bill would require a manufacturer of a connected device to provide direct notification of security patches and updates to a consumer who purchases the device.

This is just a proposal and will change as it finds its way through committee. Currently there a really no methods of punishment outlined, but recent comments have suggested individual prosecutors may have latitude to interpret these cases as they see fit. Additionally it has been suggested that the devices in question would be required to notify in some way the user when information is being collected. No language exists yet to clarify or set forth rules on this matter.

The security community has been sounding the cry of lackluster (often lack of) security on this growing army of IoT hardware and we’ve all known one day the government would get involved. Often this type of action requires a major event where people were in some way harmed either physically or financially that would push this issue. Denial of service attacks have already occurred and hijacking of webcams and such are commonplace. Perhaps what we saw in September finally pushed this into the limelight.

Any reasonable person can see the necessity of some basic level of security such as eliminating default passwords and ensuring the security of the data. The question raised here is whether or not the government can get this right. Hackaday has previously argued that this is a much deeper problem than is being addressed in this bill.

The size of California’s economy (relative to both the nation and the world) and the high concentration of tech companies make it likely that standards imposed if this law passes will have a large effect on devices in all markets.

Revealing Capcom’s Custom Silicon Security

April 3, 2017 by 52 Comments

Ask any security professional and they’ll tell you, when an attacker has hardware access it’s game over. You would think this easily applies to arcade games too — the very nature of placing the hardware in the wild means you’ve let all your secrets out. Capcom is the exception to this scenario. They developed their arcade boards to die with their secrets through a “suicide” system. All these decades later we’re beginning to get a clear look at the custom silicon that went into Capcom’s coin-op security.

Alas, this is a “part 1” article and like petulant children, we want all of our presents right now! But have patience, [Eduardo Cruz] over at ArcadeHacker is the storyteller you want to listen to on this topic. He is part of the team that figured out how to “de-suicide” the CP2 protections on old arcade games. We learned of that process last September when the guide was put out. [Eduardo] is now going through all the amazing things they learned while figuring out that process.

These machines — which had numerous titles like Super Street Fighter II and Marvel vs. Capcom — used battery-backed ram to store an encryption key. If someone tampered with the system the key would be lost and the code stored within undecipherable thanks to “two four-round Feistel ciphers with a 64-bit key”. The other scenario is that battery’s shelf life simply expires and the code is also lost. This was the real motivation behind the desuicide project.

An overview of the hardware shows that Capcom employed at least 11 types of custom silicon. As the board revisions became more eloquent, the number of chips dropped, but they continued to employ the trick of supplying each with battery power, hiding the actual location of the encryption key, and even the 68000 processor core itself. There is a 6-pin header that also suicides the boards; this has been a head-scratcher for those doing the reverse engineering. We assume it’s for an optional case-switch, a digital way to ensure you void the warranty for looking under the hood.

Thanks for walking us through this hardware [Eduardo], we can’t wait for the next installment in the series!

Cerebrum: Mobile Passwords Lifted Acoustically With NASB

April 1, 2017 by 35 Comments

 

There are innumerable password hacking methods but recent advances in acoustic and accelerometer sensing have opened up the door to side-channel attacks, where passwords or other sensitive data can be extracted from the acoustic properties of the electronics and human interface to the device. A recent and dramatic example includes the hacking of RSA encryption  simply by listening to the frequencies of sound a processor puts out when crunching the numbers.

Now there is a new long-distance hack on the scene. The Cerebrum system represents a recent innovation in side-channel password attacks leveraging acoustic signatures of mobile and other electronic devices to extract password data at stand-off distances.

Continue reading “Cerebrum: Mobile Passwords Lifted Acoustically With NASB” →

Russian Hackers Domain Fronting

March 28, 2017 by 51 Comments

FireEye just put out a report on catching the Russian hacker group “Advanced Persistent Threat 29” (APT29, for lack of a better code name) using the meek plugin for TOR to hide their traffic. If you’re using meek with meek-reflect.appspot.com, you’ll find it’s been shut down. If all of this is gibberish to you, read on for a breakdown.

meek is a clever piece of software. Imagine that you wanted to communicate with the Tor anonymizing network, but that you didn’t want anyone to know that you were. Maybe you live in a country where a firewall prevents you from accessing the full Web, and blocks Tor entry nodes as part of their Great Firewall. You’d want to send traffic somewhere innocuous first, and then bounce it over to Tor, in order to communicate freely.

That’s what meek does, but it goes one step further. The reflector server is hosted using the same content-delivery network (CDN) as a popular service, say Google’s search engine. The CDN has an IP address, like every other computer on the Internet, but it delivers content for any of the various services it hosts. Traffic to the CDN, encrypted with TLS, looks the same whether it’s going to the meek reflector or to Google, so nobody on the outside can tell whether it is a search query or packets destined for Tor. Inside the CDN, it’s unencrypted and passed along to the reflector.

Anyway, meek was invented to help bring the uncensored Internet to people who live in oppressive regimes, and now cybersecurity researchers have observed it being used by Russian state hackers to hide their tracks. Sigh. Technology doesn’t know which side it’s on — the same backdoor that the FBI wants to plant in all our communications can be used by the mafia just as easily. Plugins that are meant to bring people freedom of speech can just as easily be used to hide the actions of nation-state hackers.

What a strange world we live in.

A Red Teamer’s Guide To Pivoting

March 25, 2017 by 22 Comments

What is hacking and what is network engineering? We’re not sure where exactly to draw the lines, but [Artem]’s writeup of pivoting is distinctly written from the (paid) hacker’s perspective.

Once you’re inside a network, the question is what to do next. “Pivoting” is how you get from where you are currently to where you want to be, or even just find out what’s available. And that means using all of the networking tricks available. These aren’t just useful for breaking into other people’s networks, though. We’ve used half of these tools at one time or another just running things at home. The other half? Getting to know them would make a rainy-day project.

Is there anything that ssh and socat can’t do? Maybe not, but there are other tools (3proxy and Rpivot) that will let you do it easier. You know how clients behind a NAT firewall can reach out, but can’t be reached from outside? ssh -D will forward a port to the inside of the network. Need to get data out? There’s the old standby iodine to route arbitrary data over DNS queries, but [Artem] says dnscat2 works without root permissions. (And this code does the same on an ESP8266.)

Once you’ve set up proxies inside, the tremendously useful proxychains will let you tunnel whatever you’d like across them. Python’s pty shell makes things easier to use, and tsh will get you a small shell on the inside, complete with file-transfer capabilities.

Again, this writeup is geared toward the pen-testing professional, but you might find any one of these tools useful in your own home network. We used to stream MP3s from home to work with some (ab)use of netcat and ssh. We keep our home IoT devices inside our own network, and launching reverse-proxies lets us check up on things from far away without permanently leaving the doors open. One hacker’s encrypted tunnel is another man’s VPN. Once you know the tools, you’ll find plenty of uses for them. What’s your favorite?

Thanks [nootrope] for the indirect tip!