Криптография имеет различные преимущества, включая конфиденциальность информации . Однако чрезмерное использование криптографии для защиты приложений - плохая идея. В этом блоге
Примечание. Мы не собираемся обсуждать криптографические проблемы (например, как взломать криптографии), а скорее говорим о недостатке приложения, недосмотре со стороны разработчиков, который позволил нам создать зашифрованную полезную нагрузку (то есть зашифрованный текст для любого данного открытого текста), который затем использовался для идентифицировать и использовать инъекцию SQL.
Актуальная проблема была найдена в реальном мире. Мы воссоздали аналогичную уязвимость в нашей хакерской лаборатории для этой демонстрации, и это подробно объясняется ниже:
Во время недавнего Pentest приложения электронной коммерции , мы обнаружили , что большинство значений параметров запроса были зашифрованы. Когда параметры запроса зашифрованы, трудно протестировать приложение, если вы не сможете взломать шифрование (для этого требуется знание секретного ключа и алгоритма шифрования) . Получение их в черном ящике Pentest времени в штучной упаковке очень маловероятно. Тем не менее, проверьте наш последний блог о
Вот пример страницы сведений о заказе, в которой параметр id (orderid) отправляется в зашифрованном формате.
Примечание. Значение параметра ( BDKfx3xNKsc = ) зашифровано, а НЕ просто закодировано в base64. Зашифрованное значение параметра ID представляется в кодированном формате base64.
Мы также отметили, что если мы выйдем из приложения, а затем снова войдем в систему под тем же пользователем и перейдем на ту же страницу, значение зашифрованного параметра ( nPBri1km2ic = ) теперь будет другим, как показано ниже:
Это дает хороший признак того, что для шифрования при каждом успешном входе в систему используется случайный ключ или идентификатор сеанса (часть cookie) каким-то образом используется как часть ключа. Выглядит безопасно, да? Мы попытались поиграть с некоторыми криптографическими недостатками , но безуспешно .
Сначала мы пытались инъекционными в одинарные кавычки ( ') I п несколько мест для проверки теста ввода . T он запрашивать параметры были отклонены как таковые необходимо эд быть в зашифрованном формате (то есть действительный зашифрованного) и , таким образом , мы сортируем попадания в кирпичную стену.
Тогда мы наткнулись на функцию обмена корзиной. Эта функция позволяет пользователям делиться элементами корзины с другими. Когда пользователь сохраняет корзину для совместного использования, генерируется ссылка со случайным токеном. Получив доступ к этой ссылке (URL), пользователи могут получить доступ к корзине друг друга. Перед сохранением корзины пользователей просят указать название корзины.
Поскольку это было одно из редких полей ввода, которые принимали ввод в виде открытого текста, мы запустили его для SQLi, XSS, а что нет! но опять не повезло.
Затем мы поняли, что натолкнулись на что-то довольно интересное. При более глубоком рассмотрении выясняется, что этот токен в URL-адресе, созданном для публикации корзины, на самом деле является зашифрованным текстом названия корзины, которое мы выбрали для нашей корзины.
Примечание. Функция корзины общего доступа не была уязвима для любой атаки, но ее можно использовать для создания зашифрованной полезной нагрузки (зашифрованный текст) для заданного ввода (открытый текст). Теперь можно создать полезную нагрузку зашифрованной атаки, чтобы проверить поведение приложения на наличие уязвимостей, таких как SQL-инъекция, обход авторизации и т. Д. Для проверки на SQL-инъекцию было сгенерировано зашифрованное значение одинарных кавычек ('), как показано ниже:
Зашифрованная полезная нагрузка использовалась для размытия различных параметров приложения, которые принимали только значения зашифрованного текста в качестве входных данных. Нам потребовалось некоторое время, чтобы попасть в нужное место, но в итоге параметр ID страницы orderitem возвратил сообщение об ошибке SQL, подтверждающее уязвимость, как показано ниже:
Сообщение об ошибке доказать , что приложение генерирует динамические запросы и могут быть подвержены в инъекции SQL атаки. Тогда пришло время извлечь информацию из базы данных. SQL-запросы на основе UNION использовались для извлечения данных из базы данных. Оператор объединения используется для объединения результата двух или более операторов выбора.
Первой задачей было определить количество столбцов, возвращаемых как часть запроса SQL. Используя метод проб и ошибок , мы получили количество столбцов (30), возвращаемых в запросе. Теперь пришло время извлечь информацию из базы данных. Мы создали зашифрованные данные для извлечения информации о версии базы данных, как показано ниже:
Зашифрованный текст, сгенерированный выходными данными вышеуказанной полезной нагрузки, затем использовался в качестве входных данных для параметра уязвимого идентификатора, который обнаружил версию БД на странице.
Затем мы использовали эту уязвимость, чтобы забить систему базы данных и в итоге получили оболочку!
Вывод
Шифрование параметров для обеспечения безопасности в приложении является примером безопасности по незаметности. Это не делает программное обеспечение безопасным. Данные , зашифрованные с помощью надежных алгоритмов шифрования остается тайной ООН сезам времени ключи защищаются или вредоносную актер идентифицирует способ создания в зашифрованной полезной нагрузки. Шифрование и криптография были рассмотрены , как в механизме де - факто для защиты данных от несанкционированного доступа или подмены. Однако из-за плохих реализаций и отсутствия ясности о том, как «НЕ» использовать криптографии, может привести к довольно разрушительным нарушениям безопасности, как мы видели в этом посте.
Источник:
Ссылка скрыта от гостей
наш ведущий тренер для «
Ссылка скрыта от гостей
» учебного класса , обсудит социологическое исследование , где была идентифицирована и эксплуатируемым инъекция SQL уязвимость с помощью в электронной ncrypted р ayload.Примечание. Мы не собираемся обсуждать криптографические проблемы (например, как взломать криптографии), а скорее говорим о недостатке приложения, недосмотре со стороны разработчиков, который позволил нам создать зашифрованную полезную нагрузку (то есть зашифрованный текст для любого данного открытого текста), который затем использовался для идентифицировать и использовать инъекцию SQL.
Актуальная проблема была найдена в реальном мире. Мы воссоздали аналогичную уязвимость в нашей хакерской лаборатории для этой демонстрации, и это подробно объясняется ниже:
Во время недавнего Pentest приложения электронной коммерции , мы обнаружили , что большинство значений параметров запроса были зашифрованы. Когда параметры запроса зашифрованы, трудно протестировать приложение, если вы не сможете взломать шифрование (для этого требуется знание секретного ключа и алгоритма шифрования) . Получение их в черном ящике Pentest времени в штучной упаковке очень маловероятно. Тем не менее, проверьте наш последний блог о
Ссылка скрыта от гостей
для некоторого понимания этого вопроса.Вот пример страницы сведений о заказе, в которой параметр id (orderid) отправляется в зашифрованном формате.
Примечание. Значение параметра ( BDKfx3xNKsc = ) зашифровано, а НЕ просто закодировано в base64. Зашифрованное значение параметра ID представляется в кодированном формате base64.
Мы также отметили, что если мы выйдем из приложения, а затем снова войдем в систему под тем же пользователем и перейдем на ту же страницу, значение зашифрованного параметра ( nPBri1km2ic = ) теперь будет другим, как показано ниже:
Это дает хороший признак того, что для шифрования при каждом успешном входе в систему используется случайный ключ или идентификатор сеанса (часть cookie) каким-то образом используется как часть ключа. Выглядит безопасно, да? Мы попытались поиграть с некоторыми криптографическими недостатками , но безуспешно .
Сначала мы пытались инъекционными в одинарные кавычки ( ') I п несколько мест для проверки теста ввода . T он запрашивать параметры были отклонены как таковые необходимо эд быть в зашифрованном формате (то есть действительный зашифрованного) и , таким образом , мы сортируем попадания в кирпичную стену.
Тогда мы наткнулись на функцию обмена корзиной. Эта функция позволяет пользователям делиться элементами корзины с другими. Когда пользователь сохраняет корзину для совместного использования, генерируется ссылка со случайным токеном. Получив доступ к этой ссылке (URL), пользователи могут получить доступ к корзине друг друга. Перед сохранением корзины пользователей просят указать название корзины.
Поскольку это было одно из редких полей ввода, которые принимали ввод в виде открытого текста, мы запустили его для SQLi, XSS, а что нет! но опять не повезло.
Затем мы поняли, что натолкнулись на что-то довольно интересное. При более глубоком рассмотрении выясняется, что этот токен в URL-адресе, созданном для публикации корзины, на самом деле является зашифрованным текстом названия корзины, которое мы выбрали для нашей корзины.
Примечание. Функция корзины общего доступа не была уязвима для любой атаки, но ее можно использовать для создания зашифрованной полезной нагрузки (зашифрованный текст) для заданного ввода (открытый текст). Теперь можно создать полезную нагрузку зашифрованной атаки, чтобы проверить поведение приложения на наличие уязвимостей, таких как SQL-инъекция, обход авторизации и т. Д. Для проверки на SQL-инъекцию было сгенерировано зашифрованное значение одинарных кавычек ('), как показано ниже:
Зашифрованная полезная нагрузка использовалась для размытия различных параметров приложения, которые принимали только значения зашифрованного текста в качестве входных данных. Нам потребовалось некоторое время, чтобы попасть в нужное место, но в итоге параметр ID страницы orderitem возвратил сообщение об ошибке SQL, подтверждающее уязвимость, как показано ниже:
Сообщение об ошибке доказать , что приложение генерирует динамические запросы и могут быть подвержены в инъекции SQL атаки. Тогда пришло время извлечь информацию из базы данных. SQL-запросы на основе UNION использовались для извлечения данных из базы данных. Оператор объединения используется для объединения результата двух или более операторов выбора.
Первой задачей было определить количество столбцов, возвращаемых как часть запроса SQL. Используя метод проб и ошибок , мы получили количество столбцов (30), возвращаемых в запросе. Теперь пришло время извлечь информацию из базы данных. Мы создали зашифрованные данные для извлечения информации о версии базы данных, как показано ниже:
Зашифрованный текст, сгенерированный выходными данными вышеуказанной полезной нагрузки, затем использовался в качестве входных данных для параметра уязвимого идентификатора, который обнаружил версию БД на странице.
Затем мы использовали эту уязвимость, чтобы забить систему базы данных и в итоге получили оболочку!
Вывод
Шифрование параметров для обеспечения безопасности в приложении является примером безопасности по незаметности. Это не делает программное обеспечение безопасным. Данные , зашифрованные с помощью надежных алгоритмов шифрования остается тайной ООН сезам времени ключи защищаются или вредоносную актер идентифицирует способ создания в зашифрованной полезной нагрузки. Шифрование и криптография были рассмотрены , как в механизме де - факто для защиты данных от несанкционированного доступа или подмены. Однако из-за плохих реализаций и отсутствия ясности о том, как «НЕ» использовать криптографии, может привести к довольно разрушительным нарушениям безопасности, как мы видели в этом посте.
Источник:
Ссылка скрыта от гостей
