A7:IDENTIFICATION AND AUTHENTICATION FAILURES

Оскільки тема про тестування безпеки проектів набирає обертів, вирішила написати статейку на основі OWASP TOP 10.

Ось вони у всій своїй красі))) І так у цій статті ми розглянемо сьому вразливість Identification and Authentication Failures у всьому її цвітінні.

Ця вразливість ділиться на 3 вектори для атаки:

- Brute-Force

- Session Hijacking

- Rainbow Tables

За допомогою цих векторів атакуючий може отримати доступ до облікових даних, за допомогою звичайного підбору даних грубою силою, використовуючи мільйони можливих комбінацій, автоматичними інструментами та словниками.

1) Brute-Force

Ну что начнем разбирать этот вид уязвимости и начнем с вектора атаки

Brute force Brute force - это метод грубого подбора существующих данных, даже можно сказать перебора данных, пока злоумышленник не найдет нужного ключа входа, в данном случае, при подборе на форме авторизации пользователя, мыла (логина) и пароля, для того, чтоб войти в систему под видом жертвы. При подборе данных злоумышленник может использовать как существующею какуе-то слитую базу ранее, либо генерировать данные на лету через разные утилиты, такие как Hydra. Как воспользоваться этим замечательным инструментом, чтоб знать уязвимы ли вы к этому, можно перейти сюда.

І так, припустимо, у нас є файл з величезним списком підготовлених email (Логінів), на картинці вище це цифра 1. Потім у нас є список підготовлених паролів, можемо взяти список найпопулярніших паролів, за статистикою він виглядає приблизно так:

Пароль Кількість використань

123456 120511

12345 48452

password 39448

DEFAULT 34275

123456789 26620

qwerty 20778

12345678 14172

abc123 10869

pussy 10683

1234567 9468

696969 8801

ashley 8793

fuckme 7893

football 7872

baseball 7710

fuckyou 7458

111111 7048

1234567890 6572

ashleymadison 6213

password1 5959

madison 5219

asshole 5052

superman 5023

mustang 4865

harley 4815

654321 4729

123123 4612

hello 4425

monkey 4296

000000 4240

hockey 4191

Чи не правда смішно, що користувачі юзають такі паролі як захист своїх обліків?)))) Напевно, вони себе ніяк не поважають. Більше список можна знайти тут

Потім за допомогою допоміжної утиліти запускають скрипт, який починає підбирати відповідне мило та пароль до форми авторизації цифра 3 на зображенні. Налаштування закінчення скрипту можуть бути різноманітними, або зупиниться, як тільки знайдеться перша подібність для авторизації, так і після закінчення всіх комбінацій з наших списків.

2) Session hijacking

А тепер перейдемо до другого вектора атаки Session hijacking

Session hijacking – це крадіжка правильного сеансу користувача, з якогось сайту. Мета такої атаки передбачає отримання доступу до інформації, якою володіє цей користувач, або до його послуг. Давайте трохи розберемо докладніше на прикладі, тому що напевно з вищесказаного не зовсім зрозуміло, як це працює.

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

Що ми маємо тут? Та цій картинці показано як би працювало розпізнавання користувача, якби не було керування сеансів і кук для цього сеансу. (1) Ми користувач з ім'ям боб, даємо пароль та логін на сайті при авторизації. Цей запит з цими даними надходить на сервер цього сайту POST login.html, де відбувається дія (2) Сервер перевіряє мої дані у себе, якщо я є в системі з цими даними, він каже привіт Боб, всі нормалди, проходь і дає мені відповідь 200 OK, що означає, що мене авторизувало. Потім у дії (3), я хочу подивитися свої дані на сторінці профілю, щоб щось підредактувати, намагаюся перейти на сторінку профілю, при цьому виконується на сервер запит GET profile.html, це означає, що я хочу відвідати цю сторінку. У дії (4) Сервер починає перевіряти мене, тому що не одержав від мене жодних підтверджуючих даних, що я це я. Говорить мені у відповідь, ти хто такий братан??? і віддає мені у відповідь замість запитаної сторінки якусь сторінку з висновком помилки 401 Unauthorized. Це сталося, оскільки у другому моєму запиті не лежали жодні дані з паролем і логіном у тому, щоб мене могли розпізнати. Але погоджувач не зручно при відвідуванні якоїсь сторінки весь час давати свої дані пароля і логіна? Тому є така річ як сесія, яка зберігає в собі всі дані про мене, і не змушує мене постійно відправляти свої креденшели для відвідування тієї чи іншої сторінки. А тепер розглянемо варіант як це працює із сесією.

