Archive for the ‘Läsvärt’ Category

Riktigt elak hårdvara

Wednesday, April 30th, 2008

USENIX-konferensen Large-Scale Exploits and Emergent Threats 08 (LEET08!) presenterade Samuel T. King, Joseph Tucek, Anthony Cozzie, Chris Grier, Weihang Jiang och Yuanyuan Zhou en mycket intressant artikel om hårdvarubaserade trojaner.

LEET-logga

Artikeln Designing and Implementing Malicious Hardware, som utsågs till konferensen bästa artikel, är något av det mest intressanta och skrämmande jag läst på länge. Artikelns sammanfattning beskriver väl vad den handlar om:

Hidden malicious circuits provide an attacker with a stealthy attack vector. As they occupy a layer below the entire software stack, malicious circuits can bypass traditional defensive techniques. Yet current work on trojan circuits considers only simple attacks against the hardware itself, and straightforward defenses. More complex designs that attack the software are unexplored, as are the countermeasures an attacker may take to bypass proposed defenses.

We present the design and implementation of Illinois Malicious Processors (IMPs). There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one specific attack, can instead design hardware to support attacks. Such flexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware.

We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well.

Malicious processors are more practical, more flexible, and harder to detect than an initial analysis would suggest.

Författarna börjar med att beskriva hur olika attacker rört sig nedåt från applikation och OS till firmware och till virtualiseringssystem. Men, frågar sig författarna, hur svårt är det att modifiera en hårdvarukonstruktion, en processor, så att den dels gör systemet som kör på hårdvaran osäkert, och om det går att göra så att systemet inte märker av modifieringen.

Författarna har valt att modifiera open-source-processorn LEON3 från Göteborgsbaserade Gaisler Research.

LEON3-processorn är placerad i ett högst ordinärt och typiskt HW-system med USB-kontroller, VGA-kontroller m.m. På LEON3-processorn kör man sedan ett normalr GNU/Linux-system. Hela klabbet har realiserats på en Xilinx-FPGA.

I LEON3 har man sedan implementerat olika attacker. Den första attacken är en modifiering till LEON3-processorns MMU som gör att en process som känner till modifieringen kan trigga procesorn att ignorera minnesskydd och låta processen ge sig själv rootaccess. Författarna förklarar:

Our memory access mechanism provides hardware support for unprivileged malicious software by allowing access to privileged memory regions. Malicious software triggers the attack by forcing a sequence of bytes on the data bus to enable the memory access circuits. This sequence can be arbitrarily long to avoid false positives, and the particular sequence must be agreed upon before deployment.

Once the sequence is observed, the MMU in the data cache ignores CPU privilege levels for memory accesses, thus granting unprivileged software access to all memory, including privileged memory regions like the operating system’s internal memory. In other words, loading a magic value on the data bus will disable protection checking.

We implement this technique by modifying the data cache of our processor to include a small state machine that looks for the spe-cial sequence of bytes, plus some additional logic in the MMU to ignore privilege levels when malicious software

Författarna beskriver även en shadow-mod som gör det möjligt att gömma trojan genom att skapa en extra processormod, och kod som körs i denna mod döljs från resten av systemet. Denna shadow-mod används sedan av författarna för att implementera en funktion som snor lösenord samt ett sätt att implementera en bakdörr rätt in i OS:et. Mycket imponerande, fräckt och skrämmande.

Det författarna visar är hur lite som krävs för att implementera den här typen av funktioner. Författarna lade till mindre än 200 rader kod till VHDL-koden LEON3 består av. Minnesmodifieringen krävde knappt 1000 gates och shadow-funktionen drygt 1300 gates. Närmast avrundningsfel i en modern HW-konstruktion.

Författarna avslutar sin artikel med en diksussion om hur man kan skydda sig mot den här typen av attacker. Bla om man kan använda sidoeffekter för att detektera om en krets utför operationer man inte tänkt. Författarna konstaterar att det i dag antagligen finns få/inga vettiga skyddmekanismer, vilket jag håller med om.

Frågan man bör ställa sig i det här läget är dock: Men hur stor är risken egentligen?

Som exempel på ett ökande risk för trojaner i hårdvarukonstruktioner citerar författarna en rapport från USAs Department of Defence Science Board som bland annat skriver att

