Microsoft: IIS-lek niet oorzaak van grootschalige hackaanval
Het beveiligingslek in Microsoft's Internet Information Services (IIS) is niet de oorzaak van de grootschalige aanval waarin al meer dan 500.000 websites zijn gehackt en voorzien van malware. De kwetsbaarheid werd vorige week door de softwaregigant bekendgemaakt en een paar dagen later begonnen de aanvallen waarbij hackers een kwaadaardig JavaScript injecteerden op websites die op IIS draaien.
Uit onderzoek van Microsoft blijkt nu dat er geen enkel verband tussen de aanvallen en het recent ontdekte lek in IIS is. De oorzaak van de SQL-injectie aanvallen is slordig programmeerwerk en dat is volgens "Trustworthy Computing Response Communications Manager" Bill Sisk via verschillende best practices te verhelpen. In Nederland gaat het om een kleine duizend gehackte sites.
Reacties (18)
26-04-2008, 13:55 door
extranion
nee, dat zou een beetje niet-strategisch zijn om te zeggen
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
26-04-2008, 14:50 door
Nomen Nescio
Door extranion
nee, dat zou een beetje niet-strategisch zijn om te zeggen
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
Nee, dat is dom van die domme programmeur. De schuld bij Microsoft leggen nee, dat zou een beetje niet-strategisch zijn om te zeggen
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
is net zo infantiel als die airbag op de voorruit van een auto. Nog even en het
wegdek moet ook voorzien worden van airbags. Het is veel logischer dat
mensen zich nou eens zelf voor hun eigen fouten verantwoordelijk voelen.
Zoals die fietsers die zich aan geen enkele regel storen en met mobieltje en
MP3-speler gewoon blind in het verkeer rondtoeren.
En dan nog: een kwaadaardig JavaScript? Wie maakt die scripttaal dan? Is
dat niet ene SUN? Dat bedrijf dat geen enkel commentaar duldt? Moet die het
dan Javascript niet veiliger maken?
Door Nomen Nescio
En dan nog: een kwaadaardig JavaScript? Wie maakt die
scripttaal dan? Is
dat niet ene SUN? Dat bedrijf dat geen enkel commentaar
duldt? Moet die het
dan Javascript niet veiliger maken?
En dan nog: een kwaadaardig JavaScript? Wie maakt die
scripttaal dan? Is
dat niet ene SUN? Dat bedrijf dat geen enkel commentaar
duldt? Moet die het
dan Javascript niet veiliger maken?
tzelfde als jij zegt, dat kan niet, dat is de
verantwoordelijkheid van de programmeur om veilige scripts
te maken. als je en scripttal zou maken die super veilig was
en waarmee zelf s de meest domme scripter superveilige
scripts kon maken had die waarschijnlijk ongeveer 3 functies...
Door Nomen Nescio
Microsoft leggen
is net zo infantiel als die airbag op de voorruit van een
auto. Nog even en het
wegdek moet ook voorzien worden van airbags. Het is veel
logischer dat
mensen zich nou eens zelf voor hun eigen fouten
verantwoordelijk voelen.
Zoals die fietsers die zich aan geen enkele regel storen en
met mobieltje en
MP3-speler gewoon blind in het verkeer rondtoeren.
En dan nog: een kwaadaardig JavaScript? Wie maakt die
scripttaal dan? Is
dat niet ene SUN? Dat bedrijf dat geen enkel commentaar
duldt? Moet die het
dan Javascript niet veiliger maken?
Door extranion
nee, dat zou een beetje niet-strategisch zijn om te zeggen
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
Nee, dat is dom van die domme programmeur. De schuld bijnee, dat zou een beetje niet-strategisch zijn om te zeggen
dat het allemaal aan IIS ligt...
Wat mij dan wel opvalt dat apache in dit artikel niet aan de
orde komt en blijkbaar hier ook niet vatbaar voor is...
Is het dan niet dom van microsoft dat ze de code van de
programmeur niet veilig kunnen afhandelen?
Microsoft leggen
is net zo infantiel als die airbag op de voorruit van een
auto. Nog even en het
wegdek moet ook voorzien worden van airbags. Het is veel
logischer dat
mensen zich nou eens zelf voor hun eigen fouten
verantwoordelijk voelen.
Zoals die fietsers die zich aan geen enkele regel storen en
met mobieltje en
MP3-speler gewoon blind in het verkeer rondtoeren.
En dan nog: een kwaadaardig JavaScript? Wie maakt die
scripttaal dan? Is
dat niet ene SUN? Dat bedrijf dat geen enkel commentaar
duldt? Moet die het
dan Javascript niet veiliger maken?
Verwar javascript niet met java. JavaScript is gemaakt door
oa Brendan Eich.
Java is ver door ontwikkeld door Sun Microsystems onder
leiding van onder leiding van James Gosling. Qua syntaxis
heeft het raakvlakken.. Verdere info zie de wikipedia
26-04-2008, 17:50 door
Bitwiper
Door Nomen Nescio
Nee, dat is dom van die domme programmeur. De schuld bij Microsoft leggen is net zo infantiel als die airbag op de voorruit van een auto. Nog even en het wegdek moet ook voorzien worden van airbags.
Euh ik weet nog niet of het hier gaat om een lek in IIS, de combinatie met MS SQL Server, onjuiste voorbeeldcode, framework-bug of gammele web development tools, maar dat 500000 pages draaiend op IIS dezelfde injection vulnerability bevatten lijkt me geen toeval.Nee, dat is dom van die domme programmeur. De schuld bij Microsoft leggen is net zo infantiel als die airbag op de voorruit van een auto. Nog even en het wegdek moet ook voorzien worden van airbags.
En dan nog: een kwaadaardig JavaScript? Wie maakt die scripttaal dan? Is dat niet ene SUN?
Nee. [url=http://en.wikipedia.org/wiki/Javascript]Javascript[/url] is ontwikkeld door [url=http://en.wikipedia.org/wiki/Brendan_Eich]Brendan Eich[/url] toen hij nog bij Netscape werkte, tegenwoordig werkt hij bij Mozilla. De relatie met Sun is dat de scripttaal de naam 'Javascript' gekregen toen Netscape Sun's Java engine in de browser opnam (Javascipt en Java hebben weinig met elkaar te maken).De redactie bedoelt met 'kwaadaardig Javascript' niet dat Javascript zelf kwaadaardig is, maar dat het gebruikt wordt om kwetsbaarheden in webbrowsers uit te buiten, in veel gevallen als springplank (bijv. het starten van een kwetsbare ActiveX control).
Ik ben het er helemaal mee eens met de opmerkingen die gegeven worden,
IIS en microsoft hebben het schijnbaar toch goed voor elkaar en javascript
blijft toch wel vatbaar voor allerlei soorten intrusion.
Ik wil alleen ook maar een keer zeggen, geef microsoft ook eens wat credits.
IIS en microsoft hebben het schijnbaar toch goed voor elkaar en javascript
blijft toch wel vatbaar voor allerlei soorten intrusion.
Ik wil alleen ook maar een keer zeggen, geef microsoft ook eens wat credits.
26-04-2008, 19:27 door
Ronald van den Heetkamp
De SQL query of procedure was gemaakt voor MSSQL, waardoor alleen IIS vatbaar was. Inderdaad door slordig programmeer werk, maar belangrijker is het te weten dat MSSQL 'query stacking' toestaat, oftewel 2 queries tegelijk kan uitvoeren gescheiden middels een ( ; ) en MySQL niet, daarom is IIS een interessante server om aan te vallen, omdat het de kans erg groot maakt.
Typisch weer MS; altijd weer naar een ander wijzen. MS biedt
een platform en ontwikkelaars maken daar gebruik van. Ze
zijn er dus SAMEN verantwoordelijk voor !
een platform en ontwikkelaars maken daar gebruik van. Ze
zijn er dus SAMEN verantwoordelijk voor !
Dit klinkt een beetje als "the plane is not on fire".
De titel had ook kunnen zijn: "Onrust in Zimbabwe niet de oorzaak van
grootschalige hackaanval".
Dat is evenzo niet relevant...
De titel had ook kunnen zijn: "Onrust in Zimbabwe niet de oorzaak van
grootschalige hackaanval".
Dat is evenzo niet relevant...
27-04-2008, 23:30 door
eMilt
@Ronald van den Heetkamp: MySQL is net zo vatbaar voor dit
probleem als MSSQL. Ook bij MySQL kan je meerdere queries
uitvoeren gescheiden door een punt-comma. De statements in
de kwaadaardige javascript code zijn echter geschreven voor
MSSQL en daarom zijn het met name IIS servers en ASP
pagina's waarop dit werkt.
De echte oorzaak van het probleem is natuurlijk slecht
programmeerwerk en een slechte beveiliging / permissies in
de database. SQL injectie is eenvoudig te voorkomen en door
gebruik te maken van stored procedures hoef je geen rechten
te geven op de tabellen zelf en zouden de SQL inserts niet
werken.
probleem als MSSQL. Ook bij MySQL kan je meerdere queries
uitvoeren gescheiden door een punt-comma. De statements in
de kwaadaardige javascript code zijn echter geschreven voor
MSSQL en daarom zijn het met name IIS servers en ASP
pagina's waarop dit werkt.
De echte oorzaak van het probleem is natuurlijk slecht
programmeerwerk en een slechte beveiliging / permissies in
de database. SQL injectie is eenvoudig te voorkomen en door
gebruik te maken van stored procedures hoef je geen rechten
te geven op de tabellen zelf en zouden de SQL inserts niet
werken.
Door eMilt
@Ronald van den Heetkamp: MySQL is net zo vatbaar voor dit
probleem als MSSQL. Ook bij MySQL kan je meerdere queries
uitvoeren gescheiden door een punt-comma.
@Ronald van den Heetkamp: MySQL is net zo vatbaar voor dit
probleem als MSSQL. Ook bij MySQL kan je meerdere queries
uitvoeren gescheiden door een punt-comma.
Klopt, dat kan, maar niet standaard. Daarvoor moet de
programmeur specifiek een 'multi query' commando aanroepen
(in PHP iig.) 99.9% van alle webpagina's zal dit niet
gebruiken, en dus kan je maar beperkt SQL injecteren: je kan
van een SELECT geen DELETE of INSERT maken. Dat kan in MSSQL
wel en is daardoor *veel* gevoeliger voor SQL injection.
Sander
> MySQL is net zo vatbaar voor dit probleem als MSSQL.
Het probleem is dat geinjecteerde SQL gebruikt kan worden om een proces te
starten wat als LocalSystem draait, een privilege-niveau wat _hoger_ is dan
Administrator. En er is op dit moment geen manier bekend om dat vanuit
MySQL te doen. Microsoft heeft dus wel degelijk een serieus probleem aan
z'n
staart hangen, want via IIS en MS SQL is het mogelijk een doos over te
nemen. Dat het probleem zit in de IPC tussen IIS en MS SQL maakt niet uit, het
blijft het probleem van Microsoft.
Het probleem is dat geinjecteerde SQL gebruikt kan worden om een proces te
starten wat als LocalSystem draait, een privilege-niveau wat _hoger_ is dan
Administrator. En er is op dit moment geen manier bekend om dat vanuit
MySQL te doen. Microsoft heeft dus wel degelijk een serieus probleem aan
z'n
staart hangen, want via IIS en MS SQL is het mogelijk een doos over te
nemen. Dat het probleem zit in de IPC tussen IIS en MS SQL maakt niet uit, het
blijft het probleem van Microsoft.
28-04-2008, 12:51 door
spatieman
its not a bug.
it a feature.
it a feature.
28-04-2008, 21:18 door
eMilt
@Anoniem (maandag 28 april 2008 09:28): LocalSystem is een
account wat MINDER rechten heeft dan Administrator. Daarvoor
is het ook precies gemaakt. En je begrijpt natuurlijk dat
het uitvoeren van executables of laden van DLL's door MSSQL
wel erg goed beveiligd is en standaard alleen mogelijk is
voor het SA account. Als je voor je website het SA account
gebruikt dan is het natuurlijk vragen om problemen. Zoals
gezegd komt het gewoon neer op goed programmeerwerk en
zorgen dat je de beveiliging van je applicatie goed inricht
en dan is er niks aan de hand. Ik bouw veel websites met
MSSQL en maak me geen enkele zorgen dat één van die sites
vatbaar is voor deze exploit.
account wat MINDER rechten heeft dan Administrator. Daarvoor
is het ook precies gemaakt. En je begrijpt natuurlijk dat
het uitvoeren van executables of laden van DLL's door MSSQL
wel erg goed beveiligd is en standaard alleen mogelijk is
voor het SA account. Als je voor je website het SA account
gebruikt dan is het natuurlijk vragen om problemen. Zoals
gezegd komt het gewoon neer op goed programmeerwerk en
zorgen dat je de beveiliging van je applicatie goed inricht
en dan is er niks aan de hand. Ik bouw veel websites met
MSSQL en maak me geen enkele zorgen dat één van die sites
vatbaar is voor deze exploit.
28-04-2008, 22:09 door
Bitwiper
Door eMilt
@Anoniem (maandag 28 april 2008 09:28): LocalSystem is een account wat MINDER rechten heeft dan Administrator.
Nou nee. Microsoft [url=http://msdn2.microsoft.com/en-us/library/ms684190(VS.85).aspx]zegt[/url] over LocalSystem: Its token includes the NT AUTHORITYSYSTEM and BUILTINAdministrators SIDs - met andere woorden, het LocalSystem account heeft MEER rechten dan leden van de Administrators groep.@Anoniem (maandag 28 april 2008 09:28): LocalSystem is een account wat MINDER rechten heeft dan Administrator.
[url=http://msdn2.microsoft.com/en-us/library/ms677973(VS.85).aspx]Ook:[/url] One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources en misschien nog wel [url=http://msdn2.microsoft.com/en-us/library/ms191543.aspx]interessanter:[/url]
Security Note:
The Local System account option is provided for backward compatibility only. The Local System account has permissions that SQL Server Agent does not require. Avoid running SQL Server Agent as the Local System account.
29-04-2008, 10:58 door
SirDice
Door eMilt
@Anoniem (maandag 28 april 2008 09:28): LocalSystem is een account wat MINDER rechten heeft dan Administrator.
Om verder nog wat toe te voegen aan wat Bitwiper al opmerkte.. Probeer eens met een Administrator account HKEY_LOCAL_MACHINESAM en SECURITY te openen met regedit.. Probeer het daarna eens met LocalSystem..@Anoniem (maandag 28 april 2008 09:28): LocalSystem is een account wat MINDER rechten heeft dan Administrator.
30-04-2008, 12:28 door
eMilt
@Bitwiper: Da's dan mijn fout. Ik was altijd in de
veronderstelling dat Local System voldoende rechten had voor
het uitvoeren van diverse services maar net niet zo veel
rechten als Administrator waardoor een aantal essentiele
dingen niet mogelijk zijn (bijv. take ownership). Maar niet
dus... (valt me tegen).
Overigens hoef je MSSQL niet onder Local System te draaien.
Je kan bij installatie een account opgeven. Achteraf
wijzigen kan ook, zien:
http://blogs.msdn.com/sqlblog/archive/2006/09/17/how-to-change-the-startup-accounts-for-sql-server-services.aspx
SQL Server Agent is overigens wat anders dan SQL Server.
Maar ik blijf zeggen dat de beveiliging van je webapplicatie
op een heel ander niveau ligt. De beveiliging van je
webapplicatie moet niet afhangen van het account waar SQL
server onder draait.
veronderstelling dat Local System voldoende rechten had voor
het uitvoeren van diverse services maar net niet zo veel
rechten als Administrator waardoor een aantal essentiele
dingen niet mogelijk zijn (bijv. take ownership). Maar niet
dus... (valt me tegen).
Overigens hoef je MSSQL niet onder Local System te draaien.
Je kan bij installatie een account opgeven. Achteraf
wijzigen kan ook, zien:
http://blogs.msdn.com/sqlblog/archive/2006/09/17/how-to-change-the-startup-accounts-for-sql-server-services.aspx
SQL Server Agent is overigens wat anders dan SQL Server.
Maar ik blijf zeggen dat de beveiliging van je webapplicatie
op een heel ander niveau ligt. De beveiliging van je
webapplicatie moet niet afhangen van het account waar SQL
server onder draait.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
