Изпечатай

[RealEnder]

Последните няколко седмици се занимавах с проект, който трябваше да стане сървърната част на besside-ng - това е средство, все още живеещо в aircrack-ng svn-то. Последствие функционалността се попромени и допълни, като идеята е реализацията на разпределено crack-ване на WPA handshakes, подобно на множеството платени такива услуги. За разлика от тях аз нямам специализиран хардуер за сметките - те се извършват от доброволци, които правят изчисленията с помощта на python скрипт. Системата приема upload на libpcap captures, като за да видите резултата, предварително трябва да си извадите ключ. За момента работи с pyrit и aircrack-ng.
Адресът е http://wpa-sec.stanev.org
Приемам идеи за подобрения и допълване. Планирал съм отварянето на кода, може би ще стане към края на седмицата.

[gat3way]

Привет,

Ние си бяхме писали по този въпрос преди време. Браво за проекта, супер че си го задвижил

Като цяло имам няколко (надявам се градивни) критики по отношение на ефективността. Първата е свързана с ползването на aircrack-ския pcap analyzer, за да хващате необходимата информация за handshake-а. Понастоящем това може да е оправено, обаче допреди време, aircrack-ския парсър не беше stateful, демек въобще не вземаше предвид retransmission-и заради кофти качество на сигнала, което (някой си беше играл да вади статистики) - дава до 30-тина % грешка, средно около 10-12%, което в лошоят случай обезсмисля  по-нататъшното чупене, защото и правилната парола ще даде false negative.

Второто е ползването единствено на wordlist-ове за чупене на паролите. Вероятно това има смисъл когато имаш ограничени ресурси (да се чете липса на бързи GPU-та), но дори с проста относително евтина система като моята devel такава (2x5870) спокойно можеш да минеш 160 хиляди PMK-та в секунда, което осмисля ползването на разни rule-based атаки. Дори да не можеш да го нагодиш в софтуера, можеш да генерираш  по-големи wordlist-и на базата на съществуващи такива и прости правила (примерно leetify или добавяне на числа, комбиниране на два или повече речника и т.н). За това специално мога да ти помогна - имам относително мощен rule engine, трябва да ти драсна едно просто tool-чр, което вместо да подава нещата в удобен за мен формат, да ти плюе изхода на stdout-а.

Третото е - не знам дали си се свързал с хората, които пишат oclhashcat, в момента имат най-добрият WPA cracker (след някой друг месец това може и да се промени, хехе). Ако може да се нагоди за целта би било прекрасно. Техният cracker има и относително мощен rule engine, реализиран изцяло върху GPU-та. Предполагам това силно би помогнало, въпреки че софтуерът им не е отворен. Иначе аз поне в това отношение не мога да помогна засега - не ми е сложно да напиша PBKDF2 kernel, но идеята ми е да напиша покрай това и мой си  pcap parser, който да ми сервира нещата в удобен вид. Това може и да не влезе в следващата версия, а следващата версия няма да види бял свят в близките 1-2 месеца.

[RealEnder]

Здрасти,
Благодаря за отзивите, по въпросите:
pcap analyzer-а на aircrack-ng не е пипан от началото на 2010 и все още е на същото дередже. 30-те процента fail вероятно си ги прочел тук. Една от целите на проекта е да се преработи pcap analyzer-а на aircrack-ng, за да работи коректно. Това е важно, най-малкото защото например oclHashcat-plus използва анализатора на aircrack-ng, за да извади правилните хешове. В pyrit нещата стоят доста по-добре, там анализатора е statefull и се справя. На базата на събраната информация вече имам списък с captures, които не се process-ват правилно от aircrack-ng/pyrit, към последния tool започнах да пускам и бъгове с конкретни примери. Проблемът е, че работата е доста пипкава и тече бавно - трябва да се гледа всеки пакет, какви флагове са му вдигнати, каква е поредността и пр. Определено събраната база е доста полезна за тестове.
В момента процеса в dwpa за обработка на pcap е следният:
1. каченият capture се прекарва през wpaclean - това е от svn-то на aircrack-ng, оставя EAPOOL и broadcast пакетите
2. Изчистения capture се раззцепва по мрежи с tcpdump в отделни файлове. До вчера това ставаше с tshark, но производителността му е доста ниска в сравнение с tcpdump (нещо от рода на х100)
3. Всяко от файлчетата с мрежите минава през pyrit 0.4 analyze - ако анализатора открие коректен handshake - влиза в базата и се изпраща за чупене.
Процеса определено не е оптимален, но исках да имам бърза работеща сглобка с подръчни средства. Третата стъпка ще отпадне, когато имаме човешки анализатор във wpaclean.

