Source Code for IoT Botnet ‘Mirai’ Released

The source code that powers the “Internet of Things” (IoT) botnet responsible for launching the historically large distributed denial-of-service (DDoS) attack against KrebsOnSecurity last month has been publicly released, virtually guaranteeing that the Internet will soon be flooded with attacks from many new botnets powered by insecure routers, IP cameras, digital video recorders and other easily hackable devices.

The leak of the source code was announced Friday on the English-language hacking community Hackforums. The malware, dubbed “Mirai,” spreads to vulnerable devices by continuously scanning the Internet for IoT systems protected by factory default or hard-coded usernames and passwords.

The Hackforums post that includes links to the Mirai source code.

The Hackforums post that includes links to the Mirai source code.

Vulnerable devices are then seeded with malicious software that turns them into “bots,” forcing them to report to a central control server that can be used as a staging ground for launching powerful DDoS attacks designed to knock Web sites offline.

The Hackforums user who released the code, using the nickname “Anna-senpai,” told forum members the source code was being released in response to increased scrutiny from the security industry.

“When I first go in DDoS industry, I wasn’t planning on staying in it long,” Anna-senpai wrote. “I made my money, there’s lots of eyes looking at IOT now, so it’s time to GTFO [link added]. So today, I have an amazing release for you. With Mirai, I usually pull max 380k bots from telnet alone. However, after the Kreb [sic] DDoS, ISPs been slowly shutting down and cleaning up their act. Today, max pull is about 300k bots, and dropping.”

Sources tell KrebsOnSecurity that Mirai is one of at least two malware families that are currently being used to quickly assemble very large IoT-based DDoS armies. The other dominant strain of IoT malware, dubbed “Bashlight,” functions similarly to Mirai in that it also infects systems via default usernames and passwords on IoT devices.

According to research from security firm Level3 Communications, the Bashlight botnet currently is responsible for enslaving nearly a million IoT devices and is in direct competition with botnets based on Mirai.

“Both [are] going after the same IoT device exposure and, in a lot of cases, the same devices,” said Dale Drew, Level3’s chief security officer.

Infected systems can be cleaned up by simply rebooting them — thus wiping the malicious code from memory. But experts say there is so much constant scanning going on for vulnerable systems that vulnerable IoT devices can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.

In the days since the record 620 Gbps DDoS on, this author has been able to confirm that the attack was launched by a Mirai botnet. As I wrote last month, preliminary analysis of the attack traffic suggested that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes. GRE lets two peers share data they wouldn’t be able to share over the public network itself.

One security expert who asked to remain anonymous said he examined the Mirai source code following its publication online and confirmed that it includes a section responsible for coordinating GRE attacks.

It’s an open question why anna-senpai released the source code for Mirai, but it’s unlikely to have been an altruistic gesture: Miscreants who develop malicious software often dump their source code publicly when law enforcement investigators and security firms start sniffing around a little too close to home. Publishing the code online for all to see and download ensures that the code’s original authors aren’t the only ones found possessing it if and when the authorities come knocking with search warrants.

My guess is that (if it’s not already happening) there will soon be many Internet users complaining to their ISPs about slow Internet speeds as a result of hacked IoT devices on their network hogging all the bandwidth. On the bright side, if that happens it may help to lessen the number of vulnerable systems.

On the not-so-cheerful side, there are plenty of new, default-insecure IoT devices being plugged into the Internet each day. Gartner Inc. forecasts that 6.4 billion connected things will be in use worldwide in 2016, up 30 percent from 2015, and will reach 20.8 billion by 2020. In 2016, 5.5 million new things will get connected each day, Gartner estimates.

For more on what we can and must do about the dawning IoT nightmare, see the second half of this week’s story, The Democratization of Censorship. In the meantime, this post from Sucuri Inc. points to some of the hardware makers whose default-insecure products are powering this IoT mess.

Tags: , , , , , , ,

Don't agree to privacy policies without knowing what PII is at risk

