Dansk hackerforum er blevet hacket

Det danske hackerforum Shellsec har fået en dosis af egen medicin og er blevet hacket.

Hackerforummet Shellsec er – ironisk nok – blevet hacket. Det informerer stifteren Morph3s om på Shellsec.org, der lige nu er taget ned på grund af hackingen.

Ifølge Morph3s er det vanskelig at finde ud af, hvem der står bag angrebet, og hvordan de er kommet ind, da der kun bliver logget minimale data om brugeraktivitet på siden.

Sandsynligvis er hackingen sket gennem et sikkerhedshul i webforumapplikationen MyBB, som endnu ikke er lappet. Forummet vil være lukket, indtil sikkerhedshullet er fundet og rettet.

Der informeres om, at alle passwords på siden er krypterede, og at man ikke som bruger skal være nervøs, så længe man har brugt et stærkt kodeord.

Kommentarer (26)

Casper Nielsen

Hvad lære man så af det Lasse? :)

Micki, når du hasher et ord/password, bruger du kryptografi, ergo kryptere du det :) so same same ..

Lars Kristensen

Well, Hashing benytter kryptopgrafi, men det er envejs-funktioner. Når noget "krypteres" skal det også kunne "dekrypteres" - og det kan man ikke med Hashing ;)
Jeg er ikke fan af ordkløveri, men lige i denne sammenhæng synes jeg det burde være vigtigt at pointere forskellen.

Per Gøtterup

Hashet data kan ikke genskabes... på en triviel måde. De kan genereres med bruteforce-metoder og så kan det hashen af det genererede sammenlignes med det hashede kodeord og på den måde kan data 'genskabes' eller hashingen reverseres.

Det er denne metode der benyttes til at 'bruteforce' et kodeord.

Der findes Rainbow Tables for de fleste hashing-metoder, også den som benyttes på ShellSec, og så kan hasingen reverseres for alle passwords i sådan en database på få minutter, timer, dage... afhængig af kvaliteten af det enkelte kodeord. Et rigtigt godt kodeord kan tage årtier at knække med bruteforcing, mens et dårligt let kan knækkes på sekunder.

Pelle Söderling

Per: Løsningen på Rainbow Tables er individuelle salts pr. bruger.
Med GPU løsninger idag er der stortset ingen der cracker password med Rainbow Tables mere, det er håbløs forældet.

Hvorfra ved du iøvrigt hvordan ShellSec har hashet sine passwords?
Hvis de ikke engang har styr på det, så står det skidt til vil jeg sige.

Martin Storgaard

Hashet data kan ikke genskabes... på en triviel måde. De kan genereres med bruteforce-metoder og så kan det hashen af det genererede sammenlignes med det hashede kodeord og på den måde kan data 'genskabes' eller hashingen reverseres.


Bare for at udvide terminologien lidt, så skal message digests fra kryptografiske hash funktioner (MD5, SHA1, SHA2, Keccak etc.) være svære at genskabe på en triviel måde, alt i mens hash funktionen i Rabin–Karp algoritmen blot skal være hurtig og gerne have en uniform fordeling.

Pelle Söderling

For at udvide endnu mere er der hash algoritmer udformet til forskellige formål. F.eks. er MD5 en populær algoritme til mange formål, fordi den er relativ hurtig og resultatet kan repræsenteres med få tegn (32 tegn i hex format).

Desværre gjorde populariteren og det at algoritmen er let tilgængelig i de fleste standard libraries at den også blev misbrugt til password hashes på rigtig mange sider da folk fik besked på at det nok var smart at hashe dem istedetfor at gemme dem i clear text. Det har så vist sig ikke at gøre en dyt forskel eftersom MD5 er så hurtig en algoritme at man kan bruteforce samtlige 6-tegns passwords bestående af store og små bogstaver, tal og standard symboler ved hjælp af GPU'en fra et std. grafikkort på ca. 2 minutter. Og avancerede dictionary attacks kan klare selv passwords såsom "Sh1a-labe0uf", "k1araj0hns0n" og lign. (læs mere her: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-ou... )

