Internetdagarna 2014

Nu är tyvärr Internetdagarna 2014 över för denna gång. Var två dagar fulla med möten och intressanta föreläsningar. Eftersom min iPhone var trasig så fick jag förlita mig på en antik gammal mobiltelefon med T9 som varken hade Instagram eller Twitter.

Förutom huvudeventet Internetdagarna så var jag även på Internet Discovery Days (IDD) som Johan Jorgensen är fader för. Var som vanligt många intressanta startups som visade upp sina idéer och Ted hade en rolig söktävling: PopuläraPlatser vs Eniro. På måndagkvällen var jag förbi på Knackeriet där Jonatan hade releaseparty för HejEvent som ger personliga rekommendationer för kommande evenemang.

Min presentation från Internetdagarna under säkerhetspåret som OWASP Sweden höll i hittas på Kryptera.se.

Lyssna på mig under Internetdagarna

Under Internetdagarna 2014 så är jag inbjuden att hålla föredrag under spåret Fallgropar och läxor för säker utveckling. Jag har inte så många minuter på mig eftersom schemat är fullspäckat med andra intressanta föredrag men tänkte försökt mig på att prata om två intressanta saker:

  • Exfiltration av data – Hur antagonisterna gör för att få ut information från skyddade nätverk
  • SWF som angreppsvektor – Jag kommer att bl.a. berätta hur jag hackade Facebook

Kostnaden för att gå en dag på Internetdagarna kostar 1000kr och två dagar 2000kr. Läs mer om mig här på Internetdagarna.se.

Internetdagarna är Sveriges viktigaste mötesplats för oss som jobbar med internet.

Bomb illustration CC-BY, Bedow

Nytt projekt: Antivirus

IT-säkerhet, webbutveckling och devops är de tre delar som jag gillar allra mest. Och nu har jag äntligen utvecklat en ny typ av antivirus-produkt som använder alla dessa.

Denna nya tjänst som jag utvecklat är helt klart intressant och riktar sig både till privatpersoner och företag. Den är skapad för att hitta skadlig kod som andra produkter ej troligtvis hittar: riktade intrång, zerodays, rootkits etc.

Tanken är att först köra en beta-period helt gratis för privatpersoner och dra lärdom om hur produkten ska utvecklas. Även spännande för mig har varit att den mesta av koden är skriven i Python,  Windows kommer initialt att stödjas. Python är populärt och hipster-mjukvara såsom Dropbox är utvecklad i Python.

Hoppas även på en Mac OS X version men det ligger nog lite längre bort även det skulle behövas.

Psst, du följer väl Kryptera.se där jag bloggar om IT-säkereht och kryptering?

Konsultlivet

Det senaste året har jag fokuserat mer på min konsultverksamhet under Triop AB. Det har varit otroligt kul men också långa dagar och mycket stressigt stundtals. Försöker bli bättre på att effektivisera konsultlivets vardag genom att lära mig mer om GTD och använda verktyg såsom Billogram.

Lär mig även mer om offentliga upphandlingar och ramavtal samt försöker lägga tid på att forska och föreläsa mer. Har så klart inte övergett den egna webbutvecklingen helt och har en ny tjänst som snart lanseras. Avslutade nyss även bokslutet för förra året och vinsten tredubblades i bolaget vilket alltid är trevligt och omsättningen gick upp med 30%.

Den blogg som jag uppdaterar mest just nu är Kryptera.se där jag skriver om IT-säkerhet och kryptering vilket är några om områden som jag konsultar inom förutom DevOps.

På det mer personliga planet så klarade jag av mitt mål som jag tränat inför i två år: Ironman Kalmar 2014 vilket jag bloggade om på jonaslejon.se.

Några intressanta event framöver:

Google favoriserar https

Som Google meddelade för några månader sedan gällande att de avser att favorisera webbsajter som använder sig av https är nu officiellt bekräftat.

Detta är så klart en bra utveckling men många webbhotell åtminstone i Sverige verkar inte riktigt vara med på banan.

För att citera några webbhotell:

