Etikettarkiv: säkerhet

DevOps Säkerhet

Att jobba med DevOps samt IT-säkerhet är några av de områden som jag gillar mest. Därför är det intressant att ibland stanna upp och reflektera. För inom DevOps handlar det oftast om att skeppa kod så snabbt som möjligt och bygga skalbara och snabba mikroinfrastrukturer med continuous integration. Säkerhet däremot ses ofta som en bromskloss i utvecklingsarbetet.

Det går att fuska med säkerhet: Genomföra saker snabbt men se säkerheten som ett lån med ränta. Att betala tillbaka på lånet snabbare gör att säkerheten blir bättre och det blir inte lika dyrt längre fram (technical debt).

Att ta med säkerheten tidigt i sin planering är viktigt, för använder ni Docker så se till att använda SELinux eller AppArmor (vilket bl.a. Ubuntu Snappy gör som standard).

Exponera ej Elasticsearch, Redis, MongoDB eller andra databaser direkt mot Internet, vilket tyvärr förekommer och nyttjas av elakingar.

Se även till att inte lagra lösenord i klartext och genomför säker radering av information. Visste du exempelvis att Mac OS X har kommandot srm?

srm – securely remove files or directories

Nu är det nog med rant för det blir faktiskt bättre. Och för att ge lite matnyttiga tips tänk på följande:

10 tips till säkrare DevOps

  1. Genomför inte bara backup. Kontrollera även löpande att den verkligen innehåller allt och fungerar. Backup för prod ska ej vara tillgänglig från stage och vice versa.
  2. Prod-, stage- och utvecklingsmiljöer ska ej dela nycklar, lösenord etc.
  3. Tänk på att ej lägga alla ägg i samma korg. Nyttja exempelvis Amazons availability zones.
  4. Kryptera så mycket som möjligt. Inte bara in-transit utan även lokalt, undvik helt klartextprotokoll samt införskaffa SSL-Certifikat.
  5. ossecLogga mycket och filtrera samt arkivera med hjälpmedel såsom OSSEC. Som förresten även kan hålla koll på filintegritet.
  6. Bevaka med verktyg såsom Nagios, Pingdom och New Relic. Glöm inte ändpunkter för API (10 saker som Bit.ly glömde att bevaka).
  7. Genomför löpande säkerhetskontroller med verktyg såsom QualysNessus och Detectity. Även manuella återkommande granskningar är att rekommendera av företag som utför penetrationstester.
  8. Omvärldsbevaka och håll Er uppdaterad när det kommer nya sårbarheter i de mjukvaror som Er infrastruktur använder. Vad är best practices just nu för att lagra lösenord, är det bcrypt, scrypt eller pbkdf2?
  9. Segmentera och filtrera så mycket som möjligt. Ingen enskild server eller konto ska ha tillgång till allt.
  10. Checka aldrig in lösenord, nycklar eller annat känsligt till ett repo.

Tänk inte bara DevOps, tänk även SecOps.

Lös inte nästa problem som du stöter på, på följande sätt (saxat från Stackoverflow)

https stackoverflow

Testa säkerheten i WordPress del 2

Detta är del två av hur du kan själv testa säkerheten på Er WordPress-installation. Detta är del två och första delen hittar du här.

Denna del behandlar några mer automatiserade sätt samt är lättare för nybörjare.

DetectifyDetectify

Svenska startupen Detectify har en utmärkt bra tjänst för att söka igenom WordPress efter sårbarheter.

De har även ett tillhörande WordPress-plugin. Jag rekommenderar alla att testa eftersom kostnaden är ”det du är villig att betala”, dvs du bestämmer själv hur mycket du vill betala.

https://detectify.com

Och här hittar du pluginet https://wordpress.org/plugins/detectify-for-wp/

Exempel på en översiktsrapport kan se ut så här:

Detectify skärmdump

 

Sucuri

Sucuri är också en form av online-scanner som söker igenom Er sajt. Den tittar dock på lite andra saker än vad Detectify såsom om Er blogg dyker upp på Google med sökord som har med spam-sökord såsom viagra, cialis och liknande att göra.

https://sucuri.net

Google dorks

Sist men inte minst så måste jag nämna alla Google Dorks som finnes. Det kan lättast beskrivas som att man använder Google för att hitta intressanta saker på en blogg.

Ett exempel kan vara följande sökning:

intitle:"index of" site:utvbloggen.se

Som försöker hitta kataloger på min blogg/domän som tillåter fillistning. Här finnes en databas med många dorks:

http://www.exploit-db.com/google-dorks/

Kolla även in penetrationstest.se

Föreläsning om WordPress och säkerhet

Föregående fredag så höll jag en föreläsning om WordPress och säkerhet på Västerås Science Park. Föreläste gjorde även Christoffer Larsson från Aftonbladet och hur de använder Vagrant för utvecklingsmiljön.

