Date: Sun, 27 Sep 1998 13:52:33 -0400 From: "Max Schau (Noc-Wage)" Subject: 1+2=3, +++ATH0=Old school DoS +++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 (phoenix@iname.com). 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 characters. The 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' string in hex is: 2b2b2b415448300d . The complete command is : ping -p 2b2b2b415448300d *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. ---------------------------------------- Date: Sun, 27 Sep 1998 23:27:34 -0600 From: Brett Glass Subject: Re: 1+2=3, +++ATH0=Old school DoS I'm not entirely sure that these "kidz" quite understand what's going on here, so it probably pays to elucidate a bit. Some time ago, Hayes Microcomputer Products got a patent -- known as the "Heatherington patent" -- on its method of doing modem escape sequences. The patent was a "submarine" patent -- that is, one that issues long after others in the industry have begun using the same technique or technology -- and was bitterly disputed by other modem vendors, who didn't want to pay money to Hayes. However, Hayes gradually one most of the lawsuits due to deep pockets, clever lawyers, and the idiosyncrasies of the patent system. The patent involved the timing of the escape sequence: The characters "+++" followed by a 1-second pause. To get around the patent, some modem vendors simply eliminated the pause, so that the sequence +++AT would bring the modem back to command mode in all cases. Hayes, bitter about not being paid royalties by these vendors, sabotaged its own press releases by placing the characters "+++ATH0" at the top of each document and then circulating them widely. (The idea, I suppose, was to make the press believe that other brands of modems were not reliable.) I exposed this primitive denial of service attack in my InfoWorld column in 1991. Eventually, modem chip vendors licensed the patent, so that modem manufacturers didn't need to anymore. At that point, the whole issue became moot and the production of modems that didn't require a pause after the "+++" stopped. Today, it's rare to find a modem that responds to the attack unless there happens to be a long pause in the data stream after the "+++". Most ISPs program their modems to ignore the "+++" sequence, and so make their modems immune to it. You can, too, by setting the proper "S-register" on your modem. (You can still hang up the modem by dropping the DTR line, as virtually all communications programs do nowadays.) Therefore, this DoS attack isn't a big deal. It's easily preventable, rarely effective, and relatively harmless (all you have to do, if it hits, is redial). --Brett Glass ---------------------------------------- Date: Mon, 28 Sep 1998 01:24:03 -0500 From: Daniel Hauck Subject: Re: 1+2=3, +++ATH0=Old school DoS [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. Some characters may be displayed incorrectly. ] With all due respect to you and your prior efforts, I will also add that I tested the attack against a random channel on IRC and I downed about 33-40% of the victims tested against. In spite of what you are mentioning, it seems apparent that the folks at Rockwell did not purchase the patent...and Rockwell chipset modems are quite popular these days. My own dialup modem was suseptable to the attack (ref: the pipebomb blew up in my face.) until I fixed that. The stuff at work was also Rockwell based until I fixed it. The results are surprisingly good. Though it's an old attack (from way back in the BBS days) it's still quite valid. --my 2 cents. ---------------------------------------- Date: Mon, 28 Sep 1998 02:36:40 -0400 From: Pete Gonzalez Subject: Re: 1+2=3, +++ATH0=Old school DoS > At that point, the whole issue became moot and the production of modems > that didn't require a pause after the "+++" stopped. > Today, it's rare to find a modem that responds to the attack unless there > happens to be a long pause in the data stream after the "+++". Most ISPs > program their modems to ignore the "+++" sequence, I have a Diamond SupraExpress 56k modem (purchased a month ago) which dials an Erol's account. I tried the exploit posted by Max Schau, and it worked first try. Also, it occurs to me that this vulnerability could possibly be used to make the person's modem hang up and dial 911. :-) -Pete ---------------------------------------- Date: Mon, 28 Sep 1998 00:02:32 -0700 From: kill9 Subject: Re: 1+2=3, +++ATH0=Old school DoS On Sun, 27 Sep 1998, Brett Glass wrote: > Today, it's rare to find a modem that responds to the attack unless there > happens to be a long pause in the data stream after the "+++". ... > Therefore, this DoS attack isn't a big deal. It's easily preventable, > rarely effective, and relatively harmless (all you have to do, if it hits, > is redial). > > --Brett Glass > I have tested this out here locally, as well as with the help from a few other people onlin and it seems that 6 of 9 modems have been affected. I would hardly call that 'rarely effective', relatively harmless yes, but it seems to be a large percentage. I am interested to see more results as too how wide spread this is. (all tests were done using ping -p 2b2b2b415448300d host ) kill9 ---------------------------------------- Date: Mon, 28 Sep 1998 20:48:08 +1000 From: Ross Wheeler Subject: Re: 1+2=3, +++ATH0=Old school DoS On Mon, 28 Sep 1998, kill9 wrote: > On Sun, 27 Sep 1998, Brett Glass wrote: > > Today, it's rare to find a modem that responds to the attack unless there > > happens to be a long pause in the data stream after the "+++". > ... > > Therefore, this DoS attack isn't a big deal. It's easily preventable, > > rarely effective, and relatively harmless (all you have to do, if it hits, > > is redial). > > > > --Brett Glass > > > > I have tested this out here locally, as well as with the help from a few > other people onlin and it seems that 6 of 9 modems have been affected. I > would hardly call that 'rarely effective', relatively harmless yes, but > it seems to be a large percentage. I am interested to see more results > as too how wide spread this is. This was widespread when I was involved in Fidonet. There are two good cures, depending on the modems you use. 1. Make sure you have a guard time of at least a second. Due to licensing restrictions, not all modems implement guard times which is why the problem came about in the first place. 2. Change the escape lead-in sequence to something that's NOT "+++" Most modems will take any character with a decimal number >128 as a DISABLE, and will therefore "prevent" this DoS by ensuring an on-line modem never gets the escape lead-in in the first place. Even if your modem doesn't disable, you can pick some obscure code as an escape character. Don't use things that are likely to occur in normal use, like " " or "---" etc! There was an e-mail exploit some time back (12 months or more) that used exactly the same DoS to hang peoples mail, but simply including the string "+ + + ATH0" (without the spaces) in an e-mail message. When a vulnerable modem attempted to send the text, it went off-line immediately. RossW ---------------------------------------- Date: Mon, 28 Sep 1998 04:49:14 -0500 From: Kevin Day Subject: Re: 1+2=3, +++ATH0=Old school DoS > On Sun, 27 Sep 1998, Brett Glass wrote: > > > Today, it's rare to find a modem that responds to the attack unless there > > happens to be a long pause in the data stream after the "+++". > ... > > Therefore, this DoS attack isn't a big deal. It's easily preventable, > > rarely effective, and relatively harmless (all you have to do, if it hits, > > is redial). > > > > --Brett Glass > > > > I have tested this out here locally, as well as with the help from a few > other people onlin and it seems that 6 of 9 modems have been affected. I > would hardly call that 'rarely effective', relatively harmless yes, but > it seems to be a large percentage. I am interested to see more results > as too how wide spread this is. > > (all tests were done using ping -p 2b2b2b415448300d host ) > > kill9 > In doing some testing here on willing victims.... 30% seemed vulnerable with the ping -p attack. For IRC users: //raw NOTICE ToastyMan : $+ $chr(1) $+ PING +++ATH0 $+ $chr(1) (in mirc) Also seems to work, and will work through bnc's or whatever proxy you are going through, since it's part of the irc protocol..... This only worked on one user though. So far, A/Open(acer) 56k's were the most common modem that was vulnerable. (3 of the 6 tested that were vulnerable were using those modems) I'm working on a 'For Dummies' program that will scan your system for modems, and ATZ ATS2=255&W Hopefully this'll be fixed. I'll release it tommorow, and post it here if Aleph doesn't mind. Kevin Day DragonData ---------------------------------------- Date: Mon, 28 Sep 1998 06:58:13 -0700 From: Tudor Bosman Subject: Re: 1+2=3, +++ATH0=Old school DoS One other possible fix would be to set your modem's escape character to something other than +, especially a control character (ASCII code 0x00-0x1f), and then escape it using PPP's asyncmap option. -- Tudor Bosman E-mail: tudorb@caltech.edu Phone: *NEW!* (626) 683-8055 *NEW!* Address: Caltech MSC #345, Pasadena, CA 91126-0345, USA ---------------------------------------- Date: Mon, 28 Sep 1998 09:13:28 -0400 From: Quantum Technical Support Subject: Re: 1+2=3 +++ATH0=Old school DoS Quick note, I tried this on a Noblelink 56k Plug and Play, and it was successful, 3 for 3. Tried it on 3 different USR modems - Internal Sportster v.90, External Sportster v.90, Internal Sportster x2. All failed. A Zoom Internal 56kflex/v.90 (model 2812?) was successful. It appears that the problem may be exclusive to Rockwell and Lucent chipset modems, but I haven't tested it enough to be sure. ---------------------------------------- Date: Mon, 28 Sep 1998 03:52:40 -0400 From: John M. Flinchbaugh Subject: Re: 1+2=3, +++ATH0=Old school DoS On Mon, 28 Sep 1998, Pete Gonzalez wrote: > Also, it occurs to me that this vulnerability could possibly be used to > make the person's modem hang up and dial 911. :-) this could be a real problem. one of the early reports stated that the attacker managed to take down 30-40% of an irc channel, correct? so it seems to be a bit widespread. this could be used to make the modem dial those long-distance international pay numbers and such. and another observation i've noticed in testing this attack. the victim machine attampts to send the hangup string, drops it's network connection, and the response fails to get back to the attacking host. upon redialing, the response is again sent when it tries to flush that connection, and the modem goes offline yet again. i do not know off hand how long it will do this, but i witnessed a machine redial nearly 10 times before i finally just offlined my own computer, so it would not find me and try to send it again. another possibility in this little attack would be to reconfigure the modem, save the new settings, and online the modem again. could you see a dial up client being reconfigured to max out at a 2400 baud connection? :) ____________________}John Flinchbaugh{______________________ | -> glynis@hjsoft.com <- john@cs.millersv.edu | | glynis@netrax.net http://www.hjsoft.com/~glynis/ | ~Powered by Linux: Reboots are for hardware upgrades only ---------------------------------------- Date: Mon, 28 Sep 1998 13:29:06 -0500 From: Adrian Gonzalez Subject: Re: 1+2=3, +++ATH0=Old school DoS Hello We're and ISP and have several dedicated customers over ISDN lines, using TA's such as the Motorola Bitsurfr Pro and the 3com Impact IQ. So far, I didn't find either of these ISDN modems to be vulnerable, but while testing, I came up with the idea of using this 'feature' to 'patch' a vulnerable modem: ping -c 1 -p 2b2b2b415453323d32353526574f310d host this sends a single packet with the string + + + ATS2=255&WO1 (No spaces, of course) to the host, which changes the escape char remotely. It also sends the O1 command, which is supposed to bring the modem out of command mode and maintain the connection, however, I found that most modems just hung up, possibly because of the &w command. Why is this useful? Well I've used it to remotely patch the modems of several customers which have dedicated analog lines with us. 6 of the 11 modems I tested were vulnerable, the patch worked on all 6, but only 2 of them were able to maintain the connection after the &w. I tested 2 Terminal adapters, neither were vulnerable. -Adrian Gonzalez