Report for 0 points EY GDS Poland Cybersecurity Challenge via Challenge Rocket

By | |

This entry is divided into two parts. In the first I publish a description of vulnerabilities that I was able to identify as part of the "EY GDS Poland Cybersecurity Challenge". In the second, I describe my reservations about the form in which that 'challenge' was carried out and why I am doing so.

Part 1 – security errors detected

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
Referee: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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></label></div></form></div></div></body></html>

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
Referee: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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></div></div></body></html>

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 (parameterized) 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
Referee: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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 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>

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 user administrator.

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
Referee: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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
Referee: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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
Referee: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;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> online <b>7</b><br /></div></div></body></html>

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

Part 2 – Objections to "EY GDS UK Cybersecurity Challenge via Challenge Rocket"

Sometimes, as part of my knowledge and skills, I take part in all sorts of courses, trainings and security challenges. One of them was the "EY GDS Poland Cybersecurity Challenge" organized on the https://challengerocket.com/ey-cybersecurity-challenge/. According to the description, it consisted in conducting a security audit – quoting the organizers of "Linux and web portal". In turn, a report should be created on the basis of its results. It contained a description of the vulnerabilities found that threaten the security of the system and recommendations on how to increase the overall level of security. It was noted that the notification should be short, concise and contain a brief description of the vulnerabilities and evidence of their existence. That is, it can be said that everything was to take place according to the standard procedure for conducting penetration tests.

The actual picture of the competition and the attitude of the organizers to the question of clarifying the doubts related to it surprised me in a little positive way. My report was rated 0 points, above all, quoting jurors "scanner results are not a pentest report."

The image has an empty alt attribute; file named image-7-1024x96.png

This is a hurtful assessment for me, and I tried to clarify this issue more precisely (probable cause in point 6 of the reservations), but, in short, in addition to weekly emails (for almost a month), such as – "someday we may answer there", I did not get an explanation.

The image has an empty alt attribute; file named image-5.png
The image has an empty alt attribute; file named image-6.png

Hence this entry, in which I share a report with the 'head of thendja' and my reservations about its organisation and form of implementation. There were some shortcomings.

Nevertheless, I trust that my bad experiences are the result of a "series of unfortunate events" and not a lack of goodwill. I close the reservations in the form of a list and I hope that they will serve in the cycle of William Edwards Deming:

  1. All the fun was limited sometimes – 2h. In my opinion, this is far too little time to carry out 2 penetration tests and prepare on the basis of a full report.
  2. To take part in the head of the second was to download and mount an image of two VMs (using the available time 2h). This is not always possible for prosaic technical reasons. In my opinion, it would be easier for those involved if access to the machines could be accessed via a VPNa and the participants would not have to configure them on their side.
  3. The 2h limit could be unfairly omitted – accessing tasks by creating an account for fake data. The only point of protection against this was the provision in the regulations: "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.". The platform does not protect against such actions. It's like you say you don't need to create secure apps because hacking them is illegal.
  4. Access passwords did not work/were inerroneive to one of the machines. After reporting this, I got this reply: "when it comes to access to the machine – you may have used the incorrect data in an inappropriate way. It's completely different to one machine and much more access than the other." I am not in a position to say the validity of this opinion. I followed the steps in the manual and tried to use the passwords given in them. I received information from other participants that they also given "crayves" did not work. The machine could be accessed in a different way – via ftp service. Only then, why misleading instruction?
  5. In the "web portal" a script was sewn, which contacted an external web server called "ey-logger". This was a strange situation, as he was calling at the time of registration on the "web portal" and sending him the login and password used. In addition, in doing so, he accessed the IP address of the people involved in the game. Has anyone sewed a malicious keylogger in the application? I assessed this issue as a remnant of the tests, which was found there accidentally. However, the organizer stated that it was there intentionally: " while in terms of script – it is not a test script, but deliberately "strange" looking script with the vulnerability of XSS-Persistance (which is one of the security vulnerabilities to be detected. The address is not for the EY server, but for a insignificant and non-functional razor in Azura.".
  6. After completing the penetration test and clicking the next-to-go field to include the report, it turned out that this can only be done in a window that accepts clear text, without any formatting. Thus, the final report was devoid of readability and the possibility of attaching graphics. I think that this may have been why my report could have been misassed as a 'scanner result'. I have not been able to explain this to the end, because, as I said, I have not received any substantive answer for a month.
  7. The organizer did not publish the results of the challenge in regular time. After passing the regular time and asking when the results will appear, he surreptituily changed the dates in the terms and conditions:
Before reporting a failure to comply with the statutory deadline
After reporting a failure to comply with the statutory deadline

8. The organizer revealed the names of the participants, despite the fact that this will not happen in the regulations – "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." Is it a violation of the GDPR?

Congratulations to the winner and wish you continued success! 🙂

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.

Bookmark the permalink.

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