According to Russian security site [Dr.Web], there’s a new malware called Linux.MulDrop.14 striking Raspberry Pi computers. In a separate posting, the site examines two different Pi-based trojans including Linux.MulDrop.14. That trojan uses your Pi to mine BitCoins some form of cryptocurrency. The other trojan sets up a proxy server.
According to the site:
Linux Trojan that is a bash script containing a mining program, which is compressed with gzip and encrypted with base64. Once launched, the script shuts down several processes and installs libraries required for its operation. It also installs zmap and sshpass.
It changes the password of the user “pi” to “\$6\$U1Nu9qCp\$FhPuo8s5PsQlH6lwUdTwFcAUPNzmr0pWCdNJj.p6l4Mzi8S867YLmc7BspmEH95POvxPQ3PzP029yT1L3yi6K1”.
In addition, the malware searches for network machines with open port 22 and tries to log in using the default Raspberry Pi credentials to spread itself.
Embedded systems are a particularly inviting target for hackers. Sometimes it is for the value of the physical system they monitor or control. In others, it is just the compute power which can be used for denial of service attacks on others, spam, or — in the case — BitCoin mining. We wonder how large does your Raspberry Pi botnet needs to be to compete in the mining realm?
We hope you haven’t kept the default passwords on your Pi. In fact, we hope you’ve taken our previous advice and set up two factor authentication. You can do other things too, like change the ssh port, run fail2ban, or implement port knocking. Of course, if you use Samba to share Windows files and printers, you ought to read about that vulnerability, as well.
We will all be used to malicious software, computers and operating systems compromised by viruses, worms, or Trojans. It has become a fact of life, and a whole industry of virus checking software exists to help users defend against it.
Underlying our concerns about malicious software is an assumption that the hardware is inviolate, the computer itself can not be inherently compromised. It’s a false one though, as it is perfectly possible for a processor or other integrated circuit to have a malicious function included in its fabrication. You might think that such functions would not be included by a reputable chip manufacturer, and you’d be right. Unfortunately though because the high cost of chip fabrication means that the semiconductor industry is a web of third-party fabrication houses, there are many opportunities during which extra components can be inserted before the chips are manufactured. University of Michigan researchers have produced a paper on the subject (PDF) detailing a particularly clever attack on a processor that minimizes the number of components required through clever use of a FET gate in a capacitive charge pump.
On-chip backdoors have to be physically stealthy, difficult to trigger accidentally, and easy to trigger by those in the know. Their designers will find a line that changes logic state rarely, and enact a counter on it such that when they trigger it to change state a certain number of times that would never happen accidentally, the exploit is triggered. In the past these counters have been traditional logic circuitry, an effective approach but one that leaves a significant footprint of extra components on the chip for which space must be found, and which can become obvious when the chip is inspected through a microscope.
The University of Michigan backdoor is not a counter but an analog charge pump. Every time its input is toggled, a small amount of charge is stored on the capacitor formed by the gate of a transistor, and eventually its voltage reaches a logic level such that an attack circuit can be triggered. They attached it to the divide-by-zero flag line of an OR1200 open-source processor, from which they could easily trigger it by repeatedly dividing by zero. The beauty of this circuit is both that it uses very few components so can hide more easily, and that the charge leaks away with time so it can not persist in a state likely to be accidentally triggered.
The best hardware hacks are those that are simple, novel, and push a device into doing something it would not otherwise have done. This one has all that, for which we take our hats off to the Michigan team.
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.
This was both an amusing and frightening talk. [Sam Bowne] presented How to Trojan Financial Android Apps on Saturday afternoon at the LayerOne Conference. [Sam] calculates that 80-90% of the apps provided by major financial institutions like banks and investment companies are vulnerable and the ease with which trojans can be rolled into them is incredible.
[Sam] did a great job of concisely describing the circumstances that make Android particularly vulnerable to the attacks which are the subject of the talk. Android programs are packaged as APK files which are easy to unpack. The “compiled” code itself is called smali and is readable in a similar way as Java. It’s super easy to unpack and search this byte code using grep. Once the interesting parts are located, the smali code can be altered and the entire thing can be repackaged. The app will need to be resigned but Google doesn’t control the signing keys so an attacker can simply generate a new key and use that to sign the app. The user still needs to install the file, but Android allows app installation from webpages, email, etc. so this isn’t a problem for the bad guys either.
So what can be done? This is about information harvesting. [Sam’s] proof of concept uses a python script to insert logging for every local variable. The script looks at the start of every module in the smali code, grabs the number of local variables, increments it by one and uses this extra variable to write out the values through logcat.
He demonstrated live on the Bank of America app. From the user side of things it looks exactly like the official app, because it is the official app. However, when you register your account the log reports the card number as you can see here. Obviously this information could easily be phoned-home using a number of techniques.
As mentioned, the vast majority of banking and financial apps are vulnerable to this, but some have made an attempt to make it more difficult. He found the Bancorp app never exposes this information in local variables so it can’t just be logged out. However, the same trojan technique works as a keylogger since he found the same function kept getting called every time a key is pressed. The same was true of the Capital One app, but it echos out Google’s Android keymap values rather than ascii; easy enough to translate back into readable data though.
The Inability to Report Vulnerabilities
What is the most troubling is that none of these companies have a means of reporting security vulnerabilities. It was amusing to hear [Sam] recount his struggle to report these issues to Charles Schwab. Online contact forms were broken and wouldn’t post data and several publicly posted email addresses bounced email. When he finally got one to accept the email he later discovered another user reporting on a forum that nobody ever answers back on any of the Schwab accounts. He resorted to a trick he has used many times in the past… Tweeting to the CEO of Charles Schwab to start up a direct-message conversation. This itself is a security problem as @SwiftOnSecurity proves by pointing out that whenever @SamBowne Tweets a CEO it’s because he found a vulnerability in that company’s platform and can’t find a reasonable way to contact the company.
There is Hope
Although very rare, sometimes these apps do get patched. The Trade King app was updated after his report and when [Sam] tried the exploit again it crashes at start-up. The log reports a verification failure. This indicates that the injected code is being noticed, but [Sam] wonders if the verification is included in the app itself. If it is, then it will be possible to track it down and disable it.
This may sound like all of us Android users should despair but that’s not the case. Adding verification, even if it’s possible to defeat it, does make the apps safer; attackers may not want to invest the extra time to try to defeat it. Also, there are obsfucators available for a few thousand dollars that will make these attacks much more difficult by making variable names unreadable. The free obsfucator available now with the Android development suites doesn’t change names of everything… local variables are left unaltered and programmers have a habit of using descriptive names for variables. For instance, BofA used “CARDNUM” in the example above.
[Sam Bowne’s] slides and testing results for the entire talk are available under the “Upcoming Events” part of his website.
The Polytechnic Institute of NYU is hosting an interesting embedded systems contest. They’ve constructed a solid state cryptographic device that uses a 128-bit private key. Contestants will be tasked with designing and implementing several trojans into the system that will undermine the security. The system is built on a Digilent BASYS Spartan-3 FPGA board. The trojans could do a wide variety of things: transmitting unencrypted, storing and transmitting previously entered plain text, or just shutting down the system entirely. The modified devices still need to pass the factory testing procedure though, which will measure power consumption, code size, and function. After a qualification round, participants will be given the necessary hardware to compete.
The Zlob trojan, also known as DNSChanger, has been around for a few years, but recent Zlob variants to appear in the wild attempt to log into routers using a list of default admin/password combos. If they succeed, they alter the DNS records on the router to reroute traffic through the attacker’s server.
Our friend [Dan Kaminisky] recently did a presentation warning against vulnerabilities in internet browser plugins that allow attackers to mount DNS rebinding attacks against routers with default passwords.. Though it achieves the same end, Zlob is different because it infects by the tried-and-true method of fooling users into downloading it inside a fake video codec. Once it is running on a client machine, it is free to attempt to use the default admin id and password of the router to log in and alter DNS settings. It even supports the DD-WRT firmware.
Even if a system is wiped clean of Zlob trojans, the router could still be compromised. The good news is that it is easy to fix and even easier to prevent. Fixing it takes no more than wiping all network clients clean, then resetting the router and restoring custom settings. Prevention is a simple matter of changing the router’s password.