[asterisk-dev] My misfire ... Asterisk DoS
J. Oquendo
sil at infiltrated.net
Sun Oct 8 18:07:04 MST 2006
FYI I corrected my misfire in minutes (poop happens). No one managed to download the tool.
-bash$ awk '/5e5135b617a29d14f034614d24378cc9/{print $2,$4,$5,$6,$7,$9,$10}' access_log
- [06/Oct/2006:13:44:27 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 306
- [06/Oct/2006:13:45:14 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [06/Oct/2006:14:17:38 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [06/Oct/2006:14:33:57 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [06/Oct/2006:15:08:27 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [06/Oct/2006:17:34:32 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:00:18:00 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:02:05:50 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:02:54:48 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:02:55:08 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:04:47:38 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 306
- [07/Oct/2006:09:43:33 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:11:46:55 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [07/Oct/2006:17:34:20 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
- [08/Oct/2006:04:13:26 -0500] "GET /5e5135b617a29d14f034614d24378cc9.tar 404 318
My intentions were not to leak some stupid new DoS tool for kiddiots to run amok. I was testing the SIP protocol on a Sun 480r with Asterisk and found that a few mangled packets here and there did some horrible things. I also passed off information to CERT and Cisco regarding what I was seeing, but being the majority of the attacks seemed to affect Asterisk more, I contacted those who need to know.
So far off-list I had many requests for the tools and I have declined. I won't post them until I am sure there are fixes in place for what is going on. My first post regarding the DoS (log files) showed a glimpse as to what had happened. Since then I have mangled things a bit more (towards CCM) and things still seem to affect Asterisk.
For those wondering about doing IP syncookie protection, I can tell you it won't work. For those thinking an SBC will protect you, think again. I've got an Netrake nCite I can likely DoS to oblivion as well. For those unfamiliar with nCite, I can record my co-workers' countless "WTF's" on that platform. Why should I bother testing it when it does well DoS'ing itself.
What I have thought about was something similar to BGP's dampening/flapping mechanisms to restrict some of the attacks. Would work in a twofold manner:
IP+SIPINFO --> Packet --> Server
Server --> CHECKPACKET & if IP+SIPINFO change more than twice in X_AMOUNT_OF_TIME_THRESHOLD then TIMEOUT IPI+SIPINFO
If this makes sense to others. What I WOULD DO if I could is look at two values, the SIP information and the packet information. If the SIP information and IP address change give it say a 30 second time out the first instance of something being off. Second time about it should get a 60 second timeout. Third time, 2 minute timeout. This MAY weed out a bunch of the spoofing issues temporarily.
The other approach is to use snort_inline along with a carefully scripted IPS to look for certain values and block those packets out based on SIP information going through, .e.g: if BYE & SOMEOTHER_VALUE = SPECIFIED then (FW)Block in on _ETHERNET_ this would ensure (slightly) that bogus packets get filtered in case someone were to mangle packets using a valid SIP account. Just my thoughts.
A third approach would be to use something similar /etc/limits built into Asterisk where perhaps a user would be limited to X_Amount of channels but that would likely fail in a large environment if say the receptionist of a 1000 worker business were restricted. However it would be a nice option if configurable:
[foo]
type=friend
host=dynamic
secret=tercet
context=gateway
dtmfmode=rfc2833
qualify=2000
nat=yes
processes=10
SIP account foo would be restricted to a specified amount of processes in this instance 10. There are a few ways I can think of preventing this, but none are in all honestly f(oo)ullproof since I can think of a way to circumvent the things I think of. Anyhow, I hope some things I mentioned get modified to make things better. As for my misfiring, as I stated poop happens, but apologies, and for those who keep asking, the answer is no I won't give you anything to test your own network with, at this point I know of no other tool that is shutting down Asterisk as fast as this one and I won't release it until I am sure no kiddiots will be able to use it against my networks since after all I do use Asterisk on a non personal/hobby level.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
sil infiltrated . net http://www.infiltrated.net
"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey
More information about the asterisk-dev
mailing list