IT-säkerhet enligt HPS

Totalt gäller Adobes återkallning fyra av tillverkarens programvaror. Anledningarna är en rad fel som kan innebära säkerhetsrisker, skriver Dagens Industri.

Programvarorna började återkallas i måndags. Adobe och samriskbolaget meddelar på sin hemsida att man återkallar totalt 18 848 installationer.

Totalt gäller det säkerhetsbrister i fyra av tillverkarens program:

- Adobe Flash 10.1.102.63 kontrollerar inte längden på indata från...

...nä, inte riktigt. Det handlar egentligen om säkerhetsrisker i några av Volvos bilar. Artikeln från DagensPS.se heter Säkerhetsrisker i Volvo - återkallar 4 bilmodeller. Tänk om det hade varit likadant i vår bransch?

--
Stefan Pettersson

Metro rapporterade i förra veckan om en våg av bilstölder på Arlandas långtidsparkering. Inget konstigt kan man tänka men faktum är att moderna bilar i regel är väldigt svåra att stjäla. Det är inte samma sak som att sno en Volvo 240 när allt du behöver är en rejäl skruvmejsel och avsaknad av respekt för andras egendom.

Moderna bilar har förstås larm, är skyddade mot slim-jims, har rattlås och en startmotor som bara går igång om en radiosändare på bilnyckeln svarar på challenge-response- eller engångskod-liknande. För det första så tros detta ha lett till en ökning i carjackings (hittar ingen bra källa till det just nu men det är ett sunt antagande). För det andra, och framförallt, så kan man dra slutsatsen att Arlanda-tjuvarnas bravader är rejält high-tech.

Det här är inte samma sak som att säga att det är svårt att genomföra själva stölderna. Man kan se framför sig att det fungerar precis som med t ex exploits, rootkits eller bottar idag; smart person utvecklar svart låda som kan öppna bilar av märket BMW X6 från 2010, säljer den till personer som saknar respekt för andras egendom, dessa stjäl sedan bilar från Arlanda.

På senaste upplagan av IEEE Security and Privacy Symposium handlade ett av bidragen om något relaterat; Experimental Security Analysis of a Modern Automobile (pdf). Fascinerande läsning. Notera att en av författarna, även om han är sist på listan, Tadayoshi Kohno, också är författare till den synnerligen bra boken Cryptography Engineering.

Liknande material om bilars stöldsäkerhet sett från digitalt perspektiv har dykt upp tidigare men det här är, mig veterligen, första gången det dyker upp i ett såpass respekterat forum som IEEE Security and Privacy.

--
Stefan Pettersson

Brian Krebs har skrivit ett bra inlägg i buggräknardebatten (om det finns en sådan), Why Counting Flaws is Flawed. Budskapet är att antalet säkerhetshål eller patchar inte är en bra metod för att mäta säkerhet. Jag har skrivit raljerat om det tidigare och har i stort precis samma åsikt som Krebs:

It’s a bit like trying gauge the relative quality of different Swiss cheese brands by comparing the number of holes in each: The result offers almost no insight into the quality and integrity of the overall product, and in all likelihood leads to erroneous and — even humorous — conclusions.

Krebs drar även samma slutsats som jag; frågan "hur många buggar?" föder bara fler frågor:

• Was the vulnerability discovered in-house — or was the vendor first alerted to the flaw by external researchers (or attackers)?
• How long after being initially notified or discovering the flaw did it take each vendor to fix the problem?
• Which products had the broadest window of vulnerability, from notification to patch?
• How many of the vulnerabilities were exploitable using code that was publicly available at the time the vendor patched the problem?
• How many of the vulnerabilities were being actively exploited at the time the vendor issued a patch?
• Which vendors make use of auto-update capabilities? For those vendors that include auto-update capabilities, how long does it take “n” percentage of customers to be updated to the latest, patched version?

Trevlig helg!

--
Stefan Pettersson

Det rätt så anrika Jerringpriset ska delas ut snart. Priset ska gå till årets bästa, svenska idrottsprestation. Jag hörde om det på radio i morse och radioprataren annonserade glatt "Det inte är någon jury som avgör utan det är ni där hemma! Surfa in på ... och klicka på din kandidat!".

Woah... Webbomröstningar på Internet är ju inte särskilt pålitliga. Det är ju en sak om Aftonbladet undrar hur stor andel av deras läsare som vill att person p ska röstas ut från såpa s men Jerringpriset väl är en helt annan.

Som tur var visade det sig att jag tolkade situationen lite för fort. Det handlar inte om att rösta om vem som ska vinna utan att egentligen om vilka som inte ska vinna; de fem kandidater som får färst röster åker ut. Det här betyder att "valfusk" á la automatiserad röstning inte har lika stor effekt.