”För att ha SSL-certifikat under eget domännamn krävs en egen IP-adress” – Loopia

”Ett SSL-cert med inkluderad privat ipv4-adress” – Binero

Det behövs ej egen IP-adress utan Server Name Indication (SNI) finns implementerat i TLS (SSL) och bör användas istället. Som alla vet så är IP-adresserna slut sedan länge och att slösa på detta sätt gynnar ingen som webbhotellen föreslår.

Att kräva privat IP-adress för tls är lite 1900-tal tycker jag, eller i varje fall före 2010. Vid 2010 påstår jag tåget gick.

Skriver Internetgurun Patrik Fältström i gruppen Kodapor på Facebook.

Det finns även en mängd andra saker som bör tänkas på (lämna gärna en kommentar om jag glömt något mer)

  • Använd protokollrelativa URL:er dvs // istället för http://domän (finns i RFC 1808 sedan 16 år tillbaka)
  • Testa så du får bra betyg via Qualys SSL-Test
  • Håll koll på när certifikatet förfaller
  • Hur gör du revokering om något inträffar såsom Heartbleed?
  • Använd PFS, secure cookies och HSTS.
  • Vilket certifikat ska användas? Domänvaliderat eller EV? Wildcard?
  • Kontollera så du ej har mixed content:

Mixed content

Lättaste sättet att hitta mixed-content är enligt mig att använda Chrome Developer Tools och klicka på Networks-tabben.

Och jag säljer så klart SSL-Certifikat via https.se.

Hackad WordPress? Så här gör du

Du vet väl att du kan anlita mig för att rensa upp och utreda en hackad WordPress-installation? Kontakt här >

Har du upptäckt att din blogg länkar till suspekta sajter eller att Google Webmaster Tools larmar? Så här gör du för att undersöka hacket samt återställa bloggen efter det att den blivit hackad.

Omfattning av hacket

Det första är att ta reda på modus operandi. Hur har antagonisten tagit sig in och exakt vad har denne genomfört? Jag skulle nog påstå att något av följande scenarion är mest troliga orsaker till intrång:

  • Någon har knäckt ditt lösenord
  • Sårbarhet i plugin
  • Delad hosting

Det är inte en lätt match att ta reda på tillvägagångssättet då omfattande genomgång av loggfiler samt andra filer måste genomföras. Att redan innan ett intrång genomförs är det bra att kontrollera att du verkligen har tillgång till loggfiler och kan genomföra IT-forensik.

Att söka efter vanligt förekommande PHP-funktioner som används vid bakdörrar såsom preg_replace() med /e (execute), eval, base64_decode eller system() och liknande kan möjligtvis ge några spår. Även så är .htaccess eller liknande filer populära att lägga in bakdörrar

Det kan även vara bra att kontrollera om inlägg har modifierats och iframes eller liknande har in injicerats:

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%' OR
post_content LIKE '%<noscript%' OR post_content LIKE '%display:%';

Återställning efter hacket

Det bästa är att installera om samtliga plugins samt WordPress core och sedan återställa WordPress-databasen samt ändra samtliga lösenord i WordPress. På så sätt kan inget ligga kvar och du har troligtvis fått ut antagonisten. Dock finns det möjlighet att du installerar ett plugin som innehåller en sårbarhet igen om du ej genomfört en ordentlig utredning. Observera även att du måste helt tömma din webbroot, det räcker inte att skriva över filer för då kan eventuella extra filer (bakdörrar) ligga kvar.

Om antagonisten är inloggad i WP-admin och cookies är aktiva så måste security-keys ändras och här hittar du hur du gör (i wp-config.php filen).

Har intrånget skett genom delad hosting så kommer du troligtvis att bli hackad igen.

Du kan också givetvis anlita mitt företag Triop AB för att utföra undersökning samt rensa ut eventuella angripare.

Läs även det jag skrev 2012 om samma ämne:

Affiliateprogram för https.se

