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.

Building A Proof Of Concept Hardware Implant

October 24, 2018 by Tom Nardi 43 Comments

You’ve no doubt heard about the “hardware implants” which were supposedly found on some server motherboards, which has led to all sorts of hand-wringing online. There’s no end of debate about the capabilities of such devices, how large they would need to be, and quite frankly, if they even exist to begin with. We’re through the looking-glass now, and there’s understandably a mad rush to learn as much as possible about the threat these types of devices represent.

EEPROM (left) can be edited to enable SMBus access on this card (header to the right)

[Nicolas Oberli] of Kudelski Security wanted to do more than idly speculate, so he decided to come up with a model of how an implanted hardware espionage device could interact with the host system. He was able to do this with off the shelf hardware, meaning anyone who’s so inclined can recreate this “Hardware Implant Playset” in their own home lab for experimentation. Obviously this is not meant to portray a practical attack in terms of the hardware itself, but gives some valuable insight into how such a device might function.

One of the most obvious attack vectors for hardware implants is what’s known as the Baseboard Management Controller (BMC). This is a chip used on modern motherboards to allow for remote control and monitoring of the system’s hardware, and promises to be a ripe target for attackers. There are a few sideband channels which can be used by the BMC chip to talk to other chips. To keep things simple [Nicolas] focused on the older I2C-derived SMBus (rather than the newer and more complex NC-SI), demonstrating what can be done once you have control of that bus.

Only problem was, he didn’t have a motherboard with a BMC to experiment with. After a little research, the answer came in the form of the Intel EXPI9301CTBLK network card, which features the 82574L SMBus chip. This allows for experimenting with a subset of SMBus functionality on any machine with a PCI-E slot. Even better, the card has an SMBus header on the top to plug into. [Nicolas] describes in detail how he enabled the SMBus interface by modifying the card’s EEPROM, which then allowed him to detect it with his HydraBus.

With the hardware setup, the rest of the write-up focuses on what you can do with direct control of SMBus on the network card. [Nicolas] demonstrates not only creating and sending Ethernet packets, but also intercepting an incoming packet. In both cases, a running instance of tcpdump on the host computer fails to see the packets even exist.

He goes on to explain that since SMBus is very similar to I2C and only requires four wires, the techniques shown could easily be moved from the Hydrabus dev board used in the demo, to a small microcontroller like the ATtiny85. But you would still need to find a way to add that microcontroller directly onto the network card without it being obvious to the casual observer.

Our previous coverage of suspected hardware implants sparked considerable discussion, and it looks like no matter what side of the fence you’re on, the debate isn’t going away anytime soon.

Hack My House: ZoneMinder’s Keeping An Eye On The Place

October 23, 2018 by Jonathan Bennett 53 Comments

Hacks are often born out of unfortunate circumstances. My unfortunate circumstance was a robbery– the back door of the remodel was kicked in, and a generator was carted off. Once the police report was filed and the door screwed shut, it was time to order cameras. Oh, and record the models and serial numbers of all my tools.

We’re going to use Power over Ethernet (POE) network cameras and a ZoneMinder install. ZoneMinder has a network trigger capability, and we’ll wire some magnetic switches to our network of PXE booting Pis, using those to inform the Zoneminder server of door opening events. Beyond that, many newer cameras support the Open Network Video Interface Forum (ONVIF) protocol and can do onboard motion detection. We’ll use the same script, running on the Pi, to forward those events as well.

Many of you have pointed out that Zoneminder isn’t the only option for open source camera management. MotionEyeOS, Pikrellcam, and Shinobi are all valid options. I’m most familiar with Zoneminder, even interviewing them on FLOSS Weekly, so that’s what I’m using. Perhaps at some point we can revisit this decision, and compare the existing video surveillance systems.

Continue reading “Hack My House: ZoneMinder’s Keeping An Eye On The Place” →

LibSSH Vuln: You Don’t Need To See My Authentication

October 16, 2018 by Jonathan Bennett 19 Comments

Another day, another CVE (Common Vulnerabilities and Exposures). Getting a CVE number assigned to a vulnerability is a stamp of authenticity that you have a real problem on your hands. CVE-2018-10933 is a worst case scenario for libssh. With a single response, an attacker can completely bypass authentication, giving full access to a system.

Before you panic and yank the power cord on your server, know that libssh is not part of OpenSSH. Your Linux box almost certainly uses OpenSSH as the SSH daemon, and that daemon is not vulnerable to this particular problem. Libssh does show up in a few important places, the most notable is probably Github and their security team already announced their implementation was not vulnerable.

