Raport za 0 punktów EY GDS Poland Cybersecurity Challenge via Challenge Rocket

przez | |

Niniejszy wpis podzielony jest na dwie części. W pierwszej publikuję opis podatności, które udało mi się zidentyfikować w ramach „EY GDS Poland Cybersecurity Challenge”. W drugiej natomiast opisuję moje zastrzeżenia co do formy przeprowadzenia rzeczonego „wyzwania” i oraz wyjaśnienie, dlaczego to robię.

Część 1 – wykryte błędy bezpieczeństwa

1. Reflected Cross-Site Scripting

CVSSv3 score: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Severity: Critical

Finding:
Reflected Cross Site Scripting vulnerability has been found during the test. It allows for injecting and executing JavaScript code in the application context. JavaScript code is only reflected by the server, which differs from Stored Cross-Site Scripting that stores code in the application permanently. This vulnerability is mostly exploited in order to hijack authenticated users sessions. It can also be used to redirect users to malicious websites or steal the application user’s keystokes.

Proof:
Request:

GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connection: close

Response:

HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:04:34 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 1248
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
<head>
    <title>Internal chat system</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">my messages</a>
              <a                       href="/index.php?page=new_message">Send message</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>Login failure</div>
<form target="_self">
    <div class="container">
        <label for="login"><b>Login</b></label>
        <input type="text" placeholder="Enter login" name="login" id="login"
               value="testhqw60"><script>alert(1)</script>k9nju" required>

        <label for="psw"><b>Password</b>

Recommendation:
The issue results from lack of proper input verification and lack of proper output encoding. It is strongly recommended to incorporate both strict input sanitizing rules and output encoding. HTML special characters like '<’ and ’>’ need to be HTML-encoded (replaced by '<’ and ’>’ respectively) in all data read from the user input, databases and files. The same pertains to characters like ” (which should be replaced with „) and ’ (which should be escaped with a backslash sign ). In turn, strict input sanitizing means a different approach to input validation. For instance, if a variable is intended to hold a number, it is better to check if it is actually a number (like if it matches ^\d+$ regular expression or with an integer cast) instead of trying to figure out all possible bad characters to be filtered out. Input validation taking place on the server side is mandatory, while validation on the client side (HTML/JavaScript, web browser, which is controlled by the user) should be present mostly for usability purpose, but also in order to prevent so called DOM-based cross site scripting. If any user supplied variable is written to the database/file/HTML document without prior sanitization, and then displayed back to other users, such vulnerability becomes a stored XSS, which is much more dangerous since it can be used against authenticated users without any action taken on their side. Also, usually the scale of a stored XSS attack is wider than in case of a reflected one, as multiple users may be affected.

References:
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 Injection

CVSSv3 score: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity: Critical

Finding:
SQL injection flaw was found within the application. This vulnerability allows a potential attacker to execute direct SQL queries on the underlying database. An attacker can for example retrieve all information from the database to which current database user has access to. It also allows defacing website, execute XSS through manipulation on database data or execute system commands.

Proof:
Due to the fact the application doesn’t use parameterization almost whole parameters in the application are vulnerable for SQL injection.

Request:

GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connection: close

Response:

HTTP/1.1 302 Found
Date: Tue, 05 Jan 2021 17:15:25 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: /index.php?loggedin
Content-Length: 666
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
<head>
    <title>Internal chat system</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">my messages</a>
              <a                       href="/index.php?page=new_message">Send message</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>User Loged in</div>

Recommendation:
Every special character in users input data should be filtered or/and sanitized on server side to prevent SQL Injection vulnerabilities. Integer values should not be treated like string values and must be parsed as integer before taking action on them. The best practice is to use prepared (parametrized) statements in all cases where database queries are present.

References:
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. Stored Cross-Site Scripting

CVSSv3 score: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Severity: Critical

Finding:
Stored Cross Site Scripting vulnerabilities have been found during the test. It is mostly exploited in order to hijack authenticated users sessions. The issue results from lack of proper input verification and lack of proper output encoding. A stored XSS takes place when any user supplied vulnerable variable is written to the database/file, and then displayed back to other users. Hence stored XSS is much more dangerous since it can be used against other users without any action taken on their side like phishing. It may be extremely useful for infecting users with use of web-browser exploits, abusing the trust of attacked application.

Proof:
Request:

GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connection: close

Response with execution point:

HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:25:52 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Length: 15252

