Hacking the Aether: How Data Crosses the Air-Gap

It is incredibly interesting how many parts of a computer system are capable of leaking data in ways that is hard to imagine. Part of securing highly sensitive locations involves securing the computers and networks used in those facilities in order to prevent this. These IT security policies and practices have been evolving and tightening through the years, as malicious actors increasingly target vital infrastructure.

Sometimes, when implementing strong security measures on a vital computer system, a technique called air-gapping is used. Air-gapping is a measure or set of measures to ensure a secure computer is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network. Sometimes it’s just ensuring the computer is off the Internet. But it may mean completely isolating for the computer: removing WiFi cards, cameras, microphones, speakers, CD-ROM drives, USB ports, or whatever can be used to exchange data. In this article I will dive into air-gapped computers, air-gap covert channels, and how attackers might be able to exfiltrate information from such isolated systems.

Continue reading “Hacking the Aether: How Data Crosses the Air-Gap”

33C3: How Can You Trust Your Random Numbers?

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

mpv-shot0012-zoomCryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?”

MalDuino — Open Source BadUSB

MalDuino is an Arduino-powered USB device which emulates a keyboard and has keystroke injection capabilities. It’s still in crowdfunding stage, but has already been fully backed, so we anticipate full production soon. In essence, it implements BadUSB attacks much like the widely known, having appeared on Mr. Robot, USB Rubber Ducky.

It’s like an advanced version of HID tricks to drop malicious files which we previously reported. Once plugged in, MalDuino acts as a keyboard, executing previous configured key sequences at very fast speeds. This is mostly used by IT security professionals to hack into local computers, just by plugging in the unsuspicious USB ‘Pen’.

[Seytonic], the maker of MalDuino, says its objective is it to be a cheaper, fully open source alternative with the big advantage that it can be programmed straight from the Arduino IDE. It’s based on ATmega32u4 like the Arduino Leonardo and will come in two flavors, Lite and Elite. The Lite is quite small and it will fit into almost any generic USB case. There is a single switch used to enable/disable the device for programming.

The Elite version is where it gets exciting. In addition to the MicroSD slot that will be used to store scripts, there is an onboard set of dip switches that can be used to select the script to run. Since the whole platform is open sourced and based on Arduino, the MicroSD slot and dip switches are entirely modular, nothing is hardcoded, you can use them for whatever you want. The most skilled wielders of BadUSB attacks have shown feats like setting up a fake wired network connection that allows all web traffic to be siphoned off to an outside server. This should be possible with the microcontroller used here although not native to the MalDuino’s default firmware.

For most users, typical feature hacks might include repurposing the dip switches to modify the settings for a particular script. Instead of storing just scripts on the MicroSD card you could store word lists on it for use in password cracking. It will be interesting to see what people will come up with and the scripts they create since there is a lot of space to tinker and enhanced it. That’s the greatness of open source.

Continue reading “MalDuino — Open Source BadUSB”

Shmoocon 2017: The Ins And Outs Of Manufacturing And Selling Hardware

Every day, we see people building things. Sometimes, useful things. Very rarely, this thing becomes a product, but even then we don’t hear much about the ins and outs of manufacturing a bunch of these things or the economics of actually selling them. This past weekend at Shmoocon, [Conor Patrick] gave the crowd the inside scoop on selling a few hundred two factor authentication tokens. What started as a hobby is now a legitimate business, thanks to good engineering and abusing Amazon’s distribution program.

The product in question is the U2F Zero, an open source U2F token for two-factor authentication. It’s built around the Atmel/Microchip ATECC508A crypto chip and is, by all accounts, secure enough. It’s also cheap at about $0.70 a piece, and the entire build comes to about $3 USD. All of this is hardware, and should be extremely familiar to the regular Hackaday reader. This isn’t the focus of [Conor]’s talk though. The real challenge is how to manufacture and sell these U2F dongles, a topic we looked in on back in September.

The circuit for this U2F key is basically just a crypto chip and a USB microcontroller, each of which needs to be programmed separately and ideally securely. The private key isn’t something [Conor] wants to give to an assembly house, which means he’s programming all these devices himself.

For a run of 1100 units, [Conor] spent $350 on PCB, $3600 for components and assembly, $190 on shipping and tariffs from China, and an additional $500 for packaging on Amazon. That last bit pushed the final price of the U2F key up nearly 30%, and packaging is something you have to watch if you ever want to sell things of your own.

For distribution, [Conor] chose Fulfillment By Amazon. This is fantastically cheap if you’re selling a product that already exists, but of course, [Conor]’s U2F Zero wasn’t already on Amazon. A new product needs brand approval, and Amazon would not initially recognize the U2F Zero brand. The solution to this was for [Conor] to send a letter to himself allowing him to use the U2F Zero brand and forward that letter to the automated Amazon brand bot. Is that stupid? Yes. Did it work? Also yes.

Sales were quiet until [Conor] submitted a tip to Hacker News and sold about 70 U2F Zeros in a day. After that, sales remained relatively steady. The U2F Zero is now a legitimate product. Even though [Conor] isn’t going to get rich by selling a dozen or so U2F keys a day, it’s still an amazing learning experience and we’re glad to have sat in on his story of bootstrapping a product, if only for the great tip on getting around Amazon’s fulfillment policies.

TruffleHog Sniffs Github for Secret Keys

Secret keys are quite literally the key to security in software development. If a malicious actor gains access to the keys securing your data, you’re toast. The problem is, to use keys, you’ve got to write them down somewhere – oftentimes in the source code itself. TruffleHog has come along to sniff out those secret keys in your Github repository.

It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.

Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.

For a real world example of stolen secret keys, read up on this HDMI breakout that sniffs HDCP keys.

Super Mario Run(s) — Away With Your Money

If you are an Android user and a big fan of Super Mario beware: there is no Android version! There has been no official news on the Android version yet, let alone a version of the game. There is, however, a version circulating outside of Google Play market that will steal your bank account.

Right now attackers are taking advantage of the game’s popularity and Android users despair to spread malware posing as an Android version of Super Mario Run as they did in the past for Pokemon GO. The trojan is called Android Marcher and has been around since 2013, mostly targeting mobile users financial information. After installation, the application attempts to trick users with fake finance apps and a credit card page in an effort to capture banking details. The malware also locks out Google Play until the user supplies their credit card information.

In this new variant of Marcher, it can monitor the device and steal login data of regular apps, not just banking and payment apps, and send the stolen data back to command and control (C&C) servers. Facebook, WhatsApp, Skype, Gmail, the Google Play store are all vulnerable. Criminals can exploit these stolen accounts to carry out additional fraud.

Zscaler researchers advice is:

To avoid becoming a victim of such malware, it is a good practice to download apps only from trusted app stores such as Google Play. This practice can be enforced by unchecking the “Unknown Sources” option under the “Security” settings of your device.

We may add to turn on “App Verification”. Verify Apps regularly checks activity on your device and prevents or warns you about potential harm. Verify Apps is on by default, as is Unknown Sources turned off. Verify Apps also checks apps when you install them from sources other than Google Play. Of course, there is a privacy trade-off. Some information has to be sent about the apps you install back to Google.

The main advice is: use common sense. It’s common practice for companies to release official apps versions through Google Play and highly unlikely to do it via any other way.

OWL Insecure Internet of Energy Monitors

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.