Det är med andra ord ett perfekt exempel på att inte göra ett angrepp mindre troligt utan mindre meningsfullt. Man har därmed sänkt risken, inte genom att göra en attack svårare utan genom att minska konsekvensen av den. Risk defineras ju i regel som produkten av sannolikhet och konsekvens, båda kan minskas för att minska produkten.

I like it.

Sidenote: För skojs skull skickade jag en fråga till QuestBack (som sköter omröstningen) om vad de gör för att förhindra fusk. Vi får se om det kommer något svar. CAPTCHA känns ju som en naturlig början. Den här nedan t ex. :-)

--
Stefan Pettersson

Nu kanske ni undrar varför det är en bild på spionen Stig Bergling här ovanför. Jag vill bara göra er uppmärksamma på att SÄPO regelbundet informerar om industri- och företagsspionage i diverse publikationer på sin webbsida. Nyttig läsning. (Avdelningen för Know-Your-History™ rekommenderar även Tore Forsbergs böcker och Boris Grigorjevs sommarprogram.)

In related news så gick BitDefender idag ut i ett pressmeddelande med att de hittat ett program som gömmer sig på datorer och slussar ut diverse dokument från densamma:

The fact that it looks for all that it is linked to archives, e-mails (.eml, .dbx), address books (.wab), database and documents (.doc, .odt, .pdf etc) makes Trojan.Spy.YEK a prime suspect of corporate espionage as it seems to target the private data of the companies.

Knäryckreaktionen mot sånt här brukar bestå av antivirus-program och, nuförtiden, "data loss/leakage prevention". Jag är osäker på att det är vägen att gå och ber att få återkomma om det.

--
Stefan Pettersson

Apropå att inte kasta teknik, att öva tycker jag är bra. PTS (och Sitic) deltog i den europeiska övningen Cyber Europe 2010 igår, det hela råddades av Enisa:

The main objective of the exercise is to bring the Member States together and enhance the Member States’  communication and coordination efforts during a crisis. The exercise will test Member States’ abilities  to  find  the  right contacts and assess the competences in the other Member States during a large scale crisis.

Övningen är huvudsakligen intriktad på att testa kommunikation och kommunikationsvägar så den är inte särskilt säkerhetstekniskt inriktad. Detta förtar dock inte de generella fördelarna med en övning:

Exercises are an important mechanism to assess preparedness measures against cyber threats, natural disasters, and technology failures. They enable authorities to target specific weaknesses and increase cooperation among relevant stakeholders. Exercises identify interdependencies, stimulate continuity planning, train and educate people.

En officiell rapport kommer i början av nästa år, förhoppningsvis släpper PTS/Sitic egna lessons-learned också.

Trevlig helg!

--
Stefan Pettersson

I en artikel från CIO intervjuas Shane Sims, säkerhetsexpert på PricewaterhouseCoopers om sin syn på företags säkerhetsarbete. Centralt i budskapet verkar vara att inte lägga så stor tillit på tekniska lösningar. (Efter detta budskap väljer journalisten, underligt nog, att fråga hur en teknisk lösning kan se ut.)

Sims ger två rekommendationer; (1) var förberedd på intrång och (2) leta proaktivt efter intrång. Det här är väl inte särskilt förvånande då man kan anta att han historiskt mest har varit inblandad after-the-fact. Sims har nämligen arbetat för FBI i elva år.

Det är dock skönt att se IDG-pressen ge utrymme åt någon med den här inställningen. Prevention eventually fails är en uppfattning som måste få större spridning. Sims två punkter behöver förstås brytas ner, till en början skulle jag dela upp första punkten i (1) ha kontroll på dina nätverk och (2) förbered vad du ska göra om du (eller någon annan) upptäcker ett intrång.

I ämnet "leta proaktivt efter intrång" har Bejtlich skrivit ett klarsynt inlägg om att välja vad man ska undersöka när man inte kan undersöka allt: What do you investigate first?

--
Stefan Pettersson

Adobe har gått ut med hur de ska fixa problemen med Adobe Reader. Det är en ganska komplicerad historia med sandboxing av renderingsfunktionen och sånt. Dessutom är det en hel del kod som ska skrivas om (försvarligt beslut med tanke på kodens historia).

My two pennies worth; om du har ett program som du använder jätteofta för att lösa väldigt begränsade uppgifter – I det här fallet Adobe Reader för att titta på vanliga PDF-filer du har hämtat från Internet – utnyttja detta faktum och lämna de flashiga funktionerna därhän. Anamma den gamla UNIX-filosofin med att göra en sak och att göra det bra.