First, it has become economically infeasible to procure high performance ICs other than through commercial suppliers. Second, these commercial suppliers are increasingly moving the design, manufacturing, and testing stages of IC production to a diverse set of countries, making securing the IC supply chain infeasible. Together, commercial-off-the-shelf (COTS) procurement and global production lead to an “enormous and increasing” opportunity for attack

Att det finns problem med äktheten hos kretsar visar om inte annat att det nu bildas organisationef för att försöka stävja den snabbt ökande förekomsten av piratkopierade kretsar.

Det är inte så svårt att tänka sig att dessa kretsar skulle kunna innehålla mer än den piratkopierade konstruktionen. Man får ett mervärde man kanske inte hade tänkt sig. (Tomas Gilså uppmärksammade detta i en artikel om risker med piratkopierade routrar och switchar - ja jag är citerad.

På Cryptography-listan kommenterade Karsten Nohl trenden mot snabbt ökande komplexitet på chipnivå och användningen av IP-cores med:

Hardware designs currently move away from what in software would be open source. Chip obfuscation meant to protect IP combined with the ever increasing size of chips makes it almost impossible to reverse-engineer an entire chip.

Helt sant. I dag bygger man chip med allt fler och allt större IP-cores. Men hur vet man att dom faktiskt bara gör det dom säger att dom gör. Att kontrollera att konstruktionen följer en spec är en sak, men att visa att den även kan göra något mer?

Så möjligheten att modifiera konstruktioner, och den vägen få in en elak HW-funktion finns, frågan är om det finns kompetens och motivation? Kompetens kan man tyvärr köpa, så frågan är om någon är intresserad. Skall man döma av den snabbt ökande ekonomiska IT-brottsligheten finns det en hel del som är beredda att jobba hårt och lägga mycket pengar på att vara elaka.

Den här artikeln har uppmärksammats en del på krypto- och säkerhetslistor. Även Matt Blaze har bloggat kloka tankar som är värda att läsa. I diskussionen på Cryptography påpekades det att mikrokoden i Intels och AMDs processorer går att uppdatera. Hur kontrolleras att den mikrokod som laddas ner är ok? Någon som vet?

Jag tycker att artikeln som presenterades på LEET08 är mycket, mycket intressant. Och jag hoppas att artikeln får uppföljning i form av metodik och verktyg för att inspektera HW-konstruktioner och chip. Jag tror att vi kommer att behöva återkomma till den här frågan.

Bra introduktion till Pythons generatorer

Wednesday, April 30th, 2008

(Det börjar bli en del om Python här…. Jag har skapat en kategori för Pythonrelaterade postningar.)

För några veckor sedan bloggade jag om Pythons generatorer, vilka bland annat är utmärkta för att implementera strömkrypton, slumptalsgeneratorer etc.

För några dagar sedan sprang jag på en bra presentation som ger en introduktion till Pythons generatorer. Den klart bästa förklaring till vad generatorer är och hur man arbetar med dom. Väl värd att bläddra igenom.

En titt i FRAs årsredovisning och budgetunderlag

Thursday, April 3rd, 2008

FRA har publicerat en öppen version av sin årsredovisning för 2007.

FRA:s logga

FRAs generaldirektör Ingvar Åkesson kommenterar årsredovisningen med:

Det ligger i sakens natur att mycket av det som FRA gör är hemligt. Den öppna redovisning för 2007 som publicerats här blir därför rätt knapphändig i jämförelse med den hemliga version som regeringen och Riksrevisionen får. Det gäller särskilt avsnittet om rapportproduktion, det vill säga där vi beskriver hur vi har tillgodosett uppdragsgivarnas behov av underrättelser.

Trots knapphändigheten tycker vi ändå att den öppna redovisningen kan ge en uppfattning om FRA:s verksamhet och vilka utmaningar FRA står inför.

Trots detta tycker jag att det finns en hel del intressanta saker i årsredovisningen. En intressant sak är GD:s beskrivning av årets verksamhet som bland annat speglar FRA:s syn på den debatt som varit vad gäller utökade befogenheter för FRA:

Året har dominerats av lagstiftningen om en anpassad försvarsunderrättelseverksamhet och om personuppgiftshanteringen i myndighetens verksamhet. Inom myndigheten har sedan några år bedrivits ett arbete med att anpassa verksamheten och de interna föreskrifterna till den kommande lagstiftningen. Detta arbete accelererade under året och fick högsta prioritet. De lag- och förordningsbestämmelser som trädde i kraft under året har utan problem kunnat tillämpas av FRA.

Den uppmärksamhet som lagförslagen har fått i den offentliga debatten har krävt ett omfattande arbete i kontakterna med massmedia. Syftet har varit att nyansera den negativa bild av FRA som på sina håll manas fram och att komma till rätta med de missuppfattningar som råder.

FRA har även en sektion på sin webbplats med det tjusiga namnet Klartext där FRA bemöter vad de ser som felaktigheter i debatten. Bland annat kommenterar man flera uttalanden av Pär Ström.

En intressant sak jag fastnade för i årsredovisningen är det FRA skriver om sitt kryptoarbete under året:

Forceringsverksamheten har under året varit synnerligen framgångsrik. Vidare har flera helt nya kryptosystem identifierats och bearbetats.

Betydande arbete har under året lagts på inköpet och leveransen av en ny beräkningsdator. Genom den beräkningskraft som den nya beräkningsdatorn har kommer FRA framöver att ha ännu större möjligheter att forcera meddelanden.

Undrar vilka helt nya kryptosystem man identifierat och bearbetat… Gissningsvis är det inte KeeLoq eller MiFare. ;-)

