Cybersecurity

"Mortal Kombat" с колекции #1-5

Александър Цокев

• 3 min read
"Mortal Kombat" с колекции #1-5

След като в интернет се появиха сведения за Collection #1, много сайтове и новинарски емисии посветиха публикации и репортажи на 773-те милиона изтекли пароли. Да, хайпа (на чист български) беше сериозен, но някак покрай това се промъкна новината за Collections#2-5, съдържащи огромен брой компрометирани акаунти (или поне така се предполагаше).

В следващите редове ще се опитам да систематизирам неравната борба на Collections#2-5 с мен и постигнатото до момента, а анализите ще публикувам веднага, щом успея да импортирам данните в база данни.

"Get over here"

Благодарение на усилията на колегите от ASOC екипа на Telelink Business Services, получих достъп до torrent файл, включващ архивите от Collections#1-5. Разбира се първата ми мисъл беше, че ще изтегля около 400 GB порно или безсмислени неща, добре допълнени от зловреден код. Е, не бях прав. Торента, наистина съдържаше архиви (142 файла), в които се намираха множество текстови файлове - 75217.

Разкомпресирането на данните отне около половин ден и след това вече имаше 851 GB TXT, SQL и други файлове. Възможно е това да не са пълните колекции #1-5 и голяма част от паролите да се дублират, но въпреки това, обемът е изключителен.

102G    /media/root/Maxtor/Collection_2_5_DATA/Collection #1
488G    /media/root/Maxtor/Collection_2_5_DATA/Collection #2
43G     /media/root/Maxtor/Collection_2_5_DATA/Collection #3
179G    /media/root/Maxtor/Collection_2_5_DATA/Collection #4
41G     /media/root/Maxtor/Collection_2_5_DATA/Collection #5
851G    /media/root/Maxtor/Collection_2_5_DATA/

Някои от файловете включваст милиони редове:

wc -l 'MYR (38).txt'
216053550 MYR (38).txt

Повечето имена на файловете не носят информация за домейна, от където са изтеклите акаунти, но бърза справка показа, че от България има 27 сайта завършващи на ".bg" или имащи в името "-bg".

Започнах да преглеждам файловете и първото ми впечатление беше, че всичко е подредено, а структурата на текста е CSV с разделител ":" (акаунт:парола). За съжаление бързо попаднах на SQL файлове, такива с разделител ";" и " ", както и със странен формат - "час:акаунт:парола:други данни". Стана ми ясно, че обработката няма да е тривиална задача. Един възможен подход беше да прегледам всеки файл по отделно и да модифицирам формата. Подобна ръчно-крачна операция на 75217 файла определено не е решение поне в рамките на следващите 10-ма години. Вторият метод е да се определят шаблони за обработка на файловете - прегледа на формата показа, че са използвани 4-5 разновидности.

Прецених, че ще опитам да създам шаблони за обработка (parse) и паролите ще запиша в база данни, добавяйки информация за zxcvbn ентропията и оценката. Написах скрипт на Python за рекурсивно обработване и изчитане на текстовите файлове, а за формат на базата данни избрах SQLite (тук няма как да не направя аналогия с "канала" на Тобстера - "сял лайт"). Импортирането стартира, но размера на базата данни започна да нараства значително, въпреки, че съдържаше само една таблица с акаунт, парола, hash (PK) и данните от zxcvbn анализа. Бях пропуснал да проверя, дали SQLite поддържа компресия на таблиците.

... Ctrl+C

Втори опит. Смених базата данни с MySQL и отново пуснах скрипта. Обработката вървеше безпроблемно за първия формат на файловете, включени в Collection #1. След около 65000 вмъкнати реда (без дублиране) скрипта спря. Време беше да опиша втория формат, след това третия, да проверя, дали разделителя е част от паролата и т.н. Тук мотивацията ми намаля, а боря на WTF/min се увеличи.

... Ctr+C

Сетих се, че колега от ASOC ми беше препратил връзка към проект в GitHub именно за обработка на Collections#2-5.  Изтеглих файловете, прегледах скриптовете и ги стартирах.

"Finish him"

След няколко дни обработка разполагах с SQLite база данни с размер от 771 GB, включваща колекция 2 и част от 3 (б.а. - $@%№$%@). Големият размер на базата данни (липсата на компресия) определено нямаше да доведе до повишаване на бързодействието. Поради тази причина спрях скрипта и реших да загубя още часове в неговото преправяне и обработка на данните и да ги импортирам в MySQL.

Предполагам, че се замисляте, дали ELK няма да е по-добро решение? Не съм сигурен и за да се прецени трябва да се сравнят двете платформи с анализираните данни, но това е нещо, което на този етап не съм си поставил като цел.

Докато чаках и следях от време на време конзолата се замислих за какво бих използвал събраната информация и какви полезни сведения ще мога дa събера от там?

Стигнах до няколко извода:

  1. Ще имам не-лош речник с пароли, стига да е целесъобразно да се тестват милиони стрингове, вместо да се използва "rainbow" таблица или друг подход за анализ на пароли;
  2. Ще мога да направя справка по зададен e-mail или парола, но това се препокрива с www.haveibeenpwnd.com;
  3. Ще е възможно да се извлекат данни за e-mail адреси, свързани с даден домейн, например всички завършващи с ".bg", "@mail.bg" и др.;
  4. След допълнителна обработка ще имам възможността да направя статистически анализ на паролите, базиран на ентропията им, както и да се опитам да изведа някои от по-интересните (по подобие на любимата ни парола от Collection #1 - "grani4arskoprase").

Заслужават ли си усилията с импортирането, при условие, че полезните резултати ще са сравнително малко?

Според мен отговорът е - да. Възможността за справка по домейн или търсене с regex ще даде гъвкави възможности за проверка, които не са (абсолютно логично) публично достъпни в www.haveibeenpwnd.com.

"Flawless Victory"

Дали, ще се стигне до "Flawless Victory" ... ще видим, за сега импортирането на данните в MySQL тече с няколко паралелни процеса...