Inbäddade objekt, hyperlänkar, Javascript, kryptering, kopieringsskydd, åtkomst till filsystem/register o s v, allt det där används i princip aldrig av majoriteten av deras användare. Jag är säker på att det skulle vara mer värt (säkerhetsmässigt, se nedan) att lansera Adobe Reader Light, en simpel PDF-läsare, än att ta fram utstuderade säkerhetslösningar.

...men, självklart har Adobe goda ekonomiska incitament att stödja många avancerade funktioner i sin gratisläsare. Annars skulle de aldrig kunna sälja sina betal-program som kan implementera dessa funktioner i PDF-dokument.

--
Stefan Pettersson

I datorspel online är det så gott som alltid förbjudet att använda bottar för att sköta spelet. Bottar är autonoma program spelar spelet åt dig och gör det som datorprogram är bäst på; löser uppgifter som är tråkiga och repetitiva eller uppgifter som kräver snabb reaktionsförmåga och exakthet. Under mitten och slutet av 90-talet fanns aimbots till Doom och Quake, dessa följde sedan med till Counterstrike och andra spel som blivit än mer tävlingsinriktade. Se ett bra exempel på Youtube. Diablo, och senare, World of Warcraft har också haft problem med bottar som outtröttligt letar efter guld eller eftertraktade svärd och andra prylar. Bottar ger dig också fördelen med parallelisering då en person kan "sköta om" flera bottar samtidigt.

Synen på bottar
Det är allmänt accepterat att det är fult att använda sig av bottar, det har utvecklats flera system som t ex Warden och PunkBuster för att stävja fuskandet. Resultatet är den gamla vanliga kapprustningen med bot-program som försöker komma runt dessa o s v. Det kom till och med en (enligt utsago) riktigt bra bok i ämnet för två-tre år sen; Exploiting Online Games av Gary McGraw och Greg Hoglund.

Guess what! Till skillnad från vad man kan tro har världens börser inga problem med botprogramvaror som sköter trading och kan utnyttja fördelarna med konstant uppmärksamhet, outtröttlighet och blixtsnabba reaktioner...

De är nämligen tillåtna. Det kallas dock algorithmic trading (och intressant nog robo trading). Till råga på allt verkar det anses ganska okontroversiellt. Själv gissade jag att det knorrades lite över dessa.

Sårbarheter i algoritmerna
I helgen visade det sig att två norrmän står åtalade för olaga kurspåverkan efter att ha hittat och utnyttjat svagheter i en börsbot som körs av den amerikanska mäklaren Interactive Brokers Groups dotterbolag Timber Hill:

Larsen och Veiby köpte först en större post aktier i ett av företagen. Därefter köpte de och sålde ytterligare småposter. När Timber Hill tolkade det som att efterfrågan på aktien stigit satte det upp kursen på aktien. Då sålde de två sitt ursprungliga aktieinnehav med förtjänst.

Själva hävdar de att de bara var smartare än sin motståndare, börsbotten. Skulle det vara olagligt att med samma medel lura människor?

Oinformerade tankar
Spontant undrar jag om inte två olika börsbottar kan hamna i tillstånd där de reagerar på varandras beslut. Då kan man tänka sig att det är svårt att hinna med som vanlig, seg människa.

The system goes on-line August 4th, 1997. Human decisions are removed from strategic defense. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug.

Scary isn't it? :-)

Uppdatering 10:02: Ser man på; Handlarbugg sänkte världens börser.

--
Stefan Pettersson

Ett företag ska utveckla ett system som erbjuder en tjänst till sina kunder. Tjänsten är att en kund ska kunna lagra sina känsliga data i systemet utan att någon annan än kunden själv kommer åt den. Inte ens företaget som tillhandahåller tjänsten ska komma åt det. Här handlar det inte om att göra det krångligt eller bökigt för företaget att läsa kundens data -- det ska vara omöjligt.

"Kryptering! Kunden har nyckeln och företaget bara krypterade data!", tänker du säkert.

...det finns dock ett problem, gränssnittet mot kunden måste vara via en webbläsare (föga oväntat) och någon separat klient (eller Java-applet) duger inte. För att kunna dekryptera data måste alltså antingen (1) användaren skicka nyckeln till servern så att denna kan dekryptera och sedan skicka det till användaren eller (2) dekrypteringen skötas på klientsidan med till exempel Javascript.

I både (1) och (2) kan systemadministratören komma åt kundens data. I första fallet handlar det helt enkelt om att plocka det mellan att det hämtas och dekrypteras från databasen och att det skickas till krypteringsalgoritmen i TLS. (Det kanske räcker med att sätta DEBUGLEVEL=9 i applikationsservern.) I det andra fallet kan systemadministratören manipulera den (Javscript-)kod som användaren ska använda för att läsa sina data.

