[Forumgame] Vind de kwetsbaarheid!

---

Zoek De Kwetsbaarheid

Na toestemming gekregen te hebben van onze lieve modjes, word hier een nieuw forum-game gestart omtrent programming.
Om dit goed te laten verlopen, hier eerst de volledige uitleg over wat de bedoeling is, wat niet de bedoeling is, wat de regels zijn,..

1. De Bedoeling

De bedoeling van het spel is, zoals de titel al zegt, kwetsbaarheden zoeken. Omdat dit topic in het programming forum staat, lijkt het me logisch dat we kwetsbaarheden in programmacode gaan zoeken.
Het gaat alsvolgt:

• Ik begin met het plaatsen van een stukje programmacode/code snippet
• Jullie zoeken uit hoe je dat stukje code kan exploiten. Natuurlijk ook uitleggen hoe je het exploit, dat levert een goede leerervaring op voor anderen.
• Degene die het juist raadt plaatst het volgende stukje code.
• Zo gaan we eenvoudig genoeg verder.
• Indien er na 1 week nog niemand de exploit gevonden heeft, mag er een andere persoon een nieuwe snippet plaatsen.

Natuurlijk horen er bij een forum-game ook regels:

2. Regels & Afspraken

De code snippets

• Het is niet de bedoeling dat dit een 'check my code'-topic wordt. Je moet dus reeds zelf weten waar de kwetbaarheid zich bevind en hoe deze te exploiten alvorens een stukje code te plaatsen.
• De rest van de code moet volledig werken. Dit omdat sommigen misschien zelf de code eens willen proberen om de exploit te zoeken + eventuele achterhouding van informatie te vermijden.
• Er mag maar 1 code snippet per keer geplaatst worden, en dit alleen door degene die de vorige kwetbaarheid als eerste gevonden had.
• De kwetsbaarheid moet toe te passen zijn zonder de code zelf aan te passen/reverse engineering/hex editing. Dit zou het maar al te gemakkelijk maken om zelf een bug te maken.
• Elke programmeertaal is toegestaan; zo krijgt iedereen de kans om mee te doen.
• Indien je zelf geen code hebt voor de anderen doe je best niet mee; zo loopt het spel niet vast.

Antwoorden
Halve exploits tellen niet. Als je wel weet waar de fout zich bevind, maar niet hoe je deze moet misbruiken telt het antwoord niet.
Zulke dingen houd je dus best voor jezelf, om het de anderen niet te gemakkelijk te maken.
Het enige geldige antwoord is de plaats waar de fout zich bevind + hoe deze te misbruiken.

3. Voorbeeld

Om het een beetje duidelijker te maken voor degenen die het nog niet helemaal snappen; hier een klein (dom) voorbeeldje.

Er wordt een code-snippet geplaatst:
PHP:

1 2 3

<?php  header('Location: '.$_POST['url']);  ?>

Voor dit stukje code zou het juiste antwoord zijn:
(Omdat het hier maar 1 regeltje code was; moet er niet expliciet vermeld worden waar de fout zich bevind)

quote: user

Iedereen kan zo zijn eigen Headers toevoegen:
PHP:

1	<?php $_POST="www.url.com\nHeader: Value"; ?>

Het is natuurlijk niet slim om met POST een header te maken.. Maar het is ook maar een voorbeeld.


Zo; dat was de uitleg zo een beetje.
Ik hoop natuurlijk dat jullie je hier mee gaan amuseren & eventueel nog dingen uit leert er beveiliging van je code!

---

Om het topic te starten plaats ik hier dus het eerste stukje code. Het zou een deel kunnen zijn van een bepaalde functie op een forum waar users zichzelf kunnen op aanmelden.
PHP:

1 2 3 4 5 6 7 8 9

<?php  $result = mysql_query('SELECT name FROM players WHERE id=1');  if (!$result) {      die('Could not query:' . mysql_error());  }  $name = mysql_result($result, 0);  mysql_query("UPDATE players SET name='$name (banned)' WHERE name='$name'");  ?>

Succes & veel plezier met exploiten!

