Poging tot hack vanuit Nederland
Iemand heeft geprobeerd om mij te hacken. Dit van dit gedeeltelijke IP xx.xx.xx.xx en volgende login
105 OR 1=1
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Ik zou graag hebben dat iemand mij zegt waar er eventueel zwakke of open plekken zijn echter niet zonder mij op voorhand te waarschuwen.
Nogmaals! Ik beticht niemand gezien ik jullie helemaal niet ken behalve de login en dat ik hier al veel hulp heb gehad. Zelf probeer ik dit ook te doen maar de meesten zijn hier wel slimmer dan ik:)
De enige reden waarom ik dit hier vraag is omdat dit het enige forum is in NL waar ik mee werk.
Gelieve me dus te vergeven, niet met vergif, mocht iemand zich aangevallen voelen.
Jan
Edit:
IP adres weggehaald. Niet relevant.
Gewijzigd op 23/06/2019 12:49:23 door - Ariën -
Is dit niet gewoon sql-injection?
Ergens de mysql* real_escape vergeten te gebruiken?
Gewijzigd op 23/06/2019 13:20:30 door - Ariën -
- SanThe - op 23/06/2019 10:46:10:
Ergens de mysql* real_escape vergeten te gebruiken?
Dat is het hem juist, het gebruik van real_escape_string() alleen is niet genoeg (interne link).
real_escape_string() escapet niets als er niets te escapen valt.
Nog een keer:
real_escape_string() escapet niets als er niets te escapen valt.
real_escape_string() laat OR 1=1 compleet ongemoeid.
Nogmaals, ten overvloede:
real_escape_string() is alleen veilig in combinatie met quotes.
Ik weet overigens niet of je een gapend gat waardoor iemand naar binnen wandelt echt kunt beschouwen als "hacken".
edit: en als dit voor paniek zorgt dan zou ik je afraden om bij tijd en wijlen eens door je accesslog te spitten, wat daar af en toe voorbij komt... :). Komt er op neer dat er continu "aan de poort wordt gevoeld" om te zien of je lekken hebt (doorgaans standaard aanvalspatronen op populaire pakketten zoals WordPress).
Het is daarom zaak dat je een aantal fundamentele zaken omtrent code-veiligheid snapt en ook toe kunt passen op eigen code.
Bonus Ending:
Gewijzigd op 23/06/2019 12:38:50 door Thomas van den Heuvel
105 OR 1=1
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken."
Ik volg 'm even niet. Heb je hier op het forum een oproep gedaan om jouw site te laten testen op kwetsbaarheid? Zo niet, waarom zou dit dan iemand van het forum moeten zijn? Er vinden op servers en websites vaak duizenden aanvallen per dag plaats. Mensen die proberen via SSH binnen te komen, SQL injection, enz. Waarom zou die ene specifieke aanval van iemand van dit forum moeten komen?
"De enige reden waarom ik dit hier vraag is omdat dit het enige forum is in NL waar ik mee werk."
Euh ... hackaanvallen komen uit alle landen in de wereld. Dat je er nu toevallig eentje treft uit Nederland (wat ook nog eens via een proxy zou kunnen lopen) lijkt me niet meer dan toeval.
Niemand heeft gezet dat het gelukt was :)
realescape heeft wel gewerkt.
En ja hoor mogelijks was het via een proxy.
En verder, het ip is geblokkeerd voor alle inlogs
Jan
Jan R op 23/06/2019 16:57:37:
realescape heeft wel gewerkt.
Laat de desbetreffende query hier eens zien dan, en leg ons eens uit waarom deze veilig is of zou zijn.
De loginpoging ip en tijdstip worden in een log opgeslagen. Daar heb ik dan ook gezien dat er een poging is geweest. De username zou een e-mail moeten zijn en was dus 105 or 1=1
Worden ze gelogd omdat de combinatie gebruikersnaam/wachtwoord niet klopt?
Ozzie PHP op 24/06/2019 02:32:54:
"Enkel de niet gelukte pogingen worden gelogd."
Worden ze gelogd omdat de combinatie gebruikersnaam/wachtwoord niet klopt?
Worden ze gelogd omdat de combinatie gebruikersnaam/wachtwoord niet klopt?
Inderdaad. dan zie ik ook wie of waarom. enorm veel proberen in te loggen met een oud e-mailadres of hun naam. Moderen browsers zien toch dat het geen e-mail is.(input type="email")
Niet het wachtwoord!
Zo wordt deze gebouwd
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
$name = mysqli_real_escape_string($con, $_POST['name']);
$pwsite = mysqli_real_escape_string($con, $_POST['pw']);
$sql='SELECT
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
post_emails e
INNER JOIN post_leden l
ON e.ID = l.ID
left JOIN post_member2rol mr
ON l.id = mr.member
left JOIN post_rollen r
ON mr.rol = r.id
left JOIN post_rol2taak rt
ON rt.rol = r.id
left JOIN post_taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (' . functiecode() . ')) and
(e.email="' . $name . '") and
(password="' . hash('sha512', $pwsite) . '"))';
$pwsite = mysqli_real_escape_string($con, $_POST['pw']);
$sql='SELECT
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
post_emails e
INNER JOIN post_leden l
ON e.ID = l.ID
left JOIN post_member2rol mr
ON l.id = mr.member
left JOIN post_rollen r
ON mr.rol = r.id
left JOIN post_rol2taak rt
ON rt.rol = r.id
left JOIN post_taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (' . functiecode() . ')) and
(e.email="' . $name . '") and
(password="' . hash('sha512', $pwsite) . '"))';
met dit als resultaat
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
SELECT
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
emails e
INNER JOIN leden l
ON e.ID = l.ID
left JOIN member2rol mr
ON l.id = mr.member
left JOIN rollen r
ON mr.rol = r.id
left JOIN rol2taak rt
ON rt.rol = r.id
left JOIN taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (13)) and
(e.email="[email protected]") and
(password="a26e2d...9d612f"))
concat(voornaam, " " , achternaam) as naam,
l.id,
password,
t.id tid,
r.rol,
t.taak
FROM
emails e
INNER JOIN leden l
ON e.ID = l.ID
left JOIN member2rol mr
ON l.id = mr.member
left JOIN rollen r
ON mr.rol = r.id
left JOIN rol2taak rt
ON rt.rol = r.id
left JOIN taken t
ON t.id = rt.taak
WHERE
((actief=1) and
(t.id in (13)) and
(e.email="[email protected]") and
(password="a26e2d...9d612f"))
de taakid komt uit defines en uit de database. Beiden moeten dezelfde zijn. Deze "t.id in (13)" is voor de schaaktoernooien.
Zodoende log ik overal in met hetzelfde script.
De rechten worden op deze manier verdeeld.
Zoals je kan zien hebben we een secretaris die geen klop doet :)
Jan
Gewijzigd op 24/06/2019 09:31:56 door Jan R
Als je een waarde met een apostrof ' invult, dan dient deze geescaped te zijn in de uitvoer.
Ah oké ... maar dit zegt dus verder niks over sql injection. Dit zegt alleen dat het inloggen niet geslaagd is, omdat de combinatie gebruikersnaam/wachtwoord niet klopt.
$pwsite = mysqli_real_escape_string($con, $_POST['pw']);
en vervolgens
(password="' . hash('sha512', $pwsite) . '"))';
Dit lijkt mij gewoonweg fout.
Het is de bedoeling dat DATA die de SQL in gaat niet als SQL geïnterpreteerd kan worden. Daartoe maak je DATA net voor het gebruik in de SQL bij uitvoering van de query onschadelijk door de daarvoor bestemde escaping-functie toe te passen (in combinatie met quotes).
Maar wat jij in zekere zin met je wachtwoord doet is input escaping. Immers, je escapet het oorspronkelijke wachtwoord voordat deze door de hashingfunctie gaat. Als je dit consequent doet (bij opslaan en wijzigen) gaat dit niet fout, maar dit is wel de verkeerde volgorde.
Het is zaak dat je de DATA-delen escapet, en in zekere zin is het niet eens nodig om de hash te escapen, maar dat is wel weer handig om te doen om gewoon overal hetzelfde -en simpele- stramien toe te passen zodat je hier verder niet over na hoeft te denken. Maar op voorhand het oorspronkelijke wachtwoord escapen voor SQL-gebruik, nog voordat je deze hasht is gewoon verkeerd. Je escapet op de verkeerde plaats.
Stel dat je de implementatie van het inloggen straks verandert, en de enige info die je hebt is "gebruikers worden geïdentificeerd aan de hand van hun e-mailadres in combinatie met een SHA512 hash van hun wachtwoord.". Mocht je op dat moment de escaping wel goed hebben geregeld (of je bent inmiddels overgestapt op een andere database, maar je hebt de gegevens meegenomen via een importscript ofzo) dan werken ineens
Voorbeeld:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
$password = "asdf'\"hello"; // wachtwoord waar real_escape_string() aanpassingen in doet
$db = new mysqli('127.0.0.1', 'test', 'test', 'test');
$db->set_charset('utf8'); // <-- DIT BEPAALT TEVENS HOE ESCAPING WERKT! ESCAPING FUNCTIONALITEIT IS AFHANKELIJK VAN DE GEBRUIKTE CHARACTER ENCODERING
?><pre><?php
echo $password.'<br>';
echo $db->real_escape_string($password).'<br>';
// de foute manier - je escapet INPUT
echo hash('SHA512', $db->real_escape_string($password)).'<br>';
// de goede manier - je escapet de uiteindelijke OUTPUT
echo $db->real_escape_string(hash('SHA512', $password)).'<br>';
?></pre>
$password = "asdf'\"hello"; // wachtwoord waar real_escape_string() aanpassingen in doet
$db = new mysqli('127.0.0.1', 'test', 'test', 'test');
$db->set_charset('utf8'); // <-- DIT BEPAALT TEVENS HOE ESCAPING WERKT! ESCAPING FUNCTIONALITEIT IS AFHANKELIJK VAN DE GEBRUIKTE CHARACTER ENCODERING
?><pre><?php
echo $password.'<br>';
echo $db->real_escape_string($password).'<br>';
// de foute manier - je escapet INPUT
echo hash('SHA512', $db->real_escape_string($password)).'<br>';
// de goede manier - je escapet de uiteindelijke OUTPUT
echo $db->real_escape_string(hash('SHA512', $password)).'<br>';
?></pre>
Dit levert het volgende op:
Code (php)
1
2
3
4
2
3
4
asdf'"hello
asdf\'\"hello
0a0ae2bb7199ab9b2eabfc15e6d5f2388519b024e95d0c35ab4edaacce0654f833b3966e1e35952270548f7ffd3ffa3244192fa60d4f6049dd7399b6a7783e52
cc5dfd3a4070a1baab1dc8709a795022507aef8a9082d53dce2e02b19be832845c252b9cef8060c60396ff99bbd37a768c8f17610a619d456fee892039488862
asdf\'\"hello
0a0ae2bb7199ab9b2eabfc15e6d5f2388519b024e95d0c35ab4edaacce0654f833b3966e1e35952270548f7ffd3ffa3244192fa60d4f6049dd7399b6a7783e52
cc5dfd3a4070a1baab1dc8709a795022507aef8a9082d53dce2e02b19be832845c252b9cef8060c60396ff99bbd37a768c8f17610a619d456fee892039488862
Oops?
Gewijzigd op 24/06/2019 14:57:05 door Thomas van den Heuvel
het is consequent dat ik het zo gebruik. ps: naar een voorbeeld dat ik hier in een ver verleden vond :)
Voor de toekomst zal ik het goed doen.
echter een vraagje ivm realescape de hash.
Quote:
Returns a string containing the calculated message digest as lowercase hexits unless raw_output is set to true in which case the raw binary representation of the message digest is returned.
Waarom hexdata escapen?
jan
Gewijzigd op 24/06/2019 16:56:24 door Jan R
Quote:
het is consequent dat ik het zo gebruik.
Simpelweg omdat iets werkt, maakt het nog niet juist :p.
Quote:
naar een voorbeeld dat ik hier in een ver verleden vond :)
Dat klopt dan niet. Heb je de bron hiervan nog?
Quote:
Waarom hexdata escapen?
Dat is in principe niet nodig, maar het is veel belangrijker dat je een consequente manier van escapen hebt, en je altijd bewust bent van de aanwezigheid van externe data. Dit is wellicht lastig uit te leggen, but here goes.
Je bent altijd in een of andere context bezig: in SQL, in HTML, in JavaScript. Binnen zo'n context hebben bepaalde karakters mogelijk een speciale betekenis. Zo hebben <hoekige haken>, ampersands (&) en dubbele quotes (") een speciale betekenis binnen X/HTML. Wanneer bepaalde DATA -die mogelijk afkomstig is van een externe bron-, niet als zodanig in die context geïnterpreteerd zou moeten worden, dan is het zaak dat je de speciale betekenis die die DATA mogelijk heeft ontdoet met de voor die context bestemde escaping-functies en hulpmiddelen (quotes).
Stel bijvoorbeeld dat iemand bij zijn profiel een korte omschrijving van zijn hobby's kan opgeven. En vervolgens geef je die tekst in een HTML-document weer. Wat nu als deze omschrijving HTML bevat, of mogelijk JavaScript die stiekem informatie steelt? Deze tekst wil je dus onschadelijk maken om dit soort potentiële gevaren te neutraliseren.
Nu zou je voor elke DATA-snippet die ooit ergens gebruikt wordt (in HTML, SQL et cetera) kunnen gaan inspecteren of die een potentieel veiligheidsrisico bevat of niet. Kun je ervan verzekerd zijn dat je altijd de goede inschatting maakt? (spoiler: nee). Dus dat is een reden om altijd te escapen, je hoeft dan die overweging niet (telkens opnieuw) te maken.
Of je zou ervoor kunnen kiezen om dit soms toch niet te doen omdat de DATA-passages triviaal zijn, omdat je inderdaad weet dat dit nooit iets schadelijks oplevert (als je dit bijvoorbeeld door een hashingfunctie haalt, dit levert nagenoeg altijd output op die geen speciale betekenis heeft in de SQL context, of een andere).
Maar wat als het niet zo evident is. Is het ontbreken van escaping dan bewust zo gedaan, of is dit mogelijk toch vergeten? Vervolgens moet je dan zo'n passage gaan interpreteren, en vaak is dan (enige tijd later) toch de conclusie dat het niet per se nodig was. DIT DOE JIJ (of iemand anders) DAN MOGELIJK ELKE KEER DAT JE DIE CODE TEGENKOMT. Dit is je reinste tijdsverspilling. Het is gewoon veel simpeler en consequenter om gewoon overal alle (externe) USER DATA te escapen (Don't Make Me Think). En bovendien ook veel veiliger, het kan dan simpelweg nooit fout gaan. Je hoeft verder helemaal niet meer na te denken over het escapen van output mits je dit overal consequent (en op de juiste wijze) doet.
Een andere fout die vaak wordt gemaakt is aannames doen over de context waarin DATA gebruikt gaat worden. En die dan vervolgens op voorhand escapen (escape on input). Ook dat is een slecht idee. Want mogelijk moet je bij gebruik eerst de DATA weer un-escapen (wat zelf ook weer voor een hoop problemen kan zorgen) om die in een bepaalde context te gebruiken.
Als je gewoon overal en altijd de volgende regel toepast:
filter input, escape output
Dan kom je een heel eind.
Maar dan moet je wel:
- inhouden wat dit precies betekent
- en het vervolgens ook op de juiste wijze toepassen
Iets wat nauw samenhangt met escaping-functionaliteit zijn character encoderingen van de data. Maar dat is zelf ook een compleet hoofdstuk.
Gewijzigd op 24/06/2019 17:58:45 door Thomas van den Heuvel
Thomas van den Heuvel op 24/06/2019 17:55:55:
Simpelweg omdat iets werkt, maakt het nog niet juist :p.
Quote:
het is consequent dat ik het zo gebruik.
Simpelweg omdat iets werkt, maakt het nog niet juist :p.
Was gewoon op je antwoord van 24/6 14:32 paragraaf 4
Thomas van den Heuvel op 24/06/2019 17:55:55:
Dat klopt dan niet. Heb je de bron hiervan nog?
Quote:
naar een voorbeeld dat ik hier in een ver verleden vond :)
Dat klopt dan niet. Heb je de bron hiervan nog?
Sorry, nee
Héél goede uitleg. Niet lastig om te begrijpen :)
Bedankt
Jan
Jan R op 23/06/2019 07:02:25:
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Het lijkt me onwaarschijnlijk dat het een forumlid is, maar onderschat het probleem vooral niet: inbraakpogingen met SQL-injectie zie ik minstens wekelijks bij verschillende sites, met IP-adressen van over de hele wereld.
Ik heb er zelfs een leuke honeypot voor ingericht. ;-)
Ward van der Put op 25/06/2019 08:04:03:
Het lijkt me onwaarschijnlijk dat het een forumlid is,
Jan R op 23/06/2019 07:02:25:
Indien dit hier iemand zou zijn, en dit is geen verwijt nog een betichting, gelieve je kenbaar te maken.
Het lijkt me onwaarschijnlijk dat het een forumlid is,
Ik hoop het echt! Ik heb al te veel hulp door velen van jullie gehad. Waarvoor nogmaals dank.
Jan
Quote:
Was gewoon op je antwoord van 24/6 14:32 paragraaf 4
Dat snap ik, maar als ik code zie dan probeer ik ook na te gaan wat iemand heeft bewogen om iets op een bepaalde manier aan te pakken. Dit moet dan wel een goede motivatie zijn. Een aanpak waarbij de motivatie neerkomt op "het werkt" waarbij je situaties kunt verzinnen waarin het fout kan gaan kun je beter vermijden. Een beetje defensief programmeren kan geen kwaad.
Over of het al dan niet een forumlid zou zijn:
Aan de andere kant, als iemand een site linkt met code waar 'ie mee worstelt, dan zit het toch ook een beetje in de aard van een programmeur om een beetje rond te neuzen en eens aan wat deurklinken te hangen.
Ik zou mij dan ook niet zozeer druk maken over wie dit soort dingen precies uitspookt, maar meer met welke motivatie. Maar dit (een of een aantal pogingen) hoeft verder niet eens iets te betekenen. Als het een enkele poging was dan was dit waarschijnlijk een schot in het donker. En als die dan direct doel had getroffen dan verdien je wat mij betreft de consequenties eigenlijk wel ;).
Gewijzigd op 25/06/2019 14:55:14 door Thomas van den Heuvel