Bywają takie sytuacje w życiu administratora IT, że pomimo, że nie chce, to i tak musi przypomnieć sobie, komuś zapomniane hasło. Zgodnie z III zasadą dynamiki Newtona oddziaływania ciał są zawsze wzajemne. Skoro ktoś kiedyś zaszyfrował, ktoś inny kiedyś odszyfruje. Jak widać jest to tylko kwestia czasu. Dosyć filozofowania zabieramy się do pracy. Na początek musimy ustalić w jakiej tabeli bazy danych jest przechowywana interesująca nas informacja. Możemy to uczynić na zasadzie przeglądania poszczególnych rekordów bazy danych z poziomu PGAdminaIII. Nie zawsze jest to wbrew pozorom proste. Wynika to raz z złożoności samych baz danych, po drugie modyfikacji tabel w kolejnych wersjach systemu i po trzecie programiści może nie tyle, że nie lubią administratorów ile nie dowierzają ich rozsądkowi. Dlatego zaproponuje wykorzystać w tym celu sam silnik bazy danych by udzielił nam tej informacji. Jak go do tego zmusić. Prostym zapytaniem, które w normalnych warunkach służy do podglądania uruchomionych zapytań PostgreSQL,
select * from pg_stat_activity;
ale użyty tuż po próbie logowania (nawet nieudanej) ujawnia nam położenie hasła (patrz 2 wiersz kolumny query).
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start | state_change | waiting | state | backend_xid | backend_xmin | query
-------+---------+------+----------+----------+------------------+--------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+---------+--------+-------------+--------------+-------------------------------------------------------------------------------
16385 | bit-sos | 1606 | 10 | postgres | psql | | | -1 | 2019-03-17 19:50:53.95515+01 | 2019-03-17 19:55:42.713868+01 | 2019-03-17 19:55:42.713868+01 | 2019-03-17 19:55:42.713873+01 | f | active | | 627224 | select * from pg_stat_activity;
16385 | bit-sos | 1645 | 10 | postgres | | 192.168.0.92 | | 56359 | 2019-03-17 19:55:34.327709+01 | | 2019-03-17 19:55:37.537483+01 | 2019-03-17 19:55:37.537954+01 | f | idle | | | Select l_pole3,0,s_pole1 from g.adm_uzytkownicy_inne where id_uzytkownika=1
(2 rows)
Kopiujemy drugie zapytanie i wykonujemy je.
select l_pole3,0,s_pole1 from g.adm_uzytkownicy_inne where id_uzytkownika=1;
l_pole3 | ?column? | s_pole1
---------+----------+----------------------------------------------------
78432 | 0 | 202cb962ac59075b964b07152d234b70
(1 row)
Teraz to już kwestia czasu lub jak kto woli mocy obliczeniowej. :-) Sądząc po długości haszowania stawiam na funkcję MD5 Chiński profesor Wang w roku 2004 przedstawił przepis na znajdowanie kolizji dla dwublokowych wiadomości, które na komputerze klasy PC zajmuje godzinę, W marcu 2006 roku Vlastimil Klima publikuje algorytm, który to robi w minutę. Ja temat przyśpieszę i wykorzystam metodę mniej inteligentną, ale nie mniej skuteczną wykorzystując tzw. tablice tęczowe (rainbow tables - baza haseł zakodowanych jednokierunkową funkcją skrótu) dostępne on-line na stronie https://hashtoolkit.com .
Hasłem są trzy cyfry 123. Na deser przepis na zmianę hasła dla konta Administratora w Graffiti-ERP na to ostatnio zdekodowane:
UPDATE g.adm_uzytkownicy_inne SET s_pole1='202cb962ac59075b964b07152d234b70', l_pole3=78432 WHERE id_uzytkownika=1;
lub inne wykorzystując do wygenerowania hasła tym razem następującą stronę http://killbox.pl/work/md5/md5.php .
Na zakończenie jestem jeszcze dłużny jedną informację. By zadziałało pierwsze zapytanie może być konieczne:
dodanie do postgresql.conf następującej zmiennej stats_command_string = true
sudo service postgresql restart