I recently spent a largely sleepless night at a hotel, and out of equal parts curiosity and boredom, decided to kill some time scanning the guest network to see what my fellow travelers might be up to. As you’d probably expect, I saw a veritable sea of Samsung and Apple devices. But buried among the seemingly endless number of smartphones charging next to their sleeping owners, I found something rather interesting. I was as picking up a number of Amazon-made devices, all of which had port 5555 open.
As a habitual Android tinkerer, this struck me as very odd. Port 5555 is used for Android Debug Bridge (ADB), a development tool used to control and perform various administrative tasks on an Android device over the network or (more commonly) locally over USB. The number of users who would have legitimately needed to enable network ADB on their devices is surely rather low, so to see a half dozen of them on the network at the same time seemed improbable to say the least.
Why would so many devices manufactured by Amazon all have network ADB enabled? I realized there must be a connection, and it didn’t take long to figure it out.
Fingerprinting text is really very nifty; the ability to encode hidden data within a string of characters opens up a large number of opportunities. For example, someone within your team is leaking confidential information but you don’t know who. Simply send each team member some classified text with their name encoded in it. Wait for it to be leaked, then extract the name from the text — the classic canary trap.
Here’s a method that hides data in text using zero-width characters. Unlike various other ways of text fingerprinting, zero width characters are not removed if the formatting is stripped, making them nearly impossible to get rid of without re-typing the text or using a special tool. In fact you’ll have a hard time detecting them at all – even terminals and code editors won’t display them.
To make the process easy to perform, [Vedhavyas] created a command line utility to embed and extract a payload using any text. Each letter in the secret message is converted to binary, then encoded in zero-width characters. A zero-width-non-joiner character is used for 0, and a zero-width-space character for 1.
Of course, to get your encoding game really tight, you should be looking at getting yourself an enigma wristwatch…
You might be surprised to find out that it’s actually not a good idea to put all of your credit card information on a little Bluetooth enabled device in your pocket. Oh, what’s that? You knew already? Well in that case you won’t find the following information terribly shocking, but it’s still a fascinating look at how security researchers systematically break down a device in an effort to find the chinks in its armor.
[Mike Ryan] of ICE9 Consulting has recently published an article detailing the work done to examine and ultimately defeat the security on the FUZE Card. From using an x-ray machine to do non-destructive reconnaissance on the device’s internals to methodically discovering all the commands it responds to over Bluetooth, it’s safe to say the FUZE Card is cracked wide open at this point.
To be clear, the attacker must still pair with FUZE, so physical access is required. But as pointed out by [Mike] in the blog post, handing your card over to a merchant is standard operating procedure in many cases. It isn’t as if it would be hard to get a hold of one of these FUZE cards for a minute or two without the owner becoming suspicious. Pairing FUZE to the Linux device to continue to the next step of the attack only takes a few seconds, as demonstrated in the video after the break.
Once paired, the attacker can simply send a BLE command to FUZE which disables the lock screen. It’s really that simple. The attacker can also send commands to dump credit card info over Bluetooth, meaning they could download your information even when the card is “safely” back in your pocket. The inherent failure in the FUZE design is that you don’t need to provide any sort of authentication to pair it to a new Bluetooth device. It makes the (very dangerous) assumption that the person holding it is entitled to do so.
Even if you know better than to ever buy a device like this, the post [Mike] has written up is really a must-read for anyone who’s ever looked at a device and tried to figure out what was going on in its little silicon brain. We especially liked his assertion that reverse engineering a device essentially boils down to: “staring, thinking, a little experimentation, but mostly staring and thinking.” We’re having an internal debate here at Hackaday HQ about making that the site’s tagline.
Apple’s commitment to customer privacy took the acid test after the San Bernadino shooting incident. Law enforcement demanded that Apple unlock the shooter’s phone, and Apple refused. Court cases ensued. Some people think that the need to protect the public outweighs the need for privacy. Some people think that once they can unlock one iPhone, it won’t stop there and that will be bad for everyone. This post isn’t about either of those positions. The FBI dropped their lawsuit against Apple. Why? They found an Israeli firm that would unlock the phone for about $5,000. In addition, Malwarebytes — a company that makes security software — reports that law enforcement can now buy a device that unlocks iPhones from a different company.
Little is known about how the device — from a company called Grayshift — works. However, Malwarebytes has some unverified data from an unnamed source. Of course, the exploit used to break the iPhone security is secret because if Apple knew about it, they’d fix it. That’s happened before with a device called IP-box that was widely used for nefarious purposes.
As far as hobbies go, auditing high security external hard drives is not terribly popular. But it’s what [Raphaël Rigo] is into, and truth be told, we’re glad it’s how he gets his kicks. Not only does it make for fascinating content for us to salivate over, but it’s nice to know there’s somebody with his particular skill set out there keeping an eye out for dodgy hardware.
The latest device to catch his watchful eye is the Aigo “Patriot” SK8671. In a series of posts on his blog, [Raphaël] tears down the drive and proceeds to launch several attacks against it until he finally stumbles upon the trick to dump the user’s encryption PIN. It’s not exactly easy, it did take him about a week of work to sort it all out, but it’s bad enough that you should probably take this particular item off the wishlist on your favorite overseas importer.
[Raphaël] treats us to a proper teardown, including gratuitous images of chips under the microscope. He’s able to identify a number of components on the board, including a PM25LD010 SPI flash chip, Jmicron JMS539 USB-SATA controller, and Cypress CY8C21434 microcontroller. By hooking his logic analyzer up to the SPI chip he was able to dump its contents, but didn’t find anything that seemed particularly useful.
The second post in the series has all the gory details on how he eventually gained access to the CY8C21434 microcontroller, including a description of the methods which didn’t work (something we always love to see). [Raphaël] goes into great detail about the attack that eventually busted the device open: “cold boot stepping”. This method allowed him to painstakingly copy the contents of the chip’s flash; pulling 8192 bytes from the microcontroller took approximately 48 hours. By comparing flash dumps he was able to eventually discover where the PIN was being stored, and as an added bonus, found it was in plaintext. A bit of Python later, and he had a tool to pull the PIN from the drive’s chip.
Of all the ways to open up a lock, there are some tried and true methods. Keys, combinations, RFIDs, picks, and explosives have all had their time and place, but now someone else wants to try something new. [Erik] has come up with a lock that opens when it is shown a pattern of colors.
The lock in question uses a set of color coded cards as the “keys”. When the cards are inserted in the lock, a TCS230 color sensor interprets the pattern on the cards and sends the information over to an Arduino Uno. From there, the Arduino can command the physical lock to open if the pattern is a match, although [Erik] is still waiting on the locking mechanism to arrive while he continues to prototype the device.
This is a fairly unique idea with a number of upsides. First, the code can’t be “stolen” from inside a wallet like RFID cards can. (Although if you can take a picture of the card all bets are off.) If you lose your key, you can simply print another one, and the device is able to handle multiple different keys and log the usage of each one. Additionally, no specialized equipment is needed to create the cards, unlike technologies that rely on magnetic strips. Of course, there’s always this classic way of opening doors if you’d rather go old school with your home locks.
Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.
We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.
This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.
So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.
Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway. And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more