Een moderator wijzigde dit bericht 16-05-2008 16:34 (4%)
Reden: Ook hier de groetjes weggehaald ;)

Als je geen zin hebt om een nieuw voorbeeld te verzinnen kun je dus beter ook maar niet meeraden?

quote:

.oisyn schreef op vrijdag 16 mei 2008 @ 16:13:
Als je geen zin hebt om een nieuw voorbeeld te verzinnen kun je dus beter ook maar niet meeraden?

Is misschien wel zo handig om het topic levend te houden... Als je echt geen zin hebt kan je natuurlijk iets heel simpels doen waardoor de volgende snel het stokje weer kan overnemen? Aan de andere kant moet ik wel toegeven dat dit de drempel verhoogd om mee te doen. Want ik heb zo 1-2-3 ook geen nieuw voorbeeld klaar terwijl de huidige opdracht misschien wel met "SQL Injection" heeft te maken...

riezebosch wijzigde dit bericht 16-05-2008 16:19 (21%)

Je eerste voorbeeld is niet lek, als je maar PHP 4.4.2 of 5.1.iets of later gebruikt. Daarin is header() gefixt zodat je maar 1 header tegelijk kunt versturen.

quote:

.oisyn schreef op vrijdag 16 mei 2008 @ 16:13:
Als je geen zin hebt om een nieuw voorbeeld te verzinnen kun je dus beter ook maar niet meeraden?

Heb het even toegevoegd.
Als je nog geen snippet hebt; kan je toch snel een voorbeeldje in elkaar flansen.

Een moderator wijzigde dit bericht 16-05-2008 16:32 (3%)
Reden: Die groeten hoeft echt niet hoor ;)

Je voorbeeldcode is nogal wazig. Met het stuk op zich is niks mis volgens mij, het hangt allemaal af van wat je zou doen met de rest van de applicatie (de registratie). Maar dat laat je er niet bij zien.

De enige exploit mogelijkheid die ik zie is via die $name, maar die haal je uit de DB, dus om dat te misbruiken zul je je exploitcode bij de registratie al in de DB moeten zien te krijgen. Als je checks daar goed zijn hoeft deze code dus niet onveilig te zijn?

Zo gaat dit topic wel even duren

Bosmonster wijzigde dit bericht 16-05-2008 16:28 (53%)

quote:

Bosmonster schreef op vrijdag 16 mei 2008 @ 16:27:
Je voorbeeldcode is nogal wazig. Met het stuk op zich is niks mis, het hangt allemaal af van wat je zou doen met de rest van de applicatie (de registratie).

Alhoewel het bannen op basis van een naam natuurlijk nogal discutabel is
Maar dat is inderdaad niet direct een exploit, eerder gewoon bad design.

quote:

Bosmonster schreef op vrijdag 16 mei 2008 @ 16:27:
Je voorbeeldcode is nogal wazig. Met het stuk op zich is niks mis, het hangt allemaal af van wat je zou doen met de rest van de applicatie (de registratie).

Nee, je moet gewoon altijd escapen, dan hoef je op dat punt ook niet na te denken of iemand nou wel of niet quotes in z'n naam mocht hebben.

quote:

Cheatah schreef op vrijdag 16 mei 2008 @ 16:28:
[...]

Alhoewel het bannen op basis van een naam natuurlijk nogal discutabel is
Maar dat is inderdaad niet direct een exploit, eerder gewoon bad design.

Ja ok, die code is lelijk en onlogisch natuurlijk, maar daar ging het toch niet om (Heb mn reply nog maar iets uitgebreid)

@Voutloos: ook daar heb je gelijk in natuurlijk en dat snap ik ook wel, maar wederom was dat ook niet het onderwerp van het topic als je er niets (of niet zeker) iets mee kan.

Bosmonster wijzigde dit bericht 16-05-2008 16:30 (18%)

quote:

Voutloos schreef op vrijdag 16 mei 2008 @ 16:28:

Nee, je moet gewoon altijd escapen, dan hoef je op dat punt ook niet na te denken of iemand nou wel of niet quotes in z'n naam mocht hebben.

