Security. Общее

https://t.me/info_hunter

Информационная безопасность — состояние сохранности информационных ресурсов и защищенности законных прав личности и общества в информационной сфере.

3 кита ИБ!

Конфиденциальность: Обеспечение доступа к информации только авторизованным пользователям.
Целостность: Обеспечение достоверности и полноты информации и методов ее обработки.
Доступность: Обеспечение доступа к информации и связанным с ней активам авторизованных пользователей по мере необходимости.

Угроза - событие/ситуация которая делает нам плохо

Конфиденциальность:

Аутентификация(Authentication) - сопоставление персоны (запроса) существующей учётной записи в системе безопасности. Осуществляется по логину, паролю, сертификату, смарт-карте и т. д.
Авторизация(Authorization) - сопоставление учётной записи в системе (и персоны, прошедшей аутентификацию) и определённых полномочий (или запрета на доступ).
Аккаунтинг(Accounting) - слежение за потреблением ресурсов (преимущественно сетевых) пользователем. В accounting включается так же и запись фактов получения доступа к системе (англ. access logs).

Статья TCP/IP

Статья TCP

Статья UDP

Статья SSL | «Как это работает»: знакомство с SSL/TLS

Статья TLS | Что такое TLS

Статья SSH

Статья ICMP

Аутентификация в Интернете и обзор и OAuth

ВЕБ-атаки

Классификация основных уязвимостей

По назначению:

Получение доступа к системе
Повышение уровня привилегий
Приведение в неработоспособное состояние
Разрушение системы или отдельных элементов
Похищение информации и персональных данных
Использование системы для совершения атак или анонимизации

По механизму:

Переполнение буфера
Подмена указателя
SQL-инъекции
Инъекция кода
Перехват трафика
Просмотр директорий
Кросс-сайтовое исполнение сценариев
Инъекции HTTP-заголовков
Подделка межсайтовых запросов
Подстановка невидимых элементов других сайтов
Фишинг(делают копии сайтов)

____________________________________________________________________________

1. HTML injection

* Внедрение html форм, тегов(HTML entity encoder/decoder и URL Encode/Decode)

2. HTTP parameter(HTTP Parameter Pollution)

* HPP происходит, когда сайт принимает пользовательский ввод и использует его для создания запроса к другой системе без валидации этого ввода(отправка одинаковых параметров с разными значениями)

3. CRLF injection(Carriage Return Line Feed)

* Символы CRLF означают конец строки для множества интернет-протоколов, включая HTML, и выглядят как %0D%0A, что декодируется в \r\n. Внедрение через дополнительные заголовки в request.

Этот тип уязвимости может привести к:

• Отравлению кэша, ситуации, в которой атакующий может изменять записи в кэше и отдавать вредоносные страницы (например, содержащие javascript) вместо корректных

• Обходу файрволла, ситуации, в которой запрос может быть создан таким образом, чтобы обойти проверки безопасности, обычно, включает в себя CRLF и чрезмерно большие тела запросов

• Кражу запроса, ситуации, в которой атакующий может украсть HttpOnly cookies и информации о HTTP аутентификации. Это похоже на XSS, но не требует взаимо действия между клиентом и хакером.

4. Межсайтовая подделка запроса CSRF/XSRF(Cross Site Request Forgery)

* CSRF, является атакой, которая осуществляется в тот момент, когда вредоносный сайт, письмо, сообщение, приложение или что-либо иное заставляет браузер пользователя выполнить некоторые действия на другом сайте, где этот пользователь уже аутентифицирован. Атака, которая приводит к тому, что хакер может выполнить на неподготовленном сайте массу различных действий от имени других, зарегистрированных посетителей.

5. Уязвимость в логике приложения

* Если ищете уязвимости, основанные на аутентификации, обратить внимание, как передаются данные доступа к сайту.

• ID, PIN, Race conditions(одновременный запрос с двух ПК)

• Работа с API(json)

• Взаимодействие со сторонними сервисами

• CRUD(create, read, update, delete)

• Двухфакторной аутентификации(изменение запроса, токен, брутфорс)

• Сканирование сети

• Изменять значения false, true

6. XSS(Cross site scripting)

