Slashdot Mirror
The Reverse Challenge: Winners Announced
asqui writes: "The Reverse Challenge was a contest from The Honeynet Project to essentially reverse engineer a binary captured in the wild running on a compromised honeypot. The contest ran during May of this year and the submissions have been judged and the winners announced. Dion Mendel took first place with 43.4 points out of a possible 50. The binary turned out to be a tool for performing remote DoS attacks from compromised hosts, with its instructions being cunningly supplied via the lesser known IP protocol 11. This binary is currently being used in the wild but there is little reported activity, probably because sysadmins are focused on the other more dominant protocols."
Quickly!!! Arrest the winners!!! They have obviously violated the DMCA!!!
Don't anthropomorphize computers, they don't like it.
This really is fascinating stuff. Note that most of the entrants used the disassembler known as IDA, available here. There was also much discussion of this contest recently on various security-related mailing lists.
Hopefully they will be doing a similar contest again next year. In the meantime, I guess we'll just have the Scan of the Month to analyse.
How can we tell if some of the contestants were not the same group of persons using that binary?
:)
:)
If this was the case then reverse engineering it might be pretty straight forward.
Just wonder, not accusation made.
*checks /etc/protocols* What the hell is protocol 11?
Do routers even route protocol 11? Would it make it to its DoS destination? Interesting. Per usual slashdot behaviour, I haven't read the articles yet, but I hope they discuss this a little more.
Hmm.......
The results link posted above (http://project.honeynet.org/reverse/results/) is wonderfully tortured HTML ... with
the pleasing side-effect of triggering
a mouseover color change for over half
the text in the opening paragraph when
rendered with Mozilla.
Hey, I found it interesting...
In response to the people criticizing the information about the protocol used...
Now someone can't even mention general characteristics of a hack without being criticized for giving information to "script kiddies" or "trojan writers"?
We know that security through obscurity is a poor excuse. I'd rather have this stuff out in the open so I and others can deal with it, than have it known only to a few...
look at it here.
My life in the land of the rising sun.
"Network Voice Protocol"
Your guess is as good as mine, as usual, someone who had no previous clus about nvp will google it and make a +5 informative post, so just wait for that.
As far as blocking it in ipchains,
-A input -s 0/0 -d 0/0 -p 11 -j DROP
I've had enough abrasive sigs. Kittens are cute and fuzzy.
http://www.ietf.org/rfc/rfc741.txt
Some links to it:
RFC 741 - Specifications of Network Voice Protocol (from November 1977!)
Protocol Number Assignments
From the bonus questions:
Summary
The program was written in 2000, being inspired by the media attention of the trinoo and TFN DDOS tools. The programmer is most likely young with limited personal resources. The programmer has a low skill level and resorts to the "cut and paste" style of programming. The programmer possibly resides in Europe and socialises with other blackhat style programmers. The programmer is male, overweight and has no social life other than his computer. He wears glasses and was bullied throughout school. He uses computers as a way of getting back at the world which has maligned him. You decide where reality steps aside and Hollywood takes over.
"This protocol goes to eleven."
"And like that
To quote...
Well, what I've pulled from websites and the RFC:
/etc/protocols . The protocol specification is in the header of the 20 byte beginning part of the IPv4 datagram. It's a 8 bit field.
1:It's a protocol. In IP speak, It's under the same secion that TCP(6), UDP(17), ICMP(1), and others fit under. On unix boxen, it can be found in
2: It was created specifically for voice transfers, along with "telephone emulation" (just the way you interface with the tele). I believe that many, if not all, webphones use this IP protocol. I also think that GSM and US telephones(that use IP networks) use this protocol to transfer voice data.
Some were asking how this could flood your system.... Well, what's the difference TCP and UDP? Or how about ping floods??? Well, it's all data being sent to you. Doesnt matter what 8 bit field is switched... It's still garbage data (if you didnt request it). It fills up your receving connection.
Hopefully I've explained what this is. I'll probably be modded redundant as somebody probably wrote a better "explanation" while I wrote mine. Oh well.
No. Shut up and stop making stupid jokes.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
I have default DENY, and specific ACCEPT rules. As everything I do ACCEPT contains a protocol, this means that unknown protocols are denied. For as long as You run only IPv4, no multicast, and so on (like most people do - although IPv6 is gaining), You only need icmp, igmp, tcp, and udp. Read
If You default to ACCEPT, or have very broad ACCEPT rules based on just eg. the IP addresses, You can, with ipchains, deny as follows: Not tested, but should work.
I don't believe it would do you any harm to block protocol 11. I would recommend that you block all protocols except for udp, icmp, and tcp, while you are at it. In fact, you can probably allow TCP and UDP only if you are a home user. I would just allow ICMP for the hell of it. Just set up a default incoming policy for all packets of "DROP," then accept all TCP packets, or all TCP packets meeting certain criteria, as desired. iptables allows you to specify protocols by number or name in a rule, using the "-p" parameter.
You should be able to block everything except TCP with something like:
iptables -F INPUT
iptables -P INPUT DROP
iptables -A INPUT -p TCP -j ACCEPT
if you also want to accept UDP (you do), then add this:
iptables -A INPUT -p UDP -j ACCEPT
for ICMP:
iptables -A INPUT -p ICMP -j ACCEPT
Note that ping, and a variety of other things, use ICMP, so I reccommend that you enable it.
Proper firewall configuration is a complex topic (and I'm not an expert at it). What I have posted above is not intended to create a safe firewall. I am hoping that you can figure the rest out yourself, or modify the above to suit your needs.
I have to run, so good luck.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
As far as I can tell, this program doesn't use NVP for attacking, and instead uses it as a covert channel on which it sends instructions to already compromised hosts, such as which host to DOS etc..
As such, as long as routers in general route it (since it's encapsulated in IP, this is not a problem) it doesn't matter that noone's listening to it. An already compromised host will be listening to it, and that's what matters.
Yes that means your correct to say that it's just saying that the packets are #11, while not implementing NVP at all.
I participated in the contest, and to answer a few questions:
1) Protocol 11 is used in this tool simply as a messaging protocol. No attempt was made by the author to adhere to the published NVP RFC. The author simply sticks 11 in the protocol field of the IP header. Think of each packet as a UDP packet, no handshake, etc...
2) Protocol 11 is not used to perform any of the DoS attacks. The attacks are fairly standard DoS attacks like TCP SYN, and ICMP echo floods.
3) Protocol 11 get through many firewalls because sysadmins only set up rules to block unwanted TCP, UDP, and ICMP packets.
4) Single incoming protocol 11 packets are used to trigger compromised hosts to perform selected DoS attacks
I hope that helps
Chris
Allowing _only_ icmp udp and tcp will break your ipv6 setup if you have one.
People that don't use IPv6 should ofcourse ignore my advice :)
I spent a little time reading the solutions of the winner, and of the #9 guy who won the $200 gift certificate for the most concise answer. I clicked on the "cost estimate" link for the winner.
I thought it would be one of those vaporous confabulations of how many BILLIONS of dollars' worth of corporate man hours would be lost to this exploit. Surprise! It's an estimate of what he would charge you to do this, if you were paying him ~$70k a year. If you don't want to click, it was about $3500 for the winner, and about $850 for the 9th place guy.
Then I started clicking a couple at random, and I noticed that the various cost analyses of various teams seem to cluster between $2500 and $4000 or so.
The Italian team are the clear outliers, claiming that they would bill over $10,000 JUST for the RE team and the analysis write-up. They included a full day's billing to cover "meeting, discussion, and coffee time."
the conclusions? a) one dutch kid can do the work of 8 Italian professionals in about 1/40th the time, and b) i need to get a job in Italy.
Humpty Dumpty was pushed.
Other than to be obscure, there's no good reason to use an unused IP protocol number rather than an unused UDP protocol number. This attack could equally well have used an UDP port.
It's worth checking servers to see if there's anything configured to listen to obsolete protocol numbers and unused UDP ports. Many UNIX servers still have a vast number of obsolete Berkeley daemons running. Some, like "biff", have known vulnerabilities. And it's worth checking for traffic on obsolete protocol numbers to see if some spyware is using them.
For the DNS attack, SOA queries for the following domains are made
com
net
edu
org
de Germany
usc.edu University of Southern California
es Spain
gr Greece
ie Ireland
Why the contrast between country codes for countries in Europe, and an US university? A theory on this is that the programmer resides in Europe, hence the familiarity with the European country codes, and has friends studying at usc.edu.
Having just graduated from USC.... I am more inclined to think that coder is(was) a student here, or at a big rival school (such as UCLA). I would be more likely then that the country codes were the first ones that came to his head, or that they were the countries that his friends (or enemies) originate from. (USC and UCLA both have unordinately large populations of foreign students compared to other US universities)
I'm out of my mind right now, but feel free to leave a message.....
getprotoent() repeatedly
and find the protocol number you want to use.
If I remember correctly, all of the BGP and EGP, and a number of the router protocols speak something besides straight TCP/UDP. It's essentially anything you can do on layer 4 of the OSI network model.
It's not a port. It's not a port. It's not a port. It's a protocol (you know like the "P" in TCP). It isn't TCP, it doesn't need to be dumbed down with an analogy. Lots of plenty intelligent people on slashdot actually understand some of the technology they post on, honest.
You might want to bone up on some basic networking before talking down to a guy who clearly understands piles more about networking then you demonstrated in your previous post. For all I know you're a networking guru, your last post however did not display that very well.
Service 11 (which communicates over both TCP and UDP according to RH 7.2's /etc/service) is systat, which is a good idea to disable as it gives out information about you're machine. So the idea of shutting off port 11 probably isn't a bad one...
Thanks, Kirby
PS: Sorry to post a complete flame, but the people talking about service 11 (NVP), do actually know a lot about what they are talking about. They don't need somebody to beat them with a cluestick about how ports work in TCP, by somebody who seems completely unaware of the fact that protocols besides TCP/UDP/ICMP exist, and that numbers refer to something other then ports.
It is amazing how confidently people spout wrong information, analogies and all. I wish there were a (-1, wrong) moderation available.
IP has no concept of port numbers - it is a network layer protocol and its job is to deliver packets from one IP address to another. It acts as a "carrier" for other protocols like TCP, UDP, or in this case NVP. To identify this super-protocol, the IP packet has a field for the protocol number. TCP = 6, UDP = 17, NVP = 11. So if an incoming packet says protocol #6, it is passed up to the TCP handler; if it says 17, it is passed to UDP.
Now the TCP/UDP/whatever protocol is free to use whatever means it finds fit to identify the actual process that is the destination of the packet - this is what port numbers are used for. So IP delivers the packet to a certain host, and then the next-level protocol looks at the port number in that packet to figure out which process it should be fed to.
It should be clear now that port numbers have nothing to do with protocol numbers.
Thanks for pointing our my error without saying "Hey, you fucking dumbass" -- even though it might be implied. While I don't like being wrong more than anyone else, I do appreciate being corrected.
Thanks.
Later.
Bonus question: explain why this attack had so many valid originating IP addresses.
karma capped
This tool was already using it, so we already have to upgrade our detection tools (where necessary) to deal with odd protocol numbers. If many other trojan writers start using the same trick, then it will just make them that much easier to detect.
A samrt Sysadmin knows to check slashdot.org once per day to see what irreposnible hints you are giving to script kiddies..
:)
From The Art Of War by Sun Tzu:
"The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not
on the chance of his not attacking, but rather on the fact that we have
made our position unassailable."
So a sysadmin relying on the attackers inability is if fact the irresponible one! neener neener
FRA: STFU GTFO
i went to school with this guy :)
:) overall a great guy - met him in march this year back in perth (australia). nice to see someone finally recognises some of his talent.
one hell of a smart guy; although strange at times (not at all bad). married to tiki swain - also another "unfound" talent. many would not see him as a "computer nerd" *g* - he is short, thin, hates working, hates wearing shoes - and, likes to live in the "wild". mcdonalds, coke, all other commercial stuff just isn't his cue - he prefers finding food in the wild
kudo's dion!
I would say -P input DROP
or DENY if ipchains
same goes for forward, and if an endstation nothing more need be done.
If it is a server with predetermined network needs, the doing the same for output is possible. Actually, even for client workstations you can at the very least limit output to tcp/udp/icmp/more as needed (i.e. ESP/AH), so a default DROP rule is good there too....
If you want to be nice at the risk of consuming upstream bandwidth and opening up a route for other bad stuff, you can use REJECT. I always use DROP, few legitimate systems get hung up on the timeouts and it really slows down a vast majority of port scanners, it also causes your system to slip below the radar for certain scanners, and they never know you're there to attempt attack.. And whatever you do, never *EVER* use MIRROR unless you really really *REALLY* understand what it does and truly know what it is doing. I had a friend who used MIRROR rule liberally, he thought it would be cute to see Script Kiddies scripts backfire on them. Well, we received an attacked with a spoofed source address. The legitimate holder of the source address was operated by CERT. Needless to say thte shit hit the fan when CERT saw what appeared to be him attempting to attack CERT, and he was disconnected from his high speed network access for a year over this in the end.
Just some very basic firewall advice, as is this forum wasn't full enough of it. I always had tight enough reigns on FORWARD and INPUT so this is not so much of an issue, as the system is not at risk for sending out this traffic, but now I think I'll add more strict output rules in case something applicable comes around.
XML is like violence. If it doesn't solve the problem, use more.
Some multicast. I think NTP and RIP2, could be more.
Routers absolutely route it. IT's still IP. It's not something strange or wonderful; it's just an IP packet with the protocol ID field set to '11'.
/etc/protocols on your favorite unix system, or just google for ip protocol IDs to see.
Have a look at
It's just something you don't usually hear about because we tend to only use TCP, UDP, and ICMP, and maybe GRE. (protocols 6, 17,1,and 47, respectively).
You can generate IP packets of whatever protocol ID you want and routers SHOULD route them.
Block ICMP too, except for the TCP_FRAGMENTATION_REQUIRED messages, otherwise you cripple TCP a bit.
If you look at the story the guy calls it protocol 11 but then he tells you to grep netstat output for anything using port 11.
And if you actually read the grep command line, you note that he's only looking for lines with 'raw' in them. Anything other than TCP and UDP shows up in netstat as 'raw' - for example, ICMP is protocol 1, and will show up like this on a RedHat system:
In short... he knows what he is talking about. You, however, should probably go read a man page or two.