На цій картинці показано як би працювало розпізнавання користувача, з сеансом та кукою для цього сеансу. (1) Знову ж таки ми користувач з ім'ям боб, даємо пароль та логін на сайті при авторизації, цей запит з цими даними надходить на сервер цього сайту POST login.html, де відбувається дія (2) Сервер перевіряє мої дані у себе і якщо я є в системі з цими даними, потім створює мені унікальну сесію, кладе її в базу. Потім він каже мені "привіт Боб, всі нормалди, проходь, але запам'ятай цей ID сесії", в якій зберігаються всі дані про мене з моїми креденшилами, і давай мені цю ID при виконанні будь-якого запиту на сайті, і зрештою дає мені відповідь 200 OK, що означає, що мене авторизувало, а також дало мені унікальну айдішку. Тепер при наступних запитах, я буду просто разом із запитом на якусь сторінку сайту, давати ще ID сесії, для того щоб мене сприймали як свого користувача сайтом. Розглянемо ще, що відбуватиметься при іншому запиті на сайт.

На цій картинці вже показано як, при подальших запитах, виконується передача разом з ним і ID сесії. Для того щоб сервер міг зрозуміти, що ми його користувачі, і не дасть там відмови, як охоронець при вході на дискотеку. Ехх були часи)))) (1) Знову ж таки ми користувач з ім'ям боб, робимо запит GET profile.html, що ми хочемо подивитися сторінку профілю, щоб потім її подредачить, але в цьому запиті ми також передаємо і ID сесії, в якій лежить і пароль Set-Coockie:jf6b0mit6tjot946hrrsoqv2v3, для визначення нас, як користувач цього сайту, де відбувається дія (2) Сервер перевіряє мої дані у себе в базі, чи є такий користувач, з таким ID сесії. Якщо я є в системі з цими даними, він каже мені "привіт Боб, братуха, всі нормалди, проходь, і тримай те, що хотів побачити, даючи мені 200 OK, що означає, що я є справжнім юзером своєї обліку. А тепер подивимося , Що робить хакер у цьому всьому сценарії, для своїх злодіянь.

Так, а ось тут найцікавіше... У нас є той самий Боб, який посилає якийсь запит на сервер, позначимо його дію (1). Потім у дії (2) сервак обробляє його дані і віддає йому ID сесії, яку в цей час перехоплює хакер, в дії (3), за допомогою будь-яких допоміжних утиліт типу Wireshark або ettercap. Можна додати, що не обов'язково робити перехоплення, якщо ID сесій занадто прості, їх можна просто підібрати, методом перебору. У дії (4) цей хацкер у своєму браузері прописує всі ті дані, що перехопив, рефрешить сторінку і опиняється під урахуванням користувача, якого він перехопив. Небезпечно, чи не так?

Перейдемо до того як убезпечити себе у цьому випадку: 1) Перевірка сеансу: - Додати дату закінчення терміну сесії. Щоб, навіть якщо і хацкер якимось чином знайшов вашу сесію, то після закінчення часу вона не була вже дійсною.

- Прив'язати перевірки на IP користувача до сесії, але тут бути обережніше з цією перевіркою, так як IP може бути не сильно схожий при зміні користувачем девайса або зміні динамічного IP. У цьому випадку користувачеві доведеться часто логінитися.

