Open Source Botnet | TechSNAP 287

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

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.”
“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.”
A quote from the person who released the code: “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. 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.”
“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.”
It is surprising that the botnets are not changing the default passwords to prevent reinfection by competing botnets. Of course, if you are scanning using the new secret password, every honeypot is going to get that password and be able to recapture your devices
“In the days since the record 620 Gbps DDoS on KrebsOnSecurity.com, 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.”
“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.”

A tale of a dns packet

“BIND is the most used DNS server on the internet. It is the standard system for name resolutions on UNIX platforms and is used in 10 of the 13 root servers of the Name Domain System on the internet. Basically, it is one of the main function of the entire Internet.”
“The tests done by ISC (Internet Systems Consortium) discovered a critical error when building a DNS response.”
“This assertion can be triggered even if the apparent source address isn’t allowed to make queries (i.e. doesn’t match ‘allow-query’)”
“Following the tradition of having errors in the necessary software for the survival of humanity, CVE-2016-2776 came to light. With details of the problem basically nowhere to be found, nor what was the mysterious “Specifically Constructed Request”, we decided to see what exactly was modified in the repository of Bind9.”
“Now that we are convinced that msg->reserved is potentially dangerous when 500 < msg->reserved <= 512, it is time to see how we can manipulate this variable. Tracking the use of dns_message_renderreserve() in lib/dns/message.c we find that msg->reserved is used to track how many bytes will be necessary to write the Additional RR (OPT, TSIG y SIG(0)) once the response is finished rendering on dns_message_renderend().”
“The most direct way we’ve found of manipulating an Additional RR included on the response is sending a query with a TSIG RR containing an invalid signature. When this happens, the server echoes practically all the record when responding.”
“The following script sends a query A to the server with a TSIG large enough so as to make the server reserve 501 bytes on msg->reserved when writing the response.”
“When it gets to dns_message_renderbegin() we have the context we’ve looked for: msg->reserved on 501 and r.length on 512. The if condition which should throw ISC_R_NOSPACE in the patch is not triggered.”
And BIND crashes
“We can see now with the instruction immediately after the validation why it was so important to consider DNS_MESSAGE_HEADERLEN. Immediately after validating that the buffer has the sufficient space to store msg->reserved bytes, it allocates DNS_MESSAGE_HEADERLEN (12) bytes in it. In other words it didn’t check if after reserving msg->reserved, there is enough space to store 12 bytes more. What happens in the end is that when returning from the function, the available space on buffer is of 500 bytes (buffer->length – buffer->used = 512 – 12 = 500) but we’re reserving 501.”
“This leaves the integrity of the isc_buffer_t msg->buffer structure corrupt: now msg->buffer->used is BIGGER than msg->buffer->length. All the ingredients are here, we just need to put them in the oven.”
“Publishing a fix about a lethal bug where you would have to patch the whole internet, doesn’t leave a lot of time to find elegant solutions. So if you review the fix it’s possible that a new similar bug appears in dns_message_renderbegin(). while the use of msg->reserved is quite limited. It continues being a complex software. Meanwhile msg->reserved is still being used, the existence of a bug like CVE-2016-2776 is quite probable.”

4 ways to hack ATMs

“We have already told you about a number of hacker groups jackpotting money from ATMs. Now you can see it with your own eyes! Our experts shot four videos of ATM hack demos.”
Method 1: Fake processing center

Disconnect the network cable for the ATM, and connect it to your rogue device (a Raspberry Pi will do)
When the ATM asks “the bank” (your rpi) if it is ok you give the person money, always say yes
“The box is used to control the cash trays and send commands to the ATM, requesting money from the chosen tray. It’s as simple as that: The attacker can now use any card or input any PIN code, and the rogue transactions will look legitimate.”

Method 2: A remote attack on several ATMs

“This method involves an insider working in the target bank. The criminal purchases a key from the insider that opens the ATM chassis. The key does not give an attacker access to the cash trays, but it exposes the network cable. The hacker disconnects the ATM from the bank’s network and plugs in a special appliance that sends all of the data to their own server.”
“Networks connecting ATMs are often not segmented (separated for security), and ATMs themselves can be configured incorrectly. In that case, with such a device a hacker could compromise several ATMs at once, even if the malicious device is connected to only one of them.”
This method works when the network cables are not exposed
Then the rest is the same as Method 1

Method 3: The black box attack

In this attack, the bad guys directly connect their black box to the cash trays, and send them the commands to spit out the money
“As previously described, the attacker obtains the key to the ATM chassis and accesses it, but this time puts the machine into maintenance mode. Then the hacker plugs a so-called black box into the exposed USB port. A black box in this case is a device that allows an attacker to control the ATM’s cash trays.”
“While the attacker tampers with the ATM, its screen displays a service message like “Maintenance in progress” or “Out of service,” although in reality the ATM can still draw cash. Moreover, the black box can be controlled wirelessly via a smartphone. The hacker just taps a button on the screen to get the cash and then disposes of the black box to hide the evidence that the machine was compromised.”

Method 4: Malware attack

“There are two ways to infect a target ATM with malware: by inserting a malware-laced USB drive into the port (requiring the key to the ATM chassis) or by infecting the machine remotely, having first compromised the bank’s network.”
“If the target ATM is not protected against malware or does not employ whitelisting, a hacker can run malware to send commands to the ATM and make it dispense cash, repeating the attack until the cash trays are empty.”
“Of course, not all ATMs are hackable. The attacks described above are feasible only if something is misconfigured. It could be that the bank’s network is not segmented, or authentication is not required when the ATM’s software exchanges data with the hardware, or there is no whitelist for apps, or the network cable is easily accessible.”

So there are a number of ways to address these issues
Method 1 and 2 should normally be defeated by proper use to SSL/TLS. Of course you want the messages exchanged with the bank’s processing center to be encrypted, integrity checked (guaranteed not to have been modified by the bad guy), but TLS also provides authentication, assurance that the remote end is actually the trusted bank, not a bad guy. The ATM should have a list of trusted certificates, and refuse to process transactions with any other party.
Method 3 requires some way to establish trust between the ATM software, and the cash box hardware. Even if the messages between the computer and the cash box were encrypted, authenticated, and integrity checked, the issue is that the private key used to ‘sign’ the messages to the cashbox would need to be stored on the ATM computer. Maybe the commands to the cash box should be signed by the bank’s processing center.
To solve Method 4 will require software whitelisting. If the ATM will only run software signed by the trusted certificates of the bank or ATM manufacturer, then it is much harder for the bad guys to get their malware to work on the ATM

Open Source Botnet | TechSNAP 287

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Source Code for IoT Botnet ‘Mirai’ Released

A tale of a dns packet

4 ways to hack ATMs

Feedback:

Round Up: