Was QotD (and RFCs 862-867) actually insecure?

Question

I am fascinated by these 6 obsolete internet protocols, all written up as seperate RFCs by Jon Postel in May 1983. They are hilariously simple. (Which I mean as a compliment; their simplicity inspires me.) Several of the RFCs are less than one page long:

name	port	RFC
Echo Protocol	7	862
Discard Protocol	9	863
Character Generator Protocol	19	864
Quote of the Day Protocol	17	865
Active Users Protocol	11	866
Daytime Protocol	13	867

My favorite of the above is Quote of the Day (QotD) Protocol. It's like Twitter for teletypes! Send any packet to port 17, and it responds with whatever message the system administrator wants, up to 512 characters.

Sadly QotD and the others are nearly/totally extinct today because of security. Everything I read about QotD warns that it was insecure. For example, this document by the Irish government on QotD says:

An Internet Accessible QOTD Service can be abused for a Distributed Denial of Service (DDoS) Reflection/Amplification attack against a third party.

I don't understand why. I can see how the UDP version of the service (which the RFC specifies) is insecure. As UDP is is a connection-less protocol that does not validate source IP addresses, it can be turned against someone. But how was the TCP version insecure? Or was it?

Is insecurity the real reason they became extinct? Honestly, they seem mostly useless...could that be the real reason?

A few still run:

• djxmmx.net runs Quote of the Day Protocol
• time.nist.gov runs Daytime Protocol

Are these relics insecure? Have they modified the spec in some way to become more secure?

Answer 1

I am fascinated by these 6 obsolete internet protocols,[...]They are hilariously simple.

You mean beside that it was

• a time of low resources without room for complex protocols,
• an open frontier with room for even the smallest service,
• a tight community where everything new was exiting,
• a stage were every example what a service could be was needed, and
• an open and welcoming environment where new use cases were implemented as new protocols instead of piggy packing it onto some known one to circumvent weird security and optimization layers?

My favorite of the above is Quote of the Day (QotD) Protocol.

:)

Sadly QotD and the others are nearly/totally extinct today because of security.

I would think there's also a good dose of missing use case.

An Internet Accessible QOTD Service can be abused for a Distributed Denial of Service (DDoS) Reflection/Amplification attack against a third party.

I don't understand why. [...] But how was the TCP version insecure? Or was it?

Either is and exactly as mentioned because of providing a (D)DoS vector.

It's not about being 'insecure' in a sense to hijack the server or alike, but making them inoperable for other tasks by capturing most of the available bandwidth with QotD schmooze.

A flood of minimum size UDP packets can create a much larger size of return data. Thus one can bring the useful services (e.g. non QotD) to a grinding halt by utilizing 100% of the outgoing traffic even before filling up the inbound bandwidth. This works the same for UDP or TCP. CGP being a prime example as it doesn't require any interaction beside TCP handling to fill up.

That way this server itself is already flooded. Now imagine the attacker forging the sender IP, replacing it with some target IP he wants to get down. At least UDP based services will now send data packets toward that, overloading that target. Doing so, any QotD server will become an DDoS amplifier.

Honestly, they seem mostly useless...could that be the real reason?

Would agree a missing use (to a wider public) made them forgotten. After all, most have been test utilities for early implementers on new machines.

A few still run:

Also got some running on one of my servers.

Are these relics insecure?

As mentioned, the level of 'insecure' depends on the PoV taken.

Also, they could as well simply not care - usually such services run not on average production systems but some nerdy/historic machines, so anything an attacker might accomplish is degrading his own experience.

Have they modified the spec in some way to become more secure?

Even such services can be made secure by the usual measures against (D)DoS like limiting number of connections, throttling bandwidth use filtering in gateways and so on. So you may ask them what has been done if at all.

Answer 2

Traffic amplification is "useful" even in the trivial case where there is no IP spoofing or weirdness and you effectively "DoS yourself" with the responses.

Suppose I want to take down this stackexchange site, so I can have all the sweet sweet retrocomputing knowledge for myself. The QOTD service would be running on the same physical server and connected to the same physical network at the application I really want to take down. So if I send one byte to the stackexchange server, I can force the network to carry 512 bytes of response every time I do that. Since this is all on the same network as the real traffic, it would strangle the real traffic going to people looking up retrocomputing questions.

If I can get 2000 of my closest friends (or a bot net) to do the same thing, each of us is only sending for example 1 byte every second. But the server is responding with 512 * 2000 bytes of quotes. For very low effort, a 1 byte/sec attack is filling the target network with 1 Megabyte/second of extra traffic and packets for the server and routers to process. And the networks of the attacking machine won't really notice the small amount of traffic coming from each attacker, so they are much less likely to be taken offline by corporate IT departments than computers in a botnet doing "unamplified" DDoS attacks, so it is much easier for the attacker to stay under the metaphorical radar the more they can amplify an attack by triggering big responses to small requests.

Now if you do have some sort of clever IP spoofing attack where you confuse old buggy routers with corrupt packets or something, you can potentially do silly things like getting QOTD services to send attacks to each other, and respond to an incoming quote packet with a quote. Whenever you can chain attacks so they multiply with each other, exploiting simple service to poke at a buggy service to send a packet to a third service, etc. you can generate even more chaotic network flooding from less and less original source traffic from a machine and network you directly control. Think of something like QOTD as one brick that could be used to build a wobbly building, not just something dangerous in and of itself.

Answer 3

TCP QoTD is specifically vulnerable when combined with a sequence prediction attack. In a TCP QoTD communication, the only thing an attacker needs know to be able to send packets to the QoTD server to trigger the significantly longer response is a packet with the servers sequence number from the three way handshake. If the attacker can predict that, then they don't need to be able to receive the servers responses, meaning it can be used for a reflection attack like UDP.

However, most modern systems have access to a cheap source of randomness. And so random sequence numbers are commonly used, mitigating this attack vector.