61–70 of 112 posts
More on the SSDP servers Since we probed the vulnerable SSDP servers, here are the most common Server header values we received: 104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0 77329 System/1.0 UPnP/1.0 IGD/1.0 66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2 12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0 11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4 What an earth is internet facing and running 2.4 Linux kernels?
> Internet service providers should never allow IP spoofing to be performed on their network. IP spoofing is the true root cause of the issue. See the infamous BCP38. I don't see how it is at all reasonable to shift blame from a protocol that assumes the world can be trusted to the untraceable goal of "every single network in the entire world should only generate trusted data: then the problem would be solved". > Int…
You commented on two points: A) ip spoofing B) netflow On IP spoofing I said plenty already https://idea.popcount.org/2016-09-20-strange-loop---ip-spoof... . There are two major points: - We will always have DDoS vulnerable UDP protocols. In past we had DNS. Then we had NTP. Now we have SSDP. The next one is going to be some gaming protocol. We should fix them as we go, but a more comprehensive solution it to actuall…
A long time ago, there was a proposal (itrace, its latest draft was https://tools.ietf.org/html/draft-ietf-itrace-04; see also http://ccr.sigcomm.org/archive/2001/jul01/ccr-200107-paxson....) to make these attacks easier to trace, by having routers probabilistically emit ICMP packets towards the supposed target or source of a packet. From what I recall, as DDoS attacks moved from IP spoofing to zombies using their real IP address, the working group sort of lost its purpose and died.
More on the SSDP servers Since we probed the vulnerable SSDP servers, here are the most common Server header values we received: 104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0 77329 System/1.0 UPnP/1.0 IGD/1.0 66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2 12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0 11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4 What an earth is internet facing and running 2.4 Linux kernels?
CEP (home routers)
Earlier quoted context omitted.
IP spoofing is the problem. Even if you completely ban UDP protocols, it still allows for anonymous unamplified attacks. Attacking every single protocol that dares to respond to a query is a pretty stupid approach IMO. Look how well it's worked so far. Additionally, unless we switch DNS to TCP only, root and authoritative name servers are always going to provide and amplification factor and there are still more than…
Who are these ISPs? I would love to see a treemap apportioning blame to the worst offenders...
https://spoofer.caida.org/summary.php
23% of the address space, about 33% of AS's. It has improved a lot but still some way to go
> Internet service providers should never allow IP spoofing to be performed on their network. IP spoofing is the true root cause of the issue. See the infamous BCP38. I don't see how it is at all reasonable to shift blame from a protocol that assumes the world can be trusted to the untraceable goal of "every single network in the entire world should only generate trusted data: then the problem would be solved". > Int…
You commented on two points: A) ip spoofing B) netflow On IP spoofing I said plenty already https://idea.popcount.org/2016-09-20-strange-loop---ip-spoof... . There are two major points: - We will always have DDoS vulnerable UDP protocols. In past we had DNS. Then we had NTP. Now we have SSDP. The next one is going to be some gaming protocol. We should fix them as we go, but a more comprehensive solution it to actuall…
Quake 3 engine game servers have already been used in amplification attacks.
>It's not a novelty that allowing UDP port 1900 traffic from the Internet to your home printer or such is not a good idea. How would this even be possible? Home routers have to NAT everything. Normally you have to set up reverse NAT to get ports forwarded to the LAN.
You don't have to have a router. The apartment building where I live have fiber, with twisted pair to each apartment. DHCP leases from the apartment gives you an external IP. It's possible to hook up a switch and get DHCP leases for multiple devices. I assume there's an upper limit, I've only tried it with two devices. Now, let's say I hook up a printer to a switch in that configuration. Is it smart enough to not res…
WTF? How would it not be utterly idiotic to not respond to UPnP requests from globally routable addresses? Why should it be impossible to print from some machine, just because it has a globally routable address?
Author here. Allow me to extend the post a bit. It turns out that about 2.4% of the IPs that respond to SSDP queries, do so from a weird port number! For example: IP 192.168.1.75.50950 > 239.255.255.250.1900: UDP, length 95 IP 192.168.1.71.1026 > 192.168.1.75.50950: UDP, length 249 The first packet is SSDP M-SEARCH query. The second is a response from my printer. Notice - the source port for the response is not 1900…
Isn't that normal UDP behavior? Source port on responses can always be anything?
If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections, because you can multiple connections open with the same computer at the same time to the same dest port, and the only differentiation would be the source port.
Earlier quoted context omitted.
Isn't that normal UDP behavior? Source port on responses can always be anything?
You're half right. In most cases, programs have the OS pick their source port, but that's for the computer initiating the communication. So for example, in the communication he gave the 50950 was likely picked by the OS (by selecting a currently open port) and 1900 is the destination port. When the remote computer responds (his printer), they don't then pick a new random source port, they just swap the source/dest fr…
UDP does not have connections.
> and the only differentiation would be the source port.
... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.
Author here. Allow me to extend the post a bit. It turns out that about 2.4% of the IPs that respond to SSDP queries, do so from a weird port number! For example: IP 192.168.1.75.50950 > 239.255.255.250.1900: UDP, length 95 IP 192.168.1.71.1026 > 192.168.1.75.50950: UDP, length 249 The first packet is SSDP M-SEARCH query. The second is a response from my printer. Notice - the source port for the response is not 1900…
Isn't that normal UDP behavior? Source port on responses can always be anything?
More on the SSDP servers Since we probed the vulnerable SSDP servers, here are the most common Server header values we received: 104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0 77329 System/1.0 UPnP/1.0 IGD/1.0 66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2 12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0 11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4 What an earth is internet facing and running 2.4 Linux kernels?