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

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

В добър смисъл, 2fa трябва да бъде представен на обменници на криптовалути, банкови системи и абсолютно всички сайтове, чиито потребителски акаунти са с определена стойност, за да се затрудни хакването на акаунт за получаване на ползи/информация.

Системата за проверка на кода е доста разпространена, използва се навсякъде в различни сайтове и може да бъде свързана както за първично, така и за вторично влизане. Но случаят на използване не се ограничава до това — разработчиците добавят код за потвърждение към функционалността за възстановяване на парола, потвърждение на регистрация/абонамент, допълнително потвърждение на финансови транзакции, промяна на парола, промяна на лични данни. Също така, понякога 2FA може да се използва като стена след „времево“ излизане, а не парола или друг начин за потвърждение.

В тази статия съм събрал начини за тестване на 2FA за уязвимости, тяхното използване, както и възможни варианти за заобикаляне на съществуваща защита срещу определени видове атаки. Нека да разгледаме списъка с проверки за уязвимости, които се отнасят за 2FA:

1. Липса на ограничение на скоростта.
Алгоритъмът за ограничаване на скоростта се използва за тестване дали потребителска сесия (или IP адрес) може да бъде ограничена в опити или скорост и при какви обстоятелства се случва това. Ако потребителят е изпълнил твърде много заявки в рамките на определен период от време, уеб приложението може да отговори с код 429 (много заявки) или да приложи ограничение на скоростта, без да показва грешки. Липсата на ограничение на скоростта предполага, че по време на нормално изброяване няма ограничения за броя на опитите и/или скоростта — разрешено е да се повтарят кодове произволен брой пъти (с всякаква скорост) в рамките на периода на валидност на сесията/токена.

Доста често трябва да се справям с „безшумно“ ограничение на скоростта, — ако видите, че няма грешки и HTTP тялото/кодът не се променя в следващите заявки, рано е да се радвате и първо, трябва да проверете крайния резултат от атаката, като използвате валиден код.

2. Съществува ограничение на скоростта, но може да бъде заобиколено.
Случаи, които съм срещал преди:

1) Ограничаване на скоростта на потока с липса на блокиране след достигане на определена скорост на потока.
Често анализаторите по сигурността се опитват да уловят код, използвайки 2 или повече нишки за да направите атака по-бърза (в Burp Intruder броят на нишките по подразбиране е 2 без забавяне). Но понякога система за сигурност от груба сила или обикновен Load Balancer може да отговори само на този единствен фактор. Ако се опитвате да извършите груба сила с 2 нишки, струва си да намалите броя до 1 и след това до 1 със закъснение от една секунда. По-рано имах късмета да наблюдавам такова поведение и точно с помощта на такива манипулации се случи успешният избор на код, което доведе до Account Takeover. Ако 2FA кодът няма конкретна дата на изтичане, тогава имаме много време да сортираме. Но ако периодът на валидност е налице, тогава успехът на атаката е намален, но потенциалната опасност от уязвимост все още е налице, тъй като все още има шанс да влезете в правилния код.

2) Генерираният OTP код не се променя.
Това не се отнася за динамично променящи се кодове като в Google Authenticator, а само за статични, които идват от SMS, имейл или като съобщение в месинджъра.
Същността на този байпас е, че постоянно или за известно време, например 5 минути, се изпраща един и същ OTP код в SMS, който е валиден през цялото това време . Също така си струва да се гарантира, че няма да настъпи тихо ограничение на скоростта.
Пример за отчет: https://hackerone.com/reports/420163

Да предположим, че приложението генерира произволен код от 001 до 999 и го изпраща директно към съобщенията на телефона, в рамките на 10 минути, когато функцията „изпрати отново“ е активирана, получаваме същия код. Но ограничението на скоростта е обвързано със заявката, което ограничава броя на опитите за токен на заявка. Можем постоянно да изискваме нов код, да генерираме нов токен за заявка, да го прилагаме към следваща заявка (използвайки grep-match в Burp Suite или използвайки наш собствен скрипт) и да извършваме груба сила на диапазона от числа от 001 до 999. По този начин , постоянно използвайки нов токен за заявка, ние успешно ще вземем правилния код, тъй като той не се променя и е статичен за определен период от време. Ограниченията на тази атака са дълго число или смесване на букви с цифри като код за потвърждение.