På min föreläsning om säkerhet så berättade jag om en händelse som inträffade för några år sedan då en angripare lyckades utnyttja en sårbarhet på en av mina bloggar och placera ut ett antal bakdörrar. Genom att bakdörra angriparens bakdörrar samt spåra IP-adressen mot andra anrop på min webbserver så lyckades jag till slut hitta alla bakdörrar.

Här finnes presentationen:

Läs mer om #wpbar här. Och tack till Västerås Science park samt Flowcom som sponsrat + arrangerat detta trevliga event.

Har din WordPress-blogg hackats? Läs det här

Fler och fler WordPress-bloggar hackas och en stor faktor är den sårbarhet som identifierades i TimThumb. TimThumb var inbakad i mängder plugins och teman som inte uppdateras.

Första tecknet på att din blogg hackats kan vara något av följande:

  • Din blogg försvinner från Googles-index. Dvs söker du efter din blogg så dyker den inte upp
  • Någon kontaktar dig gällande viagra eller liknande som din blogg länkar till
  • Du hittar nya filer eller så försvinner filer från din WordPress-installation

Det du måste göra när din blogg hackats är att börja om från början och försöka lista ut hur angriparna tog sig in. Så först och främst måste du se till att du har en backup av både filsystemet och databasen.

Om du har kontroll över underliggande operativsystem så bör du även installera om det då angriparna kan ha tagit sig in i operativsystemet. Att installera om och konfigurera operativsystemet är oftast krävande och tar lång tid.

Ominstallation av WordPress

Börja med att göra en ny installation av WordPress och läs sedan tillbaka databasen, ändra lösenord och titta så att inga nya konton dykt upp i WordPress. Innan du börjar med din nya installation av WordPress måste du se till att det är helt tomt på ditt konto, inga .htaccess-filer som kan vara dolda exempelvis då det finns exempel då angripare placerat bakdörrar i dessa. Om du känner dig osäker gällande dessa steg så bör du anlita eller fråga någon som kan WordPress bra.

Installera alla plugins som du behöver och gå manuellt igenom samtliga och undersök huruvida det har identifierats några sårbarheter i dem på sistone. Secunia har en söktjänst där du kan söka på pluginnamn.

Om du har ett egenutvecklat tema (theme) och vill återställa detta från din backup så bör du gå igenom samtliga .PHP-filer för att säkerställa att ingen bakdörr har tagit sig in.

Det finns även exempel då bloggar hackats genom delade miljöer på webbhotell, då hjälper det inte så mycket att du gör en nyinstallation om inte webbhotellet vidtar åtgärder. Överväg även möjligheterna att angriparen tagit sig in med ditt FTP-konto eller dylikt genom att testa vanliga lösenord eller läckta lösenord från exempelvis BloggToppen.

För att säkerställa att det just inte var TimThumb som används för intrång mot din blogg så kan du installera ett plugin som söker igenom efter den kod som TimTumb använder sig av. Här kan du ladda hem TimThumb vulnerability scanner:

Vidare läsning

Du bör även läsa WordPress FAQ gällande hackade WordPress-bloggar.

Detta blogginlägg kommer att uppdateras löpande med nya tips. Om du är intresserad av WordPress och säkerhet så bör du även läsa mitt inlägg om hur säkert WordPress är.

Nikke Lindqvist skrev även om hur viagra-spammare tar sig in i bloggar mer och mer här.

Hur säkert är WordPress?

En fråga som uppkommer relativt ofta är: Hur säkert är WordPress? Och för att svara på den frågan så finns det ett antal faktorer som jag anser intressanta att titta på och dessa inkluderar men begränsas ej till följande:

  • Ålder – Hur gammal är mjukvaran, om mjukvaran funnits 10 år eller några månader kan vara en faktor för nyare mjukvaror har troligtvis ej genomgått samma granskning (antalet ögon som tittat på koden).
  • Track record – Har det tidigare identifierats sårbarheter? Använd Secunia.
  • Öppen vs. stängd källkod – Jag litar mer på öppen källkod än stängd.
  • Kompetens hos utvecklare – Svårt att avgöra.
  • Kodstandard – Fulkod vs. finkod. Koden i WordPress är bra, dock ej supermycket kommenterad.
  • Uppdateringar – Sker det det några uppdateringar? Om koden senast uppdaterades 2005 så finns det med större sannolikhet brister. WordPress har ett bra system för uppgradering, glöm dock inte att uppdatera.
  • Installationsbas – Hur många använder systemet? Troligtvis har fler testat systemet om fler använder det. 14.7 percent of the top million websites in the world use WordPress.
  • Säkerhetsfunktioner och säkerhetsuppdateringar – Kommer det säkerhetsuppdateringar? Finns det några säkerhetshöjande funktioner i systemet. Här finns ett antal såsom slumpmässig nonce och HttpOnly cookies.
  • Komplexitet i systemet och antal rader kod.