2) Захист сесії IDs: - ID сесії має бути унікальною та рандомною. Щоб ніхто не міг працювати під тією ж сесією, що й ви. - ID сесії повинні захищатися прапорами Secure та HTTPonly. З цими атрибутами, при спробі атакуючого перехопити ваш запит, буде прихована вся інформація про ваші куки та сесії взагалі. - Завжди перегенерувати куку зі збільшенням привілеїв у системі. Візьмемо за приклад авторизацію. Коли ви не залогінений користувач у вас має бути одна кука, у випадку, якщо ви хочете авторизуватися на сайті для отримання доступу на якісь сторінки, вам повинні дати зовсім іншу унікальну куку, а яка була, повинна видалитись.

3) Захист сесії, що зберігається: - Всі сесії повинні зберігатися на стороні сервера, щоб на фронті вони не миготіли, тому що на фронті вони набагато вразливіші, ніж на стороні сервака. - Підчищати куки в сесії не чекаючи дати закінчення кук - При розлогінніванні користувача вбивати сесію

Так, а ще хочу нагадати, ніколи не довіряйте перевірку валідації, що вводяться користувачем, тільки на фронті програми. Так як цей захист користувач може обійти за допомогою відправки даних на пряму через запити, а не UI вашої програми і самі розумієте, до чого можуть привести не валідовані дані відправлені на сервак. Такі валідації можна порівняти таким чином із такими картинками.

3) Rainbow tables

Rainbow tables - або на наші "Райдужні таблиці", використовуються для розкриття паролів, перетворених за допомогою різних хеш-функції. Але ці таблиці безсилі для атак хакерів. На дані хешів, яким застосовується і сіль, і перець, а ще краще якщо хешується по кілька тисяч разів, послідовно хеш. Ви запитаєте, а як потім розхешувати? Все просто треба розшешувати таку кількість разів, як і хешували, в тій послідовності раз по заразом як відбувався хеш.

Дайте спробую пояснити трохи докладніше, що це і як працює. Припустимо ми є таблиця з креденшилами користувачів, яка містить у собі дані для авторизації, кожного з існуючих користувачів. Я сподіваюся у вас у проекті не лежать паролі у відкритому вигляді?)))) Припустимо у нас є колонка Passwd, як у цій таблиці, яка повинна мати дані у такому вигляді як у колонці Hash Passwd. Але для наочного прикладу, я вніс і цю колонку, щоб було зрозуміло звідки беруться такі значення, які в колонці Hash Passwd. Так, наприклад візьмемо в дії (1) пароль з 4 рядка 1111, захешуємо його через формат MD5. Додам, що є різні види хешування, не лише цей тип. Ви можете взяти посилання в дії (2) і практикуватися там, як відбувається хеширование, закидаючи туди значення і натискати хешировать. У дії (3) ми отримуємо хеш для пароля 1111 і він вже має вигляд b59c67bf196a4758191e42f76670ceba, це робиться для того, щоб навіть атакуючий якимось чином дістане дані з бази, то щоб критичні дані були приховані з його очей. Але треба пам'ятати, з якою легкістю ми захешували ці дані, з такою ж легкістю можемо розхешувати, навіть на цьому сайті є можливість зробити це. Тому варто застосувати запобіжні заходи, такі як сіль і перець, але про це докладніше я пізніше розповім. Повернемося до дії (4) , де захешовані дані потрапляють у таблицю. Насправді все відбувається швидше, без участі сайту, хешування відбувається миттєво в той формат, який вказаний у вас у додатку і хеш розміщується в колонці паролів без проміжної колонки з відкритим паролем. Сподіваюся зрозуміло. А тепер розповім чому просте хешування теж не добре...

Так, ось наша таблиця, вже відразу з захищеними паролями, але тут ще додалася колонка Hint, зараз це поширена дичина, запитувати улюблене ім'я собаки тощо, щоб при забутому паролі могли легко згадати що вони вводили в поле пароль. Але знайте полегшення життя простим користувачам ви і полегшує роботу і зловмисникам. Допустимо у вас звели базу, у вас використовується просте хешування MD5 і є ці підказки на паролі. Зловмисник дивиться, ага ось є 2 схожих хеша, але різниця лише у підказці. Дивимося картинку нижче...

