It Might Be Possible To Build A Stingray With A Raspberry Pi

November 19, 2018 by Brian Benchoff 32 Comments

If there’s one thing that’s making you insecure, it’s your smartphone. Your smartphone is constantly pinging the cell towers, giving out your location and potentially leaking your private information to anyone with a radio. This is the idea behind an IMSI catcher, or Stingray in common parlance, and now you too can build one with parts you can buy off of Amazon.

The key to this hack is a software defined radio dongle, or RTL-SDR, that has been repurposed to listen in on a GSM network. Literally the only hardware required is an RTL-SDR that can be bought online for less than fifteen dollars, and you can identify the IMSI, or unique ID linked to every SIM card, in smartphones around you. The only bit of software required is a small Python script from [Oros42], freely available on GitHub.

Of course, building an IMSI catcher with a desktop is of limited utility, and using a laptop is still a bit too bulky to surreptitiously conceal in a public location. No, to really get the bang for your buck out of this, you need to do this with a small single-board computer running off a battery pack. Luckily, [Joseph Cox] over at Motherboard reports, “It is likely possible” to run this on a Raspberry-Pi. We’re guessing it’s even more than “likely” possible.

Hack My House: Opening Raspberry Pi To The Internet, But Not The Whole World

November 14, 2018 by Jonathan Bennett 29 Comments

If you’ve followed along with our series so far, you know we’ve set up a network of Raspberry Pis that PXE boot off a central server, and then used Zoneminder to run a network of IP cameras. Now that some useful services are running in our smart house, how do we access those services when away from home, and how do we keep the rest of the world from spying on our cameras?

Before we get to VPNs and port forwarding, there is a more fundamental issue: Do you trust your devices? What exactly is the firmware on those cheap cameras really doing? You could use Wireshark and a smart switch with port mirroring to audit the camera’s traffic. How much traffic would you need to inspect to feel confident the camera never sends your data off somewhere else?

Thankfully, there’s a better way. One of the major features of surveillance software like Zoneminder is that it aggregates the feeds from the cameras. This process also has the effect of proxying the video feeds: We don’t connect directly to the cameras in order to view them, we connect to the surveillance software. If you don’t completely trust those cameras, then don’t give them internet access. You can make the cameras a physically separate network, only connected to the surveillance machine, or just set their IP addresses manually, and don’t fill in the default route or DNS. Whichever way you set it up, the goal is the same: let your surveillance software talk to the cameras, but don’t let the cameras talk to the outside world.

Edit: As has been pointed out in the comments, leaving off a default route is significantly less effective than separate networks. A truly malicious peice of hardware could easily probe for the gateway.

This idea applies to more than cameras. Any device that doesn’t need internet access to function, can be isolated in this way. While this could be considered paranoia, I consider it simple good practice. Join me after the break to discuss port forwarding vs. VPNs.

Continue reading “Hack My House: Opening Raspberry Pi To The Internet, But Not The Whole World” →

Non-Nefarious Raspberry Pi Only Looks Like A Hack

November 13, 2018 by Dan Maloney 50 Comments

We’re going to warn you right up front that this is not a hack. Or at least that’s how it turned out after [LiveOverflow] did some digital forensics on a mysterious device found lurking in a college library. The path he took to come to the conclusion that nothing untoward was going on was interesting and informative, though, as is the ultimate purpose of the unknown artifacts.

As [LiveOverflow] tells us in the video below, he came upon a Reddit thread – of which we can now find no trace – describing a bunch of odd-looking devices stashed behind garbage cans, vending machines, and desks in a college library. [LiveOverflow] recognized the posted pictures as Raspberry Pi Zeroes with USB WiFi dongles attached; curiosity piqued, he reached out to the OP and offered to help solve the mystery.

The video below tells the tale of the forensic fun that ensued, including some questionable practices like sticking the device’s SD card into the finder’s PC. What looked very “hackerish” to the finder turned out to be quite innocuous after [LiveOverflow] went down a remote-diagnosis rabbit hole to discern the purpose of these devices. We won’t spoil the reveal, but suffice it to say they’re part of a pretty clever system with an entirely non-nefarious purpose.

We thought this was a fun infosec romp, and instructive on a couple of levels, not least of which is keeping in mind how “civilians” might see gear like this in the wild. Hardware and software that we deal with every day might look threatening to the general public. Maybe the university should spring for some labels describing the gear next time.

Continue reading “Non-Nefarious Raspberry Pi Only Looks Like A Hack” →

E-Mail Service Claims It Doesn’t Store Your Mail

November 10, 2018 by Al Williams 28 Comments

There have been many news stories lately about companies misusing your data, including your e-mails. What’s more, these giant repositories of data are favorite targets for hackers. Even if you trust the big corporations, you are also betting on their security. Criptext claims they have (possibly) the most private e-mail service ever. It uses the open Signal protocol and stores private keys and encrypted mail only on your device. All the applications to access your mail are open source, so presumably, someone would eventually spot any backdoors or open holes.

At the moment the service is free and the company reports that even when a paid offering is ready, there will still be a free tier. Of course, you can send and receive normal e-mail, too. You can also use a passphrase you send to someone else (presumably not by e-mail) so they can read an encrypted message.

Continue reading “E-Mail Service Claims It Doesn’t Store Your Mail” →

Shakespeare In A Zip In A RAR, Hidden In An Image On Twitter

November 7, 2018 by Al Williams 10 Comments

