Reviews and hall of fame's

Here are all the companies that written a review for my services, all the hall of fames where im listed for finding vulnerabilities and al my CVE's.

"We have a contract with Martin since April 2019. Martin is very driven about finding security leaks and does this with a lot of passion. He provides clear proof of concepts and can explain found leaks verbally if needed.
Thanks to Martin's efforts, we have been able to fix many leaks some of which were critical. Martin works in a way that you can expect from an ethical hacker, responsibly, decisively and according to agreement."

"Martin helped us a lot with the better protecting our websites and we were able to tackle important issues directly on the basis of his tests and advices."

They forgot to disable the php function putenv() in 000webhost.
That made it possible to set LD_PRELOAD and get a reverse shell in 000webhost hosting server.
More information
It was possible to send GET and POST requests to the internal network if i created a php script with fopen() and fread() on hostinger single shared hosting server.
I noticed when I gotten a restriced shell on hostingers paid hosting server that they didn't check the "/etc" directory.
This made it possible to write more than 10gb if I written it in the "/etc" directory.

On 1 September 2019 I was hired for a 3-day security test.
On those days, there were various vulnerabilities discovered, including multiple Insecure Direct Object References with patch bypasses that anyone could delete any advertisement, Stored xss in the advertisments by editing an advertisement, 2 reflective xss'es, changing the name of your premium users even when you should not be able to change it and lots more.
For the official report you can click on the link below.
it was possible to add extra javascript code to the webpage when i sended a html tag inside the "Naam" and went to the profile page. And when this was chained with clickjacking it was possible to exploit this vulnerbility without the user noticing it.
It was possible to let the user steal his own information bij making a game where you needed to do ctrl+a and ctrl+c in a specific "empty" text box and than paste in another text box.
but that "empty text box" was a iframe where the vissibilty was set to very low and the text became inpossible to read.
so if the user copied the hidden text and placed it in another text field outside the iframe it was possible to steal the information of the user without the user noticing.
Official report greybox security test (dutch) and

it was possible to add extra javascript code to the webpage when i sended a <script> tag to the search page when the response was in json.
It was possible to add extra javascript code to the webpage when I sended html encoded a script tag inside a iframe with srcdoc event.
This made reflective xss possible and could have let to account takeover if a user went to a crafted link.
it was possible to make a internal port scan toward the internal network by using a misconfiguration in the forum when someone added a video inside there thread.

It was possible to add extra javascript to the "gids" page by rewriting the parameter "type" and escaping out of the json.


Because of a incorrect escaped exec command in MagpieRSS in 0.72 in the /extlib/ file, it is possible to add a extra command to the curl binary.
This creates an issue on the /scripts/magpie_debug.php and /scripts/magpie_simple.php page that if you send a specific https url in the RSS URL field, you are able to execute arbitrary commands.


Because of no validation on a curl command in MagpieRSS 0.72 in the /extlib/ file, when you send a request to the /scripts/magpie_debug.php or /scripts/magpie_simple.php page, it's possible to request any internal page if you use a https request.


In the "ajax_calls.php" file in the "save_img" option in the "name" parameter, there is no validation on the extension name when a picture is edited and saved.
This made it possible that if you sent a real picture and placed php code in the exif data, then it was possible to save the picture as a php file.
Normally there was validation that php files should not be uploaded, but in the "save_img" option they forgot to do this check.
This allowed you to take over the entire server and get a shell on the system.


The "upload.php" file in the "url" parameter contains an internal server side request forgery vulnerability due to an incomplete patch for CVE-2018-14728.
This was because it only checks whether the extension was blacklisted or not.
This could be bypassed by requesting a php file and putting "/test.ico" at the end of the url like "index.php/test.ico" because it would than load the "index.php" web page and not "test.ico" by which we bypassed the filter.
This allowed you to create an internal proxy and request a web page within the internal network even though you shouldn't be allowed to reach that.
This vulnerability also exists in 9.14.0 but because a bug was introduced in 9.14.0 no one could upload any file via a url, but the server still sent the request so this still could be used for blind internal server side request forgery, but a copy of that request is stored in the "/tmp/" folder so if you can access the "/tmp/" then you can see the web page.


In the "post link" functionality when you added a external link to a topic there was a internal server side request forgery vulnerability.
if a domain's dns adres was targeted to the internal network it was possible to see parts of webpages in your internal network like the title tag and a few meta tags.
more information


in vBulletin 5.5.3 and lower there is no clickjacking protection on there entire website what can lead to account takeover.

2019 Hackoclipse

KvK-nr.: 69383944