Bericht für 0 Punkte EY GDS Poland Cybersecurity Challenge via Challenge Rocket

Von | |

Dieser Eintrag gliedert sich in zwei Teile. In der ersten poste ich eine Beschreibung der Verwundbarkeit, die ich im Rahmen der "EY GDS Poland Cybersecurity Challenge" identifizieren konnte. Auf der anderen Seite beschreibe ich meine Vorbehalte gegen die Form der Durchführung dieser "Herausforderung" und die Erklärung, warum ich dies tue.

Teil 1 – Sicherheitsfehler erkannt

1. Reflektiertes Cross-Site-Skript

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

Finding:
Reflected Cross Site Scripting vulnerability wurde während des Tests gefunden. Es erlaubt das Ein- und Ausführen von JavaScript-Code im Anwendungskontext. Der JavaScript-Code wird nur vom Server reflektiert, der von Stored Cross-Site Scripting abweicht, der den Code in der Anwendung dauerhaft speichert. Diese Vulnerability wird am häufigsten in der Anordnung ausgelöscht, authentizierte Benutzergerichte zu verstecken. Es kann auch verwendet werden, um Benutzer auf bösartige Websites umzuwidmen oder den Anwendungsbeauger es Keystokes zu stehlen.

Proof:
Anfrage:

GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/89.0.4356.6 Safari/537.36
Akzeptiert: 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
Referenz: http://192.168.140.129/index.php?page=login
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Verbindung: close

Antwort:

HTTP/1.1 200 OK
Datum: Di, 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
Verbindung: close
Content-Type: text/html; charset=UTF-8<html>
<head>
    <title>Internes 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">meine Nachrichten</a>
              <a href="/index.php?page=new_message">senden Nachricht</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>Login-Ausfall</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" erforderlich>

<label for="psw"> <b>Passwort</b></label></div></form></div></div></body></html>

Empfehlung: Das Thema
ertönt aus einem Mangel an richtiger Eingabeverifizierung und einem Mangel an proper output encoding. Es wird stark empfohlen, sowohl strenge Input-Regeln als auch Output-Encoding zu integrieren. HTML-Sondercharakter wie<' and="" '="">' ' müssen in allen Daten, die von der<' and="" '="">Benutzerinputation, Denxbasen und Dateien gelesen werden, relativ</'> durch HTML -encoded (ersetzt durch ' ' ersetzt) werden.</'> Die gleichen Berechtigungen für Charaktere wie " (die durch "ersetzt werden sollten) und " (die mit einem Rückschlag signiert werden sollte ). In diesem Fall bedeutet ein strenger Eintrünnigen der Sanierung einen anderen Ansatz für die Eingabe von Validierung. Wenn eine Variable eine Nummer halten soll, ist es besser zu überprüfen, ob sie tatsächlich eine Zahl ist (z. B. wenn sie den regulären Ausdruck ^d+$ oder mit einer eindringlichen Besetzung austrägt), anstatt zu versuchen, alle möglichen schlechten Charaktere herauszufiltern, um gefiltert zu werden. Die Eingabevalidierung auf der Serverseite ist erforderlich, während die Validierung auf der Clientseite (HTML/JavaScript, Webbrowser, die vom Benutzer steuerung wird) zumeist für benutzerfreundliche Benutzerfunktionen vorhanden sein sollte, aber auch in der Anordnung, eine so genannte DOM-basierte Cross-Site-Skriptierung zu verhindern. Wenn eine vom Benutzer gelieferte Variable ohne vorherige Beurlaubung in das Datenbank-/Datei-/HTML-Dokument geschrieben und dann anderen Benutzern wieder angezeigt wird, wird eine solche Verwundbarkeit zu einem gespeicherten XSS, das viel gefährlicher ist, da es gegen authentizierte Benutzer verwendet werden kann, ohne dass eine Aktion auf ihrer Seite ergreift. Auch in der Regel ist die Ursache eines gespeicherten XSS-Angriffs widerspenstig als im Falle eines reflektierten Angriffs, da mehrere Benutzer betroffen sein können.

Referenzen:
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 Punktzahl: 8.8
CVSS v3 V3 Vektor: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity: Critical