Относно wordlist-овете - специално по случая написах скрипт, който да парсва wikipedia дъмповете - wlc. От тях се вадят единствено уникалните думи, където трябва се транслитерира. Знаци, цифри и т.н. се махат. Идеята е да има такива речници, които впоследствие да са удобни за прилагането на rule engin-а. Все още не съм направил интеграция с oclHashcat-plus, но и за това ще дойде времето. Освен това чакам и hashkill-а да донатъманиш

Относно Hashcat - да, имахме лека схватка с atom Постнах на форума, но човека е доста докачлив на тема "използват ме" - имаше няколко случая на ребранд на Hashcat туловете и продажбата им. В поста ми видя единствено реклама на услуга, която на всичкото отгоре няма връзка с Hashcat. След няколко нервни поста се разбрахме кой за какво се бори и решихме да изтрием thred-а, да не ни четат простотиите В края на краищата и той разчита на анализатора на aircrack-ng и има интерес да стане по-добър. Като ми остане малко време ще допълня help_crack-a и с hashcat поддръжка, която ще включи и rule engin-а му. Това, което ме спира е, че всъщност нямам хардуер, за да тествам Лаптопа ми е с intel-ска карта от SNB и втора ATI, което обаче държа изключено да не пие ток, защото под Linux със сегашните драйвери не отлепя.
Ако ти се занимава, можеш да пуснех help_crack-а да поработи при теб известно време - под linux ако намери pyrit директно го използва, ще е интересно за сравнение на производителността. Ако ти се python-и, може да добавиш и поддръжката за oclHashcat - приемам patch-ове

P.s. хм, намерих преди малко една win машина с geforce 9200M GS, може ако ми остане време да го допиша...

[gat3way]

Относно wordlist-овете - специално по случая написах скрипт, който да парсва wikipedia дъмповете - wlc. От тях се вадят единствено уникалните думи, където трябва се транслитерира. Знаци, цифри и т.н. се махат. Идеята е да има такива речници, които впоследствие да са удобни за прилагането на rule engin-а. Все още не съм направил интеграция с oclHashcat-plus, но и за това ще дойде времето. Освен това чакам и hashkill-а да донатъманиш

Знаците и цифрите не са ли валидни в passphrase-а или мислиш после да ги вмъкваш по някакъв начин? hashkill-а няма да го натъманя скоро да чупи WPA, освен ако не се предам и не се откажа на първо време сам да си парсвам pcap файлове. Но дори при това положение, опънсорс версията ще излезе поне 2-3 месеца след като е реализирано. Защо това е дълго за обяснение.

Относно Hashcat - да, имахме лека схватка с atom  Постнах на форума, но човека е доста докачлив на тема "използват ме" - имаше няколко случая на ребранд на Hashcat туловете и продажбата им. В поста ми видя единствено реклама на услуга, която на всичкото отгоре няма връзка с Hashcat. След няколко нервни поста се разбрахме кой за какво се бори и решихме да изтрием thred-а, да не ни четат простотиите  В края на краищата и той разчита на анализатора на aircrack-ng и има интерес да стане по-добър. Като ми остане малко време ще допълня help_crack-a и с hashcat поддръжка, която ще включи и rule engin-а му.

Обикновено е отзивчив, странно.

Това, което ме спира е, че всъщност нямам хардуер, за да тествам  Лаптопа ми е с intel-ска карта от SNB и втора ATI, което обаче държа изключено да не пие ток, защото под Linux със сегашните драйвери не отлепя.
Ако ти се занимава, можеш да пуснех help_crack-а да поработи при теб известно време - под linux ако намери pyrit директно го използва, ще е интересно за сравнение на производителността. Ако ти се python-и, може да добавиш и поддръжката за oclHashcat - приемам patch-ове

В момента ми е трудно да отделям ресурси за по-продължителен период от време, защото често ми се налага да ползвам GPU-тата за тестове. Мога обаче да го оставя някоя вечер. Единствено трябва да си инсталирам pyrit.

