Lösenord på vift - vad kan du som organisation göra för att skydda dig?

0 kommentarer
Vi kunde igår läsa om hundratusentals lösenord på vift efter att ett sextiotal sajter hackats. Det finns två viktiga aspekter på det. Dels den jag skrev om igår: Vad du som användare kan göra för att skydda dig. Dels vad du som organisation eller utvecklare kan göra för att minska risken för att du eller dina användare drabbas.

Vad du som organisation kan göra för att minska risken för lösenordsrelaterade intrång
  1. Lagra inte lösenord i klartext
    Om du lagrar dina användares lösenord i krypterad form blir det mycket svårt för en inkräktare att använda lösenorden även om du blir utsatt för ett intrång. Räkna alltid med att du kommer att bli utsatt och arbeta utefter tesen att minimera konsekvenserna. Dit hör att göra det svårt för en inkräktare att använda de stulna lösenorden. Ärligt talat: Varför behöver du veta dina användares lösenord? Det du behöver veta är om ett inmatat lösenord är rätt lösenord och det löser du med hjälp av envägskryptering eller sk. hashning. På så sätt jämför du bara de krypterade versionerna av det inmatade och det lagrade lösenordet. Om de stämmer överens vet du att rätt lösenord har använts, utan att du lagrar lösenordet i klartext. Genom att dessutom salta hashen försvårar du ytterligare för en inkräktare att härleda lösenordet även om olyckan skulle vara framme.
     
  2. Single sign-on och federerade identiteter
    Single sign on eller SSO innebär att du inte hanterar alla användares konton i alla system där de loggar in. Användarens konto finns på ett ställe dit man ansluter flera andra system som användaren ska kunna logga in i. Risken med att ha olika konton i olika system är att användarna av bekvämlighetsskäl använder samma lösenord på många olika platser. Om ett system blir utsatt för ett lyckat intrång är risken stor att inkräktaren kan logga in i andra system med samma användarnamn och lösenord. Vän av ordning frågar sig om det är säkert att ha ett användarnamn och lösenord som styr tillgången till många system, men på detta sätt får man en kontrollpunkt som är lätt att hålla reda på både för användaren och administratören. Man måste dock alltid göra en analys av den totala säkerheten och värdera riskerna med olika alternativ.
    Federering innebär att en och samma identitet kan användas i flera olika organisationer och deras system. Exempel är företag och organisationer som samarbetar och som håller reda på sina egna användares identiteter och samtidigt litar på identiteterna i andras system.

  3. Tvåfaktorautenticering
    Även om SSO och federering gör det enklare för oss att hantera lösenord, löser dessa tekniker inte problemet med att lösenord kan stjälas. Därför bör man överge rena lösenord till förmån för två- eller flerfaktorautenticering. Det går till så att man autenticerar med något användaren vet (lösenordet) och något användaren har (säkerhetsdosa, certifikat, mobiltelefon som tar emot SMS etc.). Där finns idag många exempel från olika tillverkare som du kan integrera i din IT-miljö. Vilken av de olika teknikerna som är bäst beror på egenskaperna i din miljö, exempelvis hur många användarna är, hur ofta de behöver autenticera, varifrån de autenticerar och med vilken typ av enhet (dator, laptop, telefon, smartphone, surfplatta, internetcafé etc.) Helt klart är i att du genom att använda mer än bara lösenord för autenticering helt eliminerar risken för att stulna lösenord leder till intrång. Inkräktaren behöver stjäla något mer - något som användaren förhoppningsvis märker att det är stulet. När vet du om ditt lösenord är stulet? Saknar du något? Om du har tur dyker det upp i ett publikt Internetforum så att alla ser det innan det hunnit användas. Om du har otur får du inte reda på det förrän en obehörig har använt lösenordet.
  4. Jobba aktivt med säkerhet - OWASP Top 10
    En god lösenordshygien är viktigt både för dig som systemägare och för dig som användare. De flesta storskaliga stölder av användares kontouppgifter vi sett på senare tid har dock skett till följd av dåligt implementerade system. System som varit sårbara för attacker som exempelvis SQL Injection, Cross Site Scripting, bristande säkerhet i datareferenser etc. Genom att redan från början föra in säkehretsaspekten och göra alla medvetna om säkerheten när du kravställer och implementerar dina system minskar du risken för att drabbas av framtida intrång. Ett mycket bra ställe att börja på är OWASP:s topp 10-lista över de vanligaste sårbarheterna. Om du klarar av att hantera dessa är du och ditt system väl rustade för att möta dagens hotbild på Internet. Detta gäller oavsett om du är en enmansutvecklare av ett litet system eller en större organisation med hundratals utvecklare.
