SQL Server 2005 Security Breach > Forum

Forum

Unanswered

Active Topics

Forums

Forums > Forums > Algemeen

Subject: SQL Server 2005 Security Breach

Prev Next

You are not authorized to post a reply.

Author

Messages

erik hoeksma User is Offline

Posts:3

19-09-2007 01:24:41	Alert
Een goeienacht allemaal, Om maar bij het begin te beginnen, NEE, ik ben geen SQL server professional, en ik ben OOK geen windows 2003 professional. Wel heb ik een vraag aan de professionals die hier zitten, met de brandende vraag of iemand mij hier informatie over kan verschaffen. (Als ik hier niet thuishoor, dan ben ik daar snel genoeg achter, en bij deze mijn excuses dan maar...) Security breach: Ik heb een aantal windows 2003 servers in het datacenter staan, met daarop SQL server 2005 Enterprise. Feit treft dat 2 van mijn collega's mijn om hulp hebben gevraagd. Ze hosting gameservers op deze servers. Nadat ik door de security en application event-logs van deze jongens heb gekeken kom ik tot de conclusie dat iemand van buitenaf, T-sql queries heeft lopen uitvoeren. Het eventlog laat de volgende entries zien: -------------------------Eerste entry - USER: Administrator ---------------------- Using 'xpstar90.dll' version '2005.90.1399' to execute extended stored procedure 'xp_instance_regread'. This is an informational message only; no user action is required. -------------------------Tweede entry - USER: Administrator ---------------------- Using 'xplog70.dll' version '2005.90.1399' to execute extended stored procedure 'xp_sscanf'. This is an informational message only; no user action is required. -------------------------Derde entry - USER : SYSTEM ---------------------- SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. -------------------------Vierde entry USER : SYSTEM ---------------------- Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install. -------------------------Vijfde entry USER : SYSTEM ---------------------- Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install. -------------------------Zesde entry USER : SYSTEM ---------------------- Configuration option 'xp_cmdshell' changed from 1 to 1. Run the RECONFIGURE statement to install. -------------------------Zevende entry USER : SYSTEM ---------------------- Configuration option 'xp_cmdshell' changed from 0 to 1. Run the RECONFIGURE statement to install. Zoals hier duidelijk wordt, hebben we te maken met iemand die op de een of andere manier de verbinding krijgt met de SQL server om uberhaupt deze stored procedures uit te voeren, en zichzelf vervolgens acccess te geven. Er draait een php+mssql koppeling op deze zelfde server die informatie uit de database haalt met SA + wachtwoord (ik weet het, een webuser zou alles hebben voorkomen). Vervolgens heeft deze inbreker zichzelf toegevoegd aan de 'WMI Rsop Planning Mode Provider', die ze niet hadden geconfigureerd => automatisch administrator rechten kreeg op de server. Vervolgens is er een login aangemaakt, en is de remote desktop terminal open gezet, en heeft deze meneer dood en verderf aangericht op de hardeschijven van mijn maatje. Mijn daadwerkelijke vragen: - Zou dit allemaal te voorkomen zijn geweest als ze een webuser hadden aangemaakt met puur read-write rights, en vervolgens de website met die user te configureren? - Is het slim om xp_cmdshell uit te schakelen , of erger nog - helemaal te verwijderen? - Hoe zijn ze uberhaupt binnengekomen? Via een slecht gescripte php pagina (injectie?), of op een andere manier? - Wat is de beste oplossing voor deze jongens, graag een kleine uitleg. Ik weet dat jullie niet hoeven te reageren, of misschien wel niet willen reageren, maar het is erg pittig om een goed forum te vinden met daarop de mensen die precies weten wat er gebeurd is... Alvast mijn hartelijke dank voor het lezen van deze thread, reacties zouden fantastisch zijn. Mvg, Erik hoeksma

erik hoeksma User is Offline

Posts:3

19-09-2007 01:44:24	Alert
Enkele toevoegingen nog : Natuurlijk zijn de SQL poorten gesloten (1433 1434). De SQL gebruikt een mixed-mode authencation (server files vereisen dit). Verder is het gekke dat dit nu op 2 compleet verschillende servers gebeurd is (x32, windows 2003 & x64 windows 2003 enterprise + SQL x64), met 2 verschillende gameservers, en een verschillende site. Mogelijk hebben ze beiden servers verkeerd (of niet) ingesteld. Het SA password was flink (18 karakters (hoofd)letters, tekens, nummers), en daar zijn ze volgens mij ook niet mee naar binnen gekomen... Als ik iets ben vergeten, laat het me weten... Bedankt, Erik

