Författare: Erik Zalitis

12 juni, 2019

Dessa vilda dagar

Pratade tillsammans med Mattias med Marcus Murray från TrueSec och han sa att ”Ondskan har mognat”. Det slog an en klang och jag har funderat på det en hel del. Sanningen är att det känns som innan nästan inte hinner reagera mellan att man får veta att en viss typ av attacker blir vanligare och man ser att det händer i ens närhet.

Förut kunde attacker hanteras utan allt för mycket svett. Ett totalt övertagande av en miljö hände ju även då, men det vanligaste var att man hanterade enstaka datorer med skadlig kod eller läckta uppgifter. Idag är det mer och mer vanligt att man helt plötsligt har hundratals servrar och klienter som är krypterade eller på annat sätt övertagna. Ett litet ”nålstick” dödar hela organisationen.

Attacker blir allt mer riktade och det har vi ju talat om många gånger tidigare. Vad blir det av detta i framtiden, kan man undra? Hur många system måste tas över innan någon form av smärtgräns är nådd. Baltimore hålls gisslan, men när hör vi att även New York, Seattle och Washington råkar ut? Är det framtiden? Att i princip alla är drabbade och det blir standard att återställa allt från början eller punga ut med miljoner dollar till hackare för att få tillbaka viktigt data. Det kommer till sist bli som en form av hackar-skatt. Kanske blir det ett system med beskyddarpengar för att man inte ska bli drabbad. Och om man nu spenderar pengar på security operations centers som hela tiden övervakar allting, blir det ju ändå en ökad kostnad för att kunna försätta driva sin verksamhet. Detta i sig är också en form av ”hackarskatt” för alla. En kostnad som man anting betalar till attackerare eller till de som ska skydda mot dem.

Är Zero Trust Networks ett hopp för framtiden eller tar sig allt mer organiserade hackers förbi även detta? Det är inte utan ett visst mått av frustration som jag ser hur det blir allt mörkare på säkerhetsfronten.

Men kanske måste man även se ljuset. Vi blir allt mer säkerhetsmedvetna och fler och fler utbildar sig i säkerhet, vare sig de vill jobba inom området eller bara förstå hur saker fungerar.

3 juni, 2019

Att ta steget

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.

27 maj, 2019

Elektronisk röstning?

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å!

8 maj, 2019

Omvärldsbevakning

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.

24 april, 2019

När man säger för mycket

Det är en allt mer ovanlig syn: felmeddelandet som säger allt.

Kommer ni ihåg när man kunde gå till en hemsida och se följande meddelande?

”Microsoft OLE DB Provider for ODBC Drivers error ’80040e14’