True, maar dan kun je net zo goed stellen dat de fout is om direct mysql_* functies aan te roepen, in plaats van de boel te wrappen in code die SQL injection onmogelijk maakt

quote:

Cheatah schreef op vrijdag 16 mei 2008 @ 16:30:
[...]

True, maar dan kun je net zo goed stellen dat de fout is om direct mysql_* functies aan te roepen, in plaats van de boel te wrappen in code die SQL injection onmogelijk maakt

Of het resultaat van een mysql_result direct in een query gebruiken zonder dat je eerst kijkt of de resultset wel inhoud heeft... Want zonder inhoud geeft die false terug.. en dat kan dan wat onverwachte resultaten gaan opleveren in die volgende query

M.a.w. "kwetsbaarheden" genoeg in dat kleine stukje code, maar volgens mij niet zoals TS bedoeld heeft

Bosmonster wijzigde dit bericht 16-05-2008 16:34 (20%)

Ik vermoed dat het in het voorbeeld stukje toch echt gaat over een injection attack middels het kiezen van een handige username bij registratie. Vervolgens hoef je alleen nog maar een beetje te rellen en iedereen is gebanned en van naam veranderd.

kortom:

registreer je op het forum met als naam
code:

 ' or '1' = '1

Mja, id = 1, dat is meestal de id van de admin die als eerste geregistreerd heeft... kleine kans dat die a> geband wordt, en b> dat die een username heeft die de boel verpest...

Ook lijkt het me sterk, dat als je een username ziet met iets van TRUNC TABLE players, dat je die dan zo gaat bannen...

quote:

SchizoDuckie schreef op vrijdag 16 mei 2008 @ 17:02:
kortom:

registreer je als allereerste userop het forum met als naam
code:

 ' or '1' = '1

Toevoeging van mijn kant. Het is vrij essentieel dat je userid 1 hebt.

De code is ook alleen maar te gebruiken om de "Femme" van het betreffende forum te bannen, voor gewone users zal je andere code moeten hebben

quote:

Dido schreef op vrijdag 16 mei 2008 @ 17:07:
[...]

Toevoeging van mijn kant. Het is vrij essentieel dat je userid 1 hebt.

De code is ook alleen maar te gebruiken om de "Femme" van het betreffende forum te bannen, voor gewone users zal je andere code moeten hebben

True, maar dat is even inherent aan het voorbeeld hier, al heb ik het idee dat de TS díe optie zelf nog niet door had

SchizoDuckie wijzigde dit bericht 16-05-2008 17:12 (7%)

quote:

SchizoDuckie schreef op vrijdag 16 mei 2008 @ 17:10:
[...]

True, maar dat is even inherent aan het voorbeeld hier, al heb ik het idee dat de TS díe optie zelf nog niet door had

Ik heb het idee dat TS uberhaupt niet doorheeft hoe onduidelijk (en slecht) zijn codevoorbeeld is met betrekking tot zijn zijn eigen vraagstuk

De or die(mysql_error()) is natuurlijk ook een goede manier om mensen die kwetsbaarheden zoeken te helpen.

Volgende:
PHP:

1 2 3 4 5 6 7 8 9 10

<?php $id = $_GET['id']; if($id != (int)$id) {     die('Henk gaat jou opeten!'); } $res = mysql_query('SELECT content FROM table WHERE public=1 AND id=' . $id); if(mysql_num_rows($res) == 0) {     die('Henk gaat jou opeten!'); } $content = mysql_result($res, 0, 'content'); echo htmlspecialchars($content); ?>

quote:

Bosmonster schreef op vrijdag 16 mei 2008 @ 17:31:
Dit levert overigens nog steeds een dikke foutmelding op (en/of onvoorspelbaar gedrag van de rest van de code) als ik een niet bestaande ID meegeef.

Niet echt een kwetsbaarheid, maar goed, aangepast.

GlowMouse wijzigde dit bericht 16-05-2008 17:33 (33%)

Al snel veel reacties!

Excuseer mij voor de onlogische code, maar exploits worden toch op bad code gebaseerd? Ik denk niet dat er iemand expres exploits in zijn script gaat steken. Dit is daar zo'n voorbeeld van.
Maar ik ben misschien inderdaad het registratiegedeelte erbij vergeten zetten.. Maar ik heb het juiste antwoord toch al gezien & er werd al een nieuwe geplaatst.