Tittar man på ovan lista så ligger WordPress mycket bra till förutom sista punkten (men allt är ju relativt vad man jämför med). Men du bör även anamma lökprincipen:
 – Säkerhet skall likt löken byggas i flera lager, inte som en kedja. Faller ett lager finns det andra säkerhetsmekanismer som fortsätter skydda systemet. Källa
Så därför bör du även tänka på följande saker för att göra WordPress-säkrare:
  • Använd ej samma lösenord till WordPress som till övriga sajter/system.
  • Undvik kopplingar från WordPress-server till andra system. Använd gärna en molntjänst (ej delad db etc) som är frikopplad från övriga verksamhetssystem.
  • Undvik plugins – Om du vill använda plugins använd exempelvis enbart de som ingår i JetPack.me. Du kan även använda listan ovan för plugins, se till att de är uppdaterade exempelvis.
  • Använd https vid administration samt SCP eller motsvarande vid överföring av filer. Lägg till define('FORCE_SSL_ADMIN', true); i wp-config.php
  • Läs Hardening WordPress.
  • Uppdatera, uppdatera, uppdatera löpande både WordPress och underliggande operativsystem samt andra relaterade mjukvaror (exempelvis MySQL).
  • Säkra upp underliggande operativsystem samt databas. Minimera de privilegier som WordPress kan göra i MySQL.
  • Är personen som sätter upp WordPress och underliggande system kompetent?
  • Använd ett bra lösenord, byt namn på admin-kontot osv.
  • Teman (themes) kan även innehålla sårbarheter, se till att de också är uppdaterade och radera sådant du inte använder.
  • Håll koll på omvärlden – Din RSS-läsare bör minst innehålla WordPress.org News som uppdateras om någon allvarlig brist identifieras. Kan även rekommendera Sucuri-bloggen.
Nåväl, detta gav förhoppningsvis en liten insyn på några tänkvärda saker när det gäller WordPress och dess säkerhet. Lämna gärna en kommentar med det du tycker är viktigt eller om det är något jag har glömt.

Säkerhetsbrist i Skatteverkets appar

För några veckor sedan så laddade jag hem Skatteverkets nya iPhone App för deklaration dagen efter den släpptes. Jag kunde snabbt konstatera att viss information skickades okrypterat till Skatteverket.

Denna information som skickas okrypterat kan en angripare modifiera och lura den iPhone App som Skatteverket utvecklat. Detta förutsätter att någon loggar in med personliga koder över ett oskyddat eller delat krypterat WiFi-nätverk på ett café exempelvis.

Angriparen kan då presentera en inloggningssida eller deklarationssida som är helt identisk med den som Skatteverket tillhandahåller och kan då läsa av personliga koder (verifierat) och troligtvis även ändra bankuppgifter (ej verifierat). Detta helt utan användarens kännedom.

Appen hade vid tillfället då säkerhetsbristen uppdagats laddats hem över 50 000 gånger. Skatteverket uppdaterade sin app omgående då detta uppdagande rapporterats till dem. Troligtvis så gällde denna brist även Android-telefoner men det har jag dock ej verifierat.

Skärmdump på nätverkstrafiken som skickas okrypterat (http) till Skatteverket:

Vanliga frågor och svar (FAQ)

Fråga: Hur vet jag om jag blivit av med mina personliga koder?

Svar: Det vet du inte, dock så är skadan som någon kan göra med dina personliga koder begränsad.

Fråga: Om någon kan ändra mina bankuppgifter för skatteutbetalning, märks det?

Svar: Vet ej, om du vet lämna en kommentar.

Fråga: Hur går attacken till rent tekniskt?

Svar: Genom att ändra det HTTP-redirect svar som Skatteverket skickar okrypterat i den första HTTP-frågan så är det möjligt att skicka ett annat svar till godtycklig URL där exempelvis en fiktiv inloggningssida visas. Dvs Skatteverkets App fungerar enbart som en enkel webbläsare och visar vilken URL som används samt om sidan är krypterad via https eller ej.

Fråga: Varför har inte Skatteverket meddelat något om denna sårbarhet?

Svar: I dess uppdateringar till iPhone Appen så skriver de ”Förbättrad nätverkskommunikation”. Se skärmdump:

GitHub.com för Git

Nyss så var jag lite för snabb i min favoriteditor VIM och råkade radera stora delar av min kod och avsluta. Det var som tur var bara några timmars arbete men som alla vet så är det otroligt trist att skriva om kod.

Ur detta lilla misstag så försöker jag lära mig något: Så därför skapade jag ett konto på GitHub.com och checkade in några av mina viktigaste kodträd på under 30 minuter.