Finding:
SQL-Injektionsflauch wurde inner der Anwendung gefunden. Diese Vulnerability erlaubt einem möglichen Angreifer, direkte SQL-Queues auf der untergeordnelten Datenbank auszuführen. Ein Angreifer kann alle Informationen aus der Datenbank, auf die der aktuelle Datenbank-Benutzer Zugriff hat, nur abbrechen. Es erlaubt auch, die Website zu verunstalten, XSS durch Manipulation von Datenbankdaten oder Systembefehlen auszuführen.

Proof: Auf der Suche nach
der Tatsache, dass die Anwendung die Parameterisierung nicht annähern, sind alle Parameter in der Anwendung für die SQL-Injektion möglich.

Anfrage:

GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/89.0.4356.6 Safari/537.36
Akzeptiert: 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
Referenz: http://192.168.140.129/index.php?page=login
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Verbindung: close

Antwort:

HTTP/1.1 302 Gefunden
Datum: Di, 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
Ort: /index.php?loggedin
Content-Length: 666
Verbindung: close
Content-Type: text/html; charset=UTF-8<html>
<head>
    <title>Internes 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">meine Nachrichten</a>
              <a href="/index.php?page=new_message">senden Nachricht</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Benutzer einloggen</div></div></div></body></html>

Empfehlung: Jeder spezielle
Charakter in Benutzern, die Daten eingeben, sollte auf der Serverseite gefiltert und/und saniert werden, um SQL Injection-Vulnerabilities zu verhindern. Integer-Werte sollten nicht wie Zeichenfolgenwerte behandelt werden und vor der Aktion auf sie als integer pariert werden. Die beste Praxis ist die Verwendung vorbereiteter (parametrisierter) Aussagen in allen Fällen, in dem Datenbankqueries vorhanden sind.

Referenzen:
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 Punktzahl: 8.0
CVSS v3 V3 Vektor: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Severity: Critical

Finding:
Stored Cross Site Scripting vulnerabilities wurden während des Tests gefunden. Es wird am häufigsten in der Anordnung exploitiert, authentizierte Benutzer Sitzungen zu verstecken. Das Problem ertönt aus einem Mangel an richtiger Eingabeverifizierung und einem Mangel an proper output encoding. Ein gespeichertes XSS tritt an, wenn eine vom Benutzer gelieferte vulnerable Variable in die Datenbank/Datei geschrieben und dann anderen Benutzern angezeigt wird. Hence stored XSS ist viel gefährlicher, da es gegen andere Benutzer verwendet werden kann, ohne dass eine Aktion auf ihrer Seite wie Phishing. Es kann extrem hilfreich sein, Benutzer mit der Verwendung von Web-Browser-Exploits zu infizieren, wich dem Vertrauen der angegriffenen Anwendung.

Proof:
Anfrage:

GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie 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
Referenz: http://192.168.140.129/index.php?page=register
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Verbindung: close

Antwort mit Hinrichtungspunkt:

HTTP/1.1 200 OK
Datum: Di, 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
Verbindung: close
Content-Type: text/html; charset=UTF-8
Content-Length: 15252<html>
<head>
    <title>Internes 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">meine Nachrichten</a>
              <a class="active" href="/index.php?page=new_message">senden Nachricht</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Botschaft gesendet</div>
    <form target="_self">
        <div class="container">
            <h1>Senden Sie eine neue Nachricht</h1>
            <p>Bitte wählen Sie Benutzer aus und stellen Sie Einen Text zur Verfügung</p>
            <hr>

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

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