I årsredovisningen berättar FRA att anslagstilldelning för 2007 var 512 517 tkr. FRA har även publicerat en öppen version av FRAs budgetunderlag för de kommande tre åren.

Den kanske viktigaste punkten i budgetunderlaget är att FRA ser att man behöver ökade anslag för att möta de som FRA ser snabbt ökande behoven av FRAs tjänster. På kryptosidan skriver FRA att:

Användningen av krypton har ökat markant de senaste åren. Så kallade massmarknadsprodukter, dvs. krypton som kan användas av gemene man och därmed även av terrorister och andra brottslingar, blir allt vanligare och komplexare. FRA kommer att behöva möta denna trend, bland annat genom att satsa på investeringar i beräkningskraft, omfattande forskning och utveckling, men också genom att utöka antalet kryptologer.

FRA fick från och med 2007 ett ökat anslag för att regelbundet med kortare intervall investera i utökad beräkningskraft. Till följd av den urholkning av anslaget som oavlåtligt sker i och med att FRA inte får full kompensation för pris- och löneutvecklingen, kommer denna anslagsökning under perioden 2008-2019 inte att räcka till mer än en ytterligare investering i beräkningskraft.

Detta innebär att beräkningskraften i praktiken endast kan förstärkas vart sjunde eller åttonde år. Detta är helt otillräckligt för att FRA ska kunna följa med i den snabba tekniska utvecklingen på kryptoområdet, kunna motsvara de krav FRA:s verksamheter har samt kunna upprätthålla en god kryptoförmåga såväl nationellt som internationellt.

Speciellt intressant på detta området är att FRA ser ett behov att inrätta och finansiera en ny professur:

Kryptologisk grundforskning för nationella behov behöver stimuleras. En större samordning behövs mellan FRA och tekniska universitet och högskolor. FRA anser det nödvändigt att få finansiera en professur i matematik med inriktning mot kryptologi och datasäkerhet på lämpligt lärosäte och få medel att inrätta doktorandtjänster vid FRA.

Det kan även ge möjlighet för kryptologer på FRA att forska och disputera. Allt detta skulle långsiktigt ge Sverige möjlighet att vidmakthålla sitt internationellt goda renommé på området. Denna forskningssatsning skulle inte bara skapa en bättre grund för kryptologins utveckling i Sverige utan också gynna signalunderrättelseverksamheten och FRA:s informationssäkerhetsarbete.

Långsiktigt skulle denna forskningssatsning också vara av betydelse svensk tillväxtindustri inom telekom- och IT-säkerhetsområdet.

Totalt är behovet medel för en professur och fem årsarbetskrafter för att utveckla kryptologisk grundforskning.