Тут хакер або закине цей хеш в якийсь онлайн декодер і розхешує цей хеш, отримавши пароль для авторизації, але якщо користується сіль або перець, йому трохи треба попотіти, тут він підключить до свого плану підказки. Бачимо, що в однієї підказки пароль ця назва собаки, а в другій із цим же хешом назва якихось святкових днів. Можемо перебрати всі існуючі свята через хешування на онлайн якомусь енкодері і ми знайдемо, що це слово halloween, закинувши його ще раз в хешування побачимо, що так і є і у нас вже розгадано 2 паролі)))) Запишемо це в поля нашої таблиці ....

Тепер давайте приступимо до 4 рядка в таблиці. Тут я покажу, наскільки небезпечно задавати лише чисельні паролі. Це чисельний пароль, кажу заздалегідь, він має відповідь 1111. І тут просто нам досить методом перебору запустити скрипт який автоматично перебере і захешує від 0 до 1111, а потім ми просто порівняємо хеші, що отримали, і цей хеш, який в базі. Це виглядатиме таким чином...

Погодьтеся тепер вам страшно стало за свої паролі, на підбір потрібного хеша пішло менше хвилини, тому що нинішні процесори дозволяють отримати результати у швидкі терміни. Також можна підключати готові райдужні таблиці, їх можна знайти тут. Вони містять всі регістри, всі види хешування, всі ASCI коди, досить просто завантажити потрібну таблицю і зробити перетворення хешей через них. Знову ж таки час розкодування залежить від потужності праці.

А тепер давайте перейдемо до Сіль та Перець, що це таке і для чого воно потрібне.

І так сіль це та частка, яка виділена червоним наприкінці пароля, який задав користувач. Ця частка додається або на початку або в кінці, вона має рандомне значення, складається з такого числа символів, яке задасте їй ви. Після того, як ви додали це значення до значення пароля користувача, потім ви вже хешуєте все це разом і кладете в базу. Так, це всього лише маленька захист, вона всього лише збільшить час на розгадування загадки, але вміє користуватися райдужними таблицями хлопчина, все одно зможе знайти відповідь на цю справу і дізнатися пароль вашого користувача. Як ще один із способів можна додати ще й перцю. Він має такий вигляд.

Тут к нашему паролю, к нашей соли, мы еще добавляем значение перца, он выделен зеленым цветом на картинке. Вы спросите чем же отличается перец от соли, так вот соль постоянно задается новая (уникальная на пароль), а перец задается рандомный, но один и тот же на все пароли и хранится где-то в скрытом месте, где про него почти никто не знает. Это запудрит мозги нашему взломщику и ем понадобится еще больше времени на разгадывание пароля. Но опытному парню все равно это не преграда... Поэтому можно заюзать еще хеширование несколько тысяч раз))) Согласитесь норм так?

Врятували хтось зможе побудувати правильну хронологію розхешування та й ще перець і сіль))) Коротше точно не розгадають, головне щоб ми правильний побудували алгоритм розхешування))) Для того щоб авторизувати нашого користувача. На простому хешуванні горіли не малі компанії, до яких крали бази даних із простим хешуванням, яке можна розгадати за допомогою простих декодерів онлайн. Ось варочка таких:

Тут можна подивитися більше інформації про злиті бази, а також їх фактори. Фейсбук вражає)))) Як зрозуміти що вразливі:

- Дозволяємо автоматичні атаки (не маємо капчі)

- Дозволяємо слабкі або відомі паролі, такі як "Пароль: 1" або "admin / admin"

- Використовує прості текстові, зашифровані або слабо хешовані паролі

- Відсутня чи неефективна багатофакторна автентифікація

- Видає ідентифікатори сеансу в URL-адресі, для тих хто відправляє паролі, куки, користувачів в урлі або через GET запити в API

Як захиститься:

- Багатофакторна автентифікація для запобігання автоматичним атакам

- Не надсилайте в URL дані для роботи з програмою

- Впровадження перевірок з поганими паролями

- Використовуйте паролі з інструкціями NIST 800-63 у розділі 5.1.1

- Обмеження або збільшення затримки невдалих спроб входу в систему, з появою капчі