<html>
<head>
    <title>Internal chat system</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">my messages</a>
              <a class="active"                      href="/index.php?page=new_message">Send message</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Message sent</div>
    <form target="_self">
        <div class="container">
            <h1>Send new message</h1>
            <p>Please select user and provide message text</p>
            <hr>

            <label for="login"><b>User</b></label>
            <select type="text" name="login" id="login" required>
                                <option value="1">admin</option>
                                <option value="2">user</option>
                                <option value="4">prrrsihv</option>
                                <option value="5">0</option>
                                <option value="6">0</option>
                                <option value="7">0</option>
                                <option value="8">0</option>
                                <option value="9">test"</option>
                                <option value="10">ykq1o3wmfv</option>

[…]
value="14">testgl11i"><script>alert(1)</script>y9e06</option>
                                <option 
[…]

Recommendation:
It is strongly recommended to incorporate both strict input sanitizing rules and output encoding. HTML special characters like '<’ and ’>’ need to be HTML-encoded (replaced by '<’ and ’>’ respectively) in all data read from the user input, databases and files. The same pertains to characters like ” (which should be replaced with „) and ’ (which should be escaped with a backslash sign ). In turn, strict input sanitizing means different approach to input validation. For instance, if a variable is intended to hold a number, it is better to check if it is actually a number (like if it matches ^\d+$ regular expression or with an integer cast) instead of trying to figure out all possible bad characters to be filtered out. Input validation taking place both on the server side and on the client side is mandatory. Validation on the client side (HTML/JavaScript, web browser, which is controlled by the user) prevents DOM based Cross Site Scripting from occuring. Validation on the server site prevents from standard (non-DOM) Cross-Site Scripting. If security relies only on the client side validation, it is not difficult for the attacker to create an alternative interface and send maliciously crafted data to the server, successfully bypassing such kind of mechanism. It is always required to implement strict input validation on both the server side and the client side independantly. If any user supplied variable is written to the database/file, and then displayed back to other users, such vulnerability becomes a stored XSS, which is much more dangerous since it can be used against authenticated users without any action taken on their side. Also usually the scale of a stored XSS attack is wider than in case of a reflected one.

References:
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. Authorization Bypass

CVSSv3 score: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity: High

Finding:
It has been revealed that the application has poor authorization implementation. A user who knows the direct path to the resource or a URL to call a particular function, can access it without having proper role grant. Authorization Bypass allows for executing certain actions without having permissions to do so. For example an unauthorized user can be able to execute administrative functions like adding another administrator user.

Proof:
Using direct url for message anyone can read a message that doesn’t belong to him by just changing message id on bellowed url:
http://192.168.140.129/index.php?page=messages&message=1

Recommendation:
Every request to a resource or a function needs to be properly checked if the user that invoked this action has proper permissions. Implementation of mechanism like ACL (Access Control List) with entries per URL/module/function and default DENY policy is highly recommended.

References:
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. Default or Easily-Guessable User Credentials

CVSSv3 score: 8.6
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Severity: High

Finding:
Default or easily-guessable user credentials are very dangerous for the application security. An attacker with no much effort can gain access to the private section of the application. Guessed/cracked password can be used to log in to private section of the application and pivot attacks to authorized users. Now an attacker have much wider area for exploiting the application.

Proof:
Pentester found weak password in application. Additionally, the application use a weak md5 hashing method.

login hash pass
admin d8578edf8458ce06fbc5bb76a58c5ca4 qwerty
user 7815696ecbf1c96e6894b779456d330e asd

Recommendation:
All default password in the application should be changed. Application should also employ strong password policy.

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

6. Sensitive Data Sent Over Unencrypted Channel

CVSSv3 score: 7.5
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Severity: High

Finding:
This vulnerability occurs when sensitive data is sent over HTTP protocol which does not implement any encryption of data. Any data that is sent over this channel is susceptible to sniffing and tampering.

Proof:
Passwords are sent using unencrypted channel using dangerous method – get request type:

Request used to register user, sent via http:

GET /index.php?login=aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connection: close

Request used to login user, sent via http:

GET /index.php?login=test&psw=test&page=login HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connection: close

Recommendation:
HTTPS protocol must be implemented to protect sensitive data. Please also note that when HTTPS protocol will be implemented, cookies should be protected with Secure flag. This prevents from sending cookies over HTTP.

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

7. Verbose Error Messages

CVSSv3 score: 6.5
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Severity: Medium