Som utomstående kryptonörd som ägnar tid åt att bevaka vad som händer på den öppna kryptoforskningen är jag böjd att hålla med FRA. Med undantag för Thomas Johansson och hans grupp på LTH tycker jag att Sverige är extremt dåligt representerad i internationella kryptoprojekt och konferenser.

Det handlar inte bara om att publicera en enstaka artikel utan att delta i ECRYPT, NISTs AHS-arbete, vara med på workshops och konferenser och delta i diskussioner. Svensk industri är, tyvärr som vanligt i den här typen av sammanhang, väsentligen helt osynlig.

Om FRA kunde sponsra offentlig forskning och det därmed skulle innebär en totalt sett ökad satsning på krypto och IT-säkerhet tror jag att det vore det riktigt bra, både för Sverige som nation och Sveriges industri. Frågan jag spontant ställer mig är hur FRA-professorn och dennes doktorander skulle tas emot av resten av forskningsvärlden.

En annan sak som framkommer i budgetunderlaget är att FRA verkar vilja flytta fram sina positioner inom IT-säkerhet. FRA skriver:

Behovet av säkra IT-system blir allt större och inkluderar fler områden. Den verksamhet som FRA bedriver inom området är efterfrågad. FRA:s affärsidé inom informationssäkerhetsområdet bygger på att arbeta förebyggande för att kunna minimera de mer akuta reaktiva insatserna. Det förebyggande arbetet består främst av aktiv IT-kontroll (penetrationstester), specifik rådgivning till kund (säkerhetsanalys av system och nätverk), stöd vid policyarbete samt allmän utbildning (demonstrationer, deltagande i seminarier och mässor).

Informationssäkerhetsbranschen är mycket konkurrensutsatt, vilket kan göra det svårt att behålla personal med tillräcklig spetskompetens. I verksamheten bedrivs omfattande kompetensutveckling. Personalen är en kritisk framgångsfaktor. Marknadskonkurrensen är en riskfaktor att räkna med.

Av det jag vet om FRAs kompetens på IT-säkerhetsområdet är jag klart imponerad. Men samtidigt är jag mer tveksam till att FRA som myndighet med en budget på drygt en halv miljard skall vara speciellt aktiv på en marknad som FRA själv uttrycker det är mycket konkurrensutsatt.

Det finns helt klart situationer där rent kommersiella verksamheter av olika skäl inte är lämplig, men jag är rädd för att FRA här riskerar att snedvrida marknaden och därmed långsiktigt försämra Sverige förmåga inom IT-säkerhet.

Slutligen ser FRA att man har ett relativt akut behov av att förnya och anpassa sina lokaler till dagens verksamhet.

IDG har publicerat en artikel om FRAs kommande budgetunderlag.

Avlyssningsbild från IDG.

En annan artikel hos IDG om FRA tar upp att TeliaSonera flyttar epost-servrar till Finland för att inte riskera att deras Finska kunders epost skall läsas av FRA.

Allt du vill veta om minnessystem

Thursday, March 20th, 2008

Ulrich Drepper, pappa till glibc, har skrivit ett imponerande dokument om minnessystem kallat What Every Programmer Should Know About Memory.

Ulrich Drepper

Dokumentet är en genomgång av väsentligen allt du som programmerare (och andra) skulle kunna vara intresserad av vad gäller minnessystem.

Från grundläggande koncept som vad en minneshierarki är, vad som menas med sidor, rader och block och vad ett cacheminne är till information om hur ett DD3-minne arbetar, cache trashing i multicore-system, olika typer av uppdateringspolicy för cacheminnen, minnessystem med icke-uniform access (NUMA, COMA) och mycket, mycket mer.

Det här dokumentet innehåller material motsvarande en rejäl högskolekurs i datorarkitektur och jag önskat att jag hade haft det här dokumentet när jag började arbeta med processor- och datorarkitektur. Och jag är glad att jag har det nu.

Dokumentet är inte utan sina fel och brister, det erkänner Drepper själv utan omsvep i sin blog. Men av det jag har läst tycker jag att han inte bara har bra koll på såväl övergripande koncept såsom detaljer, utan har även en förmåga att uttycka dom.

Och varför skall du nu läsa detta dokument? Speciellt med tanke på IT-säkerhet? Jo, därför att dokumentet bland annat förklarar varför varianser i accesstid till en tabell med data (exempelvis en S-box i ett krypto) kan uppstå, vilket kan leda till oönskade sidoeffekter.