[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ’46’.

/webapp.php, line 12″

Detta förekommer fortfarande, men just detta meddelande är idag nästan ett museiföremål. Meddelandet ovan kommer från en sårbar webbapplikation som råkat ut för någon som testat att lägga till en apostrof i ett indatafält. Detta är en indikator att man kan göra en SQL-injektion. Meddelandet avslöjar även vilken databasmotor man använder.

Att säga att det inte sker längre är dessvärre att tro för väl om säkerheten på Internet. Det finns stora mängder exempel på system som berättar vilken version de är eller läcker ut annan känslig information. Det finns många ställen där man kan demonstrera detta. En av de mest användbara är ”Google Hacking Database” som innehåller en lista på sökord som kan användas för att hitta sårbara applikationer eller intressanta saker att titta djupare på. Den bygger på att applikationer ofta läcker ut konfigurationer, lösenord eller loggar på nätet, som Googles sökmotor snappar upp när den indexerar sidorna. Ett exempel ur den digra listan: prova följande länk för att hitta applikationer på Github som hårdkodar sina lösenord i konfigurationsfiler. Många av dessa är troligen av rätt begränsad användning. Men det finns anledning att fundera på om det är så lämpligt att skriva en applikation på detta sätt. Kan man använda denna information för att hacka? Svaret är att det beror på ens fantasi.

Sen finns ShodanHQ som låter dig söka efter enheter som är nåbara från Internet. Detta verktyg har vi pratat om på podden, så det enda jag kan säga här är att det avslöjar mycket. Det ska noteras att sökningen är helt laglig. Den gör absolut ingen skada. Däremot ska du inte göra något för att ta över systemen. Vi avråder starkt från att faktiskt försöka hacka system utan tillstånd. Vi tar inget ansvar för vad som händer om du försöker dig på något sådant. Håll dig på den lagliga sidan!

Vad finns det att lära av detta? Det jag ser är att det är viktigt att inte ge ut någon information annat än den mest absolut nödvändiga. All information kan komma att användas av någon som har oärliga avsikter.

18 april, 2019

Att förstå säkerheten

I början av 2000-talet fanns siten ”Interface Hall of Shame”. Denna site visar exempel på värdelösa grafiska användargränsnitt. Min favorit är hur de relaterar till någon som på ett forum undrade hur en dropdown meny kunde fås att fungera när man hade tusentals möjliga val i den. Svaret är: varför vill du ens bygga något så dumt?

Säkerheten är inget undantag från att dålig design. Eller, vad som nästan är ännu värre, exempel på egenpåfunna lösningar. Som jag skrivit i tidigare blogginlägg: inom säkerhetsområdet är det i stort sätt alltid en dålig idé att komma på sin egen krypteringsalgoritm och tro att den kommer förbli säker om man bara låter bli att berätta hur den fungerar.

Men det finns många tillfällen där personer och företag har byggt lösningar utan att förstå säkerheten bakom.

I Windows 95 sparades lösenorden man loggade in med i ett format som Microsoft själva hade hittat på. Hur det fungerade höll man givetvis för sig själva. Och det tog inte lång tid för några duktiga hackare att knäcka det. Lärdomen av det, som jag skrev ovan, är att inte hålla det hemligt och att inte försöka bygga algoritmerna själv.

Säkerhetsexperten Steve Gibson kom på en metod för att skydda datorer från överbelastningsattacker. Innan hans lösning blev ens byggd, tittade några andra säkerhetsexperter igenom vad han gjorde reklam för och sågade lösningen. Den var inte säker. Steve hade inte pratat med någon annan medan han satt på kammaren och byggde vad han trodde var en perfekt lösning. Dessutom hade han troligen inte koll på att en liknande lösning redan fanns och hade används under ett antal år. Lärdom: prata med andra om din lösning och kolla om du måste bygga den överhuvudtaget.

De som uppfann den trådlösa krypteringsmetoden WEP gjorde en katastrofalt dålig lösning som visade sig var extremt enkel att knäcka. Om man skyddar sitt trådlösa nätverk med WEP, är det i princip som att skicka data i klartext. Anledningen till problemet var att man inte förstått hur man krypterar säkert och gjort några nybörjarfel i designen. Lärdomen är att se till att man förstå området man ger sig in på innan man bygger sin lösning. Bara för att du själv inte kan hacka din egen lösning, betyder det inte att andra inte kan.

Och jag har själv gjort en tavla. Jag byggde ett autentiseringssytem i php som jag var mycket noggrann med att säkra. Alla inmatningar kontrollerades och sanerades. Databasanropen skedde med ett nedlåst konto. När jag provade att göra en SQL-injektion, lyckades jag hacka min egen lösning på första försöket Jag hade helt enkelt glömt att kontrollera datat från inmatningsfältet för lösenordet, vilket är det andra fältet som skickar data till applikationen. Lärdomen är att inte anta du gjort allting rätt för att du tycker att du kan området. En förmildrande omständighet var att jag faktiskt kollade säkerheten innan jag släppte applikationen lös på nätet.

Säkerhetsområdet kan vara svårt att förstå och jag tror att det korrekta sättet att hantera det är att vara öppen och låta andra titta på vad du gör. Se till att källkoden till det du bygger släpps fritt på nätet om du kan. Använd alltid testade och vedertagna principer när du arbetar med säkerhet. Försök inte göra allt själv och förlita dig inte helt och hållet på någon enstaka person som har rykte om sig att vara en guru.

4 april, 2019

Säkerhetsäggen finns fortfarande

Det är riktigt gammalt nu och jag minns att det pratades om det redan när jag började min karriär inom säkerhetsområdet. Jag talar om de berömda ägget. Alltså den där säkerhetslösningen som fungerade som ett enda hårt skal. Tog man sig igenom det, kom man åt det goda innanför utan hinder. Istället förordade man löken. Denna fantastiska ätbara tingest som hade lager på lager som måste tas bort innan man kunde komma någon vart. Precis så skulle säkerheten vara. Lösning på lösning där varje lager skyddade det nästa. Halleluja! Jag var på en föreläsning där man släppte ett riktigt ägg på en utvikt sopsäck och sedan släppte man en lök på samma sätt. Inga poäng om du lyckas gissa vilket som gick sönder och vilket som höll! Pedagogiskt och något effektsökande. Men idag är det väl inte så längre?

Kanske inte. I alla fall inte huvudsakligen. Men ändå på något sätt ska jag säga. En kompis till mig ringde för några dagar sedan och var överlycklig över att han hackat en Chromecast. Denna tingest, menade han på, var lätt att ta kontroll över. Huvudsakligen för att de har tjänster som är öppna och bjuder på lite motstånd till den som vill ta över dem. Själv roade jag mig med att hacka mitt eget Netgear NAS en kväll jag hade tråkigt. Så dessa enheter finns ju alltid. Och vad skyddar sådana tingestar?. Dörren till huset. I övrigt kan man ta sin dator och koppla in den på nätet och prata direkt med dem. Många ägg finns bland skrivare, scanners och TV-apparater som man kopplat in bland kontor-PCs på arbetsplatser. Ingen löksäkerhet så långt ögat kan nå. Men webbapplikationerna har brandväggar, reverse proxys och nås enbart via ett VPN med multifaktorautentisering. En riktig lök!

Sen hur ser det ut inne i applikationerna? Bland många organisationer jag varit ute på ser man samma mönster: numera får man inte ut så mycket data ur en katalogtjänst som Active Directory utan att autentisera sig. Men om du autentiserar dig med ett helt vanliga användarkonto är det mesta tillgängligt. De flesta attributen är läsbara du kan tömma hela personalkatalogen med några enkla LDAP-frågor från en dator med Kali-Linux på. Den webb-baserade personalkatalogen är skyddad av Kerberos och släpper bara ut utvald information, så där har du katalogtjänstens ägg mot personalkatalogens lök. En låst ytterdörr och en öppen bakdörr som ger dig både äggvita och ägg-gula. Ok, jag ska sluta prata ägg nu. Påsken är i instundande, så det kanske är rätt tid för det, men jag tror att jag lyckats få fram min poäng med denna diskussion.

28 mars, 2019

Misstag med sessionshanteringen i webbapplikationer

Låt oss vara lite tekniska för en stund. Autentisering, auktorisering och sessionshantering är en svår konst. Man vill att användaren ska loggas in på ett säkert sätt och att man inte ska kunna ta sig in i sessionen. Här är några vanliga misstag som görs av programmerare.

Session fixation

När man bygger en webbapplikation är det ganska vanligt att man använder sessions-id. Dessa är till för att man ska kunna hålla en användare inloggad. Det är en mycket känslig del av det hela rent säkerhetsmässigt. Den korrekta metoden är att logga in en användare och sedan sätta ett sessions-id därefter. Detta ska leva tills användaren loggar ur eller tills en viss tid uppnåtts. När jag utför pentester, stöter jag ofta på webbapplikationer som sätter sessions-id INNAN användaren loggar in och sedan använder samma sessions-id EFTER att du loggat in. I ett sådant scenario går det ofta att ta över användarens hela session med ett mail och lite social engineering.


Man skriver ett mail med en länk till applikationen som man ska hacka. Detta mail anger ett sessions-id som man själv hittat på. Användaren klickar på länken och loggar in som vanligt. Nu vet du denna användares sessions-id efter du själv bestämt det. Då kan du på din egen webbläsare ange samma sessions-id och gå in som användaren utan att behöva logga in.

cookies utan secure-flaggan

Ofta realiseras sessions-ids med cookies. Om man inte sätter flaggan ”secure” på dessa, kan man övertala applikationen att skicka dem över en klartextförbindelse. Genom att använda ett verktyg som sslstrip, kan en attackerare på det lokala nätverket få tag i giltiga sessionscookies.

sessions-id i get-metoden

Om man tillåter sessions-ids i address, som tillexempel www.sårbarsite.se/app?SESSION=235234532556768, kan en användare av misstag råka ge bort sin session via mail. Man bör också undvika att ta in variabeln via både get och post.

Sessionen tar aldrig slut

En session måste ha en klocka som räknar ner och avslutar sessionen när användaren varit inaktiv en viss tid. En del webbapplikationer byter även sessions-id när sessionen varit igång en viss tid. Men många webbapplikationer låter sessionerna lever i all evighet, eller har extrema värden som gör att en session kan vara inaktiv i veckor och fortfarande vara aktiv.
cookie utan httponly-flaggan

Mindre allvarligt, men ändå. En sessionscookie bör vara satt httponly, för att hindra att man på klientsidan kan manipulera den med javaskript-kod.

Ingen webcookie

En webcookie är ett värde som läggs till jämte session-id. Den måste finnas i anropen för att användaren ska kunna göra ändringar i webbapplikationen. En session är nämligen giltig i alla flikar i en webbläsare (Om man inte köra i inprivate mode). Detta gör att elak kod som körs i en annan flik kan göra ändringar i den webbapplikation du använder. Ofta saknas denna webbcookie, vilket gör webbapplikationen sårbar för en cross site request forgery-attack. Med en webcookie kan du bara göra ändringar i webbapplikation från den fliken du loggade in i webbapplikationen med. Detta kan skydda dig om du är inne och ändrar inställningarna i en routers webbinterface medan du surfar i en annan flik (Inte att rekommendera, dock!)

Ingen HSTS (HTTP Strict Transport Security)

HSTS är en HTTP Header som säger åt en webbläsare att ALLTID använda HTTPS mot en sida. Denna enkla mekanism gör verktyg som sslstrip verkningslösa. Tillsammans med secure-flaggan på sessionscookie, ökar de säkerheten enormt.
Ingen HTTPS

Detta borde inte vara ett problem idag, men det är det. Siter som hanterar inloggningar men inte har HTTPS finns fortfarande. Detta är ganska självklart ett problem. Men det finns fortfarande de som lever i det förgågna.
Så för att sammanfatta: det finns ett antal metoder man kan använda för att se till att användaren kan lita på att deras interaktioner mot din webbsida är säker. Använd dessa!

21 mars, 2019

Problemet med gamla prylar

Har du en router hemma som är 10 år gammal? Eller en trådlös accesspunkt från 2015 som du kör ditt nätverk genom? Detta kan visa sig vara ett problem. Första gången jag stötte på problemet var 2006 när jag läste om att en person hade klagat på en populär tillverkare av nätverksutrustning avsedd för hemmabruk. Han hade nämligen klagat på att han tidigare rapporterat ett allvarlig säkerhetshål i en av deras produkter och att de hade inte svarat eller gjort något åt detta problem trots att det gått flera månader sedan han hörde av sig. Detta verkar tyvärr vara ganska vanligt, men vad som är värre är när det överhuvudtaget inte kommer någon säkerhetsfix.

Din billiga hemrouter kan vara så gammal att tillverkaren helt enkelt inte skapar rättningar för den längre. De rekommenderar istället att man köper en ny modell och kör den istället. En del tillverkare av enheter man kopplar till nätet lägger in gamla versioner av Linux-kärnan som aldrig uppdaterats trots att det finns nya versioner.

Om man kollar efter uppdateringar eller nya versioner av firmware får man bara veta att ”du har den senaste versionen”, vilket gör det lätt att tro att allting är i sin ordning. Vi har diskuterat liknande problem med uppdateringar i tidigare inlägg på denna blogg. Men detta är ett separat problem och blir allt värre när mängden övergivna produkter blir kvar, uppkopplade på nätet.

Det finns idag ingen riktigt bra lösning på problemet, utom att möjligen välja produkter som har lite längre livslängd och byta ut dem när de inte längre underhålls. Detta kan innebära att du får köpa lite dyrare saker, men i längden blir både ditt hemmanätverk och Internet säkrare.

13 mars, 2019

Varför sårbarhetsskanningar inte räcker

Jag har märkt en intressant sak: många företag och organisationer blandar ihop säkerhetsskanningar med pentest. Ett pentest är när man på ett kontrollerat sätt försöker bryta sig in i ett system, medan en sårbarhetsskanning bara försöker hitta möjliga sårbarheter. Detta är mycket märkligt, men jag har sett det många gånger. Felet verkar även finnas bland de som jobbar inom området. För ett antal månader sedan hjälpte jag till att intervjua en arbetssökande till en tjänst som pentestare. Han berättade att han sökte tjänsten eftersom han var intresserad av säkerhet. Jag frågade vad han hade gjort för typer av säkerhetarbeten. Han sa att han kört programmet Nessus ett par gånger och lämnat över resultaten till någon annan att tolka. Nessus är ett program som hittar vanliga miskonfigurationer och säkerhetshål i tjänster. Ganska uppenbart kanske, men han fick inte jobbet.

Jag läste på ett forum för pentestare där en del personer beklagade av säkerhetsföretag säljer sårbarhetsskanningar som pentester. De betalar ett företag för att skanna av deras tjänster och komma med en automatgenererad rapport över ”allvarliga säkerhetshål”. Detta är knappt ett halvt pentest om ens det.

Betänk att pentest är en förkortning av penetrationstest, vilket innebär som ovan skrivet är att en inhyrd konsult eller flera försöker ta sig in i systemet. Lyckas de, lämnar de över en rapport som förklarar hur de tog sig in. Om ett försök att faktiskt hacka systemet inte görs, är det inte ett pentest. När jag gör pentester brukar jag faktiskt lämna in även hittade sårbarheter och miskonfigurationer, för att jag hittade dem på vägen när jag analyserade systemet för sårbarheter. Det tycker jag ingår i ett bra test även om det inte är huvudsyftet med det.

Så varför är inte en sårbarhetsskanning tillräcklig? Jo, för att den inte hittar problem med systemlogiken. Den kan se att en programvara har sårbarheter som potentiellt skulle kunna användas för att ta sig in. Men den kan inte hitta felaktigheter i hur t.ex. en webbapplikation hanterar inloggningen, som möjliggör att man tar över sessionen.

Sen är sårbarhetsskanningar dåliga på att hitta alla fel. Jag gjorde en gång ett pentest mot en webbapp och min programvara, Burp suite hittade ingenting. När jag klistrade in lite javaskriptkod direkt i ett inmatningsfält, hittade jag en möjlighet att köra javaskriptkod hos andra användare och läcka ut information den vägen. På så sätt kunde jag få ut data från andra användares ärenden (det var ett ärendehanteringssystem). Ett automatiserat program hade aldrig kunnat förstå vidden av problemet.

En annan attack jag gjorde mot en kund var att ladda upp ett dokument som i själva verket var ett litet program. Men detta kunde jag på under fem minuter ta över servern som körde webbapplikationen och även hela nätverket. Alla dessa attacker är värda oändligt mycket mer än att bara lämna in en rapport där det står att HTTP-protokollet stöder version 3.0 av SSL vilket inte är bra.

Om du anlitar någon att göra ett pentest på din miljö, se då till att du verkligen får vad du betalar för. Som jag skrev förut finns det många som säljer dåliga tjänster därute.

Scroll to top