TruffleHog Sniffs Github For Secret Keys

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.

Super Mario Run(s) — Away With Your Money

If you are an Android user and a big fan of Super Mario beware: there is no Android version! There has been no official news on the Android version yet, let alone a version of the game. There is, however, a version circulating outside of Google Play market that will steal your bank account.

Right now attackers are taking advantage of the game’s popularity and Android users despair to spread malware posing as an Android version of Super Mario Run as they did in the past for Pokemon GO. The trojan is called Android Marcher and has been around since 2013, mostly targeting mobile users financial information. After installation, the application attempts to trick users with fake finance apps and a credit card page in an effort to capture banking details. The malware also locks out Google Play until the user supplies their credit card information.

In this new variant of Marcher, it can monitor the device and steal login data of regular apps, not just banking and payment apps, and send the stolen data back to command and control (C&C) servers. Facebook, WhatsApp, Skype, Gmail, the Google Play store are all vulnerable. Criminals can exploit these stolen accounts to carry out additional fraud.

Zscaler researchers advice is:

To avoid becoming a victim of such malware, it is a good practice to download apps only from trusted app stores such as Google Play. This practice can be enforced by unchecking the “Unknown Sources” option under the “Security” settings of your device.

We may add to turn on “App Verification”. Verify Apps regularly checks activity on your device and prevents or warns you about potential harm. Verify Apps is on by default, as is Unknown Sources turned off. Verify Apps also checks apps when you install them from sources other than Google Play. Of course, there is a privacy trade-off. Some information has to be sent about the apps you install back to Google.

The main advice is: use common sense. It’s common practice for companies to release official apps versions through Google Play and highly unlikely to do it via any other way.

OWL Insecure Internet Of Energy Monitors

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.

33C3: If You Can’t Trust Your Computer, Who Can You Trust?

It’s a sign of the times: the first day of the 33rd Chaos Communications Congress (33C3) included two talks related to assuring that your own computer wasn’t being turned against you. The two talks are respectively practical and idealistic, realizable today and a work that’s still in the idea stage.

In the first talk, [Trammell Hudson] presented his Heads open-source firmware bootloader and minimal Linux for laptops and servers. The name is a gag: the Tails Linux distribution lets you operate without leaving any trace, while Heads lets you run a system that you can be reasonably sure is secure.

It uses coreboot, kexec, and QubesOS, cutting off BIOS-based hacking tools at the root. If you’re worried about sketchy BIOS rootkits, this is a solution. (And if you think that this is paranoia, you haven’t been following the news in the last few years, and probably need to watch this talk.) [Trammell]’s Heads distribution is a collection of the best tools currently available, and it’s something you can do now, although it’s not going to be easy.

Carrying out the ideas fleshed out in the second talk is even harder — in fact, impossible at the moment. But that’s not to say that it’s not a neat idea. [Jaseg] starts out with the premise that the CPU itself is not to be trusted. Again, this is sadly not so far-fetched these days. Non-open blobs of firmware abound, and if you’re really concerned with the privacy of your communications, you don’t want the CPU (or Intel’s management engine) to get its hands on your plaintext.

[Jaseg]’s solution is to interpose a device, probably made with a reasonably powerful FPGA and running open-source, inspectable code, between the CPU and the screen and keyboard. For critical text, like e-mail for example, the CPU will deal only in ciphertext. The FPGA, via graphics cues, will know which region of the screen is to be decrypted, and will send the plaintext out to the screen directly. Unless someone’s physically between the FPGA and your screen or keyboard, this should be unsniffable.

As with all early-stage ideas, the devil will be in the details here. It’s not yet worked out how to know when the keyboard needs to be encoded before passing the keystrokes on to the CPU, for instance. But the idea is very interesting, and places the trust boundary about as close to the user as possible, at input and output.

Santa Knows If Your Contact Form Uses PHPMailer < 5.2.18

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”

Samy Kamkar Illustrates How To Be A Hardware Hacker

Samy Kamkar is well known for many things, but lately it has been his hardware security hacks that have been turning heads. The nice thing to know is that, despite not having a background in hardware, Samy is able to run with the best of hardware researchers. At the Hackaday SuperConference he offered words of advice for anyone trying to walk the path of discovery with an exciting new piece of electronics. One might say it’s a crash-course in how to be a hardware hacker.

Continue reading “Samy Kamkar Illustrates How To Be A Hardware Hacker”

Eavesdropping Via Headphones

We all know that speakers are microphones and microphones are speakers, right? If not, take a moment to plug your headphones into a microphone jack and yell into them. It’s not exactly hi-fi, but it works.

So it’s not a huge surprise that three security researchers in Israel have managed to turn the combination headphone and microphone input jacks that are present on most laptops into an eavesdropping device. (Paper here as PDF, with an obligatory demo video on YouTube, embedded below.) Speake(a)r is a neat proof-of-concept and a horrid pun. Continue reading “Eavesdropping Via Headphones”