Om man ska designa ett system där man inte vill behöva lita på sin systemadministratör (p g a outsourcing till exempel) så har man svåra problem att lösa. Vojne, vojne...

--
Stefan Pettersson

Inlägget Säkerheten i tunnelbanans spärrar har hittills varit det mest populära på den här bloggen (besökantalet var omkring 20 gånger högre just den dagen...). Nu har ämnet avhandlats i media ännu en gång, närmare bestämt i City från 2010-08-26 (PDF finns att ladda ner) under rubriken "Det är lättare att planka än någonsin".

Artikeln handlar förstås om SL:s 25-miljonerssatsning på de höga glasspärrarna; Christian Tengblad från planka.nu säger att glasspärrarna har gjort det enklare att planka än tidigare. SL:s ordförande Christer G Wennerholm håller inte med utan har uppfattningen att "det är mycket svårare att planka med de nya dörrarna, eftersom man inte kan hoppa över dem, som med de gamla".

Nonsens, det finns inget ett-till-ett-förhållande mellan att hoppa över och att planka, det går uppenbarligen utmärkt att planka utan att hoppa över. Det är inte överhoppandet SL vill stoppa det är plankningen. Man måste ta av sig toalettpappersrulleglasögonen om man ska försöka hindra någon från att göra något. Man måste se till hela systemet annars blir det lätt "företaget är säkert för man kan inte längre använda SQL injection på den och den applikationen". Nonsens!

For the record, vad jag skrev om glasspärrarna i första inlägget från i våras:

Glasspärrarna är förstås inte immuna mot att hoppas över men det är nog tillräckligt bökigt för att vara tillräckligt avskräckande. Dessutom, om sensorerna på insidan bryts så att dörrarna öppnas kommer ett larm att tjuta om spärren passeras i fel riktning. (T ex om du släpper ner Metro på andra sidan så att fotocellerna bryts på insidan men passerar in från utsidan.) Detta larm är dock tillräckligt vanligt för att lida av samma problem som billarm har gjort i många år. Att larmet inte har någon egentlig effekt gör att tailgating är en genomförbar attack eftersom larmet ljuder även då. Så har dock inte alltid varit fallet, från början stängdes glasdörrarna fortare för att förhindra just tailgating. Detta ledde dock till att folk hamnade i kläm och tidsluckan fick därför ökas så att attacken möjliggjordes.

Om man kan stå ut med pinsamheten i att larmet ljuder alternativt att gå väldigt nära andra resenärer som precis har dragit kortet är man hemma.

--
Stefan Pettersson

"DLL hijacking" har verkligen tagit skruv. Det formligen sprutar exploits mot diverse programvaror. Sedan i tisdags har det dykt upp ett 50-tal på www.exploit-db.com. Jag vet inte om jag har sett något liknande förut.

Om du inte någon uppfattning om vad DLL hijacking är, börja med F-secures blogginlägg, läs sedan HD Moores första post i ämnet. Följ upp med hans första och andra bloggpost på Metasploit-bloggen.

Problem med kod exekveras från fel sökväg är ju inget nytt, men det är ack så lätt att trilla dit.

$ echo $PATH
.:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

--
Stefan Pettersson

Idag var en av de där läskiga dagarna när man jobbar på drift, disaster recovery-övningar. Idag provade vi hur de viktiga servrarna klarade av ett plötsligt strömavbrott. Oavsett hur bra koll man (tror att man) har på hur tjänsterna på en server fungerar är det rätt nervöst att dra ut sladdarna när den är uppe i nästan två hundra dagar uptime... Naturligtvis gick det inte som planerat (det gör det aldrig):

• 07:00-08:00 klipp strömmen till servrar, håll tummar
• 08:00-10:00 få tjänster att fungera igen innan någon märker något, tandgnisslan
• 10:00-12:00 lura ut hur man undviker problemen nästa gång, ljus i tunneln
• 12:00-18:00 ändra configs och uppdatera dokumentation, lite bättre än igår

Drift
Server- och nätverksdrift är relativt osexigt, vissa kallar det till och med "förvaltning" för att göra det ännu värre. Jag skulle dock argumentera för att det är under driftfasen som säkerhetsarbetet har störst betydelse. Tyvärr har det blivit modernt att, nästan uteslutande, problematisera applikationsutvecklingen och säga att det är där slagen kan vinnas i framtiden. Undertecknad inkluderad. Vi har nog rätt. På sikt. Men inte riktigt än.

