29/4/2012
Do śmiesznego zdarzenia doszło podczas ostatniego, kwietniowego patchowania produktów Oracle. Firma podziękowała jednemu z researcherów, który myśląc, że zgłoszony przez niego błąd został załatany opublikował szczegóły ataku. Okazało się jednak, że błąd nie został usunięty i wszystkie wersje Oracla są na niego podatne. A ponieważ nie ma patcha, administratorzy baz danych muszą sobie radzić sami…
Fatalna pomyłka Oracle
Przy wypuszczeniu ostatnich 88 łatek na produkty Oracle, firma podziękowała Joxeanowi Koretowi, który w 2008 (sic!) roku zgłosił “krytyczny” błąd. Koret opublikował więc szczegóły podatności i opisał jak można ją wyexploitować.
Kilka dni później zorientował się jednak, że błąd nie został załatany (a dokładniej: będzie załatany dopiero w wersji 12) a więc wszystkie obecne wersje bazy Oracle pomiędzy 8i to 11g R2 są na niego podatne.
Oracle TNS Poison
Na co pozwala błąd wykryty przez Koreta? Na zdalne przekierowanie przez atakującego ruchu kierowanego do bazy danych na inny serwer. Atakujący musi jedynie znać Oracle SID lub Oracle service name serwera bazodanowego Oracle, którego ruch chce przechwycić.
Oracle 0day
Krótko mówiąc, Koret znalazł sposób na to, jak zarejestrować swój złośliwy listener, który zostanie zinterpretowany jako część mechanizmu load balancing bazy danych Oracle — dzięki czemu część ruchu do bazy będzie przez niego przechodziła. Oczywiście ruch ze “złośliwego” listenera można przekierować na serwer atakującego co pozwala na podsłuchiwanie połączeń kierowanych do serwera bazdanowego Oracle.
Jak zabezpieczyć bazę Oracle?
Jeśli nie korzystasz z clusteringu, ustaw dynamic_registration = off w listener.ora. W przypadu korzystania z clusteringu, należy ograniczyć dostęp do listenera tak, aby nie był dostępny z internetu lub LAN-u — przydatne opcje: TCP.VALIDNODE_CHECKING oraz TCP.INVITED_NODE. Jeśli masz wykupione Oracle Advanced Security, warto włączyć SSL/TLS w protocol.ora lub sqlnet.ora za pomocą dyrektyw: SQLNET.ENCRYPTION_CLIENT=REQUIRED i SQLNET.ENCRYPTION_SERVER=REQUIRED.
Patrząc na udzielone Koretowi wymówki na pytanie kiedy błąd rzeczywiście zostanie usunięty (“strasznie trudne do zbackportnowania“, “nasi klienci nie chcą tego typu patchy” (!?), “błąd leży w bardzo wrażliwym fragmencie kodu“), można się spodziewać, że nie nastąpi to zbyt szybko…
Weź udział z kolegami w jednym z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
hmm no to ładna wtopa :)
I tak nikt nie lubi Oracla.
“nasi klienci nie chcą tego typu patchy” – sic!
teraz już chcą ;)
Dalej nie chcą. Jeśli nie ma patcha, to nie ma o czym mówić przełożonym, bo nie trzeba nad niczym siedzieć. Już to widzę: “Przecież i tak nikt nie zgadnie naszego SIDa, a nawet jeśli to nie dostanie się do sieci. W końcu komu by się chciało.” :)
Nominuję ten tekst jako ‘cytat miesiąca’ lub coś podobnego, epic ;)
“nasi klienci nie chcą tego typu patchy”
Bo nasi klienci stosują nasz produkt jako honeypot i liczą na ataki…
A wrażliwe dane i tak trzymają w innych bazach…
A nie… hmm… jak nie to nie nasz problem…
Jak za cenę którą Oracle liczy sobie za swoje produkty to wtopili dość poważnie i chyba im się to niezdrowo odbije na obrotach firmy.
przecudowne. taki błąd wisiał przez 4 lata… a tłumaczenia są dla mnie jasne – albo błąd leży gdzieś w założeniach tego rozwiązania i do naprawy trzeba wszystko zmienić, albo mają taki burdel w kodzie, że nie da się tego naprawić bez poprawiania setek miejsc.
odnośnie sugestii z firewallami – czy ktokolwiek o zdrowych zmysłach trzyma serwer bazodanowy wystawiony na świat? zdecydowanie nie – a wtedy atakujący musi najpierw wejść na któryś z serwerów podpiętych do sieci gdzie są bazy, a jak mu się to uda to ma dużo większe pole do popisu – jak rozumiem ten błąd z Oracle pozwala jedynie na podsłuchiwanie ruchu do bazy i ew. modyfikacje zapytań.
Dokładnie. Nikt nie stawia oracledb w LANie. Więc najpierw trzeba się wbić do DMZ, a dobrze skonfigurowany firewall też ogranicza tam pole manewru. Inna sprawa, że słabym punktem są zwykle webserwery, które i tak mają dostęp do bazy…
Cóż… Znam takich, co tak robią ;) Tacy z gatunku “password” jako hasło administratora lokalnego… I to nie firma na 5 osób, ale duża spółka giełdowa…
To ktoś jeszcze z oracla korzysta? Przecież są lepsze rozwiązania jak MySQL czy PostgreSQL.
Nie ośmieszaj się
lol, 2008 r:D szybcy są:D
http://pl.wikipedia.org/wiki/Sic! polecam
Dzięki! Normalnie nigdy byśmy nie pomyśleli, żeby sprawdzić znaczenie słowa, z którego korzystamy! To takie wiarygodne, poprawiać błędy po 4 latach.
Jedna z tych wiadomości gdzie w miarę czytania daje się zaobserwować korelacja pomiędzy powiększającymi się oczami i uśmiechem.
A może Koret, wkurzony biernością Oracle, sam postanowił “przyspieszyć” prace nad tym błędem? ;)
scb :”Dokładnie. Nikt nie stawia oracledb w LANie…”
TVP stawia. nmap -p listner /24 :*
[…] komu dostęp do bazy nie jest potrzebny, nie powinien go mieć. Ale mamy nadzieję, że już po poprzedniej krytycznej podatności w Oracle nikt z Was nie wystawia bazy na publicznym […]