Тази ситуация не трябва да се насърчава, трябва да се опитате да сортирате поне част от нашия списък и има възможност генерираният код да се появи в тази част от списъка, тъй като се генерира на случаен принцип. Когато опитвате, трябва да разчитате на случаен принцип, но все пак има шанс да попаднете в правилната комбинация, което доказва уязвимост, която определено трябва да бъде коригирана.

3) Нулиране на лимита на скоростта при актуализиране на кода.
 В заявката за проверка на кода лимитът на скоростта е налице, но след активиране на функционалността за повторно изпращане на кода , той се нулира и ви позволява да продължите грубата сила на кода.
Примери за доклади:
https://hackerone.com/reports/149598, — теория;
https ://hackerone.com/reports/205000, — практически експлойт въз основа на предишен доклад.

4) Заобикаляне на ограничението за скорост чрез промяна на IP адреса.
Много заключвания се основават на ограничението за приемане на заявки от IP, който е достигнал прага на определен брой опити при изпълнение на заявка. Ако IP адресът е променен, тогава има възможност за заобикаляне на ограничението. За да проверите този метод, просто променете вашия IP чрез прокси сървър/VPN и вижте дали блокирането зависи от IP.

Начини за промяна на IP:
— Проксита могат да се използват при атака с помощта на разширението IP Rotator за Burp Suite https://github.com/RhinoSecurityLabs/IPRotate_Burp_Extension. Според мен това е най-добрият избор, защото ни дава ~ неограничени опити за груба сила и IP адреси, които ви позволяват да извършите атака с груба сила без 42 пъти грешки и прекъсвания.

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

Тъй като инструментът за завъртане на IP изпраща заявки, използвайки IP адреси на AWS, всички заявки ще бъдат блокирани, ако уеб приложението е зад защитната стена на Cloudflare.

В този случай трябва допълнително да намерите IP адреса на оригиналния уеб сървър или да намерите метод, който не засяга IP адресите на AWS.

5) На сайта поддръжката за X-Forwarded-For е включена.
Вграденият хедър X-Forwarded-For може да се използва за промяна на IP . Ако приложението има вградена обработка за този хедър, просто изпратете X-Forwarded-For: desire_IP, за да замените IP, за да заобиколите ограничението без използването на допълнителни проксита. Всеки път, когато се изпрати заявка с помощта на X-Forwarded-For, уеб сървърът ще смята, че нашият IP адрес съответства на стойността, предадена чрез заглавката.
Свързани материали:
https://hackerone.com/ доклади/225897
https://medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf34157

3. 2FA заобикаляне чрез заместване на част от заявката от сесията на друг акаунт.
Ако параметър с конкретна стойност е изпратен за проверка на кода в заявката, опитайте да изпратите стойността от заявката на друг акаунт .
Например, когато изпращате OTP код, се проверява идентификаторът на формуляра/потребителският идентификатор или бисквитката, която е свързана с изпращането на кода. Ако приложим данните от параметрите на акаунта, на който искате да заобиколите проверката с код (Акаунт 1), към сесия на напълно различен акаунт (Акаунт 2), получим кода и го въведем във втория акаунт, тогава можем заобиколете защитата на първия акаунт. След презареждане на страницата 2FA трябва да изчезне.

4. Заобикаляне на 2FA с помощта на функцията „запаметяване“.
Много сайтове, които поддържат 2FA, имат функция „запомни ме“. Полезно е, когато потребителят не иска да въвежда 2FA код в следващите прозорци за влизане. И е важно да се идентифицира начинът, по който 2FA се „запомня“. Това може да бъде бисквитка, стойност в сесия/локално хранилище или просто прикачване на 2FA към IP адрес.

