Recent Posts

Pages: [1] 2 3 ... 10
1
Management Tools / Re: Q: Which group handles what stuff?
« Last post by Nerm on Yesterday at 08:21:07 PM »
Well I may be modifying my original post seeing as how it was just announced that our entire IT org is being restructured and my roles counterpart was just laid off as well as my boss.
2
Wireless / Re: KRACK Attack Summary
« Last post by deanwebb on Yesterday at 11:55:57 AM »
Have your patch management system check Windows devices for updates relevant to KBs 4041691, 4042895, 4041676, and 4041681.
3
Routing and Switching / Re: Carrier standards for sub-10GE?
« Last post by ristau5741 on Yesterday at 11:15:59 AM »
at the old place we just had 10GE installed, fiber handoff, and paid for a partial, I think they were at 2Gb, moving to 4Gb
4
Wireless / Re: KRACK Attack Summary
« Last post by deanwebb on Yesterday at 10:40:55 AM »
I'm now getting my home CounterACT NAC set up to check my Windows devices for compliance and if non-compliant devices are also on wireless.

Found one box that hasn't been updated since October... 2016... it's on the LAN now, running WSUS offline updates.
5
Routing and Switching / Re: Carrier standards for sub-10GE?
« Last post by Otanx on Yesterday at 10:01:22 AM »
Why do you think letting BGP handle it is wrong? That is how I would do it if I didn't just go to 10G.

-Otanx
6
Wireless / Re: KRACK Attack Summary
« Last post by Otanx on Yesterday at 09:58:10 AM »
The vulnerability release was actually done pretty well. The vendors were given heads up a little while ago and the day of the public announcement most vendors had patches ready to go either Monday or are expected pretty soon.

-Otanx
7
Updated reference links, the botnet isn't suddenly worse.

Phew.
8
TA16-288A: Heightened DDoS Threat Posed by Mirai and Other Botnets

Original release date: October 14, 2016 | Last revised: October 17, 2017

Systems Affected


Internet of Things (IoT)—an emerging network of devices (e.g., printers, routers, video cameras, smart TVs) that connect to one another via the Internet, often automatically sending and receiving data


Overview


Recently, IoT devices have been used to create large-scale botnets—networks of devices infected with self-propagating malware—that can execute crippling distributed denial-of-service (DDoS) attacks. IoT devices are particularly susceptible to malware, so protecting these devices and connected hardware is critical to protect systems and networks.


Description


On September 20, 2016, Brian Krebs’ security blog (krebsonsecurity.com) was targeted by a massive DDoS attack, one of the largest on record, exceeding 620 gigabits per second (Gbps).[1] An IoT botnet powered by Mirai malware created the DDoS attack. The Mirai malware continuously scans the Internet for vulnerable IoT devices, which are then infected and used in botnet attacks. The Mirai bot uses a short list of 62 common default usernames and passwords to scan for vulnerable devices. Because many IoT devices are unsecured or weakly secured, this short dictionary allows the bot to access hundreds of thousands of devices.[2] The purported Mirai author claimed that over 380,000 IoT devices were enslaved by the Mirai malware in the attack on Krebs’ website.[3]

In late September, a separate Mirai attack on French webhost OVH broke the record for largest recorded DDoS attack. That DDoS was at least 1.1 terabits per second (Tbps), and may have been as large as 1.5 Tbps.[4]

The IoT devices affected in the latest Mirai incidents were primarily home routers, network-enabled cameras, and digital video recorders.[5] Mirai malware source code was published online at the end of September, opening the door to more widespread use of the code to create other DDoS attacks.

In early October, Krebs on Security reported on a separate malware family responsible for other IoT botnet attacks.[6] This other malware, whose source code is not yet public, is named Bashlite. This malware also infects systems through default usernames and passwords. Level 3 Communications, a security firm, indicated that the Bashlite botnet may have about one million enslaved IoT devices.[7]


Impact


With the release of the Mirai source code on the Internet, there are increased risks of more botnets being generated. Both Mirai and Bashlite can exploit the numerous IoT devices that still use default passwords and are easily compromised. Such botnet attacks could severely disrupt an organization’s communications or cause significant financial harm.

Software that is not designed to be secure contains vulnerabilities that can be exploited. Software-connected devices collect data and credentials that could then be sent to an adversary’s collection point in a back-end application.

In late November 2016, a new Mirai-derived malware attack actively scanned TCP port 7547 on broadband routers susceptible to a Simple Object Access Protocol (SOAP) vulnerability. [8] Affected routers use protocols that leave port 7547 open, which allows for exploitation of the router. These devices can then be remotely used in DDoS attacks. [9, 10]


Solution


Cybersecurity professionals should harden networks against the possibility of a DDoS attack. For more information on DDoS attacks, please refer to US-CERT Security Publication DDoS Quick Guide and the US-CERT Alert on UDP-Based Amplification Attacks.

Mitigation

In order to remove the Mirai malware from an infected IoT device, users and administrators should take the following actions:

  • Disconnect device from the network.
  • While disconnected from the network and Internet, perform a reboot. Because Mirai malware exists in dynamic memory, rebooting the device clears the malware [11].
  • Ensure that the password for accessing the device has been changed from the default password to a strong password. See US-CERT Tip Choosing and Protecting Passwords for more information.
  • You should reconnect to the network only after rebooting and changing the password. If you reconnect before changing the password, the device could be quickly reinfected with the Mirai malware.

Preventive Steps

In order to prevent a malware infection on an IoT device, users and administrators should take following precautions:

  • Ensure all default passwords are changed to strong passwords. Default usernames and passwords for most devices can easily be found on the Internet, making devices with default passwords extremely vulnerable.
  • Update IoT devices with security patches as soon as patches become available.
  • Disable Universal Plug and Play (UPnP) on routers unless absolutely necessary. [12]
  • Purchase IoT devices from companies with a reputation for providing secure devices.
  • Consumers should be aware of the capabilities of the devices and appliances installed in their homes and businesses. If a device comes with a default password or an open Wi-Fi connection, consumers should change the password and only allow it to operate on a home network with a secured Wi-Fi router.
  • Understand the capabilities of any medical devices intended for at-home use. If the device transmits data or can be operated remotely, it has the potential to be infected.
  • Monitor Internet Protocol (IP) port 2323/TCP and port 23/TCP for attempts to gain unauthorized control over IoT devices using the network terminal (Telnet) protocol.[13]
  • Look for suspicious traffic on port 48101. Infected devices often attempt to spread malware by using port 48101 to send results to the threat actor.

References




Revision History



  • October 14, 2016: Initial release

  • October 17, 2016: Added ICS-CERT reference [11]

  • November 30, 2016: Added SOAP vulnerability references [8], [9], [10]

  • October 17, 2017: Updated reference links.




This product is provided subject to this Notification and this Privacy & Use policy.



Source: TA16-288A: Heightened DDoS Threat Posed by Mirai and Other Botnets
9
Routing and Switching / Re: Getting around global VLANs - ASR1K
« Last post by wintermute000 on October 17, 2017, 05:56:08 PM »
I've done sub interfaces before with the same tag send they're all routing nicely and definitely not switching
10
Routing and Switching / Re: Getting around global VLANs - ASR1K
« Last post by deanwebb on October 17, 2017, 01:57:55 PM »
Yo, Szechuan Rick - what are you saying, maybe they don't? :)

I can setup a test case without breaking anyone, I'll check it out.

 :showme:
Pages: [1] 2 3 ... 10