Сообщество - Life-Hack [Жизнь-Взлом]/Хакинг

Life-Hack [Жизнь-Взлом]/Хакинг

274 поста 2 806 подписчиков

Популярные теги в сообществе:

4

Атакуем веб-приложения. Уязвимость SQLi. Часть 1 - Теория

Данный пост носит теоретический характер.

В данном посте будет описано что из себя представляет SQLi и как это может быть использовано (в том числе и в незаконных целях).

Крактое определение.

Внедрение SQL-кода (SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

Как это работает?

объясненние сделано максимально простым и опущены некоторые нюансы

Для представления механизма работы SQLi, нужно представлять, что такое база данных и скрипты, в которых производятся запросы к базе данных, а также знать хотя бы на примитивном уровне SQL и иметь навык написания базовых запросов.

Грубо говоря, обычная, в нашем понимании, БД состоит из множества таблиц. У каждой таблицы, естественно, есть столбцы и есть строки. Собственно, это ключевой момент. Возьмем к примеру таблицу пользователей какого-либо интернет-магазина. Для каждого пользователя должно быть описано несколько параметров (логин, адрес электронной почты, дата регистрации, сохранённая карточка и т.д.).

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

Пример.

Представим, что вы (скрипт) идёте в магазин (базу данных), и просите в магазине (создаёте SQL запрос и отправляете его в базу данных) продавца: “Мне нужна одна бутылка воды за 25 рублей”.

Теперь переделаем это в SQL запрос к базе данных, получим следующее:

SELECT * FROM магазин WHERE (тип=’вода’ AND цена=25) LIMIT 1

Собственно, в ответ на вашу просьбу (SQL запрос) вы (скрипт) получаете бутылку (информацию), и продавца (Базу данных) уже не волнует, что вы будете с ней делать, так как свою работу он выполнил. Вы можете ее выпить, вылить, подарить (обработать, вывести, рассчитать) и тд.

Что надо бы знать?

Для полного понимания запроса в базу данных необходимо знать на базовом уровне язык SQL, однако даже без особых знаний можно заметить, что запрос выглядит понятным, так как используются довольно известные слова и они трактуются в данном случае однозначно. Вопросы может вызвать разве что окончание запроса: “LIMIT 1” – данная конструкция объявляет, что необходимо выдать только первый найденный результат, если вдруг их больше одного (бутылок по такой цене может быть очень много, но нам нужна только одна).

Все остальные мнемоники (команды) запроса предельно понятны:

SELECT – выбери (возьми)

FROM – из (указывает от куда нужно взять, чаще всего после данной команды следует название одной из таблиц в текущей базе данных)

WHERE – где (указывает какие значения различных параметров должны быть у той строки которую мы хотим получить, по сути указывает критерии для того товара который мы хотим получить)

Для успешной реализации атаки типа SQLi необходимо хорошо знать язык SQL.

Обобщенно атака типа SQL инъекция (SQL injection) возникает в случае если злоумышленник может каким-то образом модифицировать запрос к БД.

Ещё один пример.

Рассмотрим всё тот-же пример с магазином.

Допустим вы решили пойти в магазин за кефиром, и специально написали на бумажке список продуктов, которые хотите купить, чтобы ничего не забыть. Предположим, что у вас дома оказался друг, который очень любит шоколад, однако ему нельзя есть его много и на его просьбу, вы ответили отказом и не стали записывать в листочек его пожелание. Итого вы получаете листочек, в котором на каждой новой строке записаны продукты, которые вам необходимы в магазине. Допустим, что каждый из продуктов будет представлять собой некий запрос к базе данных (магазину) как и в прошлом примере. Вы просто отдаёте продавцу свой листочек (скрипт передаёт запросы в базу данных) и он, читая очередную строку кладёт в ваш пакет тот или иной продукт (сохраняет результаты, того что удалось получить из базы данных). Теперь представим, что в данный листок ваш друг всё-таки умудрился вписать шоколад (провел атаку SQL injection) и продавец, читая очередную строчку может увидеть следующее: “Масло за 100 рублей или шоколад за 150 рублей”. В магазине может не оказаться масла, или продавцу долго за ним идти, и он положит вам в пакет шоколад. Продавец в данном случае не имеет представления о том, что вашему другу нельзя шоколад и вам он тоже особо не нужен, он просто выполняет свою работу, предоставляет продукты согласно переданному ему списку (база данных будет осуществлять работу по возврату данных на основание входящих запросов, если они были составлены правильно). Переведя это в SQL запрос получим следующее:

SELECT * FROM магазин WHERE (тип=’масло’ AND цена=’100’) OR (тип=‘шоколад’ AND цена=‘150’) LIMIT 1

Атака удалась потому что вы не проверили листочек перед тем как отдать его продавцу (скрипт не проверил входные данные перед формированием запроса и его отправки в базу данных).

Где можно найти SQLi?

SQLi может возникать в местах, где есть какие либо входящие параметры, например формы поиска товаров в интернет магазине или форма авторизации, которые есть на большей части всех веб-приложений. Любой не фильтруемый пользовательский ввод – почти всегда приводит к плачевным последствиям.

Особенности.

В случае с SQLi есть некоторые особенности, связанные с запросом, в который подставляются введённые пользователем данные. Например, тип значение, в которое поступают данные от пользователя может быть целочисленным или строковым, или стоять в нескольких скобочных вложениях, что немного затруднит написание зловредного запроса.

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

Большинство из SQLi обнаруживаются путём нарушения общего мнения о том, что должно быть введено в данное поле конечным пользователем, чаще всего срабатывает символ одинарной кавычки, так как многие из параметров – строковые. Подставив в какой-либо параметр кавычку и получив ошибку, содержащую слова “SQL syntax error” или что-то подобное, можно сразу сказать, что скорей всего здесь есть SQLi.

Однако, есть варианты что кавычка фильтруется, или отключен отчёт об ошибках, в этом случае нужно прибегать к другим методам. Про обходы фильтраций будет написано в следующих постах, после того как будут выпущены посты про "практику SQLi" - следите за каналом!
Мы в телеграме: Life-Hack [Жизнь-Взлом]/Хакинг - подписывайся!

Показать полностью
0

Хакеры и данные: чем простым россиянам грозят новые взломы

За прошедшую неделю на даркнет-форумах появилась информацию сразу о нескольких новых утечках данных: утечка из подведомственного минцифры НИИ «Восход», «Высшая школа экономики» и «Сбер Спасибо».

Пока что подтверждения факта утечек ни от кого из пострадавших компаний и ведомств не было, однако Роскомнадзор совместно с ФСБ уже начал проверку.

Неужели придётся всем теперь менять паспорта?

Пока что нет. Однако по некоторым прогнозам к лету не останется ни одного жителя России, которого не затронула утечка данных.

Что становится причиной утечки?

Их несколько:

— Уязвимости в системе.

— Слабые или повторно используемые пароли.

— Целевые атаки.

— Избыточные права доступа.

— Вредоносные программы.

— Фишинг или спуфинг.

— Украденные учетные записи.

Что нужно знать и предпринять, если утечка данных произошла?

1) Быть готовым к активности мошенников в тех случаях, когда в утечку попала ваша почта и номер телефона. Телефонные мошенники активно берут на прицел новые утечки, пополняя свои базы потенциальных жертв.