1) Ако 2FA е прикрепен с помощта на бисквитка, стойността на бисквитката трябва да не може да се отгатне.
Тоест, ако бисквитката се състои от набор от числа, които са увеличени за всеки акаунт, тогава е напълно възможно да се приложи груба атака към стойността на бисквитката и да се заобиколи 2FA. Разработчиците трябва да доставят бисквитката (заедно с ключовата бисквитка на сесията и CSRF токена) с атрибута HttpOnly, така че да не може да бъде открадната чрез XSS и използвана за заобикаляне на 2FA.

2) Ако 2FA е прикачен към IP адрес, можете да опитате да замените вашия IP адрес.
За да идентифицирате този метод, влезте в акаунта си с 2FA функция за „запаметяване“, след това превключете към друг браузър или инкогнито режим на текущия браузър и опитайте да влезете отново. Ако 2FA изобщо не е заявен, тогава 2FA е прикачен към IP адреса.
За да замените IP адреса, можете да използвате заглавката X-Forwarded-For на етапа на въвеждане на потребителско име и парола, ако уеб приложението го поддържа.
Използвайки тази заглавка, можете също да заобиколите функцията „IP адрес бял списък“, ако има такава в настройките на акаунта. Може да се използва заедно с 2FA като допълнителна защита на акаунта или може дори да не изисква 2FA, ако IP адресът съвпада с белия списък (със съгласието на потребителя). По този начин, дори и без прикачването на 2FA към IP адреса чрез функцията за „запаметяване“, в някои случаи 2FA може да бъде заобиколено с помощта на заобикаляне на съпътстващите методи за защита.
Като цяло прикачването на 2FA към IP адрес не е напълно безопасен начин за защита, тъй като ако присъствате в същата мрежа или сте свързани към същия доставчик на VPN/интернет услуги със статичен IP адрес, 2FA може да бъде заобиколен.

5. Грешка при неправилен контрол на достъпа на диалоговата страница на 2FA.
Понякога диалогова страница за въвеждане на 2FA се представя като URL адрес с параметри. Достъпът до такава страница с параметри в URL адреса с бисквитки, които не съвпадат с тези, използвани за генериране на страницата или изобщо без бисквитки, не е безопасен. Но ако разработчиците са решили да приемат рисковете, тогава трябва да преминете през няколко важни точки:
1) Изтича ли връзката за диалоговата страница на 2FA;
2) Дали връзката е индексирана в търсачките .
Ако връзката има дълъг период на съществуване и/или търсачките съдържат работещи връзки за 2FA въвеждане/линковете могат да бъдат индексирани (няма правила в robots.txt / мета тагове), тогава има възможност за използване на механизъм за заобикаляне на 2FA на страницата за въвеждане на 2FA, в която можете напълно да заобиколите въвеждането на потребителско име и парола и да получите достъп до акаунта на някой друг.

6. недостатъчна цензура на личните данни на страницата 2FA.
Когато изпращате код на страница, цензурата се използва за защита на лични данни като имейл, телефонен номер, псевдоним и др. Но тези данни могат да бъдат напълно разкрити в крайните точки на API и други заявки, за които имаме достатъчно права на етап 2FA. Ако първоначално тези данни не са били известни, например сме въвели само данни за вход, без да знаем телефонния номер, тогава това се счита за уязвимост „Разкриване на информация“. Познаването на телефонния номер/имейла може да се използва за последващи фишинг/атаки с груба сила.

Пример за използване на уязвимост чрез пълнеж на идентификационни данни. Да приемем, че има публично достъпна база данни с данни за влизане и пароли за сайт A. Нападателите могат да използват данните от тази база данни на сайт B:
— Първо проверяват дали потребителят съществува в базата данни на сайт B, като използват „Акаунти“ Изброяване” грешка във функцията за регистрация/възстановяване на парола. Обикновено много сайтове не отчитат тази уязвимост и поемат рискове. „Уязвимостта“ се състои в наличието на грешка, която разкрива факта на регистрация на потребител в сайта. В идеалния случай защитено съобщение на страницата за възстановяване на парола е както следва:

- След като получат базата данни на съществуващите потребители, нападателите прилагат пароли към тези акаунти.
— Ако срещнат 2FA, те са в задънена улица. Но в случай на недостатъчна цензура на потребителските данни, те могат да допълнят своята база данни с потребителски данни, ако не са били в оригиналната база данни и идентификационните данни за оригиналния уебсайт не работят.

