Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Html injection?
28-08-2014, 09:46 door Anoniem, 15 reacties
Beste Folks
We hebben nog een oude website draaien die helaas nog even zal moeten draaien op een Windows 2003 server.
Vandaag hebben we gemerkt dat op de website een via html tag in een formulier een spamcode werd toegevoegd:
</title><style>.at6p{position:absolute;clip:rect(408px,auto,auto,408px);}</style><div class=at6p>one hour <a href=http://betterpaydayloansonline.com >payday loans</a></div></title><style>.aidu{position:absolute;clip:rect(426px,auto,auto,426px);}</style><div class=aidu>easy <a href=http://crazypaydayloansonline.com >payday loans</a> and secure !</div>
De website is een simpele oude asp site.
Ik heb de indruk dat er kan geschreven kan worden in een formulier: html asp injection?
Ik heb toegang tot de server.
De vraag is dan ook, hoe krijg ik dit eruit? Is er een toepassing die dit soort codes kan scannen?
Op de website files vind ik deze code niet terug.
Ik zal ondertussen even verder uitzoeken, maar wellicht kent iemand een snellere oplossing....
Thx
We hebben nog een oude website draaien die helaas nog even zal moeten draaien op een Windows 2003 server.
Vandaag hebben we gemerkt dat op de website een via html tag in een formulier een spamcode werd toegevoegd:
</title><style>.at6p{position:absolute;clip:rect(408px,auto,auto,408px);}</style><div class=at6p>one hour <a href=http://betterpaydayloansonline.com >payday loans</a></div></title><style>.aidu{position:absolute;clip:rect(426px,auto,auto,426px);}</style><div class=aidu>easy <a href=http://crazypaydayloansonline.com >payday loans</a> and secure !</div>
De website is een simpele oude asp site.
Ik heb de indruk dat er kan geschreven kan worden in een formulier: html asp injection?
Ik heb toegang tot de server.
De vraag is dan ook, hoe krijg ik dit eruit? Is er een toepassing die dit soort codes kan scannen?
Op de website files vind ik deze code niet terug.
Ik zal ondertussen even verder uitzoeken, maar wellicht kent iemand een snellere oplossing....
Thx
Reacties (15)
Ziet eruit als normale XSS:
Zie https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
Zie https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
Spambot, ik zou me niet te veel zorgen maken.
Ja daar zijn filters voor, een quick-fix is lastig met zo weinig info. Google?
Maar wie ben ik... ;)
Ja daar zijn filters voor, een quick-fix is lastig met zo weinig info. Google?
Maar wie ben ik... ;)
XSS is via request real time output modificeren. Dus niet de manipulatie vast opslaan op de schijf.
Bijvoorbeeld via een GET of POST verzoek te manipuleren tags/instructies toevoegen aan daaropvolgende html output.
Dus moet je kijken via logs WELKE GET of POST mogelijkheid van je asp applicatie misbruikt wordt.
Dan kun je de asp/vb code aanpassen.
Meestal zijn goede methodes met referrers werken, dat aan user agent verbinden naast alleen op ip controleren.
En ALTIJD, ALTIJD input een maxlength check meegeven alvorens wat dan ook te interpreteren of over te schrijven in de stack bv variabeles. En ALTIJD, ALTIJD, definieren welke karakters wel zijn toegestaan voor interpretatie via je POST of GEt verzoek, AL HET ANDERE gewoon overboord kieperen. Laat zo min mogelijk binary toe.
Dus bijvoorbeeld stel je html output werd via url modificatie via een GET optie gemanipuleerd;
http://host/ap.asp?getvar=sekziform&id=2
dan zou ik eerst de maxlength van alles voorbij ? of zelfs de webroot definieren, dus als dat nergens op je applicatie meer kan zijn dan 20 karakters samen, dus alleen alles onder 20 chars toelaten ALVORENS te interpreteren.
Dan zou ik bij de afzonderlijke waardes bepalen WAT nodig is toe te laten voor interpretatie en de rest niet.
Dus bij getvar slechts text met een eigen maxlength en al het andere niet, ook gebruik van kapitalen kunnen wijzen op externe manipulatie, kan handig zijn dat ook te verbieden als je scrippie geen kapitalen gebruikt.
en bij id dus slechts cijfers en dan niet meer dan 2 of drie. en dat koppelen aan de source ofzo, zodat je kan correleren.
En een proxy voor post verzoeken tussen het web en je database bijvoorbeeld. kan ook methode zijn.
maar je moet dus je afhandeling van GET/POST vars in vbscripts aanpassen, als het dus echt xss is.
oh en pas op met mogelijkheid tot uploaden van bijvoorbeeld plaatjes die later via je cms getoond worden, of binary upstream verkeer, ook gecodeerd via utf-8 of anderszins.
Bijvoorbeeld via een GET of POST verzoek te manipuleren tags/instructies toevoegen aan daaropvolgende html output.
Dus moet je kijken via logs WELKE GET of POST mogelijkheid van je asp applicatie misbruikt wordt.
Dan kun je de asp/vb code aanpassen.
Meestal zijn goede methodes met referrers werken, dat aan user agent verbinden naast alleen op ip controleren.
En ALTIJD, ALTIJD input een maxlength check meegeven alvorens wat dan ook te interpreteren of over te schrijven in de stack bv variabeles. En ALTIJD, ALTIJD, definieren welke karakters wel zijn toegestaan voor interpretatie via je POST of GEt verzoek, AL HET ANDERE gewoon overboord kieperen. Laat zo min mogelijk binary toe.
Dus bijvoorbeeld stel je html output werd via url modificatie via een GET optie gemanipuleerd;
http://host/ap.asp?getvar=sekziform&id=2
dan zou ik eerst de maxlength van alles voorbij ? of zelfs de webroot definieren, dus als dat nergens op je applicatie meer kan zijn dan 20 karakters samen, dus alleen alles onder 20 chars toelaten ALVORENS te interpreteren.
Dan zou ik bij de afzonderlijke waardes bepalen WAT nodig is toe te laten voor interpretatie en de rest niet.
Dus bij getvar slechts text met een eigen maxlength en al het andere niet, ook gebruik van kapitalen kunnen wijzen op externe manipulatie, kan handig zijn dat ook te verbieden als je scrippie geen kapitalen gebruikt.
en bij id dus slechts cijfers en dan niet meer dan 2 of drie. en dat koppelen aan de source ofzo, zodat je kan correleren.
En een proxy voor post verzoeken tussen het web en je database bijvoorbeeld. kan ook methode zijn.
maar je moet dus je afhandeling van GET/POST vars in vbscripts aanpassen, als het dus echt xss is.
oh en pas op met mogelijkheid tot uploaden van bijvoorbeeld plaatjes die later via je cms getoond worden, of binary upstream verkeer, ook gecodeerd via utf-8 of anderszins.
Dat is geen XSS, de server is "gehacked" (gecompromitteerd), vaak gebeurt dit via SQLi (SQL injection).
Je bent overigens niet de enige, Google maar naar "href=http://betterpaydayloansonline.com" (inclusief die aanhalingstekens).
Opvallend is dat ik in de resultaten bovenaan nog geen meldingen zie van hoe dit te verwijderen, dat zou erop kunnen wijzen dat dit een heel nieuwe aanval is. Ik zoek nog even verder...
Aanvulling 13:31: het lijkt te gaan om "SEO Spam" (zie http://en.wikipedia.org/wiki/Spamdexing), bij de paar sites die ik bekeken heb staat vergelijkbare info als genoemd door de TS plain text in de pagina's (doet dus niets, bezoeken van zo'n gecompromitteerde site levert door deze ingevoegde tekst zo te zien geen risico's op, maar de site zelf is natuurlijk wel kwetsbaar voor andere aanvallers):
De bedoeling is kennelijk dat zoekmachines de ingevoegde hostnames een hogere rating geven. Eerder lijken "payday loans" + hostnames vooral op forums te zijn toegevoegd, nu is er duidelijk sprake van een aanval waarbij webservers worden gecompromitteerd. Het feit dat de teksten steeds achter een schijnbaar dynamisch veld tussengevoegd lijken zijn doet me sterk vermoeden dat het hier inderdaad om SQLi gaat. Bijvoorbeeld:
Routebeschrijving: </title> ...
Komende vanuit Amsterdam gaat u ...
Er zijn kennelijk een hele reeks domains voor aangevraagd, ik kom in elk geval de volgende tegen (de punt door : vervangen, ik wil ze niet helpen):
advancedcashin10min:com
betterpaydayloansonline:com
cashadvancejjtso:com
donnpaydayloans:com
lanapaydayloans:com
legitpaydayloansdtmta:com
masikpaydayloans:com
mypaydayloanvfbjq:com
nancypaydayloans:com
paydayloansdirectlendersonlyekgof:com
paydayloansfoyvu:com
paydayloansonline8086:info
paydayloanssandiegobpmac:com
paydayloanyesqctee:com
proofpaydayloans:com,
quickloansforstudents:co:uk
sosspaydayloans:com
voltpaydayloans:com
Je bent overigens niet de enige, Google maar naar "href=http://betterpaydayloansonline.com" (inclusief die aanhalingstekens).
Opvallend is dat ik in de resultaten bovenaan nog geen meldingen zie van hoe dit te verwijderen, dat zou erop kunnen wijzen dat dit een heel nieuwe aanval is. Ik zoek nog even verder...
Aanvulling 13:31: het lijkt te gaan om "SEO Spam" (zie http://en.wikipedia.org/wiki/Spamdexing), bij de paar sites die ik bekeken heb staat vergelijkbare info als genoemd door de TS plain text in de pagina's (doet dus niets, bezoeken van zo'n gecompromitteerde site levert door deze ingevoegde tekst zo te zien geen risico's op, maar de site zelf is natuurlijk wel kwetsbaar voor andere aanvallers):
</title><style>.at6p{position:absolute;clip:rect(408px,auto,auto,408px);}</style><div class=at6p>one hour <a href=http://betterpaydayloansonline.com >payday loans</a></div></title><style>.aidu{position:absolute;clip:rect(426px,auto,auto,426px);}</style><div class=aidu>easy <a href=http://crazypaydayloansonline.com >payday loans</a> and secure !</div>
De bedoeling is kennelijk dat zoekmachines de ingevoegde hostnames een hogere rating geven. Eerder lijken "payday loans" + hostnames vooral op forums te zijn toegevoegd, nu is er duidelijk sprake van een aanval waarbij webservers worden gecompromitteerd. Het feit dat de teksten steeds achter een schijnbaar dynamisch veld tussengevoegd lijken zijn doet me sterk vermoeden dat het hier inderdaad om SQLi gaat. Bijvoorbeeld:
Routebeschrijving: </title> ...
Komende vanuit Amsterdam gaat u ...
Er zijn kennelijk een hele reeks domains voor aangevraagd, ik kom in elk geval de volgende tegen (de punt door : vervangen, ik wil ze niet helpen):
advancedcashin10min:com
betterpaydayloansonline:com
cashadvancejjtso:com
donnpaydayloans:com
lanapaydayloans:com
legitpaydayloansdtmta:com
masikpaydayloans:com
mypaydayloanvfbjq:com
nancypaydayloans:com
paydayloansdirectlendersonlyekgof:com
paydayloansfoyvu:com
paydayloansonline8086:info
paydayloanssandiegobpmac:com
paydayloanyesqctee:com
proofpaydayloans:com,
quickloansforstudents:co:uk
sosspaydayloans:com
voltpaydayloans:com
Je moet simpelweg HTML in de input eruit filteren of gewoon helemaal niet verwerken (opdracht niet verder uitvoeren).
Sowieso moet je geen HTML content laten plaatsen op de web site.
Sowieso moet je geen HTML content laten plaatsen op de web site.
29-08-2014, 08:58 door
Erik van Straten
Deze pagina vond ik gisteravond: http://blog.sucuri.net/2013/11/the-story-of-cliprect-a-black-hat-seo-trick.html. Hier wordt het probleem van de TS met veel details in beschreven, o.a. de reden om met </title> te beginnen en het doel van clip:rect.
Onderaan de pagina vind je een stel tips hoe je geslaagde aanvallen detecteert en kunt helpen voorkomen. Het beste is natuurlijk om het probleem bij de bron aan te pakken, zeer waarschijnlijk gaat het bij de recente aanvallen om SQL injection, zie https://www.owasp.org/index.php/SQL_Injection en https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
Onderaan de pagina vind je een stel tips hoe je geslaagde aanvallen detecteert en kunt helpen voorkomen. Het beste is natuurlijk om het probleem bij de bron aan te pakken, zeer waarschijnlijk gaat het bij de recente aanvallen om SQL injection, zie https://www.owasp.org/index.php/SQL_Injection en https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
01-09-2014, 21:34 door
Vandy
En standaard aan links laten toevoegen "rel=nofollow"; dan heeft de spammer, zelfs al geraakt de link door het filter, in ieder geval geen positieve PageRank-effecten van zijn actie.
07-09-2014, 11:07 door
iAm
@Erik van Straten
Misschien niet verkeerd om Google even te tippen op deze sites via https://www.google.com/webmasters/tools/spamreportform?hl=en
Misschien niet verkeerd om Google even te tippen op deze sites via https://www.google.com/webmasters/tools/spamreportform?hl=en
Door iAmWill: @Erik van Straten
Misschien niet verkeerd om Google even te tippen op deze sites via https://www.google.com/webmasters/tools/spamreportform?hl=en
Dat doe ik niet om meerdere redenen. Dat SEO spammers betere zoekresultaten realiseren interesseert mij nauwelijks. Het probleem waar ik mij grote zorgen over maak is dat zo ontzettend veel servers lek zijn, en dat los je niet op door Google te informeren over SEO spam.Misschien niet verkeerd om Google even te tippen op deze sites via https://www.google.com/webmasters/tools/spamreportform?hl=en
En waarom zou ik dit wel bij Google en niet bij Bing melden? Welke zoekmachines zijn er nog meer?
De tijd die ik in dit soort zaken wil en kan stoppen, is beperkt. In een andere "zaak" probeer ik beheerders van lekke servers met zeer vertrouwelijke informatie te bereiken; in de meeste gevallen is dat tijdrovend tot compleet onmogelijk (deze ervaring heb ik al heel lang, en niet alleen ik heb dat). Dat terwijl ik daarbij ook nog eens het risico loop dat die beheerders (of baas/marketing-collega's in het betreffende bedrijf) boodschappers met aanvallers verwarren.
Door dit soort zaken te onderzoeken heb ik zelf, denk ik, een redelijk beeld van de grootte van het probleem (en te begrijpen wat de oorzaken zijn). Door dat op sites als security.nl te delen hoop ik dat security-aware bezoekers van dit soort sites hun kennis uitdragen bij minder aware collega's en zo te helpen dit probleem aan te pakken. Bovendien kunnen eigenaren van lekke sites zich er dan later niet op beroepen dat onbekend was dat deze problemen spelen.
Ten slotte heb ik even op jouw link geklikt om te kijken welke gegevens ik dan aan Google zou moeten verstrekken (de lekke servers of de domainnames van de SEO spammers). Het begon er echter al mee dat ik mij moest aanmelden met "mijn" Google account. En zelfs al zou ik dat hebben, dat vind ik dit (gezien mijn andere ervaringen) een belachelijke barrière om misstanden te kunnen melden.
Maar als jij het belangrijk vindt dat dit aan Google gemeld wordt, be my guest!
Als het goed is staat er tussen die webserver en het internet een firewall. Een moderne L7 firewall kan dit verkeer naar oude slecht beveiligde webservers tegenhouden.
Ook zou je de webserver kunnen "publiceren" met een reverse proxyserver. Die reverse proxy kan ook filteren op html injections.
Ook zou je de webserver kunnen "publiceren" met een reverse proxyserver. Die reverse proxy kan ook filteren op html injections.
Door Anoniem: Als het goed is staat er tussen die webserver en het internet een firewall. Een moderne L7 firewall kan dit verkeer naar oude slecht beveiligde webservers tegenhouden.
Ook zou je de webserver kunnen "publiceren" met een reverse proxyserver. Die reverse proxy kan ook filteren op html injections.
Ook zou je de webserver kunnen "publiceren" met een reverse proxyserver. Die reverse proxy kan ook filteren op html injections.
Oeh, ontzettend fout! Fix gewoon het originele probleem aan de basis. Meerlaagse beveiliging is overigens prima, maar je mag er niet zomaar van uitgaan dat een firewall het wel even oplost.
08-09-2014, 08:47 door
iAm
Door Erik van Straten:
Het probleem waar ik mij grote zorgen over maak is dat zo ontzettend veel servers lek zijn, en dat los je niet op door Google te informeren over SEO spam.
Het probleem waar ik mij grote zorgen over maak is dat zo ontzettend veel servers lek zijn, en dat los je niet op door Google te informeren over SEO spam.
Misschien inderdaad in dit geval niet zo heel nuttig om meer dan alleen SEO-spam te voorkomen.
Als het echter een site is waar je andere content zou verwachten is het vaak wel de moeite waard.
De kans dat een webmaster bij Google een account heeft voor zijn site is groot. Indien dat het geval is wordt de webmaster hier meteen over geïnformeerd (anoniem [irriteer mezelf ook aan dat ik wel moet inloggen om het te melden]).
Ook websites die linken aan die site kunnen die waarschuwing wel eens krijgen (dus jijzelf ook als je je site in Google webmaster tools heb hangen).
Daarnaast wordt de lijst die google bijhoud in veruit de meeste browsers ook gebruikt om het verkeer naar die websites te stoppen (met een waarschuwing voor de gebruiker). Helaas nog niet ook die van Bing, DuckDuckGo, Yahoo of Yandex (Symantec). Toch weer aardig indien de site nog wat meer rommel blijkt te serveren dan je had verwacht (malware).
Om even terug te komen op dit topic, kan dit met stored procedures opgelost worden in de code?
16-09-2014, 17:03 door
Erik van Straten
Door Anoniem: Om even terug te komen op dit topic, kan dit met stored procedures opgelost worden in de code?
https://www.security.nl/posting/400031/#posting400156
Nee, je moet de crappy code eruit halen, server herinstalleren
:>Ik heb toegang tot de server.
Iedereen heeft toegang tot de server.
Hopelijk komen er nog andere bots langs, die je server omtoveren tot een SPAM/Zombie bot
leer je het wel af nadat je er achter bent gekomen dat je server gehacked is dit niet serieus op te lossen.
:>Ik heb toegang tot de server.
Iedereen heeft toegang tot de server.
Hopelijk komen er nog andere bots langs, die je server omtoveren tot een SPAM/Zombie bot
leer je het wel af nadat je er achter bent gekomen dat je server gehacked is dit niet serieus op te lossen.
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.
