татко Крокодил

Какво (още) гледах от 28c3:
(mirror-нал съм всичките английски записи на 28c3.ludost.net)

Keynote беше донякъде интересен, но имаше доста дупки в живото предаване. Ставаше въпрос за SpyFiles на wikileaks и изобщо индустрията, която се занимава с подслушване, мисля, че нямаше нещо много ново там.

От лекцията за Atari 2600 не можах да гледам много, но ме зарадва с това, че вече не ни се налага да работим с толкова ограничен и ужасяващ хардуер (частта за това как се избира банка от паметта с четене на определен байт и как писането се прави с четене бяха направо плашещи).

SCADA and PLC Vulnerabilities in Correctional Facilities беше интересно, въпреки че в основата си е просто хакване на хардуер, който никога не е мислен да е сигурен (и който за съжаление се използва твърде много). В общи линии полезна лекция за всеки, който реши да бяга от затвора.

Лекцията за еволюиране на алгоритми беше забавна, почти “как с random и малко техники да си създадем алгоритъм за каквото си искаме”. В тази лекция обясниха основните неща и показаха как са правили алгоритъм за един филтър за картинки, в другата показаха как са еволюирали протокол за комуникация (което беше наистина адски интересно и поне в началото трудно за вярване).

802.11 packets-in-packets беше една от най-забавните лекции на конгреса и като цяло интересна атака – да се вкара пакет на layer1 от layer7 (т.е. накратко можете да бълвате специфични пакети през tcp, udp или каквото ви падне, да ги предаде някое AP и клиентите да го прочетат по различен начин). Определено си струва гледането.

Не можах да гледам The coming war on general computation на Cory Doctorow, но някакви добри хора са написали transcript, мисля, че е важно да се прочете/гледа.

Kartsten Nohl и Luca Melette говориха за как да си предпазим мобилния телефон, последните им разработки по темата за GSM и компания. Например са направили firmware за телефон, който report-ва т.нар. “flash sms” и може да усеща дали някой прави man-in-the-middle атака.

Black OPs of 2011 на Дан Камински беше същата лекция като от CCC Camp-а, т.е. нищо ново.

Вторият ден започна с Food hacking лекция, която мога да използвам да плаша всичките “еколози” и противници на ГМО. Имаше всякакви забавни неща, от грейпфрути, отглеждани чрез облъчване с радиация до суши от светещи риби. Във въпросите след лекцията една девойка пита как точно да готви скакалци…

Data mining the Israeli census беше приятна лекция, но нищо особено – какви анализи са правили на изтеклата (5 пъти за 10 години) база данни с населението на Израел.

За лекцията за DoS-ването на web неща вече писах подробно.

The science of insecurity според мен беше най-важната лекция на конгреса. Meredith Patterson обясни много добре как сами си копаем гроба, като правим протоколи, за които няма дори теоритичен начин да проверим дали някакви данни са валиден вход, понеже представляват Turing-complete езици, а там проблемът с валидацията се свежда в общи линии до halting проблема. Аз не знаех, че някой вече е доказал, че HTML5 и CSS3 (без javascript) са turing-complete комбинация (и се зачудих колко е вероятно от web-а да се роди skynet).
Друг интересен момент беше колко по-сложно е да се напише прост parser за контекстно-зависими граматики (например, всичките протоколи, които имат length поле), и как би трябвало да се стремим към прости неща, които един елементарен краен автомат може да parse-не (т.е. които могат да се parse-нат еднозначно с регулярни изрази, например). Като пример за проблеми с length полето беше дадена атаката за 802.11 packet-in-packet.
И една от важните идеи, които със сигурност ще приложа (преди нямах толкова добро оправдание) ще е всичките parser-и и подобни неща да се генерират автоматично от ясна формална граматика, така че винаги да се работи с ясни данни и ясна валидност. Това така и така щеше да ми трябва, понеже ще гоним междуплатформеност…
(на който не му е ясно какво говоря, да почете малко за йерархия на граматиките на Чомски, машина на Тюринг и какво значи Turing-complete).

От третия ден трябва да спомена лекцията на Пейо за електронните пари (както и да му кажа, че той вече е celebrity :) ), която беше малко по-съкратен и подреден вариант на тази от Openfest. Иска ми се това да го направи на хартия и да му даде цялото нужно място (т.е. около 2-3 часа говорене), ама да видим кога ще успея да го изнудя.

Лекцията за атаките в/у принтери също беше от много веселите, а проблемите в сигурността, които се оказа, че има там бяха пак от смешния тип (например възможност да смениш firmware на устройството с печатане на файл). Ако имате HP принтер, вижте лекцията и дали трябва да се update-нете.