7. Пренебрегване на 2FA при определени обстоятелства.
Когато извършвате някои действия, които водят до автоматично влизане във вашия акаунт, 2FA може да не бъде поискано.

1) Игнориране на 2FA при възстановяване на парола.
Много услуги извършват автоматично влизане във вашия акаунт след завършване на процедурата за възстановяване на парола. Тъй като достъпът до вашия акаунт се предоставя незабавно, когато влезете в акаунта си, 2FA може да бъде пропуснат и напълно игнориран.

Въздействие на подобен доклад върху HackerOne, който изпратих наскоро:

Ако нападател получи достъп до имейла на жертвата (той може да хакне акаунта чрез фишинг, атаки с груба сила, пълнене на идентификационни данни и т.н.), той може да заобиколи 2FA, въпреки че в този случай 2FA трябва да защити акаунта. В момента за 2FA има проверка на кода на Google Authenticator или резервния код, но не и кода от имейла, така че този Bypass има смисъл.

2) Пренебрегване на 2FA при влизане през социална мрежа.
 Можете да прикачите социална мрежа към акаунта си, за да влизате бързо в бъдеще и същевременно време настрои 2FA. Когато влезете в акаунта си чрез социални мрежи, 2FA може да бъде игнориран. Ако имейлът на жертвата е хакнат, е възможно да възстановите паролата за акаунта в социалната мрежа, ако ви позволява да направите това и да влезете в желаното приложение, без да въвеждате 2FA.

Въздействие на един от докладите:

1) Куп с други уязвимости, като например изпратената преди това неправилна конфигурация на OAuth #577468, за завършване на поглъщането на акаунта, преодоляване на 2FA.
2) Ако нападател хакне имейла на потребителя, той може да се опита да получи достъп до акаунт в социалната мрежа и влезте в акаунта без допълнителна проверка.
3) Ако нападател веднъж е хакнал акаунта на жертва, той може да свърже социалната мрежа с акаунта и да влезе в акаунта в бъдеще, като напълно игнорира 2FA и въвеждане на потребителско име/парола.

3) Пренебрегване на 2FA в по-стара версия на приложението.
Разработчиците често добавят етапни версии на уеб приложение към домейни/поддомейни, за да тестват определени функции. Интересното е, че ако влезете с вашето потребителско име и парола, 2FA може да не бъде поискано. Може би разработчиците използват по-стара версия на приложението, в която няма защита за 2FA, самата 2FA е деактивирана или умишлено е деактивирана за тестване.

Можете също така да проверите други уязвимости едновременно, — регистрирането на нов потребител на етапен сървър, чийто имейл съществува в базата данни на производствената версия, може да ви даде лични данни на потребителя от производството; липсата на ограничение на скоростта във важна функционалност, например възстановяване на парола. Пример за такава уязвимост е бъг във Facebook на стойност $15 000, който позволява хакване на акаунт чрез грубия код за възстановяване на парола на beta.facebook.com https://www.freecodecamp.org/news/responsible-disclosure-how -i-could-have- hacked-all-facebook-accounts-f47c0252ae4d/.

4) Пренебрегване на 2FA в случай на крос-платформиране.
 Реализациите на 2FA в мобилна или десктоп версия може да се различават от уеб версията на приложението. 2FA може да е по-слаб, отколкото в уеб версията или напълно да липсва.

7. При деактивиране на 2FA не се изисква текущият код или парола.
Ако при деактивиране на 2FA не се изисква допълнително потвърждение, като например текущия код от приложението за удостоверяване на Google, кодът от имейл/телефон, тогава това поведение крие определени рискове. При чиста заявка има шанс за CSRF атака. Ако бъде намерен байпасен вектор на CSRF защита (ако има такъв), тогава 2FA може да бъде деактивиран. Можете също така да използвате уязвимостта на clickjacking - след няколко кликвания от нищо неподозиращ потребител, 2FA ще бъде деактивиран. Валидирането на предишния код ще добави допълнителна 2FA защита, като се вземат предвид потенциални CSRF / XSS / Clickjacking атаки, както и неправилни конфигурации на CORS.