* XSS, предполагает наличие сайта, подключающего непредусмотренный код Javascript, который, в свою очередь, передается пользователям, исполняющим этот код в своих браузерах.

• Reflective XSS: эти атаки не сохраняются на сайте, что означает создание и выполнение XSS в одном запросе и ответе.

• Stored XSS: эти атаки сохраняются на сайте и зачастую более опасны. Они сохраняются на сервере и выполняются на “нормальных” страницах ничего не подозревающими пользователями.

• Self XSS: эти атаки также не сохраняются на сайте и обычно используются как часть обмана человека с целью запуска XSS им самим.

7. SQL injection

* SQLi, является уязвимостью, которая позволяет хакеру “внедрять” SQL-утверждения в цель и получать доступ к её базе данных. Выполнять CRUD.

• Использовать разные комбинации

• Передать массив, вместо одного значения

8. Open Redirect(Open Web Application Security Project)

* Открытое перенаправление происходит, когда приложение принимает параметр и перенаправляет пользователя к значению этого параметра без какой-либо валидации и проверки содержимого этого параметра.

9. Захват поддомена

* Возможность претендовать на поддомен от имени основного и настоящего сайта.

10. XXE(XML External Entity)

* Атака, направленая на приложение, которое обрабатывает парсит XML код. OWASP утверждает, возможность этой атаки возникает, когда XML код содержит ссылки на внешние сущности, которые обрабатываются плохо настроенным парсером. XML,DOCX,XLSX.

11. Удаленное выполнение кода

* Удаленное выполнение кода возникает из-за внедренного кода, который интерпретируется и выполняется уязвимым приложением.

• url index.php?page=1, однако, если пользователь введёт index.php?page=1;phpinfo(), приложение выполнит функцию phpinfo() и вернёт приложению её результат.

• https://example.com”|ls “-la

•<%= ls %> = <%25%3dls%25>

означает код, который должен выполниться и отобразиться (RCE)

12. Инъекция в шаблоны

* Шаблонизаторы - это инструменты, которые позволяют разработчикам/дизайнерам отделить программную логику от представления данных при создании динамических веб-страниц.

• Инъекция в шаблон на стороне сервера (SSTI) возникает, когда шаблонизаторы отображают пользовательский ввод без его надлежащей обработки, подобно XSS.

CSTI уязвимость по URL deeplinking?q=wrtz{{7*7}}

Использование уязвимости через спам на mail, в поле name

{% For c in [1,2,3]%} {{c,c,c}} {% endfor %}

13. Подделка запроса на стороне сервера (SSRF - Server side request forgery)

* Это уязвимость, позволяющая взломщику использовать целевой сервер для отправки HTTP запросов от своего имени.

• В случае с SSRF жертвой является сам уязвимый сервер, а в случае с CSRF - это браузер пользователя.

• Использование Google Dorking

• %00 - нулевой байт, дополнительные слэши, вопросительный знак.

...net/global/media_-preview.php?url=http://ziot.org/?1.png

• Подделка запроса на стороне сервера (SSRF) становится возможной, когда сервер позволяет совершать запросы от лица злоумышленника.

14. Память(переполнение буфера, работа с памятью)

* Переполнение буфера это ситуация, когда программа, записывая данные в буфер или другую область памяти, имеет

больше информации для записи, чем фактически отведено для таких операций в памяти.

* Считывании информации из-за границ этой памяти, доступа к которой у буфера быть не должно.

* Повреждение памяти - это способ эксплуатации уязвимости, при котором код выполняет некоторый тип необычного или неожиданного поведения.

• Примером является Null Byte Injection. Это происходит, когда в код вставляют нулевой байт, или пустую строку %00 или 0x00 в шестнадцатеричном виде, что приводит к непредсказуемому поведению принимающей программы.

• Передача %00 в URL может привести к манипуляциям с веб-ресурсами, в том числе к чтению или к записи файлов, основанных на правах доступа к веб-приложениям в широкой серверной среде.

15. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management)

Для того, чтобы отличать одного пользователя от другого, web-приложение использует так называемые сессионные куки. После того, как Вы ввели логин и пароль и приложение вас авторизовало, в хранилище браузера сохраняется специальный идентификатор, который браузер в дальнейшем предъявляет серверу при каждом запросе страницы вашего web-приложения. Именно так web-приложение понимает, что Вы это именно Вы.