Steganography involves hiding data in something else — for example, encoding data in a picture. [David Buchanan] used polyglot files not to hide data, but to send a large amount of data in a single Twitter post. We don’t think it quite qualifies as steganography because the image has a giant red UNZIP ME printed across it. But without it, you might not think to run a JPG image through your unzip program. If you did, though, you’d wind up with a bunch of RAR files that you could unrar and get the complete works of the Immortal Bard in a single Tweet. You can also find the source code — where else — on Twitter as another image.

What’s a polyglot file? Jpeg images have an ICC (International Color Consortium) section that defines color profiles. While Twitter strips a lot of things out of images, it doesn’t take out the ICC section. However, the ICC section can contain almost anything that fits in 64 kB up to a limit of 16 MB total.

The ZIP format is also very flexible. The pointer to the central directory is at the end of the file. Since that pointer can point anywhere, it is trivial to create a zip file with extraneous data just about anywhere in the file.

Continue reading “Shakespeare In A Zip In A RAR, Hidden In An Image On Twitter” →

Apple Kernel Code Vulnerability Affected All Devices

November 1, 2018 by Jonathan Bennett 81 Comments

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices” →

When Good Software Goes Bad: Malware In Open Source

October 31, 2018 by Jonathan Bennett 28 Comments

Open Source software is always trustworthy, right? [Bertus] broke a story about a malicious Python package called “Colourama”. When used, it secretly installs a VBscript that watches the system clipboard for a Bitcoin address, and replaces that address with a hardcoded one. Essentially this plugin attempts to redirects Bitcoin payments to whoever wrote the “colourama” library.

Why would anyone install this thing? There is a legitimate package named “Colorama” that takes ANSI color commands, and translates them to the Windows terminal. It’s a fairly popular library, but more importantly, the name contains a word with multiple spellings. If you ask a friend to recommend a color library and she says “coulourama” with a British accent, you might just spell it that way. So the attack is simple: copy the original project’s code into a new misspelled project, and add a nasty surprise.

Sneaking malicious software into existing codebases isn’t new, and this particular cheap and easy attack vector has a name: “typo-squatting”. But how did this package get hosted on PyPi, the main source of community contributed goodness for Python? How many of you have downloaded packages from PyPi without looking through all of the source? pip install colorama? We’d guess that it’s nearly all of us who use Python.

It’s not just Python, either. A similar issue was found on the NPM javascript repository in 2017. A user submitted a handful of new packages, all typo-squatting on existing, popular packages. Each package contained malicious code that grabbed environment variables and uploaded them to the author. How many web devs installed these packages in a hurry?

Of course, this problem isn’t unique to open source. “Abstractism” was a game hosted on Steam, until it was discovered to be mining Monero while gamers were playing. There are plenty of other examples of malicious software masquerading as something else– a sizable chunk of my day job is cleaning up computers after someone tried to download Flash Player from a shady website.

Buyer Beware

In the open source world, we’ve become accustomed to simply downloading libraries that purport to do exactly the cool thing we’re looking for, and none of us have the time to pore through the code line by line. How can you trust them?

Repositories like PyPi do a good job of faithfully packaging the libraries and programs that are submitted to them. As the size of these repositories grow, it becomes less and less practical for every package to be manually reviewed. PyPi lists 156,750 projeccts. Automated scanning like [Bertus] was doing is a great step towards keeping malicious code out of our repositories. Indeed, [Bertus] has found eleven other malicious packages while testing the PyPi repository. But cleverer hackers will probably find their way around automated testing.

That the libraries are open source does add an extra layer of reliability, because the code can in principal be audited by anyone, anytime. As libraries are used, bugs are found, and features are added, more and more people are intentionally and unintentionally reviewing the code. In the “colourama” example, a long Base64 string was decoded and executed. It doesn’t take a professional researcher to realize something fishy is going on. At some point, enough people have reviewed a codebase that it can be reasonably trusted. “Colorama” has well over a thousand stars on Github, and 28 contributors. But did you check that before downloading it?

Typo-squatting abuses trust, taking advantage of a similar name and whoever isn’t paying quite close enough attention. It’s not practical for every user to check every package in their operating system. How, then, do we have any trust in any install? Cryptography solves some of these problems, but it cannot overcome the human element. A typo in a url, trusting a brand new project, or even obfuscated C code can fool the best of us from time to time.

What’s the solution? How do we have any confidence in any of our software? When downloading from the web, there are some good habits that go a long way to protect against attacks. Cross check that the project’s website and source code actually point to each other. Check for typos in URLs. Don’t trust a download just because it’s located on a popular repository.

But most importantly, check the project’s reputation, the number of contributors to the project, and maybe even their reputation. You wouldn’t order something on eBay without checking the seller’s feedback, would you? Do the same for software libraries.

A further layer of security can be found in using libraries supported by popular distributions. In quality distributions, each package has a maintainer that is familiar with the project being maintained. While they aren’t checking each line of code of every project, they are ensuring that “colorama” gets packaged instead of “colourama”. In contrast to PyPi’s 156,750 Python modules, Fedora packages only around 4,000. This selection is a good thing.

Repositories like PyPi and NPM are simply not the carefully curated sources of trustworthy software that we sometimes think them to be– and we should act accordingly. Look carefully into the project’s reputation. If the library is packaged by your distribution of choice, you can probably pass this job off to the distribution’s maintainers.

At the end of the day, short of going through the code line by line, some trust anchor is necessary. If you’re blindly installing random libraries, even from a “trustworthy” repository, you’re letting your guard down.