Popular Printers Pwned In Prodigious Page Prank

February 4, 2017 by Jenny List 40 Comments

A new day dawns, and we have another story involving insecure networked devices. This time it is printers of all makes and descriptions that are causing the panic, as people are finding mystery printouts bearing messages such as this:

“Stackoverflowin has returned to his glory, your printer is part of a botnet, the god has returned“

Well that’s it then, you can’t argue with a deity, especially one who has apparently created a botnet from the world’s printing devices. Printer owners the world over are naturally worried about their unexpected arrival, and have appeared on support forums and the like to express their concern.

We are of course used to taking everything our printers tell us at face value. Low on ink? I hear you, my inanimate reprographic friend! But when our printer tells us it’s part of a botnet perhaps it’s time to have a little think. It is entirely possible that someone could assemble a botnet of compromised printers, but in this case we smell a rat. Only in farcical crime dramas do crooks announce their crimes in such a theatrical fashion, you might say it’s the point of a botnet not to be detected by its host. Reading some of the reports it seems that many of the affected systems have port 9100 open to the world, that’s the standard TCP printer port, so it seems much more likely that someone has written a little script that looks for IP addresses with port 9100 open, and trolls them with this message.

The real message here is one with which we expect Hackaday readers will be very familiar, and which we’ve covered before. Many network connected appliances have scant regard for security, and are a relative push-over for an attacker. The solution is relatively straightforward to those of a technical inclination, be aware of which services the devices is exposing, lock down services such as uPNP and close any open ports on your router. Unfortunately these steps are probably beyond many home users, whose routers remain with their default manufacturer’s settings for their entire lives. It’s a shame our printer troll didn’t add a link to basic router security tips.

If you want to have a little fun, some of the printed pages include an email address for ‘the god’. It would be fun to figure out who this is, right?

Jamming WiFi By Jumping On The ACK

February 3, 2017 by Mike Szczys 27 Comments

As we fill our airwaves with more and more wirelessly connected devices the question of what could disrupt this systems becomes more and more important. Here’s a particularly interesting example because the proof of concept shows that you don’t need specialized hardware to pull it off. [Bastian Bloessl] found an interesting tweak to previous research that allows an Atheros WiFi card to jam WiFi by obscuring ACK frames.

The WiFi protocol specifies an Acknowledgement Frame (ACK) which is sent by the receiving device after error correction has been performed. It basically says: “yep, I got that data frame and it checks out”. This error correcting process turns out to be the key to [Bastian’s] technique as it provides time for the attack hardware to decide if it’s going to jam the ACK or not.

The jamming technique presented by [Mathy Vanhoef] at the end 2014 outlined both constant and selective jamming. The selective part involved listening for data packets and analyzing them to determine if they are headed to a MAC the attacker wishes to jam. The problem is that by the time your commodity hardware has decoded that address it’s too late to jam the packet. [Bastian] isn’t trying to jam the data frame, he’s jamming the ACK that the receiver sends back. Without that acknowledgement, the sender will not transmit any new data frames as it assumes there is a problem on the receiving end.

Hacking The Aether: How Data Crosses The Air-Gap

February 2, 2017 by Pedro Umbelino 35 Comments

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?

February 1, 2017 by Elliot Williams 49 Comments

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.

Cryptographically 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

January 24, 2017 by Pedro Umbelino 29 Comments

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

January 17, 2017 by Brian Benchoff 29 Comments

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

January 13, 2017 by Lewin Day 22 Comments

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.