P.s. хм, намерих преди малко една win машина с geforce 9200M GS, може ако ми остане време да го допиша...

Мммм не искам да те разочаровам, но това разполага само с 8 CUDA ядра (шейдърни процесора, ALU unit-а или според каквато и да е терминология - всичките са синоними). Скоростта твърде вероятно ще е по-бавна от който и да било по-нов процесор. По принцип, Nvidia е огромна набутвация за GPGPU задачи, изискващи предимно целочислена аритметика (какъвто е SHA-1 алгоритъма, използван под една или друга форма в WPA-PSK). Другият момент е че SHA-1 алгоритъма силно много използва циклична побитова ротация наляво, демек:

rot(A,X) = (A<<X)|(A>>(32-X))

както и т.нар "bitfield insert", което е грубо казано нещо от сорта на:

bfi(A,B,C) = (A&B)|(~A&C)

За тези две операции в instruction set-а на AMD картите имаш готова инструкция, която го прави, при NVidia няма. Отделно, AMD GPU-тата, по принцип имат много повече ALU unit-а в сравнение с еквивалентната NVidia карта, които въпреки че трудно се утилизират на 100% заради VLIW архитектурата. Накратко, NVidia е доста загубена кауза за password recovery цели - обикновено се набутваш с по-скъп, по-бавен хардуер, харчещ повече ток. Единствените предимства на NVidia е че се пише код далеч по-лесно за тях, своеволията на девелопърите на SDK-то и драйверите (ако ползваш CUDA) са далеч по-малко, както и от това че ползва скаларна архитектура и че достъпите до паметта по принцип са по-бързи, в определени случаи (най-вече чупене на голям списък от не-salt-нати хешове), загубата на скорост не е толкова рязка с увеличаване на големината на списъка от хешове за чупене. Което не те грее особено, защото WPA ползва PBKDF2/HMAC-SHA1, а той по дефиниция е salt-нат.

[RealEnder]

Идеята е в wordlist-а да има само чисти думи, а след това с rule engin-а да се добавят цифри, знаци и т.н.
Ясно ми е, че видеокартата е боза за такива занимания, но ми трябваше просто желязо, на което да подкарам oclHashcat-plus, за да го добавя в help_crack-а. Почти съм го завършил, единствено някакви драми със subprocess.check_call и неговата интелигентност при парсването на параметрите остана да оправя. Накрая може и python-a да науча като хората

[gat3way]

Мммм опасявам се че това не е много добра идея, но това е само интуитивно, защото е много трудно да се докаже нещо подобно на базата на предположения за човешките модели за избор на парола. Но примерно ако хванеш rockyou речника (който е вероятно най-добрият wordlist за експерименти в момента), там имаш пароли където включват някаква историческа дата или пък има някакъв друг смисъл (като например нацистчетата, колко предвидимо ползват 88 и 18 в паролите си ) и контекстът където е ползван има значение.

От друга страна, добра идея за експерименти е примерно правило от сорта на leetify, което да ти заменя букви с хакерския им еквивалент. Или пък правила, които добавят числа от даден range в началото или след края на речниковата дума. Мммм ще излезе интересен експеримент. Апропо, изборът на WPA пароли се подчинява на някакви модели, както и навсякъде другаде, но моделите са малко по-различни от тези при уеб приложенията. Примерно стандартът те ограничава да не ползваш пароли под 8 символа и има много по-голяма вероятност в паролата да се срещат низове като "hotspot", "wifi", "hotel", "node" или нещо от сорта. Пазиш ли някъде кракнатите пароли, интересно ми е след време какви pattern-и може да се наблюдават.

[RealEnder]

Ще добавя още речници, но поне тези да извъртим - за момента не му се вижда края, дори с този set.
Определено ще поиграя и с rule engine-а, само да завърша интеграцията на oclHashcat, че там стана малко неудобно за масова употреба - първо трябва да се мине през компилираната от svn версия на aircrack-ng за конвертиране и после да се пусне кракера. Все неща, които обикновено не са на компютъра на помагача.

[RealEnder]

Новата версия публикувана с oclHashcat-plus поддръжка. Не съм я тествал усилено, но изглежда като истинска:)

[victim70]