Empfehlung: Es wird
stark empfohlen, sowohl strenge Input-Entsorgungsregeln als auch Encoding-Ausrufe zu integrieren. HTML-Sondercharakter wie<' and="" '="">' ' müssen in allen Daten, die von der<' and="" '="">Benutzerinputation, Denxbasen und Dateien gelesen werden, relativ</'> durch HTML -encoded (ersetzt durch ' ' ersetzt) werden.</'> Die gleichen Berechtigungen für Charaktere wie " (die durch "ersetzt werden sollten) und " (die mit einem Rückschlag signiert werden sollte ). In dieser Wendung bedeutet ein strenger Eintrünnigen zur Sanierung unterschiedliche Ansätze zur Eingabe von Validierung. Wenn eine Variable eine Nummer halten soll, ist es besser zu überprüfen, ob sie tatsächlich eine Zahl ist (z. B. wenn sie den regulären Ausdruck ^d+$ oder mit einer eindringlichen Besetzung austrägt), anstatt zu versuchen, alle möglichen schlechten Charaktere herauszufiltern, um gefiltert zu werden. Die Eingabe validierung, die sowohl auf der Serverseite als auch auf der Clientseite ansteht, ist erforderlich. Die Validierung auf der Clientseite (HTML/JavaScript, webbrowser, die vom Benutzer steuerung wird) verhindern, dass DOM-basierte Cross-Site-Skripts von der Eroberung entfernt werden. Validierung auf der Server-Website enthält Standard-Cross-Site-Skript .DOM. Wenn die Sicherheit nur auf der Client-Validierungsseite erfolgt, ist es für den Angreifer nicht schwierig, eine alternative Schnittstelle zu erstellen und bösartig erstellte Daten an den Server zu senden, was eine solche Art von Mechanismus erfolgreich umgeht. Es ist immer erforderlich, eine strenge Eingabe validierung sowohl auf der Serverseite als auch auf der Clientseite sofort umzusetzen. Wenn eine vom Benutzer gelieferte Variable in die Datenbank/Datei geschrieben und dann anderen Benutzern wieder angezeigt wird, wird eine solche Verwundbarkeit zu einem stored XSS, das viel gefährlicher ist, da es gegen authentizierte Benutzer verwendet werden kann, ohne dass eine Aktion auf ihrer Seite ergreift. Auch in der Regel ist dieCale eines vorbe lagerten XSS-Angriffs widerspenstig als im Falle eines reflektierten Angriffs.

Referenzen:
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. Genehmigung bypass

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

Finding:
Es wurde enthüllt, dass die Anwendung eine fehlgeschlagene Autorisierungsimplementierung hat. Ein Benutzer, der den direkten Weg zur Ressource oder url kennt, um einen bestimmten Schalter anzurufen, kann darauf zugreifen, ohne einen richtigen Rollenzuschuss zu erhalten. Die Genehmigung von Bypass erlaubt die Durchführung bestimmter Aktionen, ohne dies zu tun. Beispiellich kann ein benutzerrechtlich autorisierter Benutzer administrative Funktionen ausführen, wie z.Art das Hinzufügen eines anderen Administrators.

Proof:
Mit direkter URL für Nachricht kann anyone eine Nachricht lesen, die ihm nicht gehört, indem er nur die Nachrichten-ID auf der gebellten URL wechselt:
http://192.168.140.129/index.php?page=messages&message=1

Empfehlung: Jeder Antrag
auf eine Ressource oder eine Funktion muss überprüft werden, wenn der Benutzer, der diese Aktion angefordert hat, über weitere Berechtigungen verfügt. Die Implementierung von Mechanismus wie ACL (Access Control List) mit Einträgen pro URL/Module/Funktion und Standard-DENY-Richtlinie wird sehr empfohlen.

Referenzen:
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 Punktzahl: 8.6
CVSS v3 V3 Vektor: 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. Ein Angreifer ohne große Anstrengungen kann Zugang zum privaten Abschnitt der Anwendung erhalten. Guessed/cracked Password kann verwendet werden, um sich in einem privaten Abschnitt der Anwendung anzumelden und Angriffe auf autorisierte Benutzer zu schwenken. Jetzt hat ein Angreifer einen sehr widerisenen Bereich für die Erklärung der Anwendung.

Proof:
Pentester gefunden weak Passwort in der Anwendung. Darüber hinaus verwendet die Anwendung eine weak md5 Hashing-Methode.

login hash pass
admin d8578edf8458ce06fbc5bb76a58c5ca4 qwerty
Benutzer 7815696ecbf1c96e6894b779456d330e asd

Empfehlung:
Alle Standardpasswörter in der Anwendung sollten geändert werden. Die Anwendung sollte auch eine starke Passwortpolitik enthalten.

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