Hugo Kornelis User is Offline

Posts:46

19-09-2007 14:35:35	Alert
Hoi Erik, >>Zou dit allemaal te voorkomen zijn geweest als ze een webuser hadden aangemaakt met puur read-write rights, en vervolgens de website met die user te configureren?<< Is moeilijk te zeggen. Dat hangt ervan af wat er allemaal moet gebeuren op de server, welke rechten daarvoor nodig zijn, en hoe een en ander gebouwd is. >>- Is het slim om xp_cmdshell uit te schakelen , of erger nog - helemaal te verwijderen?<< Uitzetten: Ja. Daarom is xp_cmdshell ook standaard uitgeschakeld als je SQL Server 2005 installeert. Een DBA moet hem inschakelen vooradt hij gebruikt kan worden. Dit is een optie op server nivo, dus je kunt dat niet per database variëren (helaas). Verwijderen: Nee. Als het goed is lukt het je niet eens als je het probeert. En als het wel lukt, heb je grote kans dat je daar in de toekomst problemen door krijgt. Dit commando proberen te verwijderen is net zoiets als een C compiler in een hexadecimale editor laden om te proberen malloc() uit de taal te verwijderen. >>- Hoe zijn ze uberhaupt binnengekomen? Via een slecht gescripte php pagina (injectie?), of op een andere manier?<< SQL injectie lijkt me de meest waarschijnlijke optie. Dit is overigens niet altijd te wijten aan de php pagina, het probleem kan ook in de SQL zelf zitten (bijvoorbeeld een stored procedure die op basis van gebruikersinvoer dynamisch uitgevoerde SQL maakt zonder de invoer goed te controleren). Er is via Google ontzettend veel informatie over SQL injectie te vinden, maar lees in elk geval http://www.sommarskog.se/dynamic_sql.html. >>- Wat is de beste oplossing voor deze jongens, graag een kleine uitleg.<< Als de oorzaak inderdaad SQL injectie is, dan is de beste oplossing het vermijden van dynamische SQL. Als dat niet kan, gebruik dan in elk geval sp_executesql in plaats van EXEC(). En bouw geen SQL strings op in de front end, maar gebruik geparametriseerde SQL met parameter objecten voor de variabele delen. >>De SQL gebruikt een mixed-mode authencation (server files vereisen dit).<< Het sa account (dat is voor SQL Server wat "Administrator" voor windows is) werd op SQL Server 2000 standaard met een blanco wachtwoord geïnstalleerd. Op SQL Server 2005 is die default gelukkig vervallen, maar volgens mij is het nog steeds mogelijk om een blanco wachtwoord te gebruiken. Of een eenvoudig wachtwoord. Als mixed mode niet uit kan, zorg dan in elk geval dat sa een sterk wachtwoord heeft - minstens 15 tekens lang (liever meer), inclusief hoofdletters, kleine letters, cijfers en speciale tekens. Oh, sorry. Ik zie net dat dit het probleem niet was. Op basis van de informatie durf ik niet echt meer te zeggen dan dit over de mogelijke oorzaken. Voor de toekomst nog wat algemeen advies: * Vermijd dynamische SQL (daarmee bedoel ik zowel EXEC(...) als sp_executesql vanuit SQL Server, en het opbouwen van een query string vanuit de client). * Als het echt niet anders kan, gebruik dan gecontroleerde dynamische SQL - geen user input in de query string, maar doorgegeven als parameters. Dit kan vanuit SQL met sp_executesql; vanuit de client hangt het af van de gebruikte library. * Gebruik in elk geval geen dynamische SQL waarbij tabel- en kolomnamen en zo door de gebruiker kunnen worden opgegeven. Dat is niet met parameters te doen, en dus niet goed te beveiligen. Bovendien is het in 99% van de gevallen een direct gevolg van een verkeerd databaseontwerp. * Gebruik stored procedures. Zorg dat de stored procedures dezelfde eigenaar hebben als de tabellen die je gebruikt. Geef de gebruikers alleen execute permissies op de stored procedures, maar zeker geen rechten op de tabellen. * Geef ook verder de logins en de users alleen de rechten die echt nodig zijn en verder niets. * Verdiep je in de beveiligingsmogelijkheden van SQL Server 2005. Er is op dat terrein heel veel mogelijk geworden dat eerst niet kan. Dit is niet mijn specialiteit, dus ik kan het je niet in een notedop uitleggen - maar ik raad je zeker aan je er in te verdiepen.

