Nicolai Hansen

It-efterforsker: CSC-hacker lavede første bagdør gennem ’zero day’-sårbarhed i IBM's mainframe

Der blev brugt en zero-day mod Logica/CGI, men den blev "kun" brugt til at eskalere rettigheder.

22. september 2014 kl. 14:55
Ny trend: Åbenhed om cyberangreb

Jeres eksempler bygger på da Evernotes mistede millioner af brugeroplysninger, og så var de ude med et tweet om at de var udsat for et DDoS angreb? Og P.F. Chang som indrømmede at de var udsat for en sikkerhedsbrist flere uger efter at kreditkort var begyndt at blive misbrugt, og efter at Brian Krebs havde afsløret det på sin blog?

Hvis noget, så er virksomheder blevet dårligere til at melde ud når de har været udsat for en sikkerhedsbrist. Omdømme og PR er så meget vigtigere end brugerdata i hænderne på russiske hackere.

11. september 2014 kl. 09:20
Læk afslører GCHQs overvågningsteknikker

UNDERPASS: Change outcome of online polls (previously known as NUBILO). BOMB BAY: is the capacity to increase website hits/rankings. GESTATOR: amplification of a given message, normally video, on popular multimedia websites (Youtube). SWAMP DONKEY: is a tool that will silently locate all predefined types of file and encrypt them on a targets machine

16. juli 2014 kl. 12:25
Kikset kryptering gjorde det nemt at afsløre alle New York-taxaers kørsel

Altså hvis man UDVIDER datasættet med saltet, så ville det jo "bare" gøre beregningen 86,5 millioner gange mere ressourcekrævende, men dette er stadig forholdsvis nemt for en kraftig computer at komme igennem.

Den rigtige løsning ville naturligvis være ikke at offentliggøre disse salts, så man ikke kan bruteforce sig frem til de oprindelige data.

28. juni 2014 kl. 23:20
Version2 ramt af spam-bølge

Hvis du benytter en RSS læser til at læse nyheder fra V2, så skal du se spam. Tror der har været i omegnen af 100 "nyheder" (punkter i RSS feeded) som indeholder alverdens links til nonsens.

Det er btw ikke første gang V2 bliver ramt af en spam bølge, men dejligt at se at I er hurtige denne gang (spam bølger der varer flere uger er godt nok irriterende).

16. juni 2014 kl. 21:03
Computernetværk nærmer sig monopol på bitcoin-beregninger

Det giver dig ikke magiske kræfter at få 51% af regnekræften, og alle double-spend forsøg kan ses af hele netværket, så med det samme GHash (eller andre) skulle få lyst til at prøve at misbruge deres kræfter vil de ikke kun få bitcoin community efter sig, men også alle de invenstorer som har gjort GHash muligt, samt de vil underminere dét de selv har invensteret tusindvis af dollars i.

16. juni 2014 kl. 14:04
Pirate Bay-grundlægger arresteret for brud på ophavsret

Han blev frikendt fra at have hacket Nordea, men ikke Logica.

2. juni 2014 kl. 13:20
Mystik: Er Truecrypt-kryptering blevet usikker?

Jo, jeg tror også han tænker på WikiLeaks' "insurance"-fil, men den er krypteret med OpenSSL.

Hvad angår "simpel" file container kryptering, så er både implementeringen og de krypteringsalgoritmer man kan vælge imellem i TrueCrypt, blevet tjekket igennem så mange gange at det er noget af det bedste vi har (ergo skulle der være en alvorlig fejl i dette, så kan vi ikke vide os mere sikker ved at vælge et andet stykke software).

Jeg tror man skal passe på med at gætte. TrueCrypt har altid været omsvøbt med mystik, og gårsdagens melding er underlig på mange forskellige måder. Forhåbentligt vil tiden vise hvad denne melding i virkeligheden betyder, men jeg ville ikke være for hurtig til at skifte til BitLocker eller FileVault.

30. maj 2014 kl. 14:14
Myndigheder vil granske eBay efter læk af 145 millioner brugeres data

Jeg er på ingen måde i tvivl :)

Hvis du kryptere noget, så gør du det fordi du vil have adgang til det oprindelige indhold igen: E(key,data) = ciphertext D(key,ciphertext) = data

Har du ikke brug for denne egenskab skal du ikke kryptere dit data. Der er ingen grund til at en tjeneste som eBay skal have adgang til dit klartekst kodeord. De skal kunne verificere dig, hvilket kan gøres uden kendskab til dit klartekst kodeord (fx via en langsom+hukommelsestung hash funktion).

Det er ufatteligt træls at se på den ene "+10M bruger"-virksomhed efter den anden, blive hacket og så finde ud af at kodeord var gemt i klartekst (eller hashet én gang med MD5, krypteret med DES, etc).