6. Sensitive Data Sent Over Unencrypted Channel

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

Finding:
Diese Verzerrung beginnt, wenn sensible Daten über HTTP-Protokoll gesendet werden, das keine Verschlüsselung von Daten implementiert. Kein Datum, das über diesen Kanal gesendet wird, ist zum Schnüffeln und Zittern nachhaltig.

Proof:
Passwörter werden mit einem verschlüsselten Kanal mit einer gefährlichen Methode gesendet – erhalten Sie eine Anfragetype:

Anfrage, die verwendet wird, um den Benutzer zu registrieren, gesendet über http:

GET /index.php? login=aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/89.0.4356.6 Safari/537.36
Akzeptiert: 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
Referenz: http://192.168.140.129/index.php?page=register
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Verbindung: close

Anfrage verwendet, um Benutzer zu loggen, gesendet über http:

GET /index.php? login=test&psw=test&page=login HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/89.0.4356.6 Safari/537.36
Akzeptiert: 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
Referenz: http://192.168.140.129/index.php?page=login
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Verbindung: close

Empfehlung:
HTTPS-Protokoll muss implementiert werden, um sensible Daten zu schützen. Bitte beachten Sie auch, dass Cookies bei der Implementierung des HTTPS-Protokolls vor dem Secure-Flag geschützt werden sollten. Dies liegt vor dem Senden von Cookies über HTTP.

Referenzen:
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 Punktzahl: 6.5
CVSS v3 V3 Vektor: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Severity: Medium

Finding:
Während des Tests wurde enthüllt, dass der Server im Falle einiger Anfragen eine Fehlerabschiebung aussendet. Die Ausnahmennachricht kann eine Vielzahl detaillierter technischer Informationen, einschließlich Dateinamen, absolute Pfade, aber auch Libraries, Klassen und verwendete Methoden, enthalten. Diese Informationen können entscheidend sein, wenn es um andere, kritische Angriffe geht (wie Arbitrary File Read, Code Execution oder Plattformspezifische Angriffe). Solche detaillierten Informationen sollten nur Anwendungsentwicklern und Systemadministratoren zur Verfügung stehen und niemals dem Endbewender offenbart werden.

Proof:
Anfrage:

GET /index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
Gastgeber: 192.168.140.129
Upgrade-Unsichere-Anfragen: 1
Benutzer-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/89.0.4356.6 Safari/537.36
Akzeptiert: 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
Referenz: http://192.168.140.129/index.php?page=login
Akzeptorisieren: gzip, deflate
Accept-Language: de-PL,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Verbindung: close

Antwort:

HTTP/1.1 200 OK
Datum: Di, 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
Verbindung: close
Content-Type: text/html; charset=UTF-8<html>
<head>
    <title>Internes 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">meine Nachrichten</a>
              <a href="/index.php?page=new_message">senden Nachricht</a>
              <a href="/index.php?logout">Logout</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>Fataler Fehler</b>: Rufen Sie eine Memberfunktionsfetch() auf einem Nichtobjekt in <b>/var/www/html/login an.php</b> auf Zeile <b>7</b><br /></div></div></body></html>

Empfehlung:
Verbose Fehler sollten nicht angeboten werden, um Benutzer zu beenden. Freundliche statische Fehlerseiten sollten stattdessen bereitgestellt werden. Fehler sollten inner dem Code untersucht werden.

Referenzen:
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. Informationsfreiheit

CVSSv3 Punktzahl: 5.3
CVSS v3 V3 Vektor: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Severity: Low

Finding:
Informationen lassen die Eignungsdauer aus, wenn sensible Informationen in irgendeiner Weise von der Anwendung übertragen werden. Die Beispielserver- oder Anwendungskonfiguration wird angezeigt. Viele dieser Fragen sind von Informationen, die sie leaked.

Proof:
Dateien wie unten sollten nicht öffentlich zugänglich sein: http://192.168.140.129/info.php

http://192.168.140.129/adminer.php

Server- und Versionsentkung im
Header: Server: Apache/2.4.6 (CentOS) PHP/5.4.16