Met vriendelijke groeten, Hugo Kornelis (SQL Server MVP)

erik hoeksma User is Offline

Posts:3

19-09-2007 15:16:51	Alert
Hey Hugo, Bedankt voor je uitgebreide reply, ik ga er even goed voor zitten om wat meer info over die 'dynamic SQL' te krijgen. Wat je dus eigenlijk zegt is dat er een 'brakke' stored procedure is , die alle commands klakkeloos uitvoert, zonder te kijken of het ook 'schadelijke' code bevat? Het vreemde is dan wel weer dat we hier praten over 2 compleet verscihllende servers, en 2 compleet verschillende soorten databases (welke echter aangeleverd zijn, niet mee geknoeid dus), op beiden is access verkregen. De enige overeenkomst die beide servers hebben is dat ze een MD5-encoding SP gebruiken voor de registratie van nieuwe accounts... Punt is wel dat beide bakken een goed SA password hadden, en op het tijdstip van de 'hack', een system reinstall is geweest. Vervolgens KAN het zijn dat de firewall niet ingeschakeld was (durf ik niet met zekerheid te zeggen), en dat ze zo verbonden werden met de server, maar aan de andere kant, zonder het SA password, is het toch onmogelijk om queries uit te voeren? Erik

Frank de Vries User is Offline

Posts:3

19-09-2007 21:16:36	Alert
Hallo Erik, Ook ik denk dat SQL Injectie de methode is geweest om je server te kraken. Misschien dat de inhoud van de post wat overlap heeft met die van Hugo, maar je kunt het beter maar twee keer lezen dan helemaal niet. Wat ik niet begrijp is dat de webapplicatie met het SA account inlogd. Dit "standaard" SQL account heeft administrator rechten op de SQL Server. Als SQL Injection is toegepast dan kun je zonder het wachtwoord te weten het wachtwoord wijzigen (op SQL 2000 tenminste, SQL2005 heb ik nog niet uitgeprobeerd). Dit kan door de url te injecteren met exec sp_password NULL, 'pietje puk', 'sa'. Als je ingelogd bent met sa en je kunt xp_cmdshell toepassen in de sql injectie dan kun je afhankelijk van de rechten van het account waarbij de SQL Services (MSSQLServer en SQLServer Agent) draaien een boel ellende uithalen (zeker als deze als domain admin zijn). Zet dus inderdaad xp_cmdshell uit, tenzij het absoluut noodzakelijk is. Mijn eerste advies is dan ook een aparte gebruiker aan te maken met niet meer rechten dan noodzakelijk. Geef alleen db_datareader en alleen indien nodig db_datawriter rechten. Als stored procedures worden gebruikt dan uiteraard execute rechten op deze procedures. Wat je binnen de stored procedures moet doen is de input valideren. Een SQLInjectie "hacker" maakt onder andere gebruik van conversieproblemen. Bijv http://.....asp?id=56 als je nu een string geeft bijvoorbeel http://....asp?@@version en de webserver geeft het volgende terug ergens op de webpage: Msg 245, Level 16, State 1, Line 1 Conversion failed when converting the nvarchar value 'Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86) Mar 23 2007 16:28:52 Copyright (c) 1988-2005 Microsoft CorporationDeveloper Edition on Windows NT 6.0 (Build 6000: )' to data type int. Kortom als je parameter een numerieke waarde controleer dan tenminste of je deze ook krijgt. Een tweede tip hierbij is dat indien er toch een dergelijke melding optreedt dat je deze niet aan de webuser geeft. In bovenstaand voorbeeldje weet de "webuser" meteen waar die aan toe is. @@version was nog maar een heel onschuldig voorbeeldje. Op de volgende link kun je heel wat nuttige informatie vinden om je databases te beschermen tegen dit soort ellende. http://www.appsecinc.com/techdocs/whitepapers/research.shtml Succes met het wederopbouwen en dichttimmeren van de website en je database. Groet, Frank

You are not authorized to post a reply.

Forums > Forums > Algemeen > SQL Server 2005 Security Breach

ActiveForums 3.6