От четвъртия ден май си струва да спомена само лекцията на NOC-а за мрежите на CCC Camp-а и на текущия конгрес. Особено забавна беше реализацията на “таван/чадър” за wifi AP-тата от кофи и тръби.

Имаше и няколко доста неприятни лекции, или много объркващи (например една за квантовата криптография), или тотално неразбираеми (имаше един французин, който говореше за криптография и на 20тото казване на “Titanic” (с ударение на последната сричка) се отказахме да го траем), или bullshit (един, който говореше за влиянието на leak-овете в/у конспирации в контекста на целта на wikileaks и който накрая го питах не смята ли, че математическия модел, който ползва е почти толкова смислен, колкото сферичен кон във вакуум).

Има още няколко неща, които искам да гледам и едно, за което искам да напиша отделен post – depression panel-а, който се е случил почти против желанието на организаторите, понеже са счели темата за неподходяща. Надявам се да намеря време в следващите дни:)

Малко за гледаните лекции от 28c3 – ще бъдат в няколко post-а по ред причини.

Ще започна с една лекция, която описа в общи линии нов проблем в повечето web-facing езици/framework-ове в хеш реализациите, за който даже написах малко код.

Къде е проблемът – повечето такива езици (в случая – perl, php, python, java, ruby, asp.net) използват hash-ове (познати още като асоциативни масиви), за да подадат към програмиста параметрите, които са дошли от HTTP request-а (най-вече от POST-а). Почти всички го реализират, използвайки стандартни hash таблици с 32 или 64битов hash (не-криптографски, т.е. даже и CRC32 би свършил работа, повечето ползват нещо, писано от DJB, например DJBX33A).
По принцип insert-а на нов елемент в такава таблица е с ниска/константна сложност, но ако вмъкваме само елементи, които дават същия hash, сложността става максималната възможна, т.е. O(n) и съответно вмъкването на n елемента ще е от порядъка на O(n^2).
Накратко, ако подадем (например) през POST параметри, които се хешират към същата стойност, времето, което ще отнеме на езика/framwork-а да обработи заявката (преди да стигне до вашето приложение) ще е бая, като тестовете при мен показаха нещо от порядъка на 1 минута за заявка с 62000 параметъра и голяма около 400kb. В лекцията (има и запис, mirror-нат при мен) има повече подробности и тестове.

Реших да видя доколко мен ме лови тоя проблем. Като за начало трябваше да си напиша генератор на тия стрингове (ВНИМАНИЕ: грозен гаден код на C), което се оказа сравнително лесно – измъкнах от source на php от Zend/zend_hash.h тяхната функция, поразгледах кода и се оказа, че от hash функцията се взимат първите X бита, като X е в общи линии log2(N) (където N е броя елементи в стуктурата). Съответно ако ми трябват по-малко от 65536 collide-ващи стринга ми е достатъчно да търся колизии само в първите 16 бита. Моята некадърна програмка на машина със 192GB памет (трябваха и около 120GB) се справи за около 5 минути.
(пускам кода като пример, който може да го разбере би могъл да си го напише и сам сравнително лесно).

Имам да се поровя още малко, но в някои случаи debian-ската default-на конфигурация реже тия атаки (понеже не позволява повече от 1000 променливи в какъвто и да е request, което па от своя страна чупи малко (малоумен) софтуер), в някои не и повечето php-та, които човек може да намери по net-а ги лови тоя проблем. Реализирането на DoS-а за да направи реален проблем изисква прилично количество паралелни връзки и определено не е толкова опасно, колкото беше проблемът с Range request-ите от август, но пак не е приятно. Също така може да се атакува и през други места, например ако трябва да се сглоби json request или какъвто и да е hash, чиито ключове зависят от данни, подадени от потребителя.

Решението е да се random-изира hash-а на всяка заявка, за което си написах една тестова програмка, която да пробва в/у такива подбрани string-ове hash, който освен всичко XOR-ва всеки 8-байтов блок от входа с един random seed. Мисля ако скоро не изкарат някакво хубаво решение да си patch-на директно php-то, но още не съм имал време да намеря подходящия entry point, в който да вкарам инициализацията на seed-а, така че хем да е различен за всеки request, хем да не счупи нещо по много лош начин (ако някой е бърникал по кода на php и знае къде, много моля да пише).

Та, добри хора, прочетете оригиналното advisory и се patch-вайте, ако правите нещо свързано с web най-вероятно проблемът ви засяга.

Организираме прожектиране на лекциите от 28c3 в initLab, от 27ми до 30ти декември. Имаме предварителен списък какво мислим да гледаме и поне две стаи, в които да прожектираме (може да ползваме и третата).

(почти са ни одобрили регистрацията за гарантиран bandwidth, така че не трябва да има проблеми)