lördag 29 maj 2010

Dödskalle vid trasigt SSL-cert

Google Chrome börjar visa en röd dödskalle vid felaktigt SSL-cert.


Chris Evans (en av talarna på sommarens konferens) skriver följande:

"The great thing about red skull + crossbones is that it highlights the site is broken and creates pressure to fix it."

Andra involverade i Chromium är tveksamma:

"Users have no control over the site, and they do have choices in browsers, so unless all browsers do it, most users will believe the browser is broken, not the site."

Det riktigt intressanta är att man överväger att visa dödskallen vid allvarliga varianter av mixat http/https-innehåll, ett vanligt problem vid mashups.
  • Varning vid mixat innehåll med ex. <img> ger "spökhänglås" + grå https-text
  • Fel vid mixat innehåll med ex. <script> ger dödskalle + röd https-text

fredag 28 maj 2010

Hur spara applikationslösenorden?

En evig fråga för systemutvecklare och driftansvariga är – hur sparar vi lösenorden som applikationen behöver? Det är ofta flera lösenord som har med applikationen eller applikationsservern att göra. Lösenord till databasen, lösenord till certifikat, lösenord till keystores, lösenord för maskin till maskin-koppel och så vidare.

Alternativen som står till buds
Det finns följande enkla men osäkra alternativ:
  • Lösenord i klartext i konfigurationsfil
  • Lösenord i klartext i koden
Sen har vi de bra mycket säkrare men också jobbigare alternativen:
  • Krypterade lösenord i konfigurationsfil med nyckel i koden (kan vara en masternyckel för hela applikationen)
  • Krypterade lösenord i kod eller kodnära konfigurationsfil och lösenord i driftnära konfigurationsfil (känns lite bakvänt men ibland har man större förtroende för driftansvarig än för utvecklarna, t ex vid outsourcing)
  • Krypterade lösenord i en LDAP eller liknande
Och så har vi hybriden:
  • Krypterade lösenord i konfigurationsfil med delad nyckel – halva i koden, halva i konfigurationsfil.
Till sist har vi de väldigt säkra och grymt jobbiga alternativen:
  • Lösenord i huvudet på driftansvariga (anges vid varje driftsättning medelst många svordomar)
  • Drakonisk hårdvarulösning
Standardlösningar?
Mig veterligen så finns ingen standardlösning på det här i vaniljsmaken på Java EE. Istället så bestämmer varje team sig för hur man ska göra med lösenorden. Synd.

I lakritsjava (=enterprise) så finns det färdiga lösningar. IBMs WebSphere kör tyvärr default med en naiv XOR (ref):

"WebSphere Application Server stores passwords XOR encoded in the XML configuration files."

Men man kan plugga in valfri krypteringslösning genom att implementera deras CustomPasswordEncryption-interface eller sätta customPasswordEncryptionClass och customPasswordEncryptionEnabled i PropFilePasswordEncoder.bat/sh. Bra grejer.

i .NET-världen kanske det ser annorlunda ut, inte minst tack vare integrationen med Windows API:er som Data Protection API (CryptProtectData). Men jag är ingen klippa på .NET. Någon som kan hjälpa till? Kristofer?

Vad ska man brygga om man brygger hemma?
OK, men för oss som inte har betalat för en WebSphere-licens, vad står till buds? En XOR-kryptering med statisk nyckel i koden kanske?

Nja, så här säger min kollega Lars Johansson om XOR-kryptering:

XOR ger visserligen "perfekt sekretess" (bevisat av Shannon 1949), men det förutsätter följande:
  1. Nyckeln måsta vara lika lång som klartextmeddelandet.
  2. Nyckeln måste vara fullständigt slumpmässig. Så fort en nyckel återanvänds går det att knäcka kryptotexten!
Båda dessa ovanstående krav gör att perfekt sekretess med XOR inte går att realisera i praktiken. Använd en etablerad kryptoalgoritm i stället, t.ex. AES. Då är det inte lika noga med nyckellängden (256 bitar duger gott). Nyckeln bör dock fortfarande ha bra slump/entropi.

Vi borde skärpa oss lite
Jag tror de flesta tycker det här är för jobbigt och har alla maskinlösenord i klartext eller med defaultskydd. Vi borde skärpa oss lite. AES-kryptering med nyckeln i källkoden borde vara ett minimum. Gärna genom en snygg öppen källkodslösning som alla kan planka :).

Vad tycker ni andra? Hur gör ni?

onsdag 26 maj 2010

CSRF mot FTP

