Reviews en hall of fame's

Ze vergaten de php functie putenv() uit te zetten in 000webhost.
Dat maakten het mogelijk dat ik LD_PRELOAD kon setten en een reverse shell op de hosting server kreeg.
Meer informatie

Het was mogelijk om GET en POST requesten naar het interne netwerk te sturen als ik een php script maakten met fopen() en fread() op hostinger single shared hosting server.

Ik merkten toen ik een gelimiteerde shell had op hostingers betaalde hosting server dat ze niet de "/etc" map controleerde of er bestanden in stonden.
Dit maakten mogelijk dat ik bestanden kon schrijven in de "/etc" map en meer dan 10gb kon plaatsen.

Op 1 September 2019 werdt ik ingehuurt voor een greybox test van 3 dagen.
Op die dagen waren er verschilende kwetsbaarheden ondekt onderandere meerdere Insecure Direct Object References met patch bypasses die iedereens advertensie kon verwijderen, Stored xss in de advertensies via het bewerken van een advertensie, 2 reflective xss'en, naam veranderen voor premium users ook al hoorde je dit niet te kunnen en nog veel meer.
Voor het officiële rapport kunt u op het linkje hieronder drukken.

Het was mogelijk om extra javascipt code toe te voegen aan de webpagina Huursector.nl wanneer ik een html tag stuurde als "Naam" en naar mijn profiel pagina ging.
Als dit gechained werdt met clickjacking was het mogelijk om deze lek te exploiten zonder dat de user het door had.

Het was mogelijk dat de user zijn eigen informatie steelde doormiddel van een game te maken waar je ctrl+a en ctrl+c in een specififiek leeg "textveld" en dat plakken in een ander textveld.
Maar dat lege "textveld" was een iframe waar de zichtbaarheid zeer laag was gezet waardoor de text onleesbaar werdt.
Wanneer de user de onzichtbare text copieeerde in een ander text veld buiten de iframe was het mogelijk om de gegevens van een user te stelen zonder dat de user het doorhad.

Het was mogelijk om extra javascript toe te voegen aan de website kpn.com wanneer ik een <script> tag in het zoekveld plaatsten als het antwoord in json was.

Het was mogelijk om extra javascript code toe te voegen aan de xs4all hoofdpagina als ik in het zoekveld een script tag html encoded stuurde in een iframe binnen de srcdoc event.
Dit maakten reflective xss moggelijk en kon tot account takeover leiden als een user naar een link van mij ging.

Het was mogelijk om een interne port scan naar het interne netwerk te sturen door een misconfiguratie in de forum wanneer iemand een video toevoegden aan zijn thread.

Het was mogelijk extra javascript toe te voegen in de "gids" pagina doormiddel van de parameter "type" te herschrijven en uit de json te springen.

Als gevolg van een onjuiste geëscaped exec command in MagpieRSS versie 0.72 in het bestand /extlib/Snoopy.class.inc, is het mogelijk om een extra opdracht toe te voegen aan de curl-binary. Dit veroorzaakt een probleem op de pagina's /scripts/magpie_debug.php en /scripts/magpie_simple.php, waarbij het invoeren van een specifieke HTTPS-URL in het RSS-URL-veld het mogelijk maakt het curl request te herschrijven en command injectie te verkrijgen.

Vanwege het ontbreken van validatie op een curl-commando in MagpieRSS 0.72 in het bestand /extlib/Snoopy.class.inc, is het mogelijk om elke interne pagina op te vragen wanneer je een verzoek naar de pagina /scripts/magpie_debug.php of /scripts/magpie_simple.php stuurt, mits je een https-verzoek gebruikt.

In de "ajax_calls.php" file in de "save_img" optie in de "name" parameter zit geen validatie op de extensie naam als een foto wordt bewerkt en opgeslagen.
Dit maakten het mogelijk dat als je een echte foto zou sturen en in de exif data php code plaatsten, dan was het mogelijk om de foto op te slaan als een php file.
Normaal was er validatie dat php files niet mochten worden geupload maar in de "save_img" optie was er vergeten om deze check te doen.
Hierdoor kun je de hele server overnemen en een shell krijgen op de server.

In de "upload.php" file in de "url" parameter zit een internal server side request forgery vulnerability door een incomplete patch voor CVE-2018-14728.
Dit kwam doordat er alleen wordt gecontroleerd of de extensie op het eind niet in de blacklist stond.
Dit was te bypassen door de php file aan te roepen en "/test.ico" op het eind te zetten zoals "index.php/test.ico" want dan laad hij wel de index.php" webpagina in en niet "test.ico" waardoor we het filter hebben gebypassed.
Hierdoor kun je een interne proxy creëren en webpagina binnen het interne netwerk aanvragen ook al hoor je deze niet te bereiken.
Deze kwetsbaarheid zit ook in 9.14.0 maar doordat er een bug was geïntroduceerd kon niemand meer een file uploaden via een url, maar de server stuurde nog wel de aanvraag waardoor dit voor blind internal server side request forgery kan gebruikt worden, maar een copy van dat request wordt wel opgeslagen in de "/tmp/" folder dus als je toegang kan krijgen tot de "/tmp/" dan kun je wel de webpagina zien.

In de "post link" functionaliteit wanneer je een externe link toevoegden aan een topic daar zat een internal server side request forgery vulnerability.
als een domein's dns adres was gericht naar het interne netwerk, dan was het mogelijk om delen van een webpagina te zien zoals de titel tag en een paar meta tags.
meer informatie

In vBulletin 5.5.3 zit geen clickjacking protectie op de hele website wat kan leiden tot account takeover.