2) Если в утечку попал пароль, то нужно в ближайшее время поменять пароль и установить двухфакторную аутентификацию.

3) Если в утечку попали персональные данные(паспорт, Снилс, адрес), нужно написать в Роскомнадзор, который заблокирует сайт, на котором опубликованы ваши данные.

4) Если в утечку попали платежные данные, обратитесь в банк и заморозьте счета.

Как проверить, есть ли мои данные в утечке?

Сайт Have i been pwned? — сайт, который основал в 2013 году известный консультант по веб-безопасности Трой Хант. Для того, чтобы узнать, были ли ваши данные скомпрометированы, нужно ввести свою электронную почту. Сайт покажет все актуальные утечки с вашими данными.

Также за актуальными утечками данных можно следить в профильных Telegram-каналах, в числе которых и наш - Life-Hack [Жизнь-Взлом]/Хакинг

Показать полностью
1

Burp Suite - удобный инструмент для проведения атак на веб-приложения

Данный пост будет носить практический характер с элементами необходимой теории.

В данном посте будет разобрана базовая настройка и основы работы с самым часто используемым инструментом при атаке на веб-приложения - Burp Suite.

Для чего нужен Burp Suite?

Данный инструмент покрывает почти всё, что может быть необходимо исследователю при анализе (имеется ввиду профессиональная версия данного инструмента), это как IDA Pro только в мире веб-исследований. Burp – является крайне функциональной платформой для анализа безопасности веб-приложений. Основной режим работы Burp Suite представляет собой перехватывающий прокси для протоколов http и https, соответственно для корректной работы Burp Suite, необходимо в вашем браузере выставить порт для проксирования трафика через Burp, далее Burp будет перехватывать и останавливать все запросы, идущие через ваш браузер, что позволит вам подменять их на лету, также вы можете отключить автоматическую остановку запросов и потом просмотреть их в истории запросов.

Настройка (короткий гайд).

Будем рассматривать случай, когда Вы работаете с Kali Linux, в котором уже установлен Burp.