Efter en av våra OWASP Sweden-kvällar så diskuterade vi cross-protocol-attacker. Nu har en CSRF-sårbarhet rapporterats in för Sun Solaris 10 ftpd. Hypertext Transfer Protocol till File Transfer Protocol.

Attackeraren kan på sin sajt ha en sån här image-tagg:

<img src="ftp://ftp.sun.com/////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
///////////////////////////////////////////////////
//////////////////////SITE%20CHMOD%20777%20valfritt filnamn";>

Om en ftp-adminstratör surfar in på den sidan så ändras behörigheten på filen till 777, dvs fullständiga rättigheter för alla användare.

Hur skydda sig?
OK, en vanlig CSRF, eller? Nja, vi är ju vana vid att skydda oss mot CSRF i webbapplikationer med hjälp av synkroniserings- eller flödesbiljetter (ViewState, synchronizer token eller forced browsing). Men ftp har inget naturligt sätt att lägga till biljetter mellan anrop.

Det föreslagna skyddet är att inte tillåta långa ftp-kommandon.

[Jag har mejlat Maksymilian Arciemowicz för att fråga om en del detaljer som inte verkar klara. Återkommer om jag får klargörande svar.]

söndag 23 maj 2010

Subdomain hijacking

En ny trend skönjas enligt Unmasked Parasites – "subdomain hijacking", med en portion malware på köpet förstås.

Dina domäner är attraktiva
Låt säga att någon kommer över inloggningsuppgifterna till ditt webbhotell, t ex för att du loggar in på ftp med lösenordet i klartext. Vad ska de då göra? Deface:a ditt fotoalbum? Nej, de studsar trafik via dig för att locka folk till fishing- och malwaresajter! Därför är även minlillakattunge.se intressant att hacka.

Redirect via .htaccess
Ett vanligt sätt att rikta om webbtrafiken på en hackad server är att skapa eller ändra på filen .htaccess (Apache). Den filen åsidosätter nämligen webbserverns konfiguration i den katalog den ligger i. Du kan t ex ha lagt flera .htaccess-filer i ditt webbträd så här:

/.htaccess
/www/.htaccess
/www/owasp/.htaccess
/www/owasp/blog/.htaccess

Normalt styr man saker som teckenkodning och sidor som kräver inloggning med hjälp av .htaccess och själva webbservern måste ha konfigurerats för att tillåta .htaccess:
  • AllowOverride All – tillåt valfri åsidosättning i .htaccess-filer
  • AllowOverride None – tillåt ingen åsidosättning
  • AllowOverride AuthConfig | FileInfo | Indexes ... – tillåt specifika ändringar
En sak man kan styra i .htaccess är Apache-extension:en mod_rewrite som är en regelmotor för att bygga om URL:er i realtid. Du kommer till en URL och mod_rewrite bygger om den, t ex gör en redirect utifrån parametrar i ditt request.

Attackeraren utnyttjar det stulna kontot till ditt webbhotell och lägger in en .htaccess med följande innehåll:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://87.248.180.90/in.html?s=ipw2 [R,L]

Den säger att om surfaren kom hit via någon sökmotor (Google, Yahoo ...) så ska han/hon skickas vidare till en annan sajt på IP 87.248.180.90. Och den sajten lurar honom/henne att installera ett "antivirus" eller liknande.

Notera att när du går direkt till din sajt (utan att söka) så kommer allt att se bra ut.

Offret kanske upptäcker redirect:en?
Nu börjar ju folk få bättre och bättre koll och kanske skulle upptäcka att klicket bland sökträffarna inte tog dem till en trovärdig sajt utan till IP 87.248.180.90. Det är då subdomain hijacking kommer in i spelet!

Det skulle ju vara mycket mer trovärdigt om uppmaningen att installera något kom från en sida under rätt domän.

Attackeraren gör redirect till en stulen subdomän
Låt säga att attackeraren har kommit över mina inloggningsuppgifter till owasp.se. Istället för att i .htaccess sätta upp regeln:

RewriteRule .* http://87.248.180.90/in.html?s=ipw2 [R,L]

... så konfigurerar han/hon upp en ny subdomän – www2.owasp.se – och sätter upp redirect-regeln:

RewriteRule .* http://www2.owasp.se/in.html?s=ipw2 [R,L]

... och publicerar sin malware där.

De flesta kommer inte upptäcka att de har en extra subdomän uppsatt. Och det är sådana extra, stulna subdomäner som nu har börjat dyka upp på nätet, under namnet subdomain hijacking. Kanske är det en trend.