Men egentligen är det ganska enkelt. Brandväggar, patchar, långa lösenord, övervakning, åtkomstkontroll, logghantering och alla andra grejer är det som håller oss flytande medan vi fortfarande lever med dåligt utvecklade system. Det är inte utvecklare som håller våra nätverk säkra. Inte än. Det är fortfarande driften som kan bära största vikten.

(Med reservation för dålig drift... naturligtvis.)

--
Stefan Pettersson

I mer eller mindre alla system som utvecklas nuförtiden ingår en databas. När säkerhet sedan kommer på tal i samband med utvecklingen kommer ofta också frågan; "borde vi kryptera databasen?". Svaret är (kanske som vanligt) att det beror på... Vem är det du skyddar dig emot och vad menar du egentligen med att "kryptera databasen"? Min uppfattning är att databaser lagrar data, vad innehållet är (utöver datatyp) ska vara egalt och är none of databasens business. På uppmaningen "ge mig kolumn k för de rader där kolumn l är lika med n" ska databasen bara returnera cellens värde, inte oroa sig över innehållet. Krypteringen av innehållet borde alltså skötas av den som förstår det, i vårt fall applikationen som lagrar data i databasen. Databasen själv ska inte ha något med krypteringen att göra.

Bruce Schneier publicerade häromdagen en gammal artikel rörande kryptering av kommunikation v. kryptering av lagrad data som är relevant i sammanhanget:

Cryptography was invented to protect communications: data in motion. This is how cryptography was used throughout most of history, and this is how the militaries of the world developed the science. Alice was the sender, Bob the receiver, and Eve the eavesdropper. Even when cryptography was used to protect stored data -- data at rest -- it was viewed as a form of communication. In "Applied Cryptography," I described encrypting stored data in this way: "a stored message is a way for someone to communicate with himself through time." Data storage was just a subset of data communication.

Historically, the reason key management worked for stored data was that the key could be stored in a secure location: the human brain. [...] In a sense, the keys were stored in a "computer" that was not attached to any network. And there they were safe. [...] This whole model falls apart on the Internet. [...] Keys can no longer be stored in people's brains. They need to be stored on the same computer, or at least the network, that the data resides on. And that is much riskier.

Argumentet är alltså att det är meningslöst att kryptera databasen eftersom nyckeln ändå måste finnas på datorn ifråga. Jag tycker att det här är en för stor förenkling av situationen, man kan enkelt tänka sig en situation där en applikation måste lagra känsliga data i en databas där man inte har kontroll över databasen. Databasen kan skötas av någon DBA du inte litar på eller den kanske delas av applikationer som är sårbara för t ex SQL injection.

 

Men, om du krypterar data i applikationslagret innan du lämnar över det till databasen så behöver du inte lita på att den kan hålla dem hemliga. Dock så kvarstår Bruces poäng; om någon får tillgång till applikationslagret så är spelet tyvärr slut. Men så hade det ju varit om du låtit bli att kryptera också plus att databasen utgör en sårbarhet.

--

Stefan Pettersson

Disciplin (från latinets disciplina - uppfostran, handledning, som i sin tur kommer från discipulus - lärjunge, elev). Uppfattas som synonymt med upprätthållande av ordning och regelföljande. [...] En disciplinerad person uppfyller sina åtaganden och handlar i enlighet med sin föreställning om vad som är bäst att göra, även då ett sådant handlande medför ett obehag på kort sikt.

Ovanstående är kopierat från Wikipedia och fångar väl vad disciplin innebär för mig. Vi börjar med lite deduktion (med reservation för osanna premisser):

1. En disciplinerad person uppfyller sina åtaganden.
2. En person som uppfyller sina åtaganden kan man lita på.
3. Man kan lita på en disciplinerad person.

Många associerar disciplin med officerare, gärna i ridstövlar, som skriker åt soldater att fickorna ska vara knäppta. Det är ju förstås inte fel, fickorna ska vara stängda av en anledning. Även om det är jobbigt att behöva öppna och stänga dem varje gång man ska plocka upp eller ner något så måste det göras, annars riskerar man tappa fickans innehåll. Att öppna och stänga fickan är ett "obehag på kort sikt".

Journalisters syn på säkerhet
Ofta när säkerhetsexperter blir intervjuade avslutas intervjun med en fråga i stil med "Kan du nämna ett par enkla steg för ett företag att öka säkerheten?". Sådana frågor är lite förolämpande och ger mig lust att fråga journalisten efter ett par enkla steg för att bygga upp och driva en framgångsrik tidningsredaktion.

De (få) gånger jag ställts inför frågan har jag svarat att ordning och reda är grunden för att kunna öka säkerhetsnivån. Några "enkla steg" som fungerar finns inte. Om du har ordning och reda; vet vilka servrar som finns, vilka tjänster som kör på dessa, vad de används till, vilka som använder dem, när de används, varifrån o s v så har du förutsättningarna för att bestämma vad som får och inte får ske.