Der findes idag flere løsninger designet til passwordbrug, nogle af de mere populære værende bcrypt og pbkdf2.
Men det er stadig ikke nok blot at bruge en af disse løsninger - det er essentielt at man anvender en overordnet salt som kun findes på webserveren, kombineret med en unik identifier pr. bruger således at saltet individualiseres. Det er ligegyldigt at denne information er tilgængelig i databasen, pointen er at istedetfor det nu tager 1 måned at cracke hele databasen på et GPU-cluster, så tager det nu worst case 1 måned at cracke én brugers password. Ved at individualisere det har man altså lige skaleret problemet for crackeren op med antallet af brugere i sin database.

Pelle Söderling

Husk btw. at måle på hvor lang tid det i praksis tager at generere en hash for en bruger på jeres server - du ønsker reelt at det tager lige så lang tid som du føler du kan holde til på din server uden at det bliver et skaleringsmæssigt problem for dig (husk dog på at det ikke kun er ved brugeroprettelse at den skal genereres, men også ved hvert loginforsøg på siden - sætter du den for højt kan du risikere at loginforsøg kan bringe dig i knæ ved et DDoS på denne funktion).

Jeg plejer at targete 10-30 ms pr. hash, håber det giver lidt at gå efter.

Martin Storgaard

[quote id=241172]
Men det er stadig ikke nok blot at bruge en af disse løsninger
[quote]

Og uden at være ekspert i opbevaring af passwords, så går jeg ud fra man kan trække på fx TLS 1.2 som kombinerer MD5-SHA-1.

Herefter skal man selvfølgelig også spørge sig selv: Er opbevaring af passwords mit svageste led, eller kan man bryde ind andre steder? Ved Shellsec må svaret være ja, og som de rigtig nok gør, så leder de efter det brudte led og forstærker det.

I sådanne tilfælde må man jo sige, at det er godt man ikke også har gemt sine passwords i plain text :)

Pelle Söderling

Martin: TLS står for Transport Layer Security og omhandler ikke opbevaring af passwordet, men er self. relevant for at modtage passwordet fra brugeren på relativ sikker vis fra eks. en browser - der er dog ikke brug for nær samme sikkerhed her som når det skal opbevares i databasen.

At kombinere MD5 og SHA1 som begge er hurtige algoritmer der ikke er beregnet til password-hashing gør ikke den store forskel - selv i kombination er de ikke egnede til formålet.

Martin Storgaard

Er godt klar over hvad det betyder og hvornår det bruges (eller dvs. TLS 1.2 ikke er standard), men princippet er, at hvis den ene viser sig at være usikker, så håber man at den anden er mindre usikker.

Ligesom man med databaser og filsystemer benytter algoritmer, der først var designet til den ene formål og så bruger den til et andet (lignende) formål, kan man vel overfører idéen om at kombinerer flere algoritmer eller lave fler-trins verifikation som ved TLS.

Som sagt er jeg ikke password ekspert, men ideen om at tage sikkerhedsforanstaltninger fra andre systemer kan vel ikke være helt skidt? TLS, som du skriver, kan gøre et led i systemet mere sikkert. Fx at bruge SHA256 på et dobbelt salted password og derefter benytter bcrypt med x antal runder.

Jeg er ikke helt sikker på hvad bcrypt gør i praksis, udover at den xor ligesom de fleste kryptografiske hash funktioner. Hvis du har et link eller en forklaring på hvorfor bcrypt er bedre en fx Keccak (som bruger sponge function med x antal runder, og som standard outputter et 1024 bit message digest).

Jeg er specielt interesseret, da jeg lige nu er i gang med min bachelor om kryptografiske hash funktioner med test af SHA-3, hvor jeg bl.a. skal ind på password verifikation pros/cons. Jeg er endnu ikke kommet til at lave en kryptoanalyse af nogle af dem endnu (SHA1/2/3 og MD5), men ved at for at man skal kunne benytte sig af dem til password verifikation skal den være resistent overfor preimage attack/brute force, samt kollisions resistent.

Pelle Söderling

Til din afhandling bør du overveje at tage et kig på scrypt også, den løser nogle teoretiske problemer i bcrypt ved bl.a. også at være meget memory-krævende udover CPU krævende. Den er dog relativ ung og har ikke samme track-record som eks. bcrypt.