Michael Westlund
IT-säkerhetsexpert

Följ mig på Twitter: @michaelwestlund

Lösenord på vift - vad kan du som användare göra för att skydda dig?

0 kommentarer
Efter gårdagens nyheter om att Bloggtoppen hackats och att användarnamn och lösenord är på vift har det kommit fram att det är fler sajter som är drabbade. Ytterligare 57 sajter och uppemot 180000 konton är på vift. Om du har eller har haft ett konto på någon av dessa sajter bör du omedelbart se till att byta dina lösenord. Speciellt om du har återanvänd samma lösenord på flera platser. Se längst ned för en lista över drabbade webbplatser.

Det är självklart alarmerande att flera kända sajter har blivit av med sina användares kontouppgifter, men det är dessvärre någonting som händer hela tiden. Och det kommer att hända igen.

För dig som användare och enskild person är det svårt att motverka intrång hos någon annan. Det handlar istället om att minska konsekvenserna för dig själv när det inträffar.

Här är några tips på hur du kan hantera dina egna lösenord för att minska risken för allvarligare konsekvenser:
  1. Välj säkra lösenord.
    Ett säkert lösenord är lätt för dig att komma ihåg men svårt för någon annan att gissa. En hjälp på vägen är att använda lösenordsfraser istället för lösenord. En fras eller mening är i regel lättare att komma ihåg än ett ord som inte betyder något. Tycker du att det blir för långt, eller klarar inte systemet av långa lösenord? Välj första bokstaven i varje ord.
    Byt ut någon eller några av bokstäverna mot specialtecken eller siffror för att ytterligare förstärka lösenordet.
  2. Använd olika lösenord för olika system.
    Med det stora antal konton vi måste hålla reda på idag är det lätt att falla i fällan att använda samma lösenord på flera ställen. Det är tyvärr en mycket dålig idé. Många dataintrång sker till följd av att samma lösenord används på flera ställen. Genom att använda olika lösenord på olika ställen eliminerar du risken för att någon som kommit över ditt lösenord på ett ställe lyckas använda det någon annanstans. Det kan räcka med att byta ut några tecken i lösenordet så att det blir lättare att komma ihåg men inte är exakt samma i olika system.
  3. Använd SSO om du kan!
    Det blir vanligare att webbsajter använder sig av SSO, Single Sign On. Det innebär att kontouppgifter hämtas från ett annat system. Ett exempel är Facebook som i flera fall används för att logga in på andra tjänster som exempelvis Spotify, Familjeliv och andra forum på nätet. Det kan till en början kännas osäkert att ha ett konto för inloggning på flera sajter, men du som användare får färre lösenord att skydda. I de flesta fall finns inte heller lösenordet mer än på ett ställe.
  4. Aktivera stark autenticering
    Flera tjänster, bland annat Facebook och Google erbjuder SMS-autenticering eller autenticeting med en programvara i din telefon. En inkräktare måste alltså stjäla din mobiltelefon för att kunna logga in. Det här minskar också risken för att någon stjäl ditt lösenord när du loggar in från högriskplatser som exempelvis internetcaféer eller okrypterade trådlösa nätverk. 