Nogmaal mijn excuses voor onduidelijkheden.


Cheers,
~ GuShe

quote:

GlowMouse schreef op vrijdag 16 mei 2008 @ 17:21:
De or die(mysql_error()) is natuurlijk ook een goede manier om mensen die kwetsbaarheden zoeken te helpen.

Volgende:
PHP:

1 2 3 4 5 6 7

<?php $id = $_GET['id']; if($id != (int)$id) {     die('Henk gaat jou opeten!'); } $res = mysql_query('SELECT content FROM table WHERE public=1 AND id=' . $id); $content = mysql_result($res, 0, 'content'); echo htmlspecialchars($content); ?>

Dit levert overigens nog steeds een dikke foutmelding op (en/of onvoorspelbaar gedrag van de rest van de code) als ik een niet bestaande ID meegeef.

PHP:

1	<?php $id != (int)$id ?>

Dit geeft iig al false als $id gelijk is aan "aap" oid. (oftewel, "aap" == (int)"aap" - gaat natuurlijk op voor elke string dat 0 oplevert bij de conversie naar int). En maar goed ook, want je id moet immers altijd einigen met een apostroph, anders is de query in regel 5 fout

.oisyn wijzigde dit bericht 16-05-2008 17:37 (17%)

quote:

.oisyn schreef op vrijdag 16 mei 2008 @ 17:34:
PHP:

1	<?php $id != (int)$id ?>

Dit geeft iig al false als $id gelijk is aan "aap" oid. (oftewel, "aap" == (int)"aap"). En maar goed ook, want je id moet immers altijd einigen met een apostroph, anders is de query in regel 5 fout

Inderdaad: wanneer je een string en een integer vergelijkt, cast php de string naar een integer, zodat dit altijd waar is (ook bij een string als "123 aap"). Next!
Waarom de query fout zou gaan zie ik niet.

GlowMouse wijzigde dit bericht 16-05-2008 17:38 (7%)

Je mist een eind-apostroph na $id Oh nvm, dat is de string-einde-apostroph van PHP zelf

Maar je codevoorbeeld heeft op zich weinig met kwetsbaarheden te maken. Je check is niet goed, maar mysql ondersteunt niet meerdere queries in een enkele mysql_query(), en je select ook alleen maar 'content' uit 'table'. Je kan er nog mooie outer joins aan koppelen om je db om zeep te helpen wellicht, maar andere data dan 'content' uit 'table' kun je er volgens mij niet mee lezen.

.oisyn wijzigde dit bericht 16-05-2008 17:42 (7%)

quote:

.oisyn schreef op vrijdag 16 mei 2008 @ 17:41:
Maar je codevoorbeeld heeft op zich weinig met kwetsbaarheden te maken. Je check is niet goed, maar mysql ondersteunt niet meerdere queries in een enkele mysql_query(), en je select ook alleen maar 'content' uit 'table'. Je kan er nog mooie outer joins aan koppelen om je db om zeep te helpen wellicht, maar andere data dan 'content' uit 'table' kun je er volgens mij niet mee lezen.

De public=1 kun je omzeilen via $id = '0 OR id=[wat je wilt]', althans hier met MySQL 5.0.41. Daarnaast is met een UNION nog een en ander mogelijk.

GlowMouse wijzigde dit bericht 16-05-2008 17:47 (4%)

quote:

Inderdaad: wanneer je een string en een integer vergelijkt, cast php de string naar een integer, zodat dit altijd waar is (ook bij een string als "123 aap"). Next!
Waarom de query fout zou gaan zie ik niet.

In de query staat:
code:

id=' . $id");

als je bijvoorbeeld $id = 567 hebt word het:
code:

id=' . 567);

op het einde mankeert de apostrophe, id word niet 'afgesloten'.

Trouwens, zou bijvoorbeeld:
code:

id='$id');

door php niet goedgekeurd worden? $id werd immers niet Escaped.


Cheers,
~ GuShe