Burp Suite имеет графический интерфейс и запускается либо с левой панели быстрого доступа, либо через вкладку Applications->03 - Web Application Analysis.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

При запуске возможно будет выдано сообщение об обновлении, лучше сразу обновить до последней версии, далее будет диалоговое окно создания нового проекта, мы просто жмём далее, и после нажимаем кнопу Start Burp. Если всё было сделано верно, то после запуска мы должны увидеть следующее окно.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Настроим прокси.

Для этого нужно в верхнем меню перейти во вкладку Proxy->Options, далее нужно запустить прокси, это делается путём выставления флажка Running.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

После запуска Burp Suite и запуска прокси сервера необходимо настроить браузер на работу через наш прокси сервер. Если вы используете всё на Kali Linux, то скорее всего вашим браузером для работы является Mozzila, для неё всё настраивается довольно просто, заходим в настройки, далее расширенные настройки и там находим настройки сети.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Далее нажимаем на настройки в выставляем наши параметры.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Начинаем работу.

После применения настроек все запросы, которые идут через браузер будут проходить через наш перехватывающий прокси и останавливаться, это мы можем увидеть в меню Proxy-> Intercepter в Burp Suite.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Если вы хотите подправить запрос вы можете изменить какие-либо данные в тексте запроса и нажать кнопку Forward что отправит запрос далее, если вы хотите не отправлять запрос можете нажать кнопку Drop. Если у вас нет необходимости править запросы на лету, вы можете отключить опцию автоматического перехвата запросов. Для этого просто нажмите на кнопку справа от Drop и увидите, как она превратиться в Intercept is off. Это значит, что перехват не будет осуществляться и вам не нужно будет каждый раз отвлекаться и вручную подтверждать запросы, однако вся история запросов будет сохранена во вкладке HTTP history.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Нажав на любой запрос из списка внизу, вы увидите его подробное описание. Также вы можете отправить необходимый запрос в так называемый Repeater или повторитель, для того чтобы отправить его заново с измененными параметрами, это может быть удобно при тестировании различных инъекции или других атак. Для этого нужно нажать на необходимый запрос правой кнопкой мыши и в выпадающем меню кликнуть на Send to Repeater.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

Удобное управление произвольным запросом.

После этого в верхнем меню перейти во вкладку Repeater. Там вы увидите запрос и сможете корректировать его и отправлять, наблюдая ответ в окне справа. Для более подробного ознакомления с данным инструментов советую потренироваться в его использовании и изучить самостоятельно материалы, которые можно найти в сети интернет. В данном фреймворке есть ещё множество полезных свойств, которые могут пригодиться при анализе веб-приложения.

Burp Suite - удобный инструмент для проведения атак на веб-приложения Взлом, Хакеры, Информационная безопасность, Гайд, Длиннопост

На этом наш краткий обзор такого инструмента, как Burp Suite - закончен, попрактиковаться в использовании данного инструмента можно на CTF’ах, различных HackQuest’ах, WarGames’ах, которых на просторах сети сейчас очень много.

Показать полностью 9
0

Атакуем веб-приложения

Данный пост носит теоретический характер.

В данном посте рассмотрим основаны атак на веб-приложения. Коротко пройдёмся по таким пунктам как:

  • Из чего состоит типичное веб-приложение

  • Какие цели атаки мы преследуем

  • Как их можно достичь

  • Какие бывают уязвимости

  • Кратко об SQLi

  • Стандартный план действий при атаке.

Из чего состоит типичное WEB-приложение.

  • В первую очередь это какие-либо статические данные, файлы, CSS (Cascading Style Sheets) или таблица стилей, JS (JavaScript) – скриптовый язык программирования, исполняемый в браузере, картинки, HTML файлы…

  • Но статические данные нам не особо интересны (кроме каких-либо важных файлов, хранящихся на веб-сервере), так как уязвимостей, связанных с ними, обычно не бывает. Нас интересует для начала, на каком языке написано веб-приложение. Язык, на котором написано веб-приложение, может быть абсолютно любой, начиная от дефолтных PHP, Ruby, Python и заканчивая ASM, но, конечно, чаще всего используется какой-либо скриптовый язык.

  • После языка нам нужно понимать, на чём “крутится” веб-приложение – это сервер, который обрабатывает запросы пользователей и отдаёт им ответы на их запросы, чаще всего это Apache2 или nginx, но бывают и другие варианты, например, для встраиваемых систем часто используют маленькие, легковесные веб-сервера написанные на С/С++.

  • Далее идут базы данных. БД почти всегда используются более-менее серьёзным веб-приложением, в БД хранятся данные пользователей, настройки сервера, файлы, картинки и прочая очень интересная для взломщика информация. Для больших БД нужны удобные системы управления или СУБД, часто используемые варианты: MySQL, Oracle, SQLite.

  • И финальный элемент структуры – ОС, на которой всё это находится. Понятно, что она может быть любой, но чаще всего используется какой-нибудь Linux-дистрибутив (серверный).

