Linux за българи: Форуми

Още преди време, когато започнах да чопкам InfoSec, все съм си мислил, че инструментът sslstrip на Moxie Marlinspike разчита на осъществена man-in-the-middle атака, и просто маха s-то от https://-а на всеки един URL, който жертвата request-ва, и това си работи на сайтове, където HSTS не е имплементиран.

Днес обаче, докато си гледах един епизод на Hak5, съвсем случайно осъзнах, че съм живял в заблуда.

Изглежда действието на sslstrip зад завесата е доста по-сложно... явява се прокси лейър, който фалшифицира сертификати, но общо взето от наличното в мрежата въобще не можах да асимилирам как се осъществява процесът в детайли.

Може ли някой да обясни простичко как работи sslstrip?

Никакви сертификати не фалшифицира, но наистина проксира съдържание. от sslstrip до сървъра комуникацията е https, оттам към жертвата е http, като всякакви линкове към https върнати от сървъра динамично се променят на http.

Някои кхм компании обаче и да "фалшифицират" сертификати се пробваха, благодарение на идиоти като Trustwave. В общи линии това е далеч по-ефективно, макар че и браузърите се научиха да pin-ват сертификати и да реват като не съответстват. Chrome-а например го прави по дефолт без никакви разширения за https сървърите на google, там дори тоя номер няма да мине...ако искаш да слухтиш https трафика за към google де.

Тоест имаме схема от рода на:

Жертва < -- > HTTP < -- > sslstrip < -- > HTTPS < -- > Сървър ?

И, доколкото разбирам, нещата протичат така:

1. sslstrip слухти за минаващ HTTPS трафик.
2. Засича такъв, взима съответното съдържание през HTTPS от сървъра, и го кешира локално.
3. Обработва кешираните данни, променя всички https href-и на http, и го връща на жертвата over plain HTTP.
4. Примерно е логин страница, и жертвата си въвежда логин данните, което при изпращането на формата отива до sslstrip, и ни се output-ва.
5. За да имаме двустранна комуникация, sslstrip препраща данните през HTTPS до сървъра, и се осъществява логин.

Тук изниква следният въпрос: Ако спрем sslstrip, какво се случва с отворената SSL/TLS връзка, тъй като жертвата няма нужният public key на сървъра (нито пък е генерирала свой), и въобще не знае, че в бекграунд комуникацията и със сървъра минава през https, като затворената програма sslstrip се е грижила за това?
Терминира ли се?

Схемата е такава, да.

Обаче sslstrip не слухти за минаващ HTTPS трафик, защото няма как да знае какво става там. TLS сесията се  установява преди да мине HTTP заявката и sslstrip на практика няма как да знае какво точно заявяваш. Сега теоретично може да може да гадае и да ти сервира нещо използвайки самоподписан сертификат, създаден динамично за целта но не мисля че е добра идея и определено доста ще бие на очи.

С други думи ако първата заявка която правиш към някой сайт е https и HTML документа който се зарежда няма никакви препратки към http ресурси, sslstrip няма как да сработи.

P.S под "първа заявка" разбирай да го нашиеш в URL bar-а на браузъра и да го отвориш, не да следваш линкове към него, линковете може вече да са "пренаписани".

Ахаааа, ето каква била работата. Ясно.
Благодаря ти за обяснението.  :)

А за това да се форсира потребителският браузър да отваря даден ресурс през https още с първата заявка HSTS (чрез изпращане на даденият хедър и справка в листите със сайтове за които е сигурно, че поддържат SSL, hardcode-нати браузърите) ли се грижи?

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

HSTS не е перфектното решение де, защото ако си нацелил да направиш първата заявка точно докато някой те mitm-ва, той спокойно може да не ти връща никакъв хедър. Та вероятно да, поради тази причина може в браузърите да има и хардкоднати списъци. За хрома и гугълските услуги примерно въобще не бих се учудил.

Явно и Mozilla го правят - https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

Our “preload list” has been seeded with entries from Chrome’s list of a similar function.

 :D

И това ако не е доказателство, че Google контролира много неща при разработката на Firefox... например охромяването на интерфейса в новите версии, със закръглените табове, ма тва е извън темата.