Verwendete Software und Versionseinteilung im
Cookie: Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version=4.7.8

Empfehlung:
Zusätzliche Informationen sollten nicht weitergegeben werden. Nur Informationen, die der Benutzer benötigt, sollten verfügbar/bereitgestellt werden.

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

Teil 2 – Vorbehalte gegen "EY GDS Poland Cybersecurity Challenge via Challenge Rocket"

Manchmal nehme ich im Rahmen der Erweiterung von Wissen und Fähigkeiten an verschiedenen Arten von Kursen, Schulungen und Sicherheitsherausforderungen teil. Eine davon war die "EY GDS Poland Cybersecurity Challenge", die auf der https://challengerocket.com/ey-cybersecurity-challenge/-Plattform organisiert wurde. Nach der Beschreibung sollte er ein Sicherheitsaudit durchführen , unter Berufung auf die Organisatoren von "Linux und das Webportal". Nacheinander müsste auf der Grundlage seiner Ergebnisse ein Bericht erstellt werden. Es enthielt eine Beschreibung der festgestellten Schwachstellen, die die Sicherheit des Systems gefährden, und Empfehlungen, wie das allgemeine Sicherheitsniveau erhöht werden kann. Es wurde darauf hingewiesen, dass die Meldung kurz, prägnant und mit einer kurzen Beschreibung der Lücken und beweisen sollte, dass sie bestehen. Man kann also sagen, dass alles nach dem Standardverfahren für Penetrationstests erfolgen sollte.

Das tatsächliche Bild des Wettbewerbs und der Ansatz der Organisatoren, die damit verbundenen Zweifel zu klären, haben mich wenig positiv überrascht. Mein Bericht wurde mit 0 Punkten bewertet, würdig, indem ich Juroren zitierte: "Scannerergebnisse sind kein Pentest-Bericht."

Das Bild hat ein leeres Alt-Attribut; eine Datei mit dem Namen image-7-1024x96.png

Es ist eine verletzende Einschätzung für mich, und ich habe versucht, diese Frage genauer zu klären (die wahrscheinliche Ursache in Punkt 6 der Einwände), aber, kurz gesagt, abgesehen von wöchentlichen E-Mails (für fast einen Monat), der Typ – "eines Tages dort können wir antworten", habe ich keine Erklärung erhalten.

Das Bild hat ein leeres Alt-Attribut; eine Datei namens image-5.png
Das Bild hat ein leeres Alt-Attribut; eine Datei namens image-6.png

Daher auch dieser Eintrag, in dem ich den Bericht mit dem "Leiter" und meine Vorbehalte gegen seine Organisation und Form der Durchführung teile. Das Fehlverhalten ist ein wenig vorbei.