Finding:
During the test it has been revealed that in case of some requests, server throws out an error exception. The exception message may contains a lot of detailed technical information, including filenames, absolute paths, but also libraries, classes and methods used. This information might be crucial in conducting other, critical attacks (like Arbitrary File Read, Code Execution or platform specific attacks). Such detail information should be available only to application developers and system administrators and should never be revealed to the end user.

Proof:
Request:

GET /index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
Host: 192.168.140.129
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4356.6 Safari/537.36
Accept: 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
Referer: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connection: close

Response:

HTTP/1.1 200 OK
Date: Tue, 05 Jan 2021 17:13:52 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 753
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
<head>
    <title>Internal chat system</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">my messages</a>
              <a                       href="/index.php?page=new_message">Send message</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>Fatal error</b>:  Call to a member function fetch() on a non-object in <b>/var/www/html/login.php</b> on line <b>7</b><br />

Recommendation:
Verbose errors should not be provided to end users. Friendly static error pages should be provided instead. Error cause should be investigated within the code.

References:
OWASP
https://www.owasp.org/index.php/Information_Leakage
CWE-209
http://cwe.mitre.org/data/definitions/209.html
CWE-200: Information Exposure
http://cwe.mitre.org/data/definitions/200.html
Kingdom: Environment
http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md

8. Information Disclosure

CVSSv3 score: 5.3
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Severity: Low

Finding:
Information disclosure vulnerability occurs when sensitive information is leaked in any way by the application. For example server or application configuration is exposed. Severity of this issue depends on information that is leaked.

Proof:
Files as below should not be publicly accessible:
http://192.168.140.129/info.php
http://192.168.140.129/adminer.php

Server and version disclosure in header:
Server: Apache/2.4.6 (CentOS) PHP/5.4.16

Used software and version disclosure in cookie:
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version=4.7.8

Recommendation:
Any additional information should not be leaked. Only information that the user needs should be available/provided.

References:
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

Część 2 – zastrzeżenia do „EY GDS Poland Cybersecurity Challenge via Challenge Rocket”

Czasami w ramach poszerzenia wiedzy i umiejętności biorę udział w różnego rodzaju kursach, szkoleniach i wyzwaniach związanych z bezpieczeństwem. Jednym z nich był „EY GDS Poland Cybersecurity Challenge” organizowany na platformie https://challengerocket.com/ey-cybersecurity-challenge/ . Wedle opisu polegać miał on na przeprowadzeniu audytu bezpieczeństwa – cytując organizatorów „systemu Linux i portalu WWW”. Kolejno na podstawie jego wyników należałoby stworzyć raport. Zawierać on miał opis znalezionych luk, które zagrażają bezpieczeństwu systemu oraz rekomendacje, jak zwiększyć ogólny poziom bezpieczeństwa. Zaznaczono, że zgłoszenie powinno być krótkie, zwięzłe i zawierać krótki opis luk oraz dowody na ich istnienie. Czyli można powiedzieć, że wszystko miało się odbyć wedle standardowej procedury przeprowadzania testów penetracyjnych.

Rzeczywisty obraz konkursu jak i podejście organizatorów do kwestii wyjaśnienia wątpliwości z nim związanych zaskoczyły mnie w mało pozytywny sposób. Mój raport został oceniony na 0 punktów, poniważ, cytując jurorów „wyniki skanera nie są raportem pentestowym”.

Obrazek posiada pusty atrybut alt; plik o nazwie image-7-1024x96.png

Jest to dla mnie krzywdząca ocena i starałem się tę kwestię dokładniej wyjaśnić (prawdopodobna przyczyna w punkcie 6 zastrzeżeń), ale, krótko mówiąc, oprócz cotygodniowych maili (przez prawie miesiąc), typu – „kiedyś tam może odpowiemy”, nie uzyskałem wyjaśnień.

Obrazek posiada pusty atrybut alt; plik o nazwie image-5.png
Obrazek posiada pusty atrybut alt; plik o nazwie image-6.png

Stąd też ten wpis, w którym dzielę się raportem z „czelendżu” oraz moimi zastrzeżeniami co do jego organizacji i formy przeprowadzenia. Uchybień trochę się znalazło.