Det finns självklart mer att göra, men om du följer ovanstående råd minskar du risken för att drabbas av intrång om dina konsouppgifter blir stulna från någon av de sajter du använder.
Listan över drabbade webbplatser
adcomlive.se
bag.nu
bildbank.eslov.se
billesholmsgif.se
bilrecension.se
blasarsymfonikerna.se
bloggtoppen.se
bildalbumet.se
bonti.se
call-up.se
campaign.iqmedier.se
carlwisborgab.se
dagensps.se
discsport.se
djurensjurister.se
easykb.se
ecoprofile.se
emusic.se
find-websites-directory.com
fjaderborgen.se
gamman.se
genealogi.se
golfbycarl.se
gulabutikerna.se
hobby.se
iplay.norran.se
itservice.omv.lu.se
kloaken.net
kryolan.se
lensy.se
matlycka.se
mchuset.se
meetingsinternational.se
natalie.se
nivado.com
nordportalen.se
nylandsnation.com
plusikassan.se
puff.se
quakeworld.nu
reklamkraft.tv
retrospelbutiken.se
rullma.fi
saifa.se
scrabbleforbundet.se
seriehyllan.se
serieplaneten.se
shellkonto.se
skcab.se
sportbilen.se
tarotlive.se
topblogarea.se
tramsmail.se
tropicarium.se
veteran.se
vilse.studorg.liu.se
world-superstore.com
yle.fi (Sex och såntdelen)

Michael Westlund
IT-säkerhetsexpert

Följ mig på Twitter: @michaelwestlund

Ubertooth - Öppen hårdvara för monitorering av blåtand

0 kommentarer

imageJag har labbat lite med Ubertooth One dom senaste dagarna och dokumenterat hur jag har fått det att fungera under OSX, vilket inte är en officiell plattform för projektet (just nu är det bara Linux som stöds officiellt).

Vad gör Ubertooth One som inte annan bluetooth-hårdvara kan göra? Ubertooth One (och Ubertooth Zero för den delen) är en blåtandsadapter som ger direkt kontroll över radion och skickar den råa bit-strömmen till datorn via USB-porten; tolkningen av bit-strömmen sker i datorn och inte på någon krets på själva blåtands-adaptern. Detta gör att man får en otrolig kontroll över vad man vill göra med adaptern.

Ubertooth var i första hand skapad för att tillåta monitorerings-läge (monitor-mode) av blåtand utan att behöver betala tio-tusentals kronor för en USRP. Monitorerings-läget gör så att man kan see vilka blåtandsenheter som finns i omgivningen utan att dom nödvändigtvis är synliga (discoverable).

Att få ut blåtandsenhetens adress är ett nödvändigt steg för att senare kunna attackera enheten. Innan Ubertooth fanns så var man relativt säker om man bara såg till att man hade stängt av discoverable mode i sin telefon: Om man inte syntes så hade angriparen svårt att hitta en för att utföra sina attacker. Så är inte fallet längre utan förvänta dig att det kommer bli lite fler ögon som granskar säkerheten i blåtandsimplementationerna i diverse enheter.

Jag uppdaterar löpande min privata blog med detaljerad teknisk information (på engelska) hur det går med mitt labbande för den som är intresserad.

/Michael Boman

Varning för depositionsbedrägerier via annonser på nätet