Ще ви дам пример за уебсайта hackerone.com, — когато изключите 2FA във формуляра, трябва да въведете две стойности едновременно, — текущия код от приложението google authenticator и парола. Това е най-добрата и препоръчителна защита.

8. Създадените по-рано сесии остават валидни след активиране на 2FA.
 Когато 2FA е активиран, желателно е паралелните сесии на един и същи акаунт да приключат и да се изисква появяването на 2FA диалогов прозорец, същото при промяна на паролата. Ако акаунтът е бил компрометиран и първата реакция на жертвата ще бъде включването на 2fa, тогава сесията на нападателя ще бъде деактивирана и следващото влизане и парола ще изискват 2FA. Като цяло това е най-добрата практика, която трябва да се следва. Често забелязвам как борсите за криптовалута добавят такава защита. Пример за доклад на HackerOne, — https://hackerone.com/reports/534450.

9. Липса на Rate-limit в акаунта на потребителя.
 2FA може да се добави към различни функции на личния акаунт на потребителя, за да се повиши сигурността. Това може да бъде промяна на имейл адрес, парола, потвърждение за промяна на код за финансови транзакции и т.н. Наличието на rate-limit във вашия акаунт може да се различава от наличието на rate-limit-a в прозореца 2FA при влизане в акаунта ви . Често съм срещал подобни случаи, когато е възможно свободно да се използва груба сила 2FA код в моя акаунт, докато на входа е конфигуриран лимит на скоростта „Strict“.

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

10. Манипулиране на версиите на API.
 Ако видите нещо като /v*/ в заявката на приложението, където * е число, тогава е вероятно да превключите към по-стара версия на API. В старата версия на API може да има слаба защита или изобщо да не е представена. Това е доста рядко явление и се случва в случай, че разработчиците са забравили да премахнат старата версия на API в производствената/поставящата среда.

Например /endpoint/api/v4/ login изпълнява заявка за влизане, като проверява потребителското име и паролата. Ако 2FA е свързано с акаунта, тази заявка трябва да бъде последвана от /endpoint/api/v4/2fa_check, без други опции. Ако заменим версията на API преди 2FA, тогава в някои случаи можем да я избегнем. /endpoint/api/v3/login може да доведе до /endpoint/api/v3/login_successful?code=RANDOM, игнорирайки 2fa_check, защото в тази версия на API, защото 2FA просто не е внедрен.
Друг пример, — в заявката /endpoint/api/v4/2fa_check има ограничение на скоростта, докато /endpoint/api/v3/2fa_check ви позволява да грубо форсирате кодовете без никакви ограничения.

11. Неправилен контрол на достъпа в заявката за резервни кодове.
Резервните кодове се генерират веднага след активирането на 2FA и са достъпни при една заявка. След всяко следващо извикване на заявката, кодовете могат да бъдат генерирани отново или да останат непроменени (статични кодове).
Ако има неправилни конфигурации на CORS/XSS уязвимости и други грешки, които ви позволяват да „изтеглите“ резервни кодове от заявката за отговор на крайната точка на резервния код, тогава атакуващият може да открадне кодовете и да заобиколи 2FA, ако потребителското име и паролата са известни.

Като цяло и като цяло, 2fa е един от най-надеждните начини за защита на вашия акаунт, освен ако, разбира се, разработчиците не съхраняват текущите 2FA кодове на всички потребители на уеб приложението в админ панела, — и това се е случвало в моята практика. Бих искал също да отбележа, че разработчиците на някои компании създават приложения за генериране на свои собствени 2FA кодове (примери са Salesforce, Valve) и поради липсата на сигурност, този акцент върху независимостта от използването на други приложения за удостоверяване дава на нападателите допълнителна входна точка за 2FA заобикаляне. Обхватът на приложение на тази защита е доста голям и дава на тези, които желаят да заобиколят 2FA защитата, повече възможности, пространство за творчество и увеличава броя на вариантите на 2FA байпаси.

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