Libssh has released a new version that fixes the problem. Stick around for the details after the break.

Continue reading “LibSSH Vuln: You Don’t Need To See My Authentication” →

FIDO2 Authentication In All The Colors

October 16, 2018 by Jonathan Bennett 14 Comments

Here at Hackaday, we have a soft spot for security dongles. When a new two-factor-authentication dongle is open source, uses USB and NFC, and supports FIDO2, the newest 2FA standard, we take notice. That just happens to be exactly what [Conor Patrick] is funding on Kickstarter.

We’ve looked at [Conor]’s first generation hardware key, and the process of going from design to physical product. With that track record, the Solo security key promises to be more than the vaporware that plagues crowdfunding services.

Another player, Yubikey, has also recently announced a new product that supports FIDO2 and NFC. While Yubikey has stepped away from their early open source policy, Solo is embracing the open source ethos. The Kickstarter promises the release of both the software and hardware design as fully open, using MIT and CC BY-SA licenses.

For more information, see the blog post detailing the project goals and initial design process. As always, caveat emptor, but this seems to be a crowdfunding project worth taking a look at.

Hacker Pops Top On NFC Vending Machines

October 16, 2018 by Tom Nardi 23 Comments

Vending machines used to be a pretty simple affair: you put some coins in, and food or drink that in all likelihood isn’t fit for human consumption comes out. But like everything else today, they are becoming increasingly complex Internet connected devices. Forget fishing around for pocket change; the Coke machine at the mall more often than not has a credit card terminal and a 30 inch touch screen display to better facilitate dispensing cans of chilled sugar water. Of course, increased complexity almost always goes hand in hand with increased vulnerability.

So when [Matteo Pisani] recently came across a vending machine that offered users the ability to pay from an application on their phone, he immediately got to wondering if the system could be compromised. After all, how much thought would be put into the security of a machine that basically sells flavored water? The answer, perhaps not surprisingly, is very little.

The write-up [Matteo] has put together is an outstanding case study in hacking Android applications, from pulling the .apk package off the phone to decompiling it into its principal components with programs like apktool and jadx. He even shows how you can reassemble the package and get it suitable for reinstallation on your device after fiddling around with the source code. If you’ve ever wanted a crash course on taking a peek inside of Android programs, this is a great resource.

By snooping around in the source code, [Matteo] was able to discover not only the location of the encrypted database that serves as the “wallet” for the user, but the routine that generates the encryption key. To cut a long story short, the program simply uses the phone’s IMEI as the key to get into the database. With that in hand, he was able to get into the wallet and give himself a nice stack of “coins” for the next time he hit the vending machines. Given his new-found knowledge of how the system works, he even came up with a separate Android app that allows adding credit to the user’s account on a rooted device.

In the video after the break, [Matteo] demonstrates his program by buying a soda and then bumping his credit back up to buy another. He ends his write-up by saying that he has reported his findings to the company that manufacturers the vending machines, but no word on what (if any) changes they plan on making. At the end of the day, you have to wonder what the cost-befit analysis looks like for a full security overhaul when when you’re only selling sodas and bags of chips.

When he isn’t liberating carbonated beverages from their capitalistic prisons, he’s freeing peripherals from their arbitrary OS limitations. We’re starting to get a good idea about what makes this guy tick.

Continue reading “Hacker Pops Top On NFC Vending Machines” →

Google Discovers Google+ Servers Are Still Running

October 9, 2018 by Tom Nardi 70 Comments

Google is pulling the plug on their social network, Google+. Users still have the better part of a year to say their goodbyes, but if the fledgling social network was a ghost town before, news of its imminent shutdown isn’t likely to liven the place up. A quick check of the site as of this writing reveals many users are already posting their farewell messages, and while there’s some rallying behind petitions to keep the lights on, the majority realize that once Google has fallen out of love with a project there’s little chance of a reprieve.

To say that this is a surprise would be disingenuous. We’d wager a lot of you already thought it was gone, honestly. It’s no secret that Google’s attempt at a “Facebook Killer” was anything but, and while there was a group of dedicated users to be sure, it never attained anywhere near the success of its competition.

According to a blog post from Google, the network’s anemic user base isn’t the only reason they’ve decided to wind down the service. A previously undisclosed security vulnerability also hastened its demise, a revelation which will particularly sting those who joined for the privacy-first design Google touted. While this fairly transparent postmortem allows us to answer what ended Google’s grand experiment in social networking, there’s still one questions left unanswered. Where are the soon to be orphaned Google+ users supposed to go?

Continue reading “Google Discovers Google+ Servers Are Still Running” →