De der hackede eBay havde medarbejder-adgang over en længere periode. Det sværeste er at skaffe sig adgang, når man har adgang er det typisk en smal sag at skaffe sig mere adgang (se bare Snowden). Hvis eBay ikke har lagt mærke til at medarbejder konti er blevet misbrugt over en længere periode til at kopier en gigantisk database ud af deres netværk, og de ikke har været forebyggende ved at sørger for at brugerkodeord var hashet forsvareligt, så skal man næppe satse for meget på at de har passet godt på deres (de-)krypteringskode.

Derfor er det altid en uheldig situation især når en "krypteret" password-database kompromiteres.

En sidste bemærkning er at Skyen er hurtig/god/billig til mange ting, men lige netop "kodeord cracking" er det en meget dyr fornøjelse og kan ikke anbefales.

30. maj 2014 kl. 13:58
Myndigheder vil granske eBay efter læk af 145 millioner brugeres data

Det sidste halve år har der været utallige datalæk og ved HVERT ENESTE er det blevet pointeret at hvis "brugernes adgangskoder er krypteret", så er det en KATASTROFE!

Men alligevel fortsætter I med at få det til at lyde som en god ting at koderne ligger gemt krypteret...

27. maj 2014 kl. 02:15
IBM Mainframes er en sikkerhedsrisiko

Mainframed, en sikkerheds researcher indenfor mainframes, giver phk ret sin kritik her: http://mainframed767.tumblr.com/post/79167015212/please-dont-post-on-mainframe-forums

Et andet interessant aspekt han har fokuseret meget på er alderen af den gns. mainframe admin, som meget snart bliver et stort problem: http://mainframed767.tumblr.com/post/36576972782/the-racf-age-gap

8. maj 2014 kl. 16:37
'Ekstremt kritisk' sikkerhedshul i Linux - opdater nu

Hvordan kan denne fejl være mere kritisk end Apples "goto fail", når "goto fail" fejlen var så kritisk som det overhovedet kunne blive.

Hvilket (realistiske) scenarier kan man udnytte ved denne fejl, som ikke også kan udnyttes ved "goto fail"-fejlen?

5. marts 2014 kl. 11:19
Bitcoin-kursen falder drastisk efter tekniske problemer

Problemet er at når man hos Mt. Gox vælger at få udbetalt sin balance i bitcoins, så laver Mt. Gox en transaktion og udsender den til bitcoin P2P netværket, samt tager et hash af transaktionen, hvilket benyttes til at holde styr på hvornår transaktionen er bekræftet.

Transaktionen er signeret, så det er IKKE muligt at ændre beløbet eller modtager / afsender. Dog tillader OpenSSL (som desværre benyttes i stor stil) at man kan ændre på visse dele af signaturen uden at den brydes. Det er lidt i stil med at "1+2=3" men OpenSSL tillader også at man skriver en masse 0'er foran tallet og så holder matematikken stadig: "0001" == "1", så "0001+2=3", dog ændres hashet af transaktionen, da hash(1+2) != hash(0001+2).

Pga dette er det muligt, hvis man er hurtig nok (en slags race-condition) at tage transaktionen fra Mt. Gox, ændre signaturen uden at bryde den, og få den sat ind i bitcoin blockchainen. Da de samme bitcoins ikke kan sendes flere gange (ingen "double spending") vil den transaktion Mt. Gox har gemt være umulig at få ind i blockchainen, da den modificerede transaktion allerede er derinde, og vil den stå som "stuck" i Mt. Gox custom system.

Hvis man derefter kontaktede Mt. Gox og sagde "af en eller anden grund har jeg ikke modtaget mine bitcoins" og fik Mt. Gox supporten til at undersøge sagen, så kunne de se at transaktionen stod som "stuck" og med lidt social engineering var det muligt at få dem til at sende nogle nye bitcoins (lave en helt ny transaktion med helt nye bitcoins).

Det var altså en fejl som kun ramte Mt. Gox, krævede at man vandt en race condition og social engineering.

Det er bestemt farligt at OpenSSL tillader "malleability", og det er en nem fejl at begå at tage et hash af transaktionen og benytte det som en identifier, men problemet har været kendt siden 2011 og der har været arbejdet med at gøre det sværre at udnytte lige siden.

Alle "standard" klienter benytter ikke et hash af transaktionen, og falder altså ikke i fælden. Det er kun custom software som er i fare.

11. februar 2014 kl. 19:30
Fransk direktør dropper retssag mod danske Secunia

Rene Madsen: Den PoC som crasher tidligere versioner af VLC findes frit tilgængeligt på Full Disclosure mailing listen og Secunia vedhæftede den også i deres første mail til VLC.

Mogens Hansen: VUPEN lever ikke af at skræmme alm. computer brugere, faktisk lige det modsatte - hvis du tror at dit software er sikkert, så er du et nemmere offer. VUPEN lever af at sælger exploits til regeringer, ikke sælge AntiVirus-produkter. VUPEN består af en stor gruppe mennesker som er nogle af de bedste indenfor deres felt, så derfor er det ENORMT relevant når de træder ind i sagen og siger at fejlen er mere alvorlig end VLC gør den. Hvem ville du ellers hive fat i? VUPEN kan deres kram, og har ingen interesse i "VLC vs Secunia"-sagen.

