Re: Sun FlashBack 1171: CERT Advisory: IP Spoofing Attacks and Hijacked Terminals

Autor: Andrzej Resztak (RESZ_at_PLUMCS11.UMCS.LUBLIN.PL)
Data: Thu 26 Jan 1995 - 14:01:56 MET


On Thu, 26 Jan 95 13:47:04 +0100 Szymon Sokol said:
>Tomasz Kokowski (kokowski_at_CS.PUT.Poznan.PL) wrote:
>
>: Przesylam kopie magazynu FlashBack (Sun) traktujacego o ostatniej serii
>: wlaman. *To nie bylo po source routing*.

Nie wiem co oznacza stwierdzenie *To nie bylo po source routing*,
jesli dobrze rozumiem ta nazwe to *source routing spoofing* jest
kluczowym elementem w tej sprawie.

>Innymi slowy: nie pomoze 'no ip source route' na routerze, i nie pomoze
>ZADEN TCP wrapper. Nie ma bowiem sposobu, zeby TCP wrapper na docelowej
>maszynie odroznil pakiet falszywy od prawdziwego. To musi robic router.
>Przyznaje sie bez bicia, ze jeszcze nie wiem, jak zmusic Cisco, zeby to robilo.
>Ale sie dowiem.

W wersji 9.17 dokumentacji chyba nic nie ma. Nowszej dokumentacji
nie posiadam.

>Oczywiscie, jesli zrodlo falszywego pakietu jest na lokalnej sieci, to router
>nic nie pomoze, ale jak masz na lokalnej sieci hosty, ktorym nie mozesz ufac,
>to i tak i tak kanal (ze wzgledu na mozliwosc nasluchu hasel).
>
>: > ftp.research.att.com:/dist/internet_security
>: >
>: > Bellovin paper: ipext.ps.Z
>: > Morris paper: 117.ps.Z
>Znalazlem, przeczytalem.

Jesli bylo cos interesujacego lub malo znanego to napisz,
jesli znajdziesz czas :-).

>
>: > Services that are vulnerable to the IP spoofing attack include
>: >
>: > o SunRPC & NFS
>: >
>: > o BSD UNIX "r" commands
>: >
>: > o anything wrapped by the tcp daemon wrappers - site dependent; check
>: > your configuration
>: >
>: > o X windows
>: >
>: > o other applications that use source IP addresses for authentication
>No i to jest rzeczywiscie problem. Moge nie uzywac .rhosts, ale nie uzywac
>NFS i X Windows to jest niemozliwosc.

Znam takich co nie uzywaja :-). Jako root loguje sie zawsze tylko lokalnie,
a NFS jest bez root-access. Poza tym wrazliwe sa niemal wszystkie
serwisy. Problem tylko w tym, ze "intruz" moze miec duze klotpoty z wyslaniem
'lewego' pakietu w odpowiednim momencie i zawierajacym niekorzystne
informacje. Ale to zalezy od jego wyczucia i szczescia.

>
>: > In taking over the existing connections, intruders can bypass one-time
>: > passwords and other strong authentication schemes by tapping the
>: > connection after the authentication is complete. For example, a
>: > legitimate user connects to a remote site through a login or terminal
>: > session; the intruder hijacks the connection after the user has
>: > completed the authentication to the remote location; the remote site is
>: > now compromised. (See Section I for examples of vulnerable
>: > configurations.)
>To tez jest powazna sprawa - to z kolei uderza w uzytkownikow uzywajacych
>np. telneta z roznych dziwnych miejsc (np. konferencji itp.), gdzie nie ma
>gwarancji, ze host nie jest juz "nadgryziony".

"Remote host" nie musi byc "nadgryziony", zeby atak sie udal. Rozumiem,
ze jesli jestes w sesji telnet ktos wysyla pakiet wpisujac Twoj
source IP oraz source i destination socket numbers zawierajacy
'Enter - ciag komend do wykonania - Enter' i jesli jestes w prompcie
shell-a te komendy zostana wykonane, a jesli jestes w edytorze
to zobaczysz co ktos chcial zrobic.
   Problem jest ze zgadnieciem numerow socketow. Jesli masz konto na ktoryms
z koncow sesji telnet w ktora checesz wejsc to nie ma problemu.
Zwykle informacje o aktywnych socketach sa dostepne dla wszystkich,
ale jesli nie masz konta na zadnym koncu to pozostaje
tylko strzelanie na oslep??? Oczywiscie tak samo mozesz probowac
wejsc w istniejace sesje X-Windows,NFS czy IRC. Rozumiem wiec, ze zaden
z uzytkownikow nie moze sie czuc bezpieczny, ale tak bylo zawsze
i to powinni wiedziec. Jako administrator czuje sie za to w 100%
bezpieczny - przynajmniej w tym temacie. Bo ze dwa dni temu Krzysio
mi napisal, ze mam zbior /usr/local/bin/autoreply set-userid to root.
I to rzeczywiscie byl problem.

Andrzej



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:49:49 MET DST