Trotzdem vertraue ich darauf, dass meine schlechten Erfahrungen das Ergebnis einer "Serie unglücklicher Ereignisse" und nicht eines Mangels an gutem Willen sind. Die Vorbehalte schließen ich in Form einer Liste und hoffe, dass sie im William Edwards Deming-Zyklus nützen:

  1. Der ganze Spaß war zeitgesteuert – 2h. Dies ist meiner Meinung nach viel zu wenig Zeit, um zwei Penetrationstests durchzuführen und auf der Grundlage eines vollständigen Berichts vorzubereiten.
  2. Um an der Spitze teilzunehmen, mussten Sie das Bild der beiden virtuellen Maschinen herunterladen und montieren (mit der verfügbaren Zeit von 2h). Dies ist aus prosaischen technischen Gründen nicht immer möglich. Einfacher wäre es meiner Meinung nach für die Teilnehmer, wenn der Zugriff auf die Maschinen über ein VPN möglich wäre und die Teilnehmer sie nicht auf ihrer Seite einrichten müssten.
  3. Die 2h-Beschränkung hätte auf unfaire Weise leicht übersehen werden können – durch die Einrichtung eines Kontos für falsche Daten auf Aufgaben zuzugreifen. Der einzige Schutzpunkt davor war die Geschäftsordnung: "4. Each Participant kann sich nur einmal für den Wettbewerb registrieren und die Wettbewerbsaufgaben übernehmen. Nach Beginn des Tests muss der Participant ihn innerhalb der angegebenen Zeitbegrenzung einstellen. Sobald der Test abgeschlossen ist, wird es nicht möglich sein, es zu retake. Participants, die versuchen, sich für den Wettbewerb von mehreren Konten zu registrieren und nehmen den Test mehr als einmal wird disqualifiziert werden." Die Plattform schützt sich nicht vor solchen Aktivitäten. Es ist, als ob Sie feststellen, dass Sie keine sicheren Apps erstellen müssen, da es illegal ist, sie zu hacken.
  4. Die Zugriffskennwörter für eine der Maschinen funktionierten nicht/wurden falsch angegeben. Nachdem ich dies gemeldet hatte, erhielt ich diese Antwort: "Was den Zugriff auf die Maschine betrifft – vielleicht haben Sie falsche Daten unangemessen verwendet. Eine Maschine ist ganz anders und viel zugänglicher als die andere." Ich kann diese Meinung nicht richtig sagen. Ich habe die in der Anleitung angegebenen Schritte ausgeführt und versucht, die darin angegebenen Passwörter zu verwenden. Ich erhielt Informationen von anderen Teilnehmern, dass ihnen auch "Kreide" nicht funktionierten. Der Zugriff auf die Maschine hätte auf andere Weise erreicht werden können – über den FTP-Dienst. Nur dann, warum die irreführende Anweisung?
  5. Das "Webportal" nähte ein Skript, das einen externen Webserver namens "ey-logger" kontaktierte. Es war eine so seltsame Situation, dass er sich zum Zeitpunkt der Registrierung auf dem "Webportal" meldete und ihm das verwendete Login und Passwort schickte. Darüber hinaus zugriff er auf die IP-Adresse der Teilnehmer des Spiels. Hat jemand einen bösartigen Keylogger in die App eingesteckt? Ich habe das Thema als Überbleibst nach Tests bewertet, das zufällig dort angekommen ist. Der Organisator erklärte jedoch, dass er sich jedoch absichtlich dort wiederfand: "Im Gegensatz dazu ist es kein Testskript und absichtlich ein "seltsam" aussehendes Skript mit XSS-Persistance-Anfälligkeit (eine der sicherheitsrechnerisch zu erkennenden Sicherheitslücken. Die Adresse ist nicht für den EY-Server, sondern nur für den nicht fähigen und nicht funktionsfähigen Rasierer in Azura."
  6. Wenn Sie den Penetrationstest abgeschlossen haben und auf ein Feld klicken, in dem Sie weiter gehen, um den Bericht beizufügen, haben Sie festgestellt, dass dies nur im Fenster mit klarem Text ohne Formatierung möglich ist. Der Abschlussbericht war daher nicht lesbar und konnte Grafiken anhängen. Ich denke, von hier aus hätte auch eine Fehleinschätzung meines Berichts als "Scanner-Score"entstehen können. Ich konnte dies nicht ganz erklären, da ich, wie ich bereits erwähnte, bereits einen Monat lang keine substanzielle Antwort erhalten hatte.
  7. Der Veranstalter veröffentlichte die Ergebnisse der Herausforderung nicht in der regulären Spielzeit. Nach Ablauf der Geschäftsordnungszeit und der Frage, wann die Ergebnisse vorliegen, änderte er heimlich die Daten in der Geschäftsordnung:
Vor der Anmeldung einer nicht eingehaltenen fristgerechten Frist
Nach Der Anmeldung einer nicht eingehaltenen fristgerechten Frist

8. Der Veranstalter gab die Namen der Teilnehmer preis, obwohl er in den Regeln vermerkt war, dass dies nicht geschehen würde – "4. Die Ergebnisse der Participants im Wettbewerb werden nach dem Ende des Wettbewerbs veröffentlicht, ohne die Namen und Namen der Participants zu veröffentlichen." Ist ein Verstoß gegen die DSGVO?

Ich gratuliere dem Gewinner und wünsche Ihnen viel Erfolg! 🙂

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). <br> 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.

Speichere in deinen Favoriten diesen permalink.

Podziel się swoją opinią na temat artykułu