Да се доверим ли на двуфакторната автентикация?

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

В последно време методите за автентикация започват да търпят промени. Microsoft обявиха комбинацията от потребителско име и парола за ненадеждна, а двуфакторната автентикация започва да става стандарт за базово ниво на превенция на неоторизиран достъп. За съжаление, не само тези методи се променят, но и инструментите за атаки, с цел осигуряване на достъп до ресурси. За да се опитам да отговоря на въпроса от заглавието на публикацията ще се позова на възможностите на популярния и изключително мощен Evilginx2. И тук едно важно уточнение - не използвайте тази програма за злонамерени цели.

Тестова конфигурация

За разлика от други инструменти, за да проведа анализа с Evilginx2 се наложи да изпия няколко чаши с кафе, да изгубя време и малко нерви в подготовка на инфраструктурата, която включваше:

1. Регистриране на домейн;
2. Създаване на няколко DNS записа;
3. Пренасочване на HTTPS заявките през защитната стена към вътрешен хост (първо опитах чрез reverse proxy, но се натъкнах на няколко проблема и предпочетох този вариант);
4. Инсталиране на Evilginx2 и конфигуриране на инструмента (... тук нещата станаха сравнително бързо и задачата - още по-интересна).

Обобщена диаграма на инфраструктурата е:

Регистрираният фиктивен домейн е tzokev.tk (безплатен) и за нуждите на анализа създадох следните DNS записи:

• *.tzokev.tk, от тип А, сочещ към 81.161.247.147 (адрес в лаборатория ИИС на МТФ);
• login.tzokev.tk, от тип А, сочещ към 81.161.247.147;
• www.tzokev.tk, от тип А, сочещ към 81.161.247.147.

Инсталирането на Evilginx2 е сравнително лесно, а предварително трябва да има наличен и конфигуриран Go.

export PATH=$PATH:/home/alex/go/bin:$GOPATH/bin

cd go/src/github.com/kgretzky/evilginx2
make
sudo make install

Конфигурирането на Evilginx2 изисква да се опишат т.нар. phishlets и lures, а при първоначалното им стартиране автоматично се генерират SSL сертификати, издадени от Let's Encrypt, за посочения домейн. Тук държа да отбележа, че процедурата е по-лесна, от колкото, когато сертификатите се създават за реален web сървър (явно законите на Мърфи тук не бяха в пълна сила). За примерът, командите, свързани с горната конфигурация са:

config domain tzokev.tk
config ip 81.161.247.147
phishlets hostname o365 tzokev.tk
phishlets hostname outlook tzokev.tk
phishlets enable o365
lures create o365

След тези стъпки инструментът е готов за работа и единствено следва lure връзката да бъде използвана (при злонамерените действия - разпратена на целевите потребители).

От горното изображение се вижда, че успешно са конфигурирани два phishlets и е активен само този за Office 365. Въпреки предупреждението, че не може да се стартира локален DNS сървър (порт 53 се използва от демон), програмата изпълнява своите функции безпроблемно.

Резултати от работата на Evilginx2

Evilnginx2 работеше и създадох тестов потребител Dummy Dumov (всяко съвпадение с имена на истински лица е напълно случайно) в Office 365. Активирах двуфакторната автентикация и зададох метода да е изпращане на код за достъп през SMS.

Започнах да тествам инструмента от гледна точка на потребител, жертва на атака (или казано по-просто, като Dummy Dumov).

В браузър отворих URL адреса на генерирания lure и ... видях до болка познатата страница за логване към Office 365.  Задържах курсорът на мишката върху част от линковете и те сочеха към ресурси на Microsoft.

Написах e-mail адресът на Dummy Dumov и след това паролата. Почти веднага телефонът ми извъня и се получи кода за двуфакторната автентикация.

Въведох данните...

Успешно се логнах в Office 365 като Dummy Dumov.

Прегледах конзолата на Evilginx2 и останах изумен. Инструментът беше визуализирал потребителското име и паролата в чист текст. С командата sessions получих информация и за session cookie.

Използвах Chrome и импортирах session cookie. Въведох легитимния адрес за автентикация login.mirosoftonline.com и за моя изненада и за съжаление получих достъп до профила на Dummy Dummov (разбира се не се наложи да се въведе паролата).

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

Вижда се колко е лесно да се прескочи двуфакторната автентикация в този конкретен случай. Всичко се свеждаше отново до социалното инженерство и начините потребителя да използва злонамерения линк. Именно тук, "катинарчето до адреса", нямаше да защити Dummy.

... да се доверим ли на двуфакторната автентикация?

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

Е, аз съм на противоположното мнение - ДА, бих се доверил.

Двуфакторната автентикация значително повишава сигурността и в горния пример, за да е успешна атаката е необходимо потребител да се опита да се логне през lure линка, генериран от Evilginx2. Разпознаването на подобни URL, въпреки усилията на злонамерените лица за тяхното прикриване (например login.officemiscrofot.tk, bit.ly/123a и др.) е възможно, дори за хора с по-малко познания в областта на информационните технологии (б.а.: най-сложния начин да кажа - обикновените потребители).

От друга страна показаната примерна атака, няма да е успешна, ако двуфакторната автентикация използва FIDO2.

Как да предпазим потребителите от атака с Evilginx2

За мен решението се свежда до запознаване на служителите с опасността (т.нар. "Security Awareness Training") и до имплементиране на решения от типа на YubiKey.

Good afternoon, Dummy...

И за заключение - не бъдете като Dummy, проверявайте адреса, на който се логвате, дори да използвате двуфакторна автентикация, тя повишава сигурността, но не я гарантира.