fredag 21 maj 2010

Clickjacking-attack mot Facebook

En mask kallad FBHOLE spred sig som en löpeld på Facebook igår och idag. Tydligen använder den sig av clickjacking. F-Secure beskriver det hela bra.

Någon av dina redan drabbade FB-vänner postar ett meddelande:
"try not to laugh xD http://www.fbhole. com/omg/allow.php?s=a&r=[slumptal]"

Om du klickar så får du upp en sida som ser ut som Facebook men visar ett fejkat felmeddelande:


Om du klickade någonstans på den sidan så postade du fbhole.com-länken på din Facebook-profil och masken fortsätter att sprida sig (förutsatt att du är inloggad på FB). fbhole.com fångar ditt klick med en transparent iframe som skickar klicket till Facebook istället.

Domänen registererades igår och pekar på en tjeckisk IP-adress. Sajten ironbrain.net har samma IP.

Mikko Hypponen på F-Secure ringde Ironbrain som lät tämligen förvånade. En stund senare var fbhole.com borta från nätet.

Vi kommer ha en intressant presentation om clickjacking på sommarens konferens i Stockholm (se passet kl 15:30).

Forefront TMG gör MitM på din SSL

Ni kanske läste mitt inlägg om hur myndigheter och säkerhetstjänster kan avlyssna SSL genom proxies och utfärdande av korrekta SSL-certifikat on the fly?

Det är precis samma sak som Microsoft Forefront Threat Management Gateway gör.

Microsoft Forefront TMG gör Man-in-the-Middle
Microsoft beskriver själva sin teknik på Technet:

"In order to inspect outgoing HTTPS traffic, Forefront TMG breaks the HTTPS connection and then acts as an intermediary or "man in the middle" between the client that initiated the connection and the secure Web site."

Det går till så här:
  1. Sysadmin på arbetsplatsen ser till att ett så kallat HTTPS inspection certificate finns installerat i alla klientdatorers Trusted Root Certification Authorities certificate store
  2. Klienten gör ett anrop till en https-sajt
  3. TMG går in och bryter anropet
  4. TMG sätter upp en egen SSL-koppling till den begärda sajten och kontrollerar det SSL-cert som sajten autentiserar sig med
  5. TMG kopierar webbsajtens SSL-certifikat, skapar ett nytt SSL-certifikat med samma uppgifter, och signerar det med HTTPS inspection certificate
  6. TMG sätter upp en https-koppling till klienten mha det nya SSL-certifikatet
  7. Klienten accepterar det nya certet som korrekt för den begärda sajten eftersom HTTPS Inspection-certet finns bland de betrodda CA-certen
Det är så din arbetsgivare kan spionera på din SSL-trafik.

torsdag 20 maj 2010

Oracle-kurs om SQL injection

Oracle har lagt ut en online-kurs om hur man undviker SQL injection. Ett bra lästips för alla utvecklare och dba:er med Oracle-databas.

Under kursen förväntas man lära sig ...
  • Kategorisera och förklara olika typer av SQL injection-attacker
  • Beskriva programmerings- och designstrategier för att undvika SQL injection
  • Använda DBMS_ASSERT för indatavalidering
  • Använda kodgranskningsverktyg för att hitta potentiella SQL injection-sårbarheter
  • Nyttja utvecklingspraxis för att undvika SQL injection-sårbarheter

måndag 17 maj 2010

CS lista på säkerhetsexperter deface:ad?

Computer Sweden brukar ju lista Sveriges skarpaste säkerhetsexperter (klicka inte på sidans länk "Redigera listan själv och lägg till uppgifter på CS Wiki" innan du läst vidare nedan). Senaste listan kom i september 2008 men CS har haft en wiki-sida där alla kan föreslå folk till den nya listan. Den wiki-sidan är inte så fin längre ...

Wikin hackad?
När jag klickade in på wikin trodde jag det var kört. – Sh*t, nu är det heap spraying på gång! tänkte jag. Men sidan såg knasig ut och näthack brukar vara diskretare än så.

Jag startade om datorn för säkerhets skull och wget:ade sen hem wiki-sidan. Verkar mest som att någon har raderat listan på säkerhetsexperter och lagt dit några skumma dummy-länkar. Kanske finns där något elakt skript men inget som fångade mitt öga. Någon annan som vill utreda vidare?

Så här ser i alla fall "listan" ut i HTML numer:

<p>BaKBX0
_<a href="<a href="http://xlbdiunbcvub.com/"
__class="external free"
__title="http://xlbdiunbcvub.com/"
__rel="nofollow">
_http://xlbdiunbcvub.com/</a>
_">xlbdiunbcvub</a>,
_[url=
__<a href="http://jclohyqgrgio.com/"
___class="external free"
___title="http://jclohyqgrgio.com/" ___rel="nofollow">http://jclohyqgrgio.com/</a>
_]jclohyqgrgio[/url],
_[link=
__<a href="http://ztpdcvhhglip.com/"
___class="external free"
___title="http://ztpdcvhhglip.com/" ___rel="nofollow">http://ztpdcvhhglip.com/</a>
_]ztpdcvhhglip[/link],
_<a href="http://mnxercozwuni.com/"
__class="external free" title="http://mnxercozwuni.com/" __rel="nofollow">http://mnxercozwuni.com/</a>

Domänerna verkar inte äkta. Men lite lustigt är det med tanke på att listan handlar om säkerhetsexperter.

söndag 16 maj 2010

AppSec-inbjudan på YouTube

Jag lade precis ut en videoinbjudan till OWASP AppSec i Stockholm i sommar. Jag har ingen formell skolning i filmskapande men ni får iaf en sneak peek på min och Dj Materias kommande mix på min låt "Fly Together" :).


lördag 15 maj 2010

Säkerhetsfolk på Twitter?

Jag har twittrat ett tag nu och gillar det. Bra nyhetsflöde och forum för korta känsloyttringar och åsikter. Bara det faktum att jag i veckan bestämde mig för att börja rekommendera kunder att avinstallera Java på klientdatorer om de inte kör applets eller Javaapplikationer. Det är sånt man kan "känna" på Twitter. I botten ligger förstås antalet allvarliga säkerhetsbuggar, Java 5:s End-of-Life och Oracles attityd till patchningar.

Jag heter johnwilander på Twitter och startade precis listan SwedishSecurityLounge – SSL (http://twitter.com/johnwilander/swedishsecuritylounge). Om andra här twittrar så messa mig på Twitter @johnwilander så lägger jag till er i listan.

Vi ses där ute!

torsdag 13 maj 2010

Personlig integritet på Facebook?

Facebook får mer och mer stryk för regler och inställningar gällande personlig integritet. Vid det här laget är deras integritetspolicy längre än den amerikanska konstitutionen (se länkad NY Times-artikel nedan). Det hela har förstås bärighet på allmänna frågor som hur man tjänar pengar på nätet, den pågående kampen om våra nätidentiteter och Facebooks ambitioner att bli den globala portalen för alla oss som "hänger" på nätet.

Visualisering av personlig integritet på FB
Matt McKeon på IBM research har gjort en visualisering av hur Facebook har gjort mer och mer personlig information tillgänglig över tid.



Nu har även New York Times gjort en ordentlig genomgång av historik och nuläge.

Bra artiklar
Wired har både en bra artikel om integritetsproblemet och om Facebooks planer på webbdominans.

Facebook reagerar
Nu har Facebook äntligen reagerat och kallat till ett internt stormöte. Blir intressant att se vad som händer och sägs där.

tisdag 11 maj 2010

Nättidningar inom säkerhet

Några nättidningar om ni är sugna på merläsning. Med läsplattorna så tror jag de kan få ett uppsving. Tipsa gärna om fler i kommentarerna.

(In)Secure Magazine

Hankin9 – numer en kostnadsfri nättidning

Club Hack Mag – ung indisk nättidning
http://chmag.in/

Phrack Magazine, #67 kommer ut 11:e juli (ett år sen senast)

Webbsårbarheter i siffror

WhiteHat har precis kommit med vårens Website Security Statistics Report (pdf). Tom Brennan kommer att hålla en presentation om det hela på sommarens OWASP-konferens i Stockholm men några av de intressantaste siffrorna tycker jag är följande:

ASPASPXCold
Fusion
StrutsJSPPHPPerl
Andel sårbarheter per indatafält9 %6 %8 %6 %10 %8 %12 %
Andel sajter som haft minst en allvarlig sårbarhet74 %73 %86 %77 %80 %80 %88 %
Andel sajter som har minst en allvarlig sårbarhet57 %58 %54 %56 %59 %63 %75 %

Man har kategoriserat utifrån filändelser asp, aspx, cfm, do, jsp, php och pl.

ASP och ASPX verkar klara sig bättre. Jag skulle gissa på att det beror på att man har ett "facit", dvs information från MSDN, och bättre security by default, något som Microsoft har arbetat mycket med. Perl ligger sämst till i alla kategorier men vem utvecklar idag webb med Perl?

söndag 9 maj 2010

Twittra och blogga om AppSec i Stockholm

Det är dags att skapa en digital storm och bjuda in världen till sommarens OWASP AppSec Research 2010 i Stockholm. Vi har ett fantastiskt program och bjuder in alla deltagare till middag i stadshuset. Snälla hjälp till genom att twittra och blogga om det, gärna söndag/måndag. Tillsammans kommer vi höras.

Tag: #OWASP


Bild:
Ni kan använda ovanstående bild på era bloggar. Koden är Marios vinnande bidrag i tävlingen om icke-alfanumerisk JavaScript som gör en alert("owasp"). Hyfsat klurigt för filter och kodgranskare ;). Om ni vill ha med skriptet i textform, så är det bara att kopiera följande:
ω=[[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}][Ś+Ó+Ŕ+Ṫ],ω()[Á+Ĺ+É+Ŕ+Ṫ](Ó+ω()[Ḃ+Ṫ+Ó+Á]('Á«)'))