Image: iStock/Urs Siedentop

Pundits and users alike understand the importance of reading privacy policies before installing software. However, not many read the policy before clicking the “accept” button, and that is understandable.

Back in 2012, two privacy experts, Dr. Aleecia M. McDonald and Dr. Lorrie Faith Cranor (as reported in this TechRepublic article) tried to determine what the cost would be if every online privacy policy was read. It amounted to more than $780 billion per year. What’s more, those brave enough to attempt reading a privacy policy quickly learn understanding the legalese is an act of futility unless they happen to be lawyers.

More about IT Security

Besides feeling angst and the monetary loss of reading privacy policies, agreeing to a privacy policy—in particular the policies associated with security software designed to prevent the exfiltration of proprietary information—without understanding the policy’s contents may give the security software’s developers permission to exfiltrate the Personally Identifiable Information (PII) it is supposed to protect.

SEE: Information Security Policy (Tech Pro Research)

To safeguard sensitive user data, security software typically requires extensive access to the data being protected. And that can be a double-edged sword according to Olaf Pursche, head of communications at AV-TEST, an independent IT security test house, who writes in this white paper:

“Users likewise have no other option than to allow far-reaching insights into systems and stored data, putting their faith in the pledge of software companies to protect them. However, this should only occur under the assumption that these access rights will be used solely to detect and thwart possible threats.”



Image: Anett Hoppe and AV-TEST

People at AV-TEST have come across examples they feel are abusing users’ faith. Anett Hoppe, an IT security expert at AV-TEST, put 26 security platforms through their paces while focusing on what access control the security software assumes. In particular:

  • What user rights are assumed by the security software
  • What data is collected by the software, and are the users being informed of that fact

Hoppe and her fellow researchers at AV-TEST came up with the following conclusions. Pursche notes that, “Only 24 privacy policies were evaluated, as two of the security packages did not include any policy whatsoever—neither on the manufacturers’ websites nor during installation of the programs.”

Assumed more access than needed: “In almost every privacy policy examined, the manufacturer presumes a vast number of access rights to data that should not be necessary for using a security software application,” writes Pursche. To be fair, Pursche adds that according to manufacturers’ statements, they (additional access rights) serve the purpose of product optimization.

Collected more data than required: The AV-TEST white paper suggests the privacy policies studied give security software developers permission to collect personal data including name, email address, and payment details. However, the same manufacturers collect additional PII—including telephone numbers—that Pursche feels are not necessary for the security packages to operate efficiently, but useful for introducing additional products to the user.

User biometric data collected: For reasons unknown to Pursche and others at AV-TEST, security software firms collect digital fingerprints and other physical attributes. Pursche adds, “How information on the user’s gender, occupation, as well as race and sexual orientation are intended to help in hunting down malware is probably difficult to explain.”

User activity tracked: Hoppe, in her research, found that some of the installed security packages wanted access to the following applications and software to track user activity:

  • Fifteen programs require access to browser history
  • Six programs ask to access search queries
  • Five programs examine emails
  • Two programs want full access to the user’s address book

User statistics compiled: 10 out of the 24 privacy policies give the security program’s developers the right to gather “user statistics.” The question then becomes what data does the term user statistics reference? “It is not clearly defined, however, which data is collected here, i.e. whether it involves the use of the security program itself, use of the device, or the collection of entirely different data,” writes Pursche. “In this area, as well as in many other points, the specifications of privacy policies of all manufacturers are extremely vague.”

SEE: It’s 2016 and we don’t know who has our personal data (ZDNet)

Recommendations for users

In lieu of security program providers creating straightforward privacy policies, Hoppe recommends that users bear data protection issues in mind when registering and configuring the product. “This begins with the user’s personal details during installation—often enough, not all the fields on the registration form are required and are only completed out of habit,” continues Hoppe. “Moreover, users should at least quickly peruse the privacy policy. Only by knowing these terms can the user determine whether an address book or private photos really should be uploaded onto a manufacturer’s server.”

Also see