[php/mssql] Vinden en oplossen van beveiligingslek

[FragFrog]

Situatieschets:
Er draait hier een MuOnline server. Dit is een MMORPG die gebruikmaakt van een MSSQL database. Eraan gekoppelt (voor gebruikersfuncties als account aanmaken, wachtwoord wijzigen, etc etc) is een PHP website grotendeels door mij geschreven. Sinds enkele dagen verandert een hacker constant dingen in de database en liet vandaag zelfs een berichtje achter.

Gegevens:
Webserver: Apache 1.3.31 icm PHP 5.0.1
Database: MS SQL Server Enterprise Evaluation Edition 2000 SP3
OS: Windows XP prof SP2
Connectie PHP -> database dmv mssql_query's, Game -> database dmv ODBC links
De website in kwestie.

Toegepaste veiligheidsmaatregelen:
• Aparte weblogin met gelimiteerde toegang aangemaakt. Helaas is het voor functionaliteit noodzakelijk dat deze login wel update en set rechten heeft op de database.
• Username / pass voor de SQL server opgeslagen in een config.htpasswd file, alle .ht files zijn als DENY ALL ingesteld in Apache's config files. AFAIK zou dit cross-site scripting moeten voorkomen.
• Meerdere SQL injectie preventie scripts toegepast. De meest aggresieve (en effectieve) bestaat hieruit:

PHP:

if (eregi("[^a-zA-Z0-9_-]", $variabele)
    {
    echo ("SQL injection detected");
    exit();
    }

Die laatste controleert alle veriabelen die gebruikt worden door MSSQL_query's, maar was echter een noodmaatregel toen bleek dat m'n andere scripts niet werkten aangezien het eigenlijk zoveel variabelen uitfiltert dat er functionaliteit verloren gaat. Niet voldoende helaas, aangezien iemand nog steeds dingen kan wijzigen in de database.

Het probleem:
zelf ben ik geen ervaren web devver, en van beveiliging heb ik al helemaal geen kaas gegeten. Ik ga er vanuit dat ik iets enorm over het hoofd zie, maar heb geen idee wat. Een handig artikel in de FAQ over security vermeld oa cross-site scripting en (SQL) variabele injecties, maar dat kan AFAIK geen probleem meer zijn. Nav dat artikel wel zojuist 'register_globals' uitgezet, geen idee of het helpt, veel functionaliteit mis ik er gelukkig niet door

Alle tips en mogelijke oplossingen hoor ik graag!

[nescafe]

Heb je je logfiles al nagekeken?

[FragFrog]

nescafe schreef op zaterdag 09 juli 2005 @ 18:05:
Heb je je logfiles al nagekeken?

Euhm, ik heb het geprobeerd, maar SQL logfiles zijn niet zomaar viewbaar. Eigenlijk ook geen idee hoe ik dit wel zou moeten doen, daarna zoeken was ik nog van plan *schaam*

Als je het over firewall logs hebt: ik gebruik een (hardware) NAT met alleen die poorten geforward die ook daadwerkelijk noodzakelijk zijn.

[ripexx]

Je praat op dit moment dus met twee applicaties naar een database.

Een van de belangrijkste beveiligings maatregel is om de sa account van SQL server een goed wachtwoord te geven.

Daarnaast je web via een IP check volledig dicht zetten, blijft alleen spoofing over en dat lukt de gemiddelde hacker niet zo eenvoudig. Verder alle externe connecties naar de database verbieden dmv een firewall.

Probeer te achterhalen of de hacker via SQL server, Apache/PHP of de game binnen komt.

Net ff met gecheked maar het lijkt erop dat je DB niet direct van buiten af berijkbaar is.

[ Voor 9% gewijzigd door ripexx op 09-07-2005 18:13 ]

[FragFrog]

ripexx schreef op zaterdag 09 juli 2005 @ 18:08:
Je praat op dit moment dus met twee applicaties naar een database.

Een van de belangrijkste beveiligings maatregel is om de sa account van SQL server een goed wachtwoord te geven.

Daarnaast je web via een IP check volledig dicht zetten, blijft alleen spoofing over en dat lukt de gemiddelde hacker niet zo eenvoudig. Verder alle externe connecties naar de database verbieden dmv een firewall.

Probeer te achterhalen of de hacker via SQL server, Apache/PHP of de game binnen komt.

Net ff met gecheked maar het lijkt erop dat je DB niet direct van buiten af berijkbaar is.

De sa account heeft uiteraard een goed wachtwoord en wordt niet gebruikt door zowel de game als de webapplicatie. De game gebruikt nl zoals gezegd ODBC connecties met windows authentication, de website PHP met een apparte gebruikersnaam.

De hacker heeft zelf een table aangemaakt in de database waarin'ie zegt dat ik m'n mssql_query's eens goed moet bekijken. De table is aangemaakt door de web user, zodat het erop lijkt dat hij inderdaad gebruik maakt van Apache / PHP. De externe toegangspoort van de SQL server is overigens geblocked door de NAT, dus die optie sluit ik eigenlijk uit.

Wat je bedoelt met een IP check is me niet helemaal duidelijk, ik zal hier zo wat meer info over gaan googelen

//edit
Van wat Google mij leert bedoel je alleen toegang geven tot de server aan bekende IP's, of zelfs alleen maar interne IP's. Ik ben het met je eens dat dit een stuk veiliger is, maar betekent dit niet dat de website door niemand meer bekeken kan worden? Dat is namelijk ook niet helemaal de bedoeling

[ Voor 11% gewijzigd door FragFrog op 09-07-2005 19:00 ]

[ripexx]

FragFrog schreef op zaterdag 09 juli 2005 @ 18:20:
[...]

De sa account heeft uiteraard een goed wachtwoord en wordt niet gebruikt door zowel de game als de webapplicatie. De game gebruikt nl zoals gezegd ODBC connecties met windows authentication, de website PHP met een apparte gebruikersnaam.

De hacker heeft zelf een table aangemaakt in de database waarin'ie zegt dat ik m'n mssql_query's eens goed moet bekijken. De table is aangemaakt door de web user, zodat het erop lijkt dat hij inderdaad gebruik maakt van Apache / PHP. De externe toegangspoort van de SQL server is overigens geblocked door de NAT, dus die optie sluit ik eigenlijk uit.

Wat je bedoelt met een IP check is me niet helemaal duidelijk, ik zal hier zo wat meer info over gaan googelen

Welk deel van je website heeft echt insert en update rechten nodig? Verder heb je geen create en drop rechten nodig dus die kan je uitzetten.

Maar het lijkt er echt op dat er fout in je beviliging zit want anders zou de hacker er niet bij kunnen. Dus hoe check je de login en wat doe je tegen ongewneste includes etc etc

[FragFrog]

ripexx schreef op zaterdag 09 juli 2005 @ 19:01:
Welk deel van je website heeft echt insert en update rechten nodig? Verder heb je geen create en drop rechten nodig dus die kan je uitzetten.

Maar het lijkt er echt op dat er fout in je beviliging zit want anders zou de hacker er niet bij kunnen. Dus hoe check je de login en wat doe je tegen ongewneste includes etc etc

Update rechten zijn nodig voor een vrij groot gedeelte van de useropties, dingen als moordenaarstatus afkopen (SET CtlCode = NULL), naam wijzigen, etc etc. Het gaat hierbij in totaal om tientallen columns in ongeveer 4 tables.

Ik check alle variabelen (maak nergens gebruik van sessies, dus geen echte logins zoals jij die bedoelt ws) met het script wat in de startpost staat, wat dus alle scripts stopt zodra er iets anders gebruikt wordt dan een letter, nummer of '-' danwel '_'. Ik heb er over gedacht om 'allow_url_fopen' uit te zetten tegen ongewenste externe includes, maar dat levert me wat problemen op met een status-check script zodat ik die liever aan laat staan. Username en password informatie is zoals gezegd opgeslagen in een .htpasswd file, wat AFAIK zou moeten betekenen dat alle externe requests hiernaar geblocked worden.

[kingmuze]

Ik heb zo gauw niets kunnen vinden. Ook je PHPBB is veilig voor zover ik weet. Als je de fout hebt post je hem natuurlijk wel hè

[ripexx]

Blijkbaar zit er toch ergens een bug in je code. Zonder expliciete code kunnen wij er ook niets mee. Welke zaken controleer je en hoe is de beveiliging. Maar met alleen dit verhaal en een regex kan ik niet veel en ik was ook niet van plan om je site volledig te gaan nalopen . Bovendien werkt je site braq in firefox

[kingmuze]

ripexx schreef op zaterdag 09 juli 2005 @ 20:22:
Blijkbaar zit er toch ergens een bug in je code. Zonder expliciete code kunnen wij er ook niets mee. Welke zaken controleer je en hoe is de beveiliging. Maar met alleen dit verhaal en een regex kan ik niet veel en ik was ook niet van plan om je site volledig te gaan nalopen . Bovendien werkt je site braq in firefox

Ja daar kwam ik ook al achter heb al half uur lopen klooien en zoeken, maar in firefox is dat geen pretje. Anyway misschien is het slim als je je code even ergens upload zodat de rest er even naar kan kijken.

[Suepahfly]

Grote kan dat de hacker via Apache / IIS en sql inject je databse aanpast. Deze dingen zijn vaak terug te vinden in de access log. Gaan eens opzoek naar request URI's waar sql inzit

[whoami]

Hoe zien jouw queries eruit ?
Als je jouw dynamische queries opbouwt mbhv string-concatenation, dan is de kans op injection idd reeël.

[André]

Sowieso moet je string-concatenation niet gebruiken, zoek eens op parametrized queries

[ripexx]

André schreef op zaterdag 09 juli 2005 @ 20:44:
Sowieso moet je string-concatenation niet gebruiken, zoek eens op parametrized queries

Klop maar dat staat niet in de gemiddelde tutorial

[FragFrog]

André schreef op zaterdag 09 juli 2005 @ 20:44:
Sowieso moet je string-concatenation niet gebruiken, zoek eens op parametrized queries

Oopsje, dat staat zelfs in de FAQ

Interessant leesmateriaal, alhoewel ene Peter DeBetta ervoor pleit om stored procedures te gebruiken ipv PQ, maar dat is een discussie die ik liever overlaat aan de mensen die er verstand van hebben

De sourcecode van m'n website heb ik hier geupload, ik hoop dat het zaken iets verduidelijkt. Voordat iedere pro hier gaat roepen dat m'n source eruit ziet als gebakken stront: dat weet ik allang Heb nooit een PHP of SQL cursus gevolgd maar gekeken naar wat anderen deden en hun source aangepast en hergebruikt voor nieuwe pagina's totdat er uiteindelijk een werkende site aan hing die er in IE leuk uit ziet. Of zoals Linus' himzelf ooit zei: 'if it compiles and works, its perfect!'

Overigens zijn QP's zo te zien inderdaad een stuk beter om te gebruiken, scheelt me ook die lelijke brute-force SQL injectie checks. Ik zal zeker overwegen dit toe te passen (enige nadeel is dat het om nogal veel variabelen en functies gaat dus een hel zal worden om alles aan te passen), wellicht los ik dan ook gelijk daarmee m'n hacker probleem op

[nescafe]

Suepahfly schreef op zaterdag 09 juli 2005 @ 20:31:
Grote kan dat de hacker via Apache / IIS en sql inject je databse aanpast. Deze dingen zijn vaak terug te vinden in de access log. Gaan eens opzoek naar request URI's waar sql inzit

@TS: Waarom blijf je deze vraag negeren? Ga in ieder geval op zoek naar wat vreemds, vaak dezelfde request o.i.d.
Helaas zul je geen post-data terugvinden, maar wellicht wel een ip-adres en dan weet je ook welk bestand je het in moet zoeken.

[kingmuze]

Ik denk dat de fout niet zozeer zit in dit gedeelte van de site, maar in 1 van de andere sites die worden gehost op dezelfde site.

[FragFrog]

nescafe schreef op zaterdag 09 juli 2005 @ 21:28:
[...]

@TS: Waarom blijf je deze vraag negeren? Ga in ieder geval op zoek naar wat vreemds, vaak dezelfde request o.i.d.
Helaas zul je geen post-data terugvinden, maar wellicht wel een ip-adres en dan weet je ook welk bestand je het in moet zoeken.

Omdat ik zoals gezegd nog niet een goede manier heb gevonden om logfiles te bekijken van een database die active is. Google is hierin niet erg duidelijk helaas, ben nu bezig te zoeken op microsoft.com

Verder vraag ik me af hoeveel nut het heeft om transaction logs te doorzoeken, zelfs al kan ik daaruit het IP halen wat gebruikt is lost dat nog niet het lek op.

Last but not least: de andere websites zijn inderdaad zwaar onderbeveiligt, maar maken dan ook gebruik van een SQL login die totaal geen rechten heeft op de MuOnline database (waar het hier om gaat). Heb ze ondertussen wel offline gehaald

[nescafe]

't gaat niet om de logs van je database (daar zal het ip-adres van je 'hacker' ook niet instaan), maar van je webserver!

[FragFrog]

nescafe schreef op zaterdag 09 juli 2005 @ 21:51:
't gaat niet om de logs van je database (daar zal het ip-adres van je 'hacker' ook niet instaan), maar van je webserver!

D'oh!


Mmm... 40Mb aan acces logs, zal eens zoeken rond het tijdstip dat de hacker vanochtend de table gemaakt heeft

//edit
HEBBES!

Hij maakte gebruik van mijn topplayers.php script met variabelen in de url. Aangezien die nu niet meer toegestaan worden verklaart dat ook waarom m'n database tnt nog veilig is

Bedankt voor de tips iedereen, sorry dat't even duurde voor ik doorhad dat ik in m'n webserver logs moest kijken

[ Voor 38% gewijzigd door FragFrog op 09-07-2005 22:11 ]

[ripexx]

FragFrog schreef op zaterdag 09 juli 2005 @ 21:50:
[...]

Omdat ik zoals gezegd nog niet een goede manier heb gevonden om logfiles te bekijken van een database die active is. Google is hierin niet erg duidelijk helaas, ben nu bezig te zoeken op microsoft.com

Zoeken in books online Maar het gaat in eerste instantie om je webserver logs

Verder vraag ik me af hoeveel nut het heeft om transaction logs te doorzoeken, zelfs al kan ik daaruit het IP halen wat gebruikt is lost dat nog niet het lek op.

IP blocken is water naar de zee brengen. Zorg voor goede beveiliging

Last but not least: de andere websites zijn inderdaad zwaar onderbeveiligt, maar maken dan ook gebruik van een SQL login die totaal geen rechten heeft op de MuOnline database (waar het hier om gaat). Heb ze ondertussen wel offline gehaald

Zorg er altijd voor dat andere nooit bij jouw webroot kunnen, anders kunnen ze gewoon je files uitlezen. Hack je een site is de rest nog beveiligd.

Verder nogmaals mijn verzoek. Post eens wat code zodat we dat kunnen bekijken. En als laatste SP's zijn niet de oplossing. Er is ooit een lange discussie hier op GoT geweest over het gebruik van SP's.

Kijk voor de grap eens naar adodb voor PHP. Een aardig lib waar je eenvoudig parametized queries kan gebruiken.

[FragFrog]

ripexx schreef op zaterdag 09 juli 2005 @ 22:00:
[...]

Zoeken in books online Maar het gaat in eerste instantie om je webserver logs

Zover was ik al ja

IP blocken is water naar de zee brengen. Zorg voor goede beveiliging

Helemaal met je eens. Vandaar ook mijn opmerking, bedoelde het ook als in 'kan nu wel IPs gaan blocken, maar daar schiet ik toch niets mee op zolang het lek blijft'.

Zorg er altijd voor dat andere nooit bij jouw webroot kunnen, anders kunnen ze gewoon je files uitlezen. Hack je een site is de rest nog beveiligd.

AFAIK staat dat wel goed ingesteld in m'n Apache config files, maar het is zeker de moeite waard hier nog even extra aandacht aan te besteden. Will do!

Verder nogmaals mijn verzoek. Post eens wat code zodat we dat kunnen bekijken. En als laatste SP's zijn niet de oplossing. Er is ooit een lange discussie hier op GoT geweest over het gebruik van SP's.

Volledige sourcecode staat zo'n 3 posts hierboven al vermeld

En zoals ik al zei: of SP's al dan niet de oplossing zijn laat ik liever aan experts over. Aangezien er hier in ieder geval 3 van rondlopen die me PQ's aanraden ga ik daar wel voor.

Kijk voor de grap eens naar adodb voor PHP. Een aardig lib waar je eenvoudig parametized queries kan gebruiken.

Bedankt voor de tip, heb adodb al eens vaker horen noemen, zal eens googelen

//edit: voor de volledigheid
Semi-oplossing:
In het bestand c:\windows\php.ini kun je door 'register_globals' uit te zetten (register_globals = off) voorkomen dat iemand een variabele in een URL gebruikt. Als al je invoer variabelen vervolgens gechecked worden door een injectie script (zoals vermeld in de TS) ben je relatief veilig voor SQL injecties.

'Echte' oplossing:
Geen gebruik meer maken van string-concatenation, maar in plaats daarvan parametrized queries. Hoe en wat staat oa in de FAQ alhier.

[ Voor 17% gewijzigd door FragFrog op 09-07-2005 22:16 ]

[whoami]

André schreef op zaterdag 09 juli 2005 @ 20:44:
Sowieso moet je string-concatenation niet gebruiken, zoek eens op parametrized queries

Dat is hetgeen wat ik ook wou zeggen.

Tja, parametrized queries of SP's; da's weer een heel andere discussie. Met parametrized queries bereik je in ieder geval ook iets wat je met SP's kunt bereiken: je laat geen sql injection toe.
Met stored procedures kan je nog een stap verder gaan: je kan alle access op je tabellen verbieden, en ervoor zorgen dat alle toegang tot die tabellen via SP's moet verlopen. Op die manier heb je wel een wat 'gecontroleerde' toegang tot je data, immers, jij schrijft die SP's, dus jij bepaalt wat er kan gebeuren met de data.
Aan de andere kant: een SP is niet altijd even handig, zeker als het om zoek-queries gaat waar je WHERE clauses nogal dynamisch zijn. Als je dat moet gaan doen in een SP, dan ben je, ofwel bezig met alle combinaties te coderen, of ga je in je SP je query dynamisch gaan opbouwen. Het eerste is gewoon onbegonnen werk, het tweede is slecht voor de performance.
SP's zijn dus zeker niet altijd 'de ideale oplossing', of de 'enige echte oplossing'.


In ieder geval, nu je gebruik maakt van parametrized queries, heb je alleszins al een grote stap gezet naar een veiligere site.

[ Voor 73% gewijzigd door whoami op 09-07-2005 23:17 ]

[ripexx]

FragFrog schreef op zaterdag 09 juli 2005 @ 22:10:
Volledige sourcecode staat zo'n 3 posts hierboven al vermeld

En zoals ik al zei: of SP's al dan niet de oplossing zijn laat ik liever aan experts over. Aangezien er hier in ieder geval 3 van rondlopen die me PQ's aanraden ga ik daar wel voor.

Sorry het viel niet echt op

//edit: voor de volledigheid
Semi-oplossing:
In het bestand c:\windows\php.ini kun je door 'register_globals' uit te zetten (register_globals = off) voorkomen dat iemand een variabele in een URL gebruikt. Als al je invoer variabelen vervolgens gechecked worden door een injectie script (zoals vermeld in de TS) ben je relatief veilig voor SQL injecties.

Standaard wordt het tegenwoordig al door PHP uitgezet en je moet het zelf expliciet aanzetten. Dus of je hebt het zelf aangezet of je hebt een hele oude versie van PHP draaien. Iig is beide gevallen niet echt slim

'Echte' oplossing:
Geen gebruik meer maken van string-concatenation, maar in plaats daarvan parametrized queries. Hoe en wat staat oa in de FAQ alhier.

En terecht