Låt oss hjälpas åt att få ut budskapet – tack!

torsdag 6 maj 2010

Sandlådor för CSS/HTML/JavaScript

Gareth Heyes donerar sina tre sandlådeprojekt till OWASP. Så här skrev han nyss på leaders-listan:

I'm donating CSSReg/HTMLReg/JSReg to OWASP.

https://code.google.com/p/jsreg/
http://code.google.com/p/htmlreg/
http://code.google.com/p/cssreg/

Currently I use a local SVN server but I'm switching to Google code with the above projects. All projects are developed in JavaScript and use regular expressions to create a safe sandboxed version of the language. I know you have Anti-Samy which is very good (I've tested it) I don't want to compete with that but rather offer devs a safe way of outputting code using JavaScript.

Öppen Google-kurs i webbsäkerhet

Google har kommit med en öppen kurs i utveckling av säkra webbapplikationer – Web Application Exploits and Defenses. Genom ett antal labbar får man prova att hacka en medvetet sårbar bloggapplikation vid namn Jarlsberg.



Labbarna i att knäcka Jarlsberg finns i tre typer:
  • Blackbox: Du kan lösa labben utan att titta på hur applikationen är konstruerad.
  • Whitebox: Du måste på något sätt undersöka applikationens källkod.
  • Ledtråd: Du får en ledtråd som hjälper dig lösa labben.
Bland labbarna finns:
  • Cross-site scripting
  • Cross-site request forgery
  • Denial of service
  • Remote code execution
Givetvis lär man sig säkra Jarlsberg parallellt.

måndag 3 maj 2010

EOL – snart i en produkt nära dig

End of Life. EOL. Inga fler uppdateringar, inga patchar. You're on your own.

Så ser det ut för fler mjuvaruprodukter än man kanske vill veta.

Windows 2000 dör i sommar
Den 13:e juli dör Windows 2000 även för dem som köpt utökad support. Man får hoppas att inga kritiska applikationer snurrar på Win2k efter det datumet. Särskilt inte om maskinen har kontakt med Internet.

Java 5 dog i november förra året
Ännu mer skrämmande är att Java 5 dog 3:e november förra året. Det är jättemånga som fortfarande kör Suns Java 5. Har de köpt utökad support?

Den sista mars kom nämligen Secunia Advisory SA37255:
Sun Java JDK / JRE Multiple Vulnerabilities

... som motsvaras av patchen JavaSE 5.0_x86: update 24 patch – en diger lista med säkerhetshål, toppad av en remote exploit via buffer overflow (6901039 CVE-2009-3910 - Java HsbParser.getSoundBank Heap Buffer Overflow Vulnerability)

Förvisso ett klientproblem men det är onekligen läge att patcha. Är då denna patch tillgänglig för alla? Jag skaffade ett vanligt SunSolve-konto och fick beskedet: "You have selected premium content which requires a valid Sun Contract to access".

Java har fler problem
Ovanstående Java-buggar toppades sen upp med ett par feta säkerhetshål i Java 6 nu för två veckor sen. De problemen anses så allvarliga att Java som webbläsar-plugin har svartlistats av Mozilla från version 6.0.200.0 och bakåt.

Har alla koll på EOL?
Frågan är om alla har koll på EOL för sina kritiska komponenter? Anses det som en säkerhetsrisk eller sorterar det under licenser och support? Jag tror det ser rätt illa ut på många ställen.