1+2=3, +++ATH0=Old school DoS

[wage () IDIRECT CA (Max Schau)]

+++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<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.