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."
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.
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
The important design objectives of the Network Voice Protocol (NVP) are:
- Recovery of loss of any message without catastrophic effects. Therefore all answers have to be unambiguous, in the sense that it must be clear to which inquiry a reply refers.
- Design such that no system can tie up the resources of another system unnecessarily.
- Avoidance of end-to-end retransmission.
- Separation of control signals from data traffic.
- Separation of vocoding-dependent parts from vocoding-independent parts.
- Adaptation to the dynamic network performance.
- Optimal performance, i.e. guaranteed required bandwidth, and minimized maximum delay.
- Independence from lower level protocols.
I would assume it's NVP (Network Voice Protocol)
See rfc741
To quote...
I think this may help:
s
http://www.iana.org/assignments/protocol-number
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.
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
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.