Disciplin passar bra in i resonemanget. Det krävs disciplin för att hålla säkerhetsnivån:

• Att byta ut MySQL-root-lösenordet från "demo1234" till något bättre när testsystemet blir produktionssystem.
• Att dokumentera vilken nätverkstrafik som är väntad till och från servern så att brandväggen konfigureras korret.
• Att stänga av och avinstallera den där IMAP-servern som installeras automatiskt med operativsystemet men inte används, trots att den ändå "är bakom en brandvägg".
• Att använda sudo för att genomföra åtgärder som root istället för su så att man får någon form av spårbarhet.
• Att kontrollera den publika nyckeln första gången man loggar in mot en SSH-server.
• Att skriva rutiner i backupscriptet så att den säger till när en backup misslyckas.
• Att inte använda domänadmin-konton för att, slentrianmässigt, logga in på användares datorer.
• Att testa återställningen av backup med jämna mellanrum.
• o s v

Allt det här är exempel på "obehag på kort sikt". Precis som med soldatens ficka så kan man blankt skita i att knäppa den. Det är bekvämt att låta bli. Det är inte säkert att något förloras. På sikt, however, så ökar risken. Med disciplin kan du lita på vilket tillstånd ditt nätverk befinner sig i. Utan disciplin kommer ditt nätverk att bli en knarkarkvart med tiden.

Intressant nog så är det svårt att upptäcka att nätverket är en knarkarkvart. Hade det gällt för kontorslandskapet skulle det ha upptäcks omedelbart så fort besökare kommer. Förhoppningsvis kan vi återkomma till det här.

--
Stefan Pettersson

PC för Alla har startat en rätt underhållande artikelserie om nätbluffar som de kallar Trolltider och igår berättade de om "den bakvända PIN-koden":

Legenden om den bak-och-fram-vända pin-koden började spridas via mejl i september 2006:
"Jag fick just reda på att om du någonsin blir tvingad till att ta ut pengar från en bankomat, så kan du alltid tillkalla polis genom att trycka in din pin-kod baklänges! Bankomaten kommer då att ge dig den summa pengar du angett, men också aktivera ett tyst alarm som kommer leda till en omedelbar polisutryckning."

Funktionen kallas hotkod, du har två PIN-koder varav den ena sänder en signal om att du tvingas slå in din PIN-kod under hot. Det är vanligt förekommande i säkerhetssystem, bl a hemmalarm. Att bankomatkort skulle komma med dem inbyggda i form av din egen PIN-kod baklänges är dock, som sagt, en myt.

Nu kommer jag inte ihåg vem som berättade det här men en person hade skaffat hemlarm. Till larmet kommer förstås PIN-koder men också ett kodord (lösenord) som man uppger i telefonen till larmbolaget för att avbryta ett falsklarm om man råkar trigga det själv. Larmbolaget tilldelade kunder två kodord varav det ena skulle uppges när man blev tvingad att ringa in ett falsklarm, en hotkod.

En dag gjorde vår historieberättare, vi kan kalla honom Adam, en tavla och råkade dra av larmet. Lugn i hågen går han fram till telefonen och trycker på snabbvalstangenten för larmbolaget.

Veronica: Välkommen till Larmbolaget, du talar med Veronica.
Adam: Hej, mitt namn är Adam Andersson, jag råkade precis dra av larmet i min bostad.
Veronica: Jag ser det, ingen fara, vad är ditt kodord?
Adam: Mitt kodord är "Tiger Woods".

*obehaglig tystnad*

Adam: Nej! Förresten, det är "Michael Jordan"! Förlåt...
Veronica (uppenbart lättad): Guud vad skönt! Jag hade ingen aning om vad jag skulle göra! Men sådär, nu är falsklarmet registrerat.
Adam: Tack, du får ursäkta.
Veronica: Ingen fara, ha en bra dag.

Adam råkade förstås uppge sin hotkod till larmbolaget. Man blir ju lite oroad...

Trevlig helg!

--
Stefan Pettersson

Joachim Strömgbergson på Kryptoblog har tagit sig en funderare över Phonekey, produkten som nämndes här i veckan. En skarp analys, hoppas att ni läser Kryptoblog redan. Några utdrag:

Pudelns kärna är att man litar på att det telefonnummer som ringer upp ett givet annat telefonnummer går att lita på. Tyvärr är det kanske inte något som är skrivet i sten. [...]

Men det mest bekymmersamma med hela systemet är att det (att döma av artikeln) blir svårt att hantera säkerhetsproblem. Vad skall man göra om något så trivialt som att en användares mobil vars nummer har registrerats för en tjänst blir stulen? [...]