Имам един въпрос?
Паролата: _Bahur4e!
Със речникова атака по този начин след колко време ще я строши?
Имам и други фаворити Drugel

[RealEnder]

Първо, за да е успешна атаката паролата трябва да я има в речниците или да е възпроизводима чрез правилата в rule engine-а (разбирай, базирана на речникова парола)
Сървиса работи като първо подава за търсене от по-малките речници към по-големите - погледни статистиките за речниците. Ако горните неща са налице, времето зависи от броя на хората, които пускат продължително help_crack.py и възможностите на хардуера им.

[victim70]

В такъв случай подобни правила на неправилно написани жаргони български, руски, японски, китайски, арабски ...... думи нямат разбиване с подобна политика на речниково търсене и на правила.
Ако не открие фразата с речника и шаблоните, това продължава ли с груба сила да се опитва да  я разбие и как пропуска вече пробваните варианти?

[RealEnder]

По принцип за чупене на WPA не се прилага директно комбиниране, тъй като ключовете са с дължина от 8 до 63 байта - при тази сложност е безмислен директен bruteforce. Например, на моя core i7 прави около 2000 опита в секунда, на правилна видеокарта/и (чети по-горе в треда) - по 40000-50000, според много зависи от картата. Затова и е необходим подобна система, за комбиниране на усилията на повече хора.
Речниковата атака е ОК, особено комбинирана с rule engine-а.

[gat3way]

Мощна двучипна AMD видеокарта като 6990 може да изклати 130-140 хиляди, ако си сглобиш някой дзвер с 4 такива карти (повече от това не можеш да сложиш поради ограничение в драйверите, но има и други кофти проблеми като например охлаждане и захранване - това ще ти яде към 1.7-1.8 киловата, няма захранване което да поема толкова, трябва да правиш магарии) - може и да докараш към половин милион/секунда. Обаче това е безумно малко, за да се пробваш да bruteforce-ваш пароли съставени дори от само малки букви.

Неправилно написаните думи на какъвто и да било език може да се хванат с подходящият rule и речник.

[victim70]

За жалост в примерите дето съм дал не виждам нито правила нито речник. Знам и паролите на още няколко харпуна които са по подобен манталитет написани, включително японска фраза която е побългарена.
Но по този начин 80% от паролите на потребителите ще подадат.
//офф
Това с GPU тата ме заинтересува. Имам специална такава карта за обработка на циклични изчисления в реално време с плуваща запетая (използва се за многозвенни FIR IIR ..... филтри и обработка на сигнали).
Не се бях досещал че видеото има възможност за такова нещо колкото и да е логично че е така. Има ли някъде пример да го разгледам на подобно ползване? 

[gat3way]

Побългарената японска фраза най-вероятно няма да падне. Keyspace-а и сложността на алгоритъма са прекалено големи, за да има смисъл да се пробваш да bruteforce-ваш, поради тази причина речниците и правилата са някакъв начин нещата да добият по-практичен вид в случая, следвайки някакви модели, които хората често обичат да повтарят. Но гаранция 100% нямаш, поне с днешния хардуер.

Иначе за подобни проекти - oclhashcat, pyrit, ighashgpu, EGB и т.н, можеш да ги google-неш да ги разгледаш, в общи линии идеята е сходна.

Що се отнася до криптографията върху видеокарти - това е доста пристрастяващо Програмирането на GPU-та не е особено сложно веднъж като схванеш идеята. Кривата е доста стръмна, основната идея е малко трудна за смилане в началото, но иначе е доста проста. Всички framework-ове за целта правят едни и същи неща, но OpenCL и CUDA са най-удобни и лесни за ползване, особено ако имаш опит с C. Осмислянето на крипто-алгоритмите е малко по-различна работа, но за сметка на това не чак толкова сложна. Като цяло, според мен над 50% от това няма нищо общо нито с програмиране, нито с познаване на хардуерните особености, а е по-скоро чиста математика, нагаждане на нещата така че да могат да сработят върху хардуера и колкото и да е странно - малко геометрично мислене (което предполагам за хора, занимавали се с FPGA неща е доста познато).

Иначе password cracking-а е силно пригоден за GPU хардуера, защото е embarassingly parallel и в общият случай ползва предимно 32-битова целочислена аритметика и побитови операции. Асиметричната криптография е друга бира, там портването върху GPU-та е почти безсмислено занимание.