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.

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.

Source Of Evil – A Botnet Code Collection

September 9, 2018 by Sven Gregori 9 Comments

In case you’re looking for a variety of IRC client implementations, or always wondered how botnets and other malware looks on the inside, [maestron] has just the right thing for you. After years of searching and gathering the source code of hundreds of real-world botnets, he’s now published them on GitHub.

With C++ being the dominant language in the collection, you will also find sources in C, PHP, BASIC, Pascal, the occasional assembler, and even Java. And if you want to consider the psychological aspect of it, who knows, seeing their malicious creations in their rawest form might even give you a glimpse into the mind of their authors.

These sources are of course for educational purposes only, and it should go without saying that you probably wouldn’t want to experiment with them outside a controlled environment. But in case you do take a closer look at them and are someone who generally likes to get things in order, [maestron] is actually looking for ideas how to properly sort and organize the collection. And if you’re more into old school viruses, and want to see them run in a safe environment, there’s always the malware museum.

Intel Forms New Security Group To Avoid Future Meltdowns

January 17, 2018 by Roger Cheng 57 Comments

Intel just moved some high level people around to form a dedicated security group.

When news of Meltdown and Spectre broke, Intel’s public relations department applied maximum power to their damage control press release generators. The initial message was one of defiance, downplaying the impact and implying people are over reacting. This did not go over well. Since then, we’ve started seeing a trickle of information from engineering and even direct microcode updates for people who dare to live on the bleeding edge.

All the technical work to put out the immediate fire is great, but for the sake of Intel’s future they need to figure out how to avoid future fires. The leadership needs to change the company culture away from an attitude where speed is valued over all else. Will the new security group have the necessary impact? We won’t know for quite some time. For now, it is encouraging to see work underway. Fundamental problems in corporate culture require a methodical fix and not a hack.

Editor’s note: We’ve changed the title of this article to better reflect its content: that Intel is making changes to its corporate structure to allow a larger voice for security in the inevitable security versus velocity tradeoff.

Santa Knows If Your Contact Form Uses PHPMailer < 5.2.18

December 25, 2016 by Pedro Umbelino 18 Comments

PHPMailer, one of the most used classes for sending emails from within PHP, has a serious vulnerability in versions less than 5.2.18 (current version). The security researcher [Dawid Golunski] just published a limited advisory stating that PHPMailer suffers from a critical flaw that might lead an attacker to achieve remote code execution in the context of the web server user. PHPMailer is used by several open-source projects, among them are: WordPress, Drupal, 1CRM, SugarCRM, Yii and Joomla. A fix has been issued and PHPMailer is urging all users to upgrade their systems.

To trigger this vulnerability (CVE-2016-10033) it seems that the attacker only has to make the web application send out an email using the vulnerable PHPMailer class. Depending on the application itself, this can be accomplished in different ways, such as contact/feedback forms, registration forms, password email resets and so on.

Upon a quick diff analysis, we found that the vulnerable code seems to lie in the following lines of the class.phpmailer.php:

Continue reading “Santa Knows If Your Contact Form Uses PHPMailer < 5.2.18” →

Reliably Exploiting Apport In Ubuntu

December 16, 2016 by Pedro Umbelino 17 Comments

[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.

One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.

CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.

The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:

“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”

Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.

Continue reading “Reliably Exploiting Apport In Ubuntu” →