Se også første kommentar på VLC bloggen (har stået der i lang tid): companys like VUPEN would do just that

11. juli 2013 kl. 22:02
Hackere bryder igen ud af Chromes sikre sandkasse

"omgå Windows' sikkerhedsmekanismer DEP og ASLR ved at udnytte sårbarheder i Windows-kernen" - nej, DEP kan omgås ved hjælp af en trick kaldet "ROP", men for at kunne gøre dette (ROP), skal man omgå ASLR, hvilket kan omgås hvis ikke alle elementer i hukommelsen er flyttet tilfældigt rundt.

Når dette så lykkes, så kan koden stadig kun køre med de privilegier brugeren har, hvilket man kan omgå via fejl i Windows-kernen (privilege escalation).

7. marts 2013 kl. 17:10
Evernote hacket: 50 millioner brugere skal skifte kodeord

Kan se at det var en lidt gammel blogpost jeg fandt frem til (2011), men jeg tvivler desværre meget på at de har ændret deres måde at gemme passwords på: http://blog.evernote.com/tech/2011/05/17/architectural-digest/

Morten Wegelbye Nissen: MD5 skal ikke bruges til digitale certifikater, da man 'nemt' kan finde kollisioner (og det er kun (MD5)hashet som er signeret). Men når vi gemmer passwords, er vi ligeglade med dette. Hvad vi er interesseret i, er at finde en langsom algoritme. MD5 er beregnet til at hashe mange hundrede megabyte pr sekund, så en enkelt gang MD5(DATA) kan ikke bruges. Hvis man vil bruge MD5, så lav et stort loop: FOR(i=0; i<100.000; i++){ hash = MD5(hash+password+salt); } Havde Evernote brugt et loop med 100k iterationer, så ville det kræve 5,000,000,000,000 MD5 hash operationer for at tjekke ét password mod databasen. Altså vil man teste hvem der bruger koden "12345678", kræver det 5 billioner MD5 hash operationer, og vil man se hvem der bruger koden "superman" kræver det endnu engang 5 billioner MD5 hashes, osv..

Bedst er at bruge pbkdf2/bcrypt eller en anden algoritme beregnet til at håndtere passwords. Dog er det stadig meget vigtigt at sige, at SHA1/2/3 eller HMAC-MD5 ikke løser problemet. Fx LinkedIn som brugte SHA1 og ingen salts var meget værre end Evernote hvad angår sværhedsgraden af at bryde deres hashes. MD5 + salts = meget bedre løsning end SHA1 uden salts.

("problemet" ved sikker password hashing er at det kræver mere serverside kraft, end fx en enkelt gang MD5(data), så husk også at begrænse hvor mange passwords man kan prøve (pr tid), så man ikke kan DoS'e serveren ved at sende en masse lange passwords hele tiden).

5. marts 2013 kl. 02:52
Evernote hacket: 50 millioner brugere skal skifte kodeord

Koderne er hashed, ikke krypteret. Havde de været krypteret, kunne hackerne bare decryptere dem. Man kan heller ikke kryptere noget med en hash funktion, da en hash funktion er en en-vejs funktion.

Det er rigtigt at Evernote brugte salts, men det betyder ikke at koderne er "sikkert opbevaret". Evernote skriver i en kommentar på deres blok, at koderne er hashet med MD5, men de skriver intet om PBKDF2 eller at koderne har været igennem flere gange MD5-iterationer, så man kunne gætte på at koderne er gemt i databasen som: hash = md5(kode+salt) hvilket bestemt ikke er sikker opbevaring!

4. marts 2013 kl. 16:03
Ny tæller: Så ofte bliver du registreret, når du surfer

"gør det nu muligt at se præcist, hvor mange gange din færden på nettet bliver registreret af teleselskaberne" - nej, den prøver så vidt muligt at vise hvor mange gang man blive logget mens man surfer, men den er bestemt ikke præcis (det kan ikke laves som en Chrome Extension). Det rigtige tal er højere en hvad den kan se.

22. februar 2013 kl. 14:31
Surhed over skeptiske it-folk

Jeg er meget enig hvad du skriver, meeen synes dog godt lige at beskrivelsen på kategori 1 kunne finpudses lidt.

Kritik for.. tja kritikkens skyld, er spild af tid, men om kan kan lide Firefox (og Chorme ikke kan de samme som Firefox - fx avanceret realtids manipulation af en http header) har vel ikke noget med dét at gøre? :-)

14. februar 2013 kl. 17:32
Ekstra Bladet lagt ned i cyberangreb

"Ved et SYN-flood attack sender angriberen en lang række SYN-forespørgsler til serveren, men undlader at svare på de SYN-ACK-meddelelser, der kommer retur." - Hvis IPen er spoofed, så kommer SYN-ACK beskederne vel ikke retur til angriberen (men til den spoofede IP)?

7. februar 2013 kl. 16:19