Jag anser att bra säkerhet bygger på så få hemligheter som möjligt – och att dessa hemligheter är så lätta att byta ut som möjligt. En PIN-kod eller ett lösenord är bara en sekvens av tecken. Kan du inte lita på dom är det relativt lätt att byta ut dom. Att byta telefonnummer för att du inte kan lita på den längre för att logga in på din tjänst är inte alls lika enkelt.

--
Stefan Pettersson

Så här lagom efter föregående inlägg om säkerhetsprodukter kom en artikel ut i morgonens CS om en "ny" form tvåfaktorsautentisering från svenska Phonekey. Cool teknologi:

Tekniken innebär att du måste ringa ett speciellt nummer från din telefon innan det går att använda ditt betalkort, logga in på ditt konto på den sociala nätverkssajten eller komma åt någon annan tjänst som använder sig av det hänglås Phonekey innebär.

Ironiskt nog har CS också en artikel om att säkerheten bakom kortbetalningar är för krångliga. Men, det var något annat som fångade uppmärksamheten i morse på tunnelbanan; ett citat från en av företagets grundare, Tonie Söderström, något i stil med: "Phonekey har/innebär en sinnessjukt hög säkerhet". (Såg just att citatet inte finns med i onlineupplagan.)

Jag förstår förstås att det handlar om att pusha en produkt här, en produkt som kanske till och med är bra. Men, internetbanken är inte säker bara för att kommunikationen mellan bank och dator är krypterad.

Låt mig ta ett exempel jag har kört på flera presentationer förut. Berättelsen börjar med företaget StrongWebmail som kavlade upp ärmarna och sa: "Nu ska vi konkurrera mot Gmail, Hotmail och Yahoo!". Ett ganska djärvt beslut får man erkänna. Självklart måste man som uppstickare ha någon form av edge för att klara av det här, StrongWebmail valde säkerhet och lanserar således en webbmailtjänst med tvåfaktorsautentisering via mobiltelefon (tillsammans med en del skrämselpropaganda). När du registrerar för ett konto kopplar du din mobiltelefon till kontot, när du ska logga in får du ett SMS eller samtal med en engångskod som måste matas in. Alltså, något du vet och något du har.


För att få ut sitt meddelande gjorde man ytterligare en djärv manöver, ett PR-stunt (en rejält smart manöver om man tänker efter, vi hade förmodligen aldrig hört talas om dem annars). CEO:n för StrongWebmail utmanade Internetinvånarna att läsa dennes mail.


Utmaningen var att ta reda på vad CEO:n hade på sitt schema någon viss dag (en kalenderfunktion fanns i webbapplikationen). Till sin hjälp fick man dennes lösenord (Mustang85) men tanken var att detta skulle vara omöjligt utan telefonen som var kopplad till kontot. Alltihop till en belöning på $10,000.

Det som hände strax därefteråt beskrivs ganska väl av följande seriestrip.


Tre personer; Mike Bailey, Lance James och Aviv Raff tog hem prispengarna efter att (1) ha registrerat ett eget mailkonto, (2) bäddat in Javascript i ett mail och (3) skickat det till CEO:n. Cross-site scripting. Tvåfaktorsautentiseringen saknade fullständigt betydelse.

--
Stefan Pettersson

I dagens Computer Sweden svarar Tomas Djurling på en fråga om osäkra lösningar i säkerhetsprodukter. Jag har egentligen inget att invända men skulle vilja ge ett skuggsvar och utveckla frågan en aning samt referera till tidigare diskussioner.

Frågan var om det finns buggar i säkerhetsprodukter i samma utsträckning som det finns i program och operativsystem. Egentligen är frågan rätt enkel att svara på; SQL injection i en inloggningsruta är ett bra exempel  på ett säkerhetshål i en säkerhetsfunktion, och det är ju inte särskilt ovanligt. Men eftersom frågeställaren verkade vara ute efter "fysiska" säkerhetssystem vore det kul att diskutera iväg det hela en bit.

Security features != secure features
En gammal sanning i branschen är: säkerhetsfunktionalitet är inte samma sak som säker funktionalitet. Jag pratade om det i stor utsträckning under en presentation på Sundsvall 42 i höstas:

Principen kan tolkas på två sätt och båda är relevanta. Dels som att (1) säkerhetsfunktionalitet inte betyder att systemet är säkert. Internetbanken är inte säker bara för att kommunikationen mellan bank och dator är krypterad, även om krypteringen är riktigt utförd. Vidare kan principen uppfattas som att (2) säkerhetsfunktioner behöver inte vara säkra, de kan ha buggar.