Финальные цели атакующего.

Изначально  хакер хочет получить web-shell.

Что такое web-shell?

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

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

Следующий пункт, к которому стремится хакер — это получение шелла на сервере. Что даёт шелл? Шелл даёт возможность управлять непосредственно самим сервером, на котором находится веб-приложение, создавать директории, менять какие-либо правила, оставлять свои зловредные программы, например, для майнинга криптовалюты, сниффинга различных данных, добавление взломанной машины в ботнет. Или он может использовать эту машину для атаки на внутреннею сеть (если таковая имеется).

Финальная цель – это получение root-доступа к машине. Это означает, что хакер имеет полный контроль на сервере и может делать с ним абсолютно всё, вплоть до полного захвата машины.

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

Как выглядит на практике внедрение SQL кода?

Допустим, мы имеем определённый запрос к базе данных, в котором в качестве одного из параметров участвуют данные, которые были введены пользователем на веб-сайте. Если эти данные участвуют в составлении запроса к базе данных, то мы можем непосредственно влиять на этот запрос, например, сначала мы запросим товар с идентификационным номером 1, далее с номером 2, если такие номера есть, то мы получим по ним данные, какое-нибудь описание, цену и прочее. Так упрощённо работают запросы к базе данных. Что произойдёт, если мы захотим нарушить логику запроса и запросим не номер товара, а передадим в этих данных какие-либо ключевые слова языка запроса?

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

SELECT * FROM goods WHERE id = userinput,

где userinput – это то, что ввёл пользователь. Представим, что никакой обработки не происходит и то, что ввёл пользователь, никак не проверяется и вставляется в запрос как есть. Что тогда произойдёт? Если на месте пользователя окажется злоумышленник или специалист по уязвимостям веб-приложений, то он сможет с помощью ключевых слов языка SQL управлять запросом и доставать из различных таблиц необходимые данные, например, логин и хэш пароля администратора, номера банковских карточек, электронные почты пользователей и прочее, что чаще всего хранится в базе данных. Вот так приблизительно и работает уязвимость, связанная с инъекцией SQL-кода. Почти все уязвимости связаны с неправильной обработкой входных данных, получаемых от пользователя.

Атакуем веб-приложения Хакеры, Взлом, Информационная безопасность, Длиннопост

Теперь рассмотрим стандартный план действий при атаке на веб-приложение.

Итак, на первом этапе анализа веб-приложения происходит сбор информации о данном веб-приложении (сайте).

Он бывает двух видов: пассивный и активный. Суть их в том, что при активном режиме вы уже фактически вмешиваетесь в работу веб-приложения, и если у вас нет на это разрешения, то это является нарушением законодательства, по крайне мере в РФ.

Активный сбор информация – это, например, сканирование активных портов, которое вы проводите. Иногда активные порты можно посмотреть через различные сервисы наподобие Shodan или онлайн сканеров.

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

После сбора информации обычно идёт поиск уязвимостей. Фактически самая важная часть исследования и одна из самых сложных. Здесь нет как такового верного подхода, у каждого исследователя свой подход к поиску уязвимостей: кто-то использует сканеры, фаззеры и прочие утилиты, кто-то ищет вручную, используя только базовые инструменты по типу Burp Suite или только браузер, но это совсем редко встречается. Поиск уязвимостей особенно в BlackBox’e чаще всего представляет из себя создание разнообразных предположений и гипотез и последующую проверку их. Есть также так называемые “известные” уязвимости – это уязвимости, которые уже известны сообществу и могут быть обнаружены, если веб-приложение не обновляло ту часть, где находится эта уязвимость, как раз для такого рода уязвимостей и существуют сканеры.

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

Это значит, что, исходя из найденных уязвимостей и их типа, необходимо разработать план нападения на приложение, который должен учитывать, что и как будет проводиться и какие финальные цели, обычно это очень подробно описывается в отчётах исследователей. У злоумышленников вектор атаки зависит от целей, исследователям же приходится расписывать все возможные варианты атаки злоумышленника и последствия, которые будут после удачной или неудачной атаки. Также есть обще описательные вектора уязвимостей, которые содержат в себе тип уязвимости, доступ необходимый для её эксплуатации и критичность.

Далее идёт эксплуатация, это считается самой сложной частью, так как правильно поэксплуатированная одна небольшая, некритичная уязвимость может привести к катастрофическим последствиям.

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

Вот приблизительно так выглядит карта атаки на веб-приложение.

Показать полностью 1
Отличная работа, все прочитано!