[Pussnboots]

A new instance of DrDOS has been found. This particular individual is far more intelligent than the last.

This version of DrDos is far more complex than the previous and let me define below;


New DrDos'er:

This new DrDOS'es now uses a plethora of Master Server lists to reflect UDP commands. These commands are STILL interpreted by URT 4.1 servers (Even though SOME are blocked) and replied to.

This works by a script that varies in a few ways as follows:

1:. This script WILL and DOES work on ALL current Quake Engine Servers!

2: This script uses multiple high and low level bandwidth servers to accomplish it's Denial Of Service Attacks via UDP.

3: This script uses Q3 servers OTHER THAN it's originator to complete the task.

What this means is that this script relies on Master Servers of ANY (Potentially ALL) Quake 3 servers to forward fallacious requests to another game server of ALWAYS a different Q3 game Mod/type.

For instance, this latest script will NEVER use it's OWN gaming platform to "reflect" UDP commands. This means the originator AND send are ALWAYS on 2 different platforms...... ALWAYS..

What this means for URT Server operators?.... This means you are still NOT safe. Though the latest official binary is directed towards network safety, it is the exact opposite of immune and VERY vulnerable to UDP DOS attacks.

Currently, there is NO way to run a Q3 game server WITHOUT modifying your iptables. Windows users are shit out of luck.. Windows is incredibly vulnerable to such attacks and always will be unless they re-platform. If Windows users have access to a physical external firewall, they can prevent such DIRECT attacks to their servers HOWEVER...... Since routing works the same across the spectrum.. Linux, Cisco, Windows.. what-have-you.. are ALL ALWAYS susceptible to UDP DOS attacks as it is connection-less and does NOT require packet verification..

On the other hand... To stat again, Linux is the MOST safe because it has the ability to ignore packets at layer 3 as opposed to Windows equivalent Layer 7 (It's gotten WAY tp far at this point).. Because Linux (iptables) decided at layer 3 , it will not forward any packets.. whereas most common (Windows based) firewalls (or lack thereof) WILL forward SOME of these requests, this makes this vulnerability THAT much more prevalent.


My suggestion:
Though this process can take considerably more time, dbasing ALL q3 servers (including MOD servers such as URT etc) at server startup and regular (say 24 hour) intervals would make such an attack to be effective on ANY level.

This mod can ONLY be added to the source code and Preferably complimented by an actual memory based dbase such as MySQL as opposed to a flat-file based dbase such as SQLlite....

In summary... URT (and other URT) servers would be impacted during load/update time, however; overall performance for server and players WOULD increase substantially... Although I have begun working on such a mod myself at Layer 3, I think it would be MOST effective at Layer 7 considering the target audience..


I'll find this next mofo with a bit of time and kick his ass too... In the meantime, it is DIRE that ALL server operators make the required changes as necessary ...

To reiterate once more... These are Multi-Reflective attacks and perhaps should be known as DmrDOS as they NEVER rely on the originators MODTYPE to "reflect" or "bounce" UDP packets. (Meaning Originator Q3 mod-type differs from it's destination mod-type via spoofed packets (Tried and true)...

[Pussnboots]

...Or even.. Just require an authentication handshake...

Example:
Packet 1 (Client => Server):
[0]Connection String
[1]Host Name
[2]Random Key

Packet 2 (Server => Client):
[0]Connection String
[1]Original Key
[2]Hashed Key (Hashed with it's own random string)

Packet 3 (Client => Server):
[0]Connection String
[1]Original Key
[2]Hashed Response Key
[3]Command (Get Status Getinfo)

If the hashed key does not match the original key, the command is ignored.

Also, to step it up a bit, put an expire on any given key.

Run verification against the sender. If the sender attempts X amount of times in Y amount of time, deny all requests from that host.

This post has been edited by Pussnboots: 15 June 2012 - 10:38 PM

[|P|Nitro]

raider was on the lilpwny teamspeak and we (happyface, gramps, raider and me) were brainstorming and we were talking about the above technique but also making use of bandwidth division (rather than multiplication) instead of making it beneficial to attackers by turning their 1mb/s bandwidth into a 10mb/s reflected attack.

we just need to make sure the Server -> client response asking for authentication is equal to (or less than) the CLIENT -> SERVER request, essentially turning the attack on its head meaning for every 10mb/s attackers bandwidth we only respond with 1mb/s (or 5, 6, 7mb/s etc).


this essentially would act as a deterrent to use the urban terror network.

[FS |HSO|RaideR]

Yep. The only real way to prevent the abuse of the UDP is to make the weight for the client to be able to get a status reply heavy enough to counter the benifit.

At the moment we have the following.

Client (Tiny Request) ---> Server ---> Large Data Burst Responce. With the manipulation of the return path in the proticol you get a Dos effect that we are all very much aware.

If we implement Source Handshake Validation and Initial responce weight at the same time we get the following.

Client (Larger Request such as "HELLO <X Bytes>) --->
Server (Check that the X Bytes are recieved, reply with "HELLO <TOKEN>" --->
Client (Recieves Token and makes a local cache of ServerIP-Port-Token) --->
Client ("<TOKEN> GetStatus") --->
Server (Server Validates Token and responds to the getstatus with its standard databurst)

This implementation should make it costly to recieve a getstatus. The impact is it will make doing a full server list FAR more intensive on the client. This should be fine because a legit client will be able to handle this weight.

Either way, we are looking at this actively, when we have a workable fix i will be back to you with the data.

[Pussnboots]

I understand your thoughts on "more weight"... But it would only take marginally longer to get the Master Server list.. Seconds more at most for the complete list. Frankly, I think it'll be worth the wait :D

[FS |HSO|RaideR]

The current security issues are based in the IP for return being unvalidated. If we implement HELLO handshaking, then the only address that can be flooded is a legitimate source (i.e. the attacker) and thus pointless.

I will explain this to the coders and get a patch realised ASAP

[|P|Nitro]

this will require ~everyone~ to update including the master servers, so I take it the patch wont be released until either with 4.2 or afterwards?

[[Ice]IceLogic]

Does anyone know how far along Frozen Sand Developers are to comming up with a solution to this attack? This new Dos attack is not patched in 4.2 at the moment.

[undead]

I'm not looking into this but I have a few suggestions:

1) If the client/server was based on the latest ioquake3, then you could iterate with upstream to get the fix applied to the source code that others care about. No one uses the 2007 era code that UrT uses.

2) Have you looked into how well known protocols handle this? This type of attack isn't new and didn't originate with games. For instance, it has been a well known attack with DNS. Since DNS is a core Internet protocol, there are more people looking into the problem and suggesting ideas. It may be a better idea to see what others have done for DNS before implementing a new idea. Since you can't easily change DNS, it may give you an alternative mitigation idea rather than implementing a new handshake for quake3.

[/eVo/Divinity]

If the goal is to prevent using UrT servers from being used in an attack, then two things should be done IMO:

1) Handshaking to validate the source IP.

2) Thresholds to limit the number of failed handshakes from a given source IP in a specific time slice.

The first prevents a small number of hosts from doing massive amounts of damage. The second prevents large numbers of source hosts from performing a broader DoS with handshake packets and masking their identity to the target host or hosts.