I en tid när antalet processorkärnor går upp (kärnor som på olika sätt är kopplade till varandra via ett delvis gemensamt minnessystem) blir det allt svårare att gissa hur minnesaccesser och därmed exekveringstiden för ett program kommer att fungera. Att som programmera då kunna läsa på vilka effekter som kan uppstå och hur man kan mäta och hantera dessa effekter är helt klart ett steg framåt.

Security Power Tools

Thursday, February 14th, 2008

Jag har en ny bok i mitt bibliotek med IT-säkerhetsböcker: Security Power Tools.

Security Power Tools

En av mina absoluta favoriter bland IT-böcker är O’Reillys klassiker UNIX Power Tools(UPS), och både namn och beskrivning av den nya boken försöker göra gällande att Security Power Tools (SPS) är en nära släkting till UPS.

UNIX Power Tools

Nu har jag inte hunnit så långt in i SPS, men någon UPS är den inte. En stor skillnad är att den nya boken ägnar ganska stora textmassor att förklara hur IT-system fungerar och vilka säkerhetsproblem som finns. UPS bryr sig inte om sådana saker, utan där är det sida upp och sida ner med smarta tricks och sätt att snabbt lösa problem.

Vad böckerna har gemensamt är att man utifrån ett scenario tar fram kända verktyg och applicerar dom. Men UPS tar exempelvis upp scenarion som hur man flyttar filer från en katalog till en annan, och sedan visar 100 olika sätt att göra detta på - beroende på om du skall flytta mer än en fil, till filsystem över nätverk, om du skall döpa om filerna samtidigt etc. SPS tar istället upp hur du övervakar ett nätverk, hur du undersöker ett nätverk, hur du hanterar elak kod som kommer in i ditt system. Dvs SPS arbetar på en mycket högre nivå.

Så här långt har SPS varit en bra läsning. Det är som sagt inte en ny UPS, men det betyder inte att det är en sämre bok - det är en annan sorts bok. Om man bortser från bokens namn och författarnas försök att koppla ihop sin bok med UPS är SPS antagligen en ypperlig bok om IT-säkerhet.

Jag skulle vilja hävda att SPS har mer gemensamt med en kombination av böcker som Ross Anderssons Security Engineering och Michal Zalewskis Silence on the Wire (mycket bra böcker båda två), dvs bra teoribeskrivning och krassa, effektiva metoder och sätt att använda olika verktyg för att lösa problem.

Någon som läst boken och har en annan uppfattning?

Koda säkrare med CERT

Tuesday, January 22nd, 2008

CERT har ett pågående projekt för att utveckla kodningsregler och rekommendationer för att skriva säkrare program i C och C++. Reglerna utvecklas som ett öppet projekt och utvecklingen sker på projektets webbplats.

Här hittar du reglerna för C-kod och här hittar du reglerna för C++-kod.

Reglerna tar upp ett stort antal aspekter, vilket en snabb lista med kategorierna för C-kod visar:

01. Preprocessor (PRE)

02. Declarations and Initialization (DCL)

03. Expressions (EXP)

04. Integers (INT)

05. Floating Point (FLP)

06. Arrays (ARR)

07. Characters and Strings (STR)

08. Memory Management (MEM)

09. Input Output (FIO)

10. Temporary Files (TMP)

11. Environment (ENV)

12. Signals (SIG)

13. Error Handling (ERR)

14. Miscellaneous (MSC)

50. POSIX (POS)

99. The Void

Under de olika kategorierna kommer sedan ett antal regler som alla följer en gemensam form med beskrivning exempel, analys av säkerhetsproblem och referenser. Ett exemåel är INT07-A. Only use signed or unsigned char type for numeric values:

The three types char, signed char, and unsigned char are collectively called the character types. Compilers have the latitude to define char to have the same range, representation, and behavior as either signed char or unsigned char. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.

Only use signed char and unsigned char types for the storage and use of numeric values, as this is the only way to (portably) guarantee the signedness of the character types.
Non-Compliant Code Example