Grundlæggende handler password hashing om at gøre det så omkostningsfuldt som muligt at knække dem uden at gøre det alt for omkostningsfuldt at generere dem ved eks. oprettelse af bruger eller login-check - det er med andre ord en balancegang.

bcrypt og lign. algoritmer til passwordbrug er lavet til at være meget ressourcekrævende imodsætning til eks. MD5 og SHA1 som er lavet til at kunne beregne hash af en større mængde data med meget få ressourcer. De fleste algoritmer fungerer ved at du kan indstille antal iterationer og dermed kan du tweake hvor resssourcekrævende de skal være - det er vigtigt man rent faktisk måler på dette og tweaker i forhold til det ellers baserer man sig bare på rent gætværk.

Du kan godt køre mange iterationer på eks. MD5 også, men det er stadig at foretrække at benytte en algoritme som er specifikt designet til at tage hånd om de problemstillinger der er ved password-hashing, fremfor en der er designet til eks. CRC checking af indhold i store filer.

Martin Storgaard

Tak for dit svar. Jeg vil have det med i mine tanker når jeg skal ind på snakken om passwords og kryptografiske hash funktioner.

Fun fact: Jeg er lige blevet færdig med at teste den pseudorandom number generator jeg har lavet ud fra hhv. SHA-3, SHA-2, SHA-1 og MD5, som sammenlignet med java.util.Random's nextBoolean er MD5 mere uniform fordelt på det data set jeg har valgt, samt har mindre grupper af sekvenser af true. Dog har jeg ikke lavet en udtømmelig mængde af tests og slet ikke alle dem NIST anbefaler, men i de to tests så slår MD5 som den eneste java.util.Random :)

Pelle Söderling

Random numrer er også en interessant diskussion, men ønsker man "ægte" random numrer så er der ik nogen vej udenom at man har brug for en ekstern kilde - det kan ikke lade sig gøre at producere det ud fra en smart algoritme.

www.random.org har en masse gode dokumenter om problematikkerne og leverer også random data til download: http://www.random.org/files/ - der generes nye filer dagligt. Disse er baseret på atmosfærisk støj og er noget af det tætteste vi kommer på at være ægte random.

Andre løsninger inkluderer at måle på gamma-stråling.

Pelle Söderling

desuden er det reelt ikke specielt svært at slå java.util.Random i randomness - pseudo-randomness er også et tradeoff imellem hvor lang tid du ønsker at investere på at generere en værdi og hvor random du har brug for at værdien er.

java.util.Random er beregnet til general-purpose brug og er derfor "good-enough" random samtidig med at den ikke kræver alt for mange clockcycles.

Har man brug for noget mere seriøst end det er svaret oftest at gøre det ordentligt og ty til data fra en ekstern kilde - såsom random.org.

Pelle Söderling

Ser jo umiddelbart fornuftigt nok ud og ja ihvertfald betydeligt bedre end PHP's rand() ;-)

Jeg formoder dog at det er en relativ langsom metode at anvende MD5 i den forbindelse - har du lavet nogle timings på hvor godt din metode performer sammenlignet med eks. java.util.Random?

Martin Storgaard

Jeg har godt overvejet at time det, men du har ret. Jeg kan se med øjemål når min test suite kører at alle andre, og især Keccak/SHA-3 er en del langsommere end simpele modulo operationer. Korrekthed og hastighed er vel oftest et tradeoff, så det giver god mening at lave statistik (som jeg har gjort) for at måle "korrekthed" og så måle hastighed, for at se om det kan "betale sig" med denne grad korrekthed.

Jeg har det med i mine tanker :)

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Kvinder med passion

Hvornår: 2015-11-17 Hvor: Storkøbenhavn Pris: kr. 2990.00

Diplom i stærkstrømsteknologi

Hvornår: Hvor: Fyn Pris: kr. Efter aftale

Dynamics NAV 2013 - Økonomistyring

Hvornår: 2015-09-07 Hvor: Østjylland Pris: kr. 4200.00

Advanced Solution of Microsoft SharePoint Server 2013 [20332]

Hvornår: 2015-10-19 Hvor: Østjylland Pris: kr. 19500.00

Customization and Configuration in Microsoft Dynamics CRM 2013

Hvornår: 2015-09-28 Hvor: Storkøbenhavn Pris: kr. 11700.00