В случае, если ваш идентификатор украдет злоумышленник, а в системе не были реализованы проверки, скажем IP-адреса сессии, или проверки наличия более одного соединения в одной сессии, злоумышленник сможет получить доступ в систему с правами вашего аккаунта. А если это интернет-банк или кабинет платежной системы, о последствиях такого несанкционированного доступа Вы можете легко догадаться сами.

16. Небезопасные прямые ссылки на объекты (Insecure Direct Object References)

Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:

mysite.ru/read_message.jsp?id=123654

Перебирая число после "id=" можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом.

17. Небезопасная конфигурация (Security Misconfiguration)

Безопасность Web-приложения требует наличия безопасной конфигурации всех компонентов инфраструктуры: компонентов приложения (таких как фреймворки – frameworks), веб-сервера, сервера баз данных и самой платформы. Настройки компонентов сервера по-умолчанию зачастую небезопасны и открывают возможности к атакам. Например, кража сессионной cookie через JavaScript при XSS-атаке становится возможна благодаря выключенной по-умолчанию настройке cookie_http only.

При правильной настройке сервера и включенной опции cookie_httponly, получить сессионную cookie через JavaScript невозможно, но зачастую эта простая и важная настройка отсутствовала в таких критично важных местах, как личные кабинеты платежных систем.

Еще один пример детской уязвимости – использование настроек по-умолчанию в серверах баз данных, таких как Redis, Memcached и других – закрытая служба может быть доступна на публичном IP-адресе сервера, и/или использовались пароли, установленные производителем по-умолчанию. Это позволяет злоумышленнику запросто читать и изменять данные, в числе которых, нередко бывают и сессионные cookies (чем это чревато – мы уже знаем) и выводимые пользователям в браузер данные (что позволяет еще и XSS-атаку применить).

18. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)

Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.

Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.

Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.

____________________________________________________________________________

Анализ работы

Сеть, поддомены и сбор ключевой информации

Cосредоточиться на разведке, нахождении всех доступных файлов, директорий и IP адресов.

Инструменты: Nmap, Recong-ng, KnockPy и Whois

Просмотр и понимание приложения

Начать с логики веб-приложения.

Инструменты: Burp

Пример: Силу пароля и лимит попыток: Обеспечивает ли сайт надежный пароль и имею ли я бесконечные попытки на ввод пароля, если я знаю имя пользователя? - Безопасные и HTTP only

Куки: Безопасны ли куки, идентифицирующие пользователя, отправляются ли они токо через HTTPS? Являются они читабельными через Javascript?

Восстановление пароля: Насколько сильны токены восстановления пароля? Можно ли их использовать повторно? - Реализация двухфакторной авторизации: Сколько попыток мне нужно предпринять, чтобы угадать токен? Насколько длинный этот токен? Могу ли я узнать этот токен любым способом?

Далее: Закончив с функциональностью логина, смотреть взаимодействие с сайтом - где создаю, изменяю или удаляю содержимое.

{ Вставку XSS кода, чтобы увидеть отображаются ли двойные кавычки или угловые скобки

Тестирование HTML5 атрибутов, таких как onload, onerror, и т.д. в элементах, таких как тег img

Поиск CSRF токенов и их тестирование - можете ли вы удалить содержимое, это делается через GET или POST запрос? Если GET, то может не быть CSRF защиты.

Передается ли идентификатор аккаунта как параметр в POST-запросе? Можете ли вы изменить это, чтобы получить доступ к другому профилю?

Берёт ли сайт URL параметр для загрузки ресурса, например, www.victim.com?id=4 - можно ли изменить 4 и загрузить файл, такой как ../../etc/passwd? }

Идентифицировать используемые технологии

Каждая из этих технологий имеет свой список уязвимостей. Знание того, с чем вы взаимодействуете, поможет вам обнаружить Внедрение Шаблонов на стороне сервера (SSTI), побег из песочницы.

Инструменты: Wappalyzer

- Rails/Django/Drupal/Wordpress

- Angular/Node/Flask/React