In this non-compliant code example, the char-type variable c may be signed or unsigned. Assuming 8-bit, two’s complement character types, this code may either print out i/c = 5 (unsigned) or i/c = -17 (signed). As a result, it is much more difficult to reason about the correctness of a program without knowing if these integers are signed or unsigned.

char c = 200;
int i = 1000;
printf(”i/c = %d\n”, i/c);

Compliant Solution
In this compliant solution, the variable c is declared as unsigned char. The subsequent division operation is now independent of the signedness of char and consequently has a predictable result.

unsigned char c = 200;
int i = 1000;
printf(”i/c = %d\n”, i/c);

Risk Assessment
This is a subtle error that results in a disturbingly broad range of potentially severe vulnerabilities.
Recommendation Severity Likelihood Remediation Cost Priority Level
INT07-A 2 (medium) 2 (probable) 2 (medium) P8 L2

Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References
[ISO/IEC 9899-1999] Section 6.2.5, “Types”
[MISRA 04] Rule 6.2, “Signed and unsigned char type shall be used only for the storage and use of numeric values”

Det finns även en bok från CERT på området av Robert C. Seacord:
Boken

För den som har bråttom har CERT även en lista på de tio viktigaste generella reglerna, regler som inte bara går att applicera på C och C++:

1. Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05].

2. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A].

3. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.

4. Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.

5. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75].

6. Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75].

7. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.

8. Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05].

9. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Penetration testing, fuzz testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05].

10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

Nu gäller det bara att till sig allt och börja applicera det också…

Ekonomi och affärsmodell för IT-brott

Thursday, January 3rd, 2008

Bruce Schneier pekar på en mycket intressant artikel som tar upp ekonomin och affärsmodellerna som driver IT-brotten.

Artikeln tar bland annat upp hur den svarta ekonomin på Internet är en högt globaliserad, outsourcad verksamhet där allt kan säljas som en tjänst, inklusive access till trojaner:

In March the price quoted on malware sites for the Gozi Trojan, which steals data and sends it to hackers in an encrypted form, was between $1,000 (£500) and $2,000 for the basic version. Buyers could purchase add-on services at varying prices starting at $20.

According to reports, the malware was available this summer as a service from iFrameBiz and stat482.com, who bought the Trojan from the HangUp team, a group of Russian hackers. The Trojan server was managed by 76service.com, and hosted by the Russian Business Network, which security vendors allege offered “bullet-proof” hosting for phishing sites and other illicit operations.

Artikeln hänvisar även till forskaren Peter Gutmann som publicerat en mycket extensiv och läsvärd rapport kallad TThe Commercial Malware Industry. Tanka ned och läs. Skrämmande men nyttig läsning.

Google TechTalk om krypto

Sunday, December 16th, 2007

Googles serie med inspelade presentationer från Googleplex är en guldgruva om man vill lyssna på intressanta föreläsningar.

En av dessa är en presentation om krypto i teori och praktik som Steve Weis höll i början av december. Steve tar bland annat upp en intro till modern krypto, hur man använder krypto i verkligen och då speciellt på Google.

Steve Weis är från MIT och ansvarar på Google för deras interna kryptobibliotek KeyMaster.

Lästips för att hänga med i NISTs AHS-tävling

Thursday, December 6th, 2007

På Bloggen Light Blue Touchpaper från säkerhetsgruppen i Cambridge finns en postning med lästips för att hänga med i NISTs tävling för att få fram nya hashfunktioner.

Det jag skulle vilja komplettera listan med är Jag skulle vilja komplettera listan med de HASH-workshops som NIST och ECRYPT arrangerat de senaste åren.

Ross Andersson söker efter ondska

Thursday, November 22nd, 2007

En av mina stora idoler på säkerhetsfronten, forskaren Ross Andersson har hälsat på Google och hållit en presentation. Presentationen Searching for Evil finns på YouTube och är väl värd att titta på:

Sammanfattningen på YouTube förklarar vad presentationen handlar om:

Computer security has recently imported a lot of ideas from economics, psychology and sociology, leading to fresh insights and new tools. I will describe one thread of research that draws together techniques from fields as diverse as signals intelligence and sociology to search for artificial communities.

Evildoers online divide roughly into two categories - those who don’t want their websites to be found, such as phishermen, and those who do. The latter category runs from fake escrow sites through dodgy stores to postmodern Ponzi schemes.