Russian banks floored by withering DDoS attacks

Re: The problem is the internet protocols - Explain!

There are many network protocols, and they exist in a hierarchy (I'm referring to the OSI model here; other models exist).

OSI layer 3, the Network layer, is "IP" or "Internet Protocol." Its job is to facilitate moving packets of data from one host to another, locally or across routers. While it is responsible for moving data between hosts, it cannot deliver it to the applications or services that need it-- that is done by OSI layer 4.

OSI layer 4, the Transport layer, is responsible for the end-to-end delivery of data for applications and services. There are two main Transport layer protocols for use with IP: "Transmission Control Protocol" or "TCP"; and "User Datagram Protocol" or "UDP."

You might recognize TCP from "TCP/IP," which commonly-- and improperly-- is used as shorthand for any Internet data communication. TCP is a "session oriented" protocol. That is, communication using TCP requires that the client and server establish a session before communication commences, which requires the client ask the server to start a new session, receive an acknowledgement from the server, and then negotiate the session details.

Setting up the session is, relatively, expensive: it take a bit of time, because multiple non-data exchanges need to occur first, and it requires a little more RAM to maintain information about the session. TCP has its benefits, however, because it guarantees the delivery of data by ensuring each packet is received and re-sending those that go missing. It also requires that the client address in the IP header be valid, because two-way communication is necessary to complete session setup. Most protocols make use of TCP: HTTP, SMTP, POP3, IMAP, SSH, TELNET, FTP, LDAP, SQL (Microsoft, MySQL, Postgress, Oracle, etc), and so on.

The other Transport layer protocol, UDP, is "the" problem. UDP is a "connection-less" protocol, which does not require any session setup. A client simply sends a UDP packet to a server and the server-- if it is listening-- sends a response. Because there is no session information, there is no built-in retransmission of lost packets, but that's usually okay because you rarely use UDP for anything sensitive to data loss: audio and video transmission are the most popular uses of UDP, along with DNS and NTP. It also doesn't perform any validation of the client address in the IP header.

The lack of session setup makes UDP ripe for abuse. A malicious user can create a UDP packet to a server with the "from" address field set to the target system the user wants to DDoS, "spoofing" the address. The server, upon receiving it, will then reply-- completely unaware that it is sending to a third-party.

UDP attacks are made worse by a process called "amplification." Take DNS, for example: the spoofed DNS request doesn't have to be very large-- maybe 120 bytes, maybe less-- requesting a particular domain name lookup, but the lookup could be for a domain name with lots of records, causing the reply to be ten or more times larger. This amplifies the attacker's power, allowing him to generate ten or more times as much traffic as he has directly available through his Internet connection.

Taking over an IoT device is even worse, as the attacker now has the potential to load custom scripts or firmware and generate attack traffic directly, without relying on amplification and with minimal Command and Control traffic. And because the traffic is sent using UDP, there's no session setup to prevent or mitigate the flood: it just goes and goes and goes.

It should be noted that TCP is not without its faults with regard to DoS attacks. One of the early DoS attacks involved sending bad session setup requests that were never completed but still caused the server to allocate resources while waiting for the session setup to complete, which ultimately lead to resource exhaustion and the denial of service. This has been at least partly mitigated, and tends to affect a small number of servers, so it is no longer a common attack method.

UDP attacks, on the other hand, are kind of like saturation bombardment: the target server is knocked out, and service is degraded or denied for anyone else using the same Internet connection as the target.

Re: Leaving security to the end user = no security

"Maybe someone could write a scanner which finds these open IoT devices and changes their password?"

The problem with this is that as soon as the miscreants discover a device with a default password they will probably change it themselves so that they don't lose control to rival hacking gangs. So your scanner is going to have to operate more prolifically than the hackers themselves if it's going to be able to compete. This cure is arguably as bad as the disease, as it ends with competing floods of IoT pwnage traffic blasting the internet offline in the attempt to gain/stop new recuits to the various botnets out there.

The end user won't give a toss about who is actually in control of the admin functions of their IoT whatnot, as long as they can still use the front end interface. If the miscreants can avoid messing with that, they've got carte blanche to use the whatnot as a bot indefinitely. The alternative of bricking devices completely instead of just password protecting them would at least gain some consumer awareness of what exactly it is they are unwittingly unleashing on the world, though this is seriously grey hat (and arguably black hat) territory. From the owner of the whatnot's point of view, this cure is also worse than the disease.

Making manufacturers have to conform with minimal security standards (including no generic default passwords) is about the only thing that can help without causing massive collateral damage, even if it can only ever be a partial success. If the whole of Europe (CE) and North America (whatever equivalent standards exist over there) add this to the regulations the potential market for pwnable kit will decrease significantly, and the manufacturers will have to start taking it into account or they won't be able to make any sales through the legitimate channels. Good luck getting that change approved though!

Re: Mandatory password

I think there's merit to that proposal. The Linux distro I'm currently using encrypts the hard drive by default and requires a password for that, and also a password to log on once the OS has loaded. It complains if the passwords provided are too easy.

That's an OS install, though, and consumers aren't used to doing that when setting up most IoT tat. Unfortunately. And so perhaps the biggest drawback to your proposal might be: it's easier for the consumer if an IoT device is simply plug-and-go. And it's cheaper in the short term to make devices without any particular care to security. So marketplace competition: X is easier and cheaper than Y, even though Y is more secure and more socially responsible. X wins.

Until regulation requires it. Which makes the manufacturers bark with dismay, because to them regulation = evil socialist totalitarianism. But that's a different whinge.

Re: I hope the perps aren't Russian

Goldman Sachs have way more money that you could shake them down for than any Russian bank. Wonder what influenced the choice of targets... Hmmmm?

Re: I hope the perps aren't Russian

"And how strange they didn't attack Goldman-Sachs, or anything like that. Gosh."

The DDOS on the Russian banks is the payback for the Russians hacking our election. I'm still waiting for the reports of hacked vote counts in certain states that went for Trump. There will be riots in the streets, well, uh, more so then now.