Bounce, bounce, bounce. Spam.

Spotkałem się ostatnio z interesująca techniką wykorzystywaną przez spamerów. Niechciana poczta wysyłana była przez zabezpieczony przed niechcianym relayingiem serwer pocztowy. Skąd się tam wzięła?

Pewne urządzenie embedded w sieci tego serwera pocztowego ma publicznie dostępny adres IP. Jedyną godną zainteresowania usługą jest serwer WWW, który przeprowadza uwierzytelnienie za pomocą hasła i umożliwia interakcję z urządzeniem. Adres tego urządzenia znajdował się w nagłówkach wysyłanego spamu. Jednocześnie znajdował się w puli adresów IP, z których wspomniany serwer pocztowy przyjmuje przesyłki bez ograniczeń. Znalazło się więc źródło spamu, ale skąd wziął się sam spam?

Mimo braku logów słownikowe zdobycia hasła do urządzenia zostało wykluczone. Użycie nieznanego ,,hasła serwisowego'' wchodziło w grę, ale wydawało się mało prawdopodobne. Odpowiedź przyniosło podejrzenie za pomocą tcpdump pakietów kierowanych z internetu do urządzenia. Ich zawartość wyglądała mniej więcej tak:

10:18:32.958950 IP gw.chicago.genotech.no.sah-lm > xxx.gda.pl.http: . 0:1460(1460) ack 1 win 65535
E....q@.o...BZe.
..g....P...U....
P.......POST.http://153.19.yyy.yyy:25/.HTTP/1.1.
Content-type:.application/octet-stream..
Content-length:.3729..
Host:.153.19.xxx.xxx..

HELO.cluster1.hk.messagelabs.com..
MAIL.From:<xxx@dyxnet.com>..
RCPT To:<xxx@COX.NET>..
RCPT.To:<xxx@EARTH

Adres 153.19.yyy.yyy to wykorzystany serwer pocztowy, będący MXem dla domeny xxx.gda.pl. Spamer wykonał zapytanie POST, zasadniczono ,,odbijając'' połączenie od urządzenia. Nie zalogował się i nie uzyskał dostępu, wykorzystał tylko niedoskonałość wbudowanego serwera WWW, który nie powinien pozwalać na więcej niż HEAD, GET i POST. Bo to wystarcza do spełnienia przez niego swojej funkcji.

Rozwiązaniem problemu polegało na zawężeniu na routerze zakresu adresów IP, które mogą się kontaktować z urządzeniem. Zabronienie serwerowi SMTP przyjmowania poczty nie wchodziło w grę — urządzenie generuje czasem alerty emailem. Niemożliwa jest wymiana lub rekonfiguracja oprogramowania serwera WWW, taka specyfika urządzenia. Pozostaje winić producenta za możliwość wykorzystania POST, a wymogi konfiguracyjne za pozostawienie urządzenia otwartego do internetu.

Archived comments:

b 2007-04-24 22:03:30

Obstawiam im.gda.pl?

zdz 2007-04-24 22:04:11

Zakładów nie przyjmuję :P

b 2007-04-24 22:08:18

Szkoda,
SzkodaX2 ze ostatni czlon adresu nie jest ascii-printable ;)

japhy 2007-04-25 20:57:36

Czyli generalnie wykorzystanie open proxy w tej samej podsieci.

Można walczyć też od strony serwera SMTP, każąc serwerowi zamykać połączenia, w którym zamiast dialogu SMTP dostanie śmieci (jak HTTP/1.0 POST /, czy Content-Type: application/octet-stream). Albo każąc serwerowi kazać czekać na faktyczny dialog (nie przyjmować kolejnej linijki wejścia zanim nie zostanie wysłane wyjście -- a wysłanie wyjścia można odrobinę opóźnić, żeby odciąć boty, które po prostu wrzucają swoją część sesji na smtp i się rozłączają).

zdzichuBG 2007-09-30 12:08:11

Spamowanie via SP w X2100/X2200

Pół roku temu miałem wątpliwą przyjemność doświadczenia
użycia modułu zdalnego zarządzania do spamowania. Rzecz dotyczyła Service Processora w serwerach Sun Fire x2200 M2.

Sun Microsystems w końcu poprawił błąd. Więcej (niewiel[...]