Notera särskilt den senare uppfattningen, (2). ASSA (låstillverkarna) gav oss ett skinande exempel på detta under 2008 när det visade sig att deras paradprodukt ASSA EVO gick att öppna från utsidan med ett bladmått. Låset (den renaste formen av säkerhetsprodukt) hade ett säkerhetshål.

Vanliga lås
Här rör det sig om en säkerhetsprodukt i form av ett "vanligt lås", vi försöker extrapolera lite. Nycklar är, precis som lösenord, jobbiga att hantera. Om någon tappar bort en nyckel, eller ännu värre, en huvudnyckel, har man ett allvarligt problem. Eftersom en nyckel egentligen bara är en bärare av information (nyckelämne och djupet på varje hack) kan du inte känna dig säker bara för att nyckeln återfunnits, någon kan ha gjort en kopia på den. Det enda du kan göra är att byta ut alla låskolvar, alternativt installera ytterligare ett lås på varje dörr.

Digitala lås
Den digitala världen kommer dock till undsättning och ger oss möjligheten att låta en godtycklig grupp nycklar öppna samma lås samt en nyckel öppna en godtycklig grupp lås. Man kan se det som att alla nycklar är olika och varje lås har en lista på vilka nycklar som får öppna låset. Om både du och jag har en  varsin nyckel som kan öppna låset och jag sumpar min kan vi helt enkelt ta bort den ur låsets lista. Din möjlighet att öppna låset påverkas inte och jag kan få en ny nyckel som läggs in i listan. Kanon.

Centralstyrning
Men, eftersom vi tenderar bygga hus med kolossalt många dörrar (och är rätt lata) är det inte särskilt praktiskt att behöva promenera runt till varje dörr och ta bort förlorade nycklar. Vi behöver central administration. Vi behöver kunna kommunicera med låsen på distans.

Sådan här kommunikation har traditionellt skötts med hjälp av LON, MODBUS och diverse andra (för de flesta) obskyra kommunikationsstandarder. Det här gäller naturligtvis inte bara dörrlås; massor av andra teknologier njuter i hög grad av den centralstyrning som möjliggörs av kommunikation. Inte är det någon vaktmästare som går runt till varje termostat i Turning Torso en gång om dagen och justerar gränsvärdena. Tidpunkten för då fasadlamporna på DN-skrapan tänds och släcks ställs naturligtvis inte in på ett vred på varje lampa. Någon sköter det här från en central manöverpanel någonstans i källaren.

Ute på djupt vatten
Någonting har dock skett, jag vet inte vad, men sådan här kommunikation har börjat krypa över mot TCP/IP och häri ligger ett av huvudproblemen för de branscher som länge jobbat i en verkstad skyddad av obskyra kommunikationsprotokoll. I samma veva som det sker en övergång mot välkända, öppna protokoll ökar komplexiteten i dessa system i och med detta. Det här skiftet har gjort och kommer att göra situationen värre.

I en intervju i AffNyheter (pdf) (fastighetsbranschens tidning) från i början av 2009 sa jag ungefär samma sak som Tomas Djurling skrev i Computer Sweden idag. Då handlade det inte bara om passersystem utan alla slags system för fastighetsautomation:

"I samband med övergången till öppna protokoll som baseras på TCP/IP har leverantörerna gett sig in på ett område där kunskap och verktyg för att manipulera tekniken finns i överflöd. Tidigare har de till viss del kunnat förlita sig på att deras teknologier varit för obskyra för att någon skulle intressera sig.", säger Stefan Pettersson.

Problemen med fastighetsautomationens intåg på våra LAN är ett ämne jag har velat skriva om länge. Nu är det dock fredag och det får vara nog med självcitat. :-)

Trevlig helg!

--
Stefan Pettersson

McAfee gjorde en rejäl tavla igår. De markerade svchost.exe som skadlig i sina virussignaturer vilket gjorde att dess processer blev antastade av antivirusprogrammet och Windows fick svårt att köra ordentligt. Bra beskrivningar finns på SANS ISC:

• McAfee DAT 5958 Update Issues
• How McAfee turned a Disaster Exercise Into a REAL Learning Experience for Our Community Disaster Team

När jag läser artiklar med rubriker som Datorkaos i hela Sverige tänker jag på Dan Geer & co:s gamla uppsats Cyberinsecurity: The Cost of Monopoly som skrevs 2003. Då handlade det om att Microsofts monopol innebar en risk i o m den monokultur som uppstår; en sårbarhet påverkar nästan alla. Det var något vi fick uppleva under maskåren 2000-2003.

Det är inte självklart att monokulturer är sämre än de är bra (det finns många fördelar) men det är tänkvärt att det inte bara gäller operativsystem

--
Stefan Pettersson