Jag säljer sedan några år tillbaka SSL-Certifikat på https.se och har nu startat ett affiliate-program via Adrecord. På https.se så hittar du SSL-Certifikat från bl.a. Comodo, GeoTrust  och RapidSSL.

Under Juli och Augusti så kan du tjäna hela 100kr per order. Jag har även försökt att underlätta flödet under beställning av certifikat så mycket som möjligt och använder bl.a. garlicjs. Och du kan så klart betala med Bitcoin, kort samt faktura vid beställning.

https_ad_250x250PS: Om du inte har testat Adrecord tidigare, gör det! Och använd gärna någon av ovan affiliate-länkar.

 

iOS Reverse-engineering

Behöver Er organisation hjälp med reverse-engineering eller IT-säkerhetsgranskningar? Kontakta mig gärna via https://triop.se

Att utföra reverse-engineering av Apples operativsystem iOS som återfinnes i bl.a. iPhone samt iPad kan inneha olika syften (Ciscos operativsystem heter även iOS). Det kan röra sig om att skapa kompatibilitet mot tredjepartsprodukter, analysera skadlig kod eller identifiera eventuella säkerhetsbrister.

Just konstformen reverse-engineering behöver inte direkt innebära att lusläsa assemblerkod dagarna i ända utan handlar mer om att lägga ett pussel för att dra eventuella slutsatser.

Det som tar längst tid är att upprätta en miljö som innehar diverse verktyg som är bra vid utförande av analysen.

Labbplattform iOS

Du behöver en iPad eller iPhone som du jailbreakar och sedan installera Cydia. När du installerat Cydia så finns det ett antal paket som jag rekommenderar:

  • adv-cmds
  • Bigboss recommended tools
  • OpenSSH
  • gdb
  • cycript

Det spelar även roll om du kör med iOS 6.x, 7.x eller 5.x eftersom vissa appar enbart stödjer iOS > 6.x. Även så kan det underlätta om du har en Mac samt Xcode för att kompilera program för att sedan köra på iOS (utvecklarlicens är ej nödvändig).

Du kan även köra kommandot installtheos på iOS om du vill installera en mängd utvecklarverktyg:

Theos is a cross-platform suite of development tools for managing, developing, and deploying iOS software without the use of Xcode.

Jag har även ett dedikerat WiFi-nätverk för att labba med iOS-enheter för att sätta upp filter och proxy-servrar. Det är lätt att konfigurera och jag använder en Raspberry Pi med hostapd.

Granskning

Jag brukar dela upp granskningen i tre steg. Jag har tidigare skrivit om nätverk samt hur du kan titta på API-trafik exempelvis med hjälp av Charles Proxy eller RVI. Ibland räcker det enbart att genomföra ett av nedan tre områden.

  • Nätverk
  • Filsystem
  • Runtime

Varje steg har sina verktyg och metoder som kan användas. Jag går nu igenom dessa tre steg mer i detalj. Även så kan ett förberedande arbete genomföras då information från öppna källor inhämtas (läs googla). Går man exempelvis in och klickar på Licenser under Facebook Messenger appen så hittar du direkt en hel del bibliotek som återfinnes:

 

Facebook Messenger iOS Nätverk

Här är Wireshark eller NetworkMiner din vän. Se vilken trafik som kommuniceras till eller från appen då den startas eller om den kör i bakgrunden. Om den är krypterad så kan du behöva installera ditt eget certifikat. Även i vissa fall så använder ej appen dina proxy-inställningar om du vill använda Charles eller Burp.

Viktigt är att dokumentera löpande all information som kan vara av intresse såsom sökvägar, IP-adresser och user-agent.

Swedavia API anrop

 

Ovan skärdump från ett tidigare blogginlägg.

Filsystem

Gå till den mapp där just din app håller hus. Om du inte vet vilken mapp som används kan du kontrollera processlistan när du startat appen.

Många utvecklare lämnar kvar information och filer i mapparna. Här kan sqlite-filer (.db) hittas med information eller .plist-filer som kan läsas med plutil.

Här är ett exempel då jag listar några E-postadresser samt telefonnummer på Facebook-vänner från filen fbsyncstore.db med hjälp av sqlite3-kommandot:

fbsyncstore.dbFilerna kan även ändras om det skulle vara en fördel för dig. Såsom om det finns möjlighet till att se mer debug-information.

Runtime

Detta är den svåraste biten, dels för att Apparna på iOS är krypterade när dom ligger på disk men även för att det tar otroligt lång tid att kartlägga hur en App fungerar i detalj.

Ett bra första test är att använda dumpdecrypted och sedan class-dump-z och då kan vi bl.a. se följande information:

SSCrypto iOS

Vilket berättar att dom troligtvis använder SSCrypto som är en wrapper för OpenSSL. Dock så uppdateras ej SSCrypto (Septicus Software) och dom rekommenderar istället Apples CCCrypto.

För att sedan se mer information så rekommenderas theos (mobile substrate), gdb samt cycript. När det gäller gdb så kan objc_msgSend användas för att logga alla Objective-C metodanrop med följande:
break objc_msgSend
commands
printf "-[%s %s]\n", (char *)class_getName(*(long *)$r0,$r1),$r1
c
end

Detta är förutsatt att du redan har anslutit till processen genom gdb -p <processid> innan. Då fortsätter du bara med kommandot c så ska du få ut löpande information.

Även så kan jag rekommendera Snoop-It som i sin tur använder sig av Mobile Substrate Tweak.xm (tyvärr stödjer ej Snoop-It 64 bitars-appar ännu). Bra guide här hur du skapar en egen tweak.

Även så fungerar det bra att ladda in den dekrypterade appen direkt i IDA Pro för att underlätta processen:

IDA Pro iOSKoden för funktionen generateRSAPrivateKeyWithLength ser ut att vara samma som denna.

Tipsar även om att kolla in iRet som Veracoda har släppt samt guiden på penetrationstest.se.

Kör Docker med CoreOS och fleet

Mitt företag Triop AB erbjuder konsulttjänster inom DevOps. Se här: triop.se/devops

Fleet är en av de nyare verktygen som kommer från gänget bakom operativsystemet CoreOS. Fleet är till för att köra din kod på kluster av Dockers som rullar under CoreOS.

fleet ties together systemd and etcd into a distributed init system. Think of it as an extension of systemd that operates at the cluster level instead of the machine level.

Jag tänkte visa när jag startar upp två noder på Amazon EC2 som kör CoreOS och som sedan administreras med hjälp av kommandot fleetctl.

Python-koden för att starta upp nya servrar hittar du längst ner i detta blogginlägg. Det finns några inställningar som du bör göra innan, såsom att nyckelnamnet stämmer och security group har regler som tillåter port 7001, 4001 och 22. Samt EC2 access id och key.

Starta upp klusterchefen

Först och främst startar vi upp en leader. Detta kommuniceras ut via den unika token som återfinnes under discovery i user_data som du bör sätta till ett unikt värde för varje kluster.

$ python ec2-coreos.py
# Starting EC2 server with hostname coreos-roseanne
 - Wait..
 - Wait..
 - Wait..
Found IP: 46.137.21.3

Du kan även kontrollera att det fungerar att ansluta till den nya servern med IP-adress 46.137.21.3:

$ ssh -p 22 [email protected]
CoreOS (alpha)
[email protected] ~ $

Perfekt. Även kan det vara till fördel att se så att etc verkligen lyssnar på tcp port 4001 och 7001 antingen tittar vi via lsof eller testar att ansluta direkt med curl:

$ curl 46.137.21.3:4001
404 page not found
$ curl 46.137.21.3:7001
404 page not found

Och det fungerar bra. Skulle inte etcd starta upp så kan det bero på att din cloudconfig är felaktig (ej unik nyckel) eller så kan du titta på loggen med journalctl -u etc. Även så kan du starta upp etcd med kommandot:

sudo systemctl start etcd.service

Starta upp en arbetsnod

För att vi ska ha någon mer nod i klustret så startar vi upp en till. Precis som ovan så kör vi bara ec2-coreos.py och väntar några sekunder på att vår nya nod ska starta upp:

$ python ec2-coreos.py
# Starting EC2 server with hostname coreos-alia
 - Wait..
 - Wait..
 - Wait..
 - Wait..
Found IP: 54.220.243.180

Om allt gick som det ska så ska denna nya nod automatiskt ansluta till coreos-roseanne som är leader. Du kan även titta på loggen med journalctl -u etcd om något skulle vara fel eller använda den unika discovery URL:en direkt för att lista alla noder i ditt kluster:

curl https://discovery.etcd.io/db7ce1f96d42b24f38b5c96a3018f1ea|python -mjson.tool

CoreOS Fleet

Då var det dags att administrera vår flotta med noder med hjälp av fleetctl. Jag har på min Mac installerat fleetctl från github men det går även bra via homebrew:

$ brew update
$ brew install fleetctl

Om vi har rätt ssh-nycklar är det bara att köra. Du kan installera rätt ssh nyckel via kommandot ssh-add coreos.pem exempelvis.

Vi börjar med att lista alla maskiner:

$ fleetctl --tunnel=46.137.21.3 list-machines
MACHINE IP METADATA
9c62bc5f... 10.73.195.43 -
f9946c83... 10.35.3.231 -

Perfekt. Då är det dags att slänga ut vårat första jobb som ska utföras i klustret. Det är ett simpelt Hello World test som ska exekveras, så vi lägger följande innehåll i filen myapp.service:

[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
ExecStart=/usr/bin/docker run busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"

Och startar upp:

$ fleetctl --tunnel=46.137.21.3 start myapp.service
Job myapp.service launched on 9c62bc5f.../10.73.195.43

Perfekt. Nu ska jobbet ha startat och vi kan titta med fleetctl journal myapp.service eller list-nodes.

Så här ser det ut med info:

CoreOS Docker FleetOch nu ligger Hello World och kör under Docker på en av noderna vilket fleetctl list-units kan bevittna.

För delning av jobb och leader/follower genomförs av Raft Consensus algortimen.

 ec2-coreos.py

Här återfinnes koden som jag använder för att starta upp nya noder:

#!/usr/bin/env python
## 
## Jonas Lejon 2014
##
## sudo pip install apache-libcloud names

import os, sys, time
import names 
from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver
import libcloud.security
libcloud.security.CA_CERTS_PATH = ['ca-bundle.crt'] # from Mozilla

EC2_ACCESS_ID     = '' # Paste your Amazon EC2 credentials here
EC2_SECRET_KEY    = ''

userdata = """#cloud-config

coreos:
  etcd:
    # generate a new token for each unique cluster from https://discovery.etcd.io/new
    discovery: https://discovery.etcd.io/unique_token_here
    # multi-region and multi-cloud deployments need to use $public_ipv4
    addr: $public_ipv4:4001
    peer-addr: $public_ipv4:7001
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
"""

#EC2Driver = get_driver(Provider.EC2)
EC2Driver = get_driver(Provider.EC2_EU_WEST)
conn = EC2Driver(EC2_ACCESS_ID, EC2_SECRET_KEY)

hostname = "coreos-" + names.get_first_name(gender='female').lower()

print "# Starting EC2 server with hostname",hostname

MY_SIZE = 't1.micro'
#MY_IMAGE = "ami-8f30fff8" # CoreOS beta at eu-west-1
MY_IMAGE = "ami-87a769f0" # CoreOS alpha at eu-west-1

sizes = conn.list_sizes()
images = conn.list_images()

size = [s for s in sizes if s.id == MY_SIZE][0]
image = [i for i in images if i.id == MY_IMAGE][0]

node = conn.create_node(name=hostname, image=image, size=size, ex_keyname="coreos", ex_userdata=userdata, ex_securitygroup="coreos")
nodes = conn.list_nodes()
time.sleep(5)
while nodes[-1].state != 0:
	time.sleep(5)
	print " - Wait.."
	nodes = conn.list_nodes()
print "Found IP:",nodes[-1].public_ips[0]

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