4 kommentarer
I en värld av bostadsbrist blir det allt vanligare med s.k. escrow fraud (ung. depositionsbedrägeri). Det samma gäller för handel med andra kapitalvaror som begagnade bilar. Det är lätt att falla för bedragarnas metoder om man inte är uppmärksam. Det lönar sig alltid att dubbelkolla innan man för över pengar någonstans och gamla sanningar håller ännu: Om något låter för bra för att vara sant – då är det oftast det!
Denna lilla utvikning i ämnet kommer sig av att jag själv söker bostad för ett temporärt boende, då vi ska göra en större ombyggnad av huset. Febrilt letande på blocket och andra forum för andrahandskontrakt gör att man lätt kommer i kontakt med både ljusskygga delar av bostadsmarknaden och bedragare som försöker profitera på folks desperation.
Det som hände var följande: Vi svarade på en annons för ett andrahandskontrakt på en lägenhet i Sannegårdshamnen i Göteborg (annonsen är nu borta från Blocket). Hyran var låg och läget var perfekt och på bilderna såg allt verkligen lovande ut. Annonsen var underskriven med namnet Goran och såg verkligen trovärdig och korrekt ut. Den var skriven på bra svenska och enda möjliga varningsflaggan var att den var inlagd under fel stadsdel, men detta kunde varit ett simpelt misstag.
Första svaret kom väldigt snabbt, men det var ett litet bekymmer:
image
OK? Vad hände med Göran/Goran? Och så var det ju det där problemet med att han befann sig i London, men det verkar han ju ha en lösning på…
Lite Google-uppslag på “Dr. Ronald Smith” ger inga väsentliga träffar. Om personen vore på riktigt borde det åtminstone finnas spår av honom. Han borde ha en praktik, ha publicerat en avhandling, eller åtminstone skrivit något på nätet. Sökning på Linked-in ger heller inga träffar med någon relevans.
Om inte varningsklockorna har börjat ringa ännu, så är det dags. Detta luktar fisk lång väg, men vi spelar med lite för att se hur det utvecklar sig.
image
Jo men visst! Nu kommer han med en lösning som låter trygg och bra. Vi deponerar pengar hos en oberoende tredje part och kan i lugn och ro titta på lägenheten först. Kanon! …eller?
Om vi glömmer bort alla andra varningsflaggor och fokuserar på deponeringsföretaget, så finns det lite saker man kan kolla upp. Vi gör lite kontroller på hemsidan för skojs skull. Jag börjar med ett besök:
image
Sidan ser mycket seriös och övertygande ut. Massor av information och professionellt byggd. Den inger förtroende och även om jag aldrig har hört talas om ATO Shipping, så kanske de är stora utomlands. Vi får väl kolla. En snabb sökning på Google:
image
Konstigt! Inga träffar utom på deras egen hemsida. Om de hade varit ”stora i Europa” så borde ett antal träffar finnas på expat-forum eller andra sidor där det diskuteras transporter. Varningsflagg!! Dessutom låter ju ”Across The Ocean Shipping” lite väl… tillrättalagt och banalt.
Jag gräver lite djupare och tittar vem som äger domänen. Här använder jag http://whois.domaintools.com/ som är en tjänst på nätet för att söka i whois-databaser. Det är lite smidigare än att manuellt fråga RIPE, APNIC eller ARIN som är de organ som håller reda på databaserna.
image
En snabb Google på mailadresserna (som mycket väl kan vara förfalskade) ger mer kött på benen:
image
Hmm.. Fraud Data - Escrow Fraud Prevention. Varning, varning!
Den andra informationen som är intressant ur whois-databasen är namnservrarna som svarar för domänens DNS uppslag. Dessa pekar på ett webbhotell i Australien som erbjuder webbplats och mail för ca 20 kr i månaden (AUD 3,95). Jag använder mig sedan av nslookup (eller dig) för att ta reda på mer om domänen atoshipping.com.
image
Hela deras infrastruktur pekar på en enda IP adress och det är ingen idé att försöka maila till deras administrativa kontakt, för den domänen har inget MX-record (DNS uppslag som berättar vilken maskin som tar emot epost för domänen).
Undantaget varningen om bedrägeri så tyder inte denna information på något seriöst företag, än mindre ett multinationellt logistikföretag med deponeringstjänster.
Vidare sökningar och granskning av domännamnet atoshipping.com avslöjar flera anmälningar om bedrägliga deponeringsärenden…
Men det roliga slutar inte här. Vi är ju nyfikna på var ”Ronald” sitter, eller hur? Eftersom han använt sig av en Hotmail-adress så kan vi faktiskt ta reda på det (det finns andra tekniker för att spåra andra epost alternativ). Genom att titta på epost-huvudet (lite olika sätt beroende på epostklient) så kan vi få fram vilken IP adress som skickade brevet. På Gmail gör man så här:
image
Utdrag från original:
Message-ID: <BAY156-w56FD4DA5F6CC1025AC8F54A1570@phx.gbl>
Return-Path: ronald.smith1@hotmail.com
Content-Type: multipart/alternative; boundary="_b8ba9d9c-46f9-43f9-ae9c-f6a97c71efef_"
X-Originating-IP: [129.63.210.141]
From: Ronald Smith <ronald.smith1@hotmail.com>