Mimo wszystko ufam, że moje złe doświadczenia są wynikiem „serii niefortunnych zdarzeń”, a nie brakiem dobrej woli. Zastrzeżenia zamykam w formie listy i mam nadzieję, że przysłużą się w cyklu Williama Edwardsa Deminga:

  1. Całość zabawy była limitowana czasem – 2h. Jest to moim zdaniem zdecydowanie zbyt mało czasu na przeprowadzenie 2 testów penetracyjnych i przygotowania na ich podstawie pełnego raportu.
  2. Żeby wziąć, udział w czelendżu należało pobrać oraz zamontować obraz dwóch maszyn wirtualnych (wykorzystując dostępny czas 2h). Nie zawsze jest to możliwe z prozaicznych przyczyn technicznych. Łatwiejsze moim zdaniem dla osób biorących udział byłoby, gdyby dostęp do maszyn był możliwy za pomocą VPNa, a uczestnicy nie musieliby konfigurować ich po swojej stronie.
  3. Ograniczenie 2h można było w nieuczciwy sposób łatwo pominąć – uzyskać dostęp do zadań poprzez założenie konta na fałszywe dane. Jedynym punktem zabezpieczającym przed tym był zapis w regulaminie: „4. Each Participant can register for the Competition and take the Competition tasks only once. After starting the test, the Participant must complete it within the given time limit. After the test is completed, it will not be possible to retake it. Participants who will try to register for the Competition from multiple accounts and take the test more than once will be disqualified.”. Platforma nie zabezpiecza się przed takimi działaniami. To tak jakby stwierdzić, że nie trzeba tworzyć bezpiecznych aplikacji, gdyż ich hackowanie jest nielegalne.
  4. Do jednej z maszyn hasła dostępowe nie działały/były podane błędnie. Po zgłoszeniu tego dostałem niniejszą odpowiedź: „jeśli chodzi o dostęp do maszyny – być może użyłeś niepoprawnych danych w nieodpowiedni sposób. Do jednej maszyny jest całkiem inny i o wiele większy dostęp niż do drugiej” . Nie jestem w stanie stwierdzić słuszności tej opinii. Wykonałem kroki podane w instrukcji i próbowałem użyć haseł w nich podanych. Uzyskałem informacje od innych uczestników, że im również podane „kredki” nie działały. Dostęp do maszyny można było uzyskać w inny sposób – poprzez usługę FTP. Tylko w takim razie, po co instrukcja wprowadzająca w błąd?
  5. W „portalu WWW” zaszyty był skrypt, który kontaktował się z zewnętrznym serwerem internetowym nazwanym „ey-logger”. Była to o tyle dziwna sytuacja, że wywoływał się w momencie rejestracji na „portalu WWW” i wysyłał do niego użytego loginu i hasła. Ponadto robiąc to, uzyskiwał dostęp do adresu IP osób biorących udział w zabawie. Czyżby ktoś zaszył złośliwego keyloggera w aplikacji? Oceniłem tę kwestię jako pozostałość po testach, która znalazła się tam przypadkowo. Organizator stwierdził jednak, że znalazła się tam on jednak celowo: „natomiast w kwestii skryptu – nie jest to skrypt testowy, a celowo „dziwnie” wyglądający skrypt z podatnością XSS-Persistance (będący jedną z luk bezpieczeństwa do wykrycia. Adres nie jest do serwera EY, tylko do nieznaczącej i niefunkcjonalnej maszynki w Azurze.”.
  6. Po zakończonym teście penetracyjnym i kliknięciu pola z przejściem dalej w celu dołączenia raportu okazało się, że można to zrobić jedynie w oknie przyjmującym czysty tekst, bez żadnego formatowania. Tym samym raport końcowy pozbawiony był czytelności i możliwości załączenia grafik. Sądzę, że stąd też mogła wyniknąć błędna ocena mojego raportu jako „wynik skanera”. Nie udało mi się tego do końca wyjaśnić, gdyż jak wspominałem, już wyżej przez miesiąc nie uzyskałem, żadnej merytorycznej odpowiedzi.
  7. Organizator nie opublikował wyników wyzwania w regulaminowym czasie. Po upłynięciu regulaminowego czasu i zapytaniu kiedy pojawią się wyniki, ukradkiem zmienił daty w treści regulaminu:
Przed zgłoszeniem o niedotrzymanym regulaminowym terminie
Po zgłoszeniem o niedotrzymanym regulaminowym terminie

8. Organizator ujawnił imiona i nazwiska uczestników, mimo zapisu w regulaminie o tym, że tak się nie stanie – „4. The results obtained by the Participants in the Competition will be published after the end of the Competition without publishing the names and surnames of the Participants.” Czyżby naruszenie RODO?

Zwycięzcą gratuluję i życzę dalszych sukcesów! 🙂

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.

Otagowano , , , , , , , , , , , .Dodaj do zakładek Link.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *