Премини към съдържанието

programings

Потребител
  • Публикации

    1062
  • Регистрация

  • Последно онлайн

Харесвания

1003 Жестока репутация

Всичко за programings

  • Титла
    Nihilist

Информация

  • Пол
    Неопределен
  • Интереси
    InfoSec, Cryptography, Networking, Linux, Tor, Philosophy

Последни посетители

16058 прегледа на профила
  1. Търся филм, в който семейството на главната героиня (май беше жена на средна възраст) се опитва всячески да прикрие от нея, че събитията около прехода и падането на Берлинската стена са настъпили. Тя беше болна от нещо, прекарваше по-голямата част от времето си на легло. Пускаха и стари новини на запис с едно видео от съседната стая. Спомням си ясно една от сцените - на съседната сграда слагаха рекламен трансперант на Coca-Cola, докато тя гледаше през прозореца, и синовете и (или каквито там и бяха) побързаха да я махнат оттам. Трябва да е бил драматично-комедиен. Въртяха го продължително време по кабелната (каналите "Диема") преди 7-8 години. П.С. Намерих го - Good Bye, Lenin! (2003) .
  2. By the way, с извинение, че пиша в темата, ще си позволя да пусна линк към едно забавно четиво в което главен герой е небезизвестният в InfoSec средите security researcher Dragos Ruiu, който заради параноята си покрай BadBIOS отнесе сума ти и подигравки в Twitter: http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/ Иначе да, остава си само концепция за сега, като разбира се изключим неща от миналото като CIH (Чернобилският вирус), експлоатиращи познати уязвимости в някои BIOS-и, но техният принцип на работа е мъничко по-различен.
  3. Щом системата стартира нормално и работи (липсват най-честите симптоми в такива случаи - спонтанни замръзвания и BSOD-и заради свръх/ниско напрежение), значи ремонта е дал ползотворен резултат. Изтичането на някакво количество електролит не винаги прави даден кондензатор напълно неработоспособен, и при ниски натоварвания на блока може да не си видял разлика, но определено го превръща в дефектен, и смяната е задължителна за да се избегне неочакван failure по време на работа.
  4. https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf Изключително проста и интересна атака върху HSTS протокола, гарантиращ сигурната over-SSL/TLS комуникация чрез хедър, който се връща от сървъра към клиента при положение, че последният поддържа HTTPS, и държи да информира клиента, че от този момент нататък, всички заявки към него трябва да стават само и единствено през HTTPS. При пристигане на отговора към клиента, браузърът вижда този хедър, и записва entry в една таблица, че за този хост, за времето, което е зададено с max-age параметър на HSTS хедъра, комуникацията трябва да става само през HTTPS, а не през plain HTTP. Тоест, дори и клиента да напише http://site, оттук нататък, браузърът ще прави заявки до site само с HTTPS. Атаката по-горе използва Network Time Protocol, и чрез спууфнати отговори се разчита компютъра на жертвата да бъде пратен в бъдещето, като съответно стойността в max-age параметъра отдавна е изтекла. Това ще накара жертвата евентуално отново да направи заявка през HTTP, като вече в този момент тази заявка е в plain вид, и не е енкапсулирана в TLS/SSL сесия, което позволява на атакуващият, ако е man-in-the-middle например, при връщане на отговор от сървъра да strip-не HSTS хедъра, и жертвата никога да не разбере, че трябва да комуникира с даденият сайт само през HTTPS. При това положение, защо атакуващият не strip-не HSTS хедъра още в началото, при първата заявка през HTTP на жертвата? Ами защото в този момент може да не е бил MiTM, и трафикът на жертвата да не е минавал през него. Може да е станал MiTM в по-късен етап, когато вече браузърът е получил HSTS хедъра, и праща данните само криптирано, в TLS/SSL лейър, съответно няма абсолютно никакъв начин атакуващият да види с неща като SSLStrip какво има вътре в тази сесия. Когато се използва по-горната атака, просто се форсира стойността на max-age-а да изтече, и евентуално вече mitm-ващият атакуващ да хване HTTP заявката на жертвата. Защо въобще е нужна тази атака, не може ли да изчакаме да изтече ей така? Не. Сървъра периодично праща нов HSTS хедър с нарастващ max-age, който презаписва старият, вси още неизтекъл. Много ли е опасно? Браузърите отдавна имат hardcode-нати едни списъци наречени HSTS Preloaded lists - листи със статично зададени сайтове (популярни, като Фейсбоклук и Гугъл) за които е сигурно, че поддържат HTTPS, и още на клиентско ниво, ако потребителят не напише име на протокол пред сайта или напише http://, браузърът си знае, че ще прави заявката само през https://. Ей ги в кода на Chrome (лисицата, както се очаква, откакто си продадоха задкулисно г*за на Google, ползват същите листи): http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json Лошото е, че с тези листи се имитира поведението на получен хедър, но всички entry-та се задават още при стартирането на браузъра в дадената таблица, съответно пак си имат max-age, и се разчита, че като браузъра почне да комуникира със сайта, той ще си го подновява този max-age. По този причина - да, опасно е. Дискусията по темата в oss-security мейл листата: http://www.openwall.com/lists/oss-security/2014/10/16/6
  5. Класически пример за територията на България (и други страни от третия свят): отиваш в кварталната "книжарница" (където книги отдавна няма, но може да си купиш анцунг и CD на Азис) / копирен център, и си носиш на флашка това, което желаеш да ти разпечатат... ама флашката не е обикновена, а машината е античен калкулатор с XP, дори без активен антивирусен щит заради ограничената RAM, какво остава за HIPS... Pwned.
  6. Разбира се, че се използва драйвер, но хакера ще си я направи цялата процедура по подготовка на флашката на своя машина без HIPS-ове и какъвто и да е било антивирусен софтуер, и след това действа. Вече ако на машината-жертва има up-to-date свестен HIPS... трябва да тествам, не мога да говоря така.
  7. Зависи от HIPS-а. Когато фърмуера е модифициран и със сменен дескриптор, за компютъра ти не включваш флашка, а клавиатура, която изпраща някаква поредица от клавиши. Ако HIPS-а е програмиран да "познава" поведението на BadUSB, като например да съобрази скоростта с която се изпращат клавишите, чак тогава може да вдигне тревога. Иначе поведението изглежда напълно легитимно - все едно да се задейства, докато си писал по-горното. Не е нужно този, създал флашката да е зад машината. Защо да е нужно? Нали се досещаш, че флашката може да стартира и експлойт (експлоатирайки примерно EoP уязвимост, с цел да се добере до kernel land-а) който да работи на по-долно ниво от HIPS, и тогава въпросният е безсилен. http://en.wikipedia.org/wiki/Protection_ring Goal-а тук е не дали стартираното ще навреди (защото ако можем да си стартираме случайни неща, рано или късно ще счупим каквото и да е било security), а че въобще по заобиколен, бекграунд начин, можем да стартираме нещо.
  8. HIPS-а би засякъл само евентуалния резултат при изпълнението на malicious фърмуера върху флашката (основно симулиране на натискане на клавиши, което е метода, използван при концепцията зад BadUSB за придобиване на контрол над машината и изпълняване на arbitrary commands, тъй като с descriptor флашката се представя като USB клавиатура), но в никакъв случай не би бил способен да разбере, че дадената plug-ната флашка е с различен от фабричният, зловреден фърмуеър на такова изолирано ниво. Просто последният работи върху флашката като отделен unit, и не се интересува от комуникация с kernel драйвери на OS и прочие. USB контролерът на host машината се грижи за това, не е работа на флашката. Нейната работа се изчерпва до това да подава организирано данни по USB шината (и да си изпрати там в началото descriptor-а, за да заяви на OS какви функционалности съчетава в себе си, за да знае как да я третира - примерно една уебкамера ще каже, че има Video и Audio входни данни, и OS ще я третира като мултимедийно USB устройство, осигуряващо някакъв input), за което разбира се е нужен някакъв софтуер (фърмуера и) и елементарен процесор с подбран за елементарните нужди минимален set от поддържани инструкции (в повечето флашки, печалният вече Intel 8051). Аз си поиграх малко с кода на Adam Caudill, и успях безпроблемно да препрограмирам няколко евтини флашки (random контролери) за които намерих burner image из мрежата с dump на оригиналния фърмуеър + ембеднат зловреден код от примерните в Git repo-то, и работи точно по начина по който се очаква. Крайно плашещо. Иначе с release-натия от Adam и там другия рисърчър софтуер (който е за Window$ дори), нещата вече са далеч от машинен код, и може да си направиш BadUSB флашка с copy-paste на команди в cmd...
  9. Каква е тая Blackhat Bulgaria конференция с участието на Калин за която ми беше оспамен брутално мейла (което след преглед на сайта ми стана ясно защо е така - един от партньорите е именно компания, занимаваща се със спам) ? Цените са "много приятни" - от 80 до 120 кинта за конференция, която изглежда повече маркетинг, отколкото ИТ и InfoSec ориентирана? Та тия още малко и BlackhatConf и DEFCON ще започнат да конкурират...
  10. programings

    Linux - обща дискусия 3

    Препоръчайте някой шрифт, който да изглежда добре като се рендва от Xfce, и да съчетава стандартният стил (като M$) на символите на английски и на кирилица (не като дифаултският Sans на Xfce, който с английските букви няма проблем и въобще горе-долу другото си му е наред, но кирилското "б" го изкарва почти като "6"). Пробвах и proprietary шрифтовете на M$ и разните им свободни форкове - тц, пак е грозно. То е ясно, че и средата има грозен рендъринг, ама какво да се прави, поне да го облекча максимално. Иначе anti-aliasing-а е включен, и Hinting-а е на Medium, ако има значение.
  11. Това е момичето от Intel, което преди година беше казало на Торвалдс да се държи професионално, и да не псува в мейл листите. :D
  12. programings

    Конзолни решения

    Хм, при мен това връща бинарни данни?
  13. programings

    Конзолни решения

    Генериране на 10 MB-ови файлове с ASCII числа от /dev/urandom. Единици и нули: < /dev/urandom tr -dc 01 | head -c 10000000 > 10mb.txtОт 0 до 9: < /dev/urandom tr -dc '[:digit:]' | head -c 10000000 > 10mb.txtВ моя случай ми трябваше за да си правя random bitmap-и за визуализация на бял шум със spectra, та тъй като сорса на въпросният туул е буквално един C файл, който използва GD библиотеката за да чертае изображения, и автора го е домързяло да добави някой и друг ред код, че да може да чете директно бинарни данни, а не да умира, ако input-а не е ASCII число. Държа да отбележа, че по този начин реално от /dev/urandom ще се прочете доста по-голямо количество данни от 10 MB (някъде около 1 GB, и отнема време), тъй като с tr просто филтрираме това, което ни трябва от останалото, а random flow-а на /dev/urandom далеч не е само 1 и 0 или числа от 0 до 9...
  • Разглеждащи това в момента   0 потребители

    Няма регистрирани потребители разглеждащи тази страница.

×
×
  • Добави ново...