Den rad i all teknisk information som du letar efter är ”X-Originating-IP”. En sökning på whois visar att den tillhör University of Massachusetts Lowell. IP adressen är dynamiskt tilldelad, men det var samma IP vid båda tillfällena. Nslookup ger namnet: fal210-129-63-210-141.dhcp.uml.edu.
Det kan vara så att ”Ronald” sitter på plats i Lowell, men det troligaste är att maskinen är hackad och att ”Ronald” sitter någon helt annan stans. Vi skulle kunna gå vidare och kontakta polismyndigheter i berörda länder (Sverige, Australien, USA…) samt universitetet, för att gå vidare i utredningen, men möjligheten att ro hem en sådan utredning med ett bra resultat är liten. Dessutom så är det svårt att påvisa att ett brott har begåtts. Ännu så länge är det bara försök till bedrägeri.
Tips och råd: 1. Undvik denna typ av transaktioner helt.
2. Om du måste göra en depositionstransaktion, använd en betrodd tjänst som escrow.com, paypal.com eller trustedfriend.com.
3. Kontrollera med exempelvis FSA (http://www.fsa.gov.uk/) om tjänsten är registrerad och under kontroll
4. Lyssna på varningssignalerna!
5. Google är din vän
Som en uppföljning åkte jag till Sannegårdshamnen för att titta på portuppgången. Det fanns varken någon Goran eller Ronald. Dessutom verkade det vara en hyresfastighet. Om du är tveksam, så ta kontakt med hyresvärden eller bostadsrättsföreningen och kontrollera alla uppgifter. Det kostar inget och kan bespara dig många tusenlappar och huvudvärk.
Och en sak till: Det finns bedragare i Sverige också, så var försiktig och gå inte med på några svartkontrakt!

Rikard Bodforss, Säkerhetsexpert inom IT-forensik och incidenthantering

Genomgång av ZeuS 2.0.8.9 Control Panel

0 kommentarer

Nyligen läkte källkoden för ZeuS malware ut och jag lovade att jag skulle ta en närmare titt på den. Denna analys består av flera inlägg. Jag börjar med webbgränssnittet (CP, Kontrollpanelen) och gör detta på en virtuell miljö som är skapad just för denna typ av uppgifter. Zeus är en känd skadlig programvara och det kan gå fruktansvärt fel om du inte är försiktig. Du har härmed blivit varnad!

Först måste du installera gränssnittet. Detta gör du genom att gå till /install/ katalogen och fylla i formuläret.

image

Efter att ha fyllt i formuläret och tryckt på knappen “Install” får du följande resultat:

image

För att logga in på ZeuS konsolen behöver du gå till: /cp.php?m=login och skriva in dina tidigare valda loginuppgifter. Efter inloggning finner du dig stirrandes på följande sida:

image

Det finns inte mycket annat att se i ZeuS kontrollpanel i detta skede eftersom vi inte har några aktiva bot:ar anslutna till kontrollpanelen ännu. Nästa steg är att infektera några Windows-maskiner med den skadliga koden och få dem att ansluta till kontrollpanelen, något som jag ska försöka täcka in i senare blogginlägg.

/Michael Boman, Säkerhetsexpert inom sårbarheter och skadlig kod

Läckor i den digitala undre världen

0 kommentarer

image De senaste dagarna har det hänt en hel del intressanta saker inom den digitala undre världen. Först har källkoden för Zeus läckt ut och finns att ladda ner från flertalet sajter på nätet (jag kommer att gå lite djupare in på Zeus vid ett senare tillfälle). Sedan har även Stuxnet-masken blivit disassemblerad och konverterad till C++ kod (kallad MRxNet) av Amr Thabet. Detta betyder att man kan titta på hur masken fungerar även ifall man inte är en über-hacker som läser x86-assembler lika lätt som en barnbok.

Vad betyder detta för oss? Till att börja med så kan man tänka sig att varianter av Stuxnet dyker upp som används av mindre begåvade kriminella än skaparna av Stuxnet-masken. Själva sårbarheterna som utnyttjades kommer med största sannolikhet att ändras. Tekniken för spridning däremot lämpar sig bra för spear-phishing attacker. Som vanligt så är det de vanliga skydden som gäller: öppna inte oväntade bilagor i mejl, ladda bara ner filer från sajter som du litar på, se till att ha något antivirus-program installerat, samt att detta, operativsystem och annan programmvara är uppdaterade.

Jag tror att kortsiktigt kommer utvecklarna av Zeus få svårigheter att motivera priset på USD$10’000 för en installation. Det lär även bli rätt vanligt med Zeus command & control servrar. Långsiktigt lär Zeus (eller dess efterföljare) vidareutvecklas och den nyss läckta versionen (2.x) bli gammalmodig och falla ur bruk.

Naturligtvis har jag införskaffat mig en kopia av både Zeus och MRxNet för analys.

Vad tror ni kommer hända nu när Zeus och Stuxnet har blivit allmänt tillgängligt? Var vänlig använd kommentarsfunktionen på bloggen och skicka in dina synpunkter.

/Michael Boman

BeEF (Browser Exploitation Framework)

0 kommentarer

BeEF 0.4.2.5 alpha släpptes tidigt i morse och jag tänkte gå igenom vad BeEF är och vad det kan användas till. BeEF är ett exploit-ramverk som sköter mycket av det tunga arbetet som är associerat med att skriva Cross-Site Scripting (XSS) exploits som är centralt styrda. BeEF är från och med version 0.4 skrivit I ruby (tidigare versioner var skrivna I PHP).

Jag brukar använda mig utav BeEF när man behöver demonstrera att en Cross-Site Scripting sårbarhet faktiskt är något farligt och behöver åtgärdas. Jag använder mig mycket utav alert(1) när jag letar efter dom, för det är väldigt visuellt när man hittar hittar sårbarheten. Däremot så verkar inte en alert() ruta så farlig när man visar den för utvecklare eller systemansvarig:

image

Med hjälp av BeEF så blir situationen lite annan. BeEF har många attacker redan inbygda och kan laddas ner gratis från internet. Man behöver inte vara någon über-hacker för att kunna utnyttja dom och konsekvenserna kan bli förödande.

Installationen är lätt (åtminstånde på Linux och OSX, Windows ej testat). Efter att man har laddat ner källkoden kör man (från “beef” katalogen):

ruby install

Detta kommando kontrollerar att alla moduler som krävs är installerade på systemet. Om någon av modulerna saknas kan du antingen låta installationsprogrammet installera dom åt dig eller lista vilka moduler som saknas och låta dig installera dessa.

När alla moduler som krävs att köra BeEF är installerade så startar man BeEF:

ruby beef

När servern har startat upp så styr man webbläsaren till BeEF adressen som står på skärmen (t.ex. http://127.0.0.1:3000/). Efter man har loggat in (och kopplat in några offer till systemet) ser man följande:

image

På vänster sida ser man vilka webbläsare är eller har varit ihopkopplade med BeEF servern. Man får även information om vilken webbläsare och version samt operativsystem som körs av offrets system (via ikonerna). Markerar man IP-adressen så får man ytterligare information av det inkopplade systemet:

image

Väljer man “Commands” tabben så får man en lista på olika (inbyggda) kommandon (attacker) som finns att tillgå. Innan vi går in på vilka attacker som finns så kan man titta lite snabbt hur dom är klassifierade:

image

I första hand så är kommandona klassifierade hurvida man vet att dom fungerar mot den valda plattformen och om användaren kommer att märka av något när dom körs.

Sedan är kommandona indelade I olika kategorier:

image

Och där under finns själva kommandorna. Jag kommer inte att räkna upp alla kommandon som finns eftersom det kommer fler och fler vid varje uppdatering, därimot så kommer här en skärmdump på vilka moduler som finns i denna version:

image

Hoppas att detta har väckt ditt intresse för BeEF. Har du kommentarer eller frågor var vänlig använd kommentarsfunktionen på bloggen.

/Michael Boman

RSA hackat - hur påverkar det dig?

0 kommentarer

De flesta som arbetar med IT-säkerhet har förmodligen hört om förra veckans hack av RSA, där inkräktare kom över information om deras SecurID-produkt för flerfaktorautenticering. RSA har gått ut med en varning till alla kunder där ett antal säkerhetsåtgärder rekommenderas. Exempel på åtgärder som varje företag redan borde ha i sin IT-säkerhetspolicy: att hålla systemen uppdaterade, att bevaka loggar från sina olika system (servrar, brandväggar, IDS etc.) och att minska risken för att användaruppgifter läcker.

Än så länge har inte RSA avslöjat exakt vad inkräkrarna kom över och det pågår just nu en livlig debatt och ryktesspridning om detta. Många frågar sig om det skulle kunna vara någon slags "masternyckel" eller del av algoritmen som gör att det går att härleda den kod som syns på en viss SecurID-dosa vid en viss tid.

Om vi gör antaget att det är just det som en inkräktare kan göra, dvs härleda godtycklig engångskod för en dosa, återstår flera andra faktorer i autenticeringen: användarnamn, PIN-kod och lösenord. I alla fall i de system där man inte bara förlitar sig på användarnamn och den kod som syns i dosan. En inkräktare måste således känna till vilken dosa som är tilldelad till en viss användare och vilket användarnamn som denne användare har. Det är information som RSA inte har, den ligger i kundens system.

Om vi också gör antagandet att inkräktaren kommit över information om vilken kund som har en viss SecurID-dosa blir det lite desto mer intressant. Informationen kan delvis komma från RSA som ju vet vilken kund som köpt en viss dosa, men ett intrång hos kunden krävs för att avslöja vilken individ som använder en viss dosa.

Även om det generella hotet mot alla SecurID-användare kan antas vara lågt - även efter RSA:s läckage, skulle det kunna innebära att en inkräktare som är intresserad av ett visst mål och som på annat sätt lyckats komma över användarinformation, kan lägga det klassiska (o)säkerhetspusslet: ett antal sårbarheter som var och en för sig inte är kritiska skapar tillsammans en kritisk sårbarhet.

Oavsett vad inkräktarna har kommit över från RSA visar det än en gång att det inte räcker med bra teknik för att uppnå ett fullgott skydd. Det är inte den tekniska lösningen SecurID i sig som attackerats, utan en organisation som misslyckats med att upprätthålla tillräcklig konfidentialitet och blivit utsatt för informationsstöld.

Vad bör du som SecurID-användare göra idag? Precis samma sak som du förhoppningsvis redan gör och gjort tidigare:

  • Håll dina användares identiteter skyddade
  • Tilldela rättigheter enligt minsta nödvändiga behörighetsnivå
  • Håll dina system uppdaterade, skyddade och bevakade.

Just nu i fallet med SecurID-problematiken är de viktigaste bitarna att inte exponera användarnas användarnamn eller PIN-koder:

  • Kryptera alla inloggningar - även flerfaktorinloggningar
  • Hjälp användarna att välja bra PIN-koder och att dessa skyddas på ett bra sätt.
  • Utbilda och informera användare och helpdesk för att minska risken för sk social engineeringförsök eller phishing som kan exponera information om dina användare eller deras SecurID-dosor.

Om du tillhör en organisation där det är viktigt att ingen utomstående, inte ens din leverantör, känner till något om någon av faktorerna i din flerfaktorautenticering, använder du idag varken RSA SecurID eller någon annan säkerhetsprodukt där tillvekraren har kopior av eller information om dina nycklar.

För de flesta som använder SecurID idag finns ingen anledning till omedelbar panik, men du bör snarast göra en egen riskbedömning: Finns det anledning att tro att en inkräktare har information om din organisation och dina användare som tillsammans med RSA-hacket är kritisk?

Michael Westlund
Säkerhetsarkitekt
Omegapoint AB

Skript för att migrera Nessus rapporter

0 kommentarer
Jag hade behov av att migrera en massa gamla scan rapporter från ett system till ett annat. Som jag helt föraktar återkommande manuellt arbete jag skrev några Perl-skript för att lösa problemet för mig.

exportReports.pl

use strict;
use warnings;
use Net::Nessus::XMLRPC;

# Settings
my $nessus_url = "https://127.0.0.1:8834";
my $nessus_user = "username";
my $nessus_pass = "password";
my $base_dir    = "C:\\Temp\\Nessus";
# Variables
my $xmlReport;
my $n = Net::Nessus::XMLRPC->new( $nessus_url, $nessus_user, $nessus_pass );
die "Cannot login to: " . $n->nurl . "\n" unless ( $n->logged_in );
print "Logged in\n";
my @reports = $n->report_list_uids();
for my $report (@reports) {
    for my $reportUID ( @{$report} ) {
        print "Report " . $reportUID . ": Downloading...";
        $xmlReport = $n->report_file_download($reportUID);
        print " Saving...";
        open( FH, ">" . $base_dir . "\\" . $reportUID . ".xml" );
        print FH $xmlReport;
        close(FH);
        print " Done!\n";
    }
}
$n->logout();
print "Export completed!";



importReports.pl

use Net::Nessus::XMLRPC;

# Settings
my $nessus_url  = "https://127.0.0.1:8834";
my $nessus_user = "username";
my $nessus_pass = "password";
my $base_dir    = "C:\\Temp\\Nessus";
# Variables
my $xmlReport;
my $n = Net::Nessus::XMLRPC->new( $nessus_url, $nessus_user, $nessus_pass );
die "Cannot login to: " . $n->nurl . "\n" unless ( $n->logged_in );
print "Logged in\n";
print "Reading dir...";
opendir( DIR, $base_dir . "\\." );
@reports = grep( /\.xml$/, readdir(DIR) );
closedir(DIR);
print " Done!\n";
foreach $report (@reports) {
    print "Uploading report " . $report . "...";
    #$n->report_import_file ( $base_dir . "\\" . $report ); # Didn't work for me
    print " Reading...";
    {
        local $/ = undef;
        open FILE, $base_dir . "\\" . $report or die "Couldn't open file: $!";
        binmode FILE;
        $xmlReport = <FILE>;
        close FILE;
    }
    print " Uploading...";
    my $filename = $n->upload( $report, $xmlReport );
    print " Importing...";
    $n->report_import($filename);
    print " Done!\n";
}
$n->logout();
print "Done importing reports!" 


Om du fått nytta av skripten eller har förslag hur man gör det bättre lämna gärna en kommentar. Tack!

/Michael Boman