Taggat med: IIS

Begränsa attackytan mot Er organisation

Begränsa attackytan mot Er organisation

Inom cybersäkerhet så har det på senare tid blivit populärt att prata om hur man kan analysera och begränsa attackytan, engelska: Attack surface reduction (ASR). Och jag har som vanligt funderat en hel del på området: Det är av stor vikt att organisationer har en insikt och förmåga att förstå sin attackyta.

Tittar man först och främst från internet där majoriteten av alla cyberattacker sker från så ser attackytan ut enligt följande:

  • Tjänster, servrar och enheter som är exponerade mot internet
  • Annan utrustning som kopplas upp såsom switchar, kopiator/scanner, laptops och mobiltelefoner
  • Indirekt attackyta, dvs sådant som kan bifogas med E-post och hamna hos en anställd. Eller när en anställd surfar ut eller på annat sätt ansluter utåt
  • Supply Chain. Mjukvaruppdateringar, hårdvara som köps in, firmware osv
  • Via en annan leverantör eller kund. Tänk exempelvis delad hosting
  • WiFi, bluetooth och andra uppkopplingar såsom VPN
  • Via molntjänster eller molnleverantörer
Alice i Underlandet

Finns säkert fler sätt än ovan som attacker kan ske men viktiga här är att begränsa och isolera samtliga områden där attacker kan genomföras. Ni som organisation måste förstå i detalj vad det innebär att exponera tjänster såsom Apache, Nginx eller Microsoft IIS.

Är det så att ni exponerar en webbserver, vad har den för TCP/IP-stack, TLS-implementation osv? Och kollar vi längre upp i lagret, vad har ni för API:er exponerade? Har ni köpt en on-premise appliance eller någon annan form av magisk låda, så har denna troligtvis en hel del funktioner så ni inte känner till som exponeras utåt.

För det är inte en fråga om ni kommer att bli hackade, utan en fråga om när. Och då måste ni ha verktyg att upptäcka denna attack. Övervaka därför samtliga kanaler på både insida och utsida och titta efter avvikande mönster. Om webbservern pratar TLS 100% av fallen så ska inte helt plötsligt förekomma klartext (annat än just sådant som kan förekomma i protokollet).

Jag gillar OpenBSD-teamets filosofi där allt ska vara avstängt från start och behöver du någon funktion eller tjänst så måste du aktivt aktivera denna ”secure by default”.

På klienter som används mot internet bör därför så lite funktioner, applikationer och dylikt användas. Tittar man på en standard Windows-installation så stödjer denna runt 600-700 olika filformat där många kan användas för att utnyttja eventuella sårbarheter.

Sammanfattning

Tänk så här: Desto mindre rader kod ni exponerar direkt eller indirekt mot internet eller andra attackvägar in mot Er organisation, desto säkrare blir ni. Bryt ner attackytan även mot individuella tjänster och portar som exponeras.

Isolera servrar, tjänster och annat som går att nå direkt från internet. Övervaka dessa tjänster och titta efter avvikande beteenden. Förändringar i attackytan över tid är också viktig att uppmärksamma.

Om någon lyckas få åtkomst till Er mail från internet, eller VPN eller annat som används remote. Vad får det för konsekvenser? Testa och granska, med exempelvis penetrationstester eller red-teaming.

Cybersäkerhetskompetens i styrelser

Cybersäkerhet i styrelser

Under sommaren har jag försökt att jobba så lite som möjligt men bevakat nyhetsflödet gällande Transportstyrelsens outsourcing-fiasko. Mycket bra har skrivits och precis som många pekar på så beror problemet troligtvis på en bristande säkerhetskultur där säkerhet inte ligger högt upp på prioriteringslistan.

Men vad kan detta bero på? Jo, detta är ett fenomen som jag har sett generellt förekommer på många ställen och beror på att styrelse och ledning inte har kompetens inom cybersäkerhet. På tjänstemanna-nivå är kunskapen god och det finns många eldsjälar som brinner för sitt område.

Jag sitter själv med i styrelsen på Internetstiftelsen i Sverige (IIS) och upplever att kompetens inom just cybersäkerhet är otroligt viktigt i många beslut. Därför är det även bra att flertalet myndigheter nu tar in cybersäkerhetskompetens i sina styrelser:

  • Anne-Marie Eklund-Löwinder till Trafikverkets styrelse. CSO på IIS.
  • Pia Gruvö till Post- och telestyrelsens (PTS) styrelse. Chef för krypto och it-säkerhet vid Militära underrättelse- och säkerhetstjänsten (MUST).

Vi kan hoppas att fler myndigheter och företag tar efter: Cybersäkerhet behövs i våra styrelser och ledningar. Stort grattis till Anne-Marie och Pia som är otroligt kompetenta samt grattis till myndigheterna i fråga.

Intressant i sammanhanget är även det som Riksrevisionen skrev 2016 i rapporten om myndigheters informationssäkerhetsarbete, här är ett axplock:

Granskningen visar att myndigheternas ledningar har delegerat ansvaret för informationssäkerhet, utan att se till att de ansvariga har ett tillräckligt mandat att utföra sina uppgifter och tillräckligt med resurser.

Även intressant att notera när det gäller myndigheter så har vi 32 styrelsemyndigheter (leds av en styrelse), 55 nämndmyndigheter och 131 myndigheter leds av en ensam myndighetschef.

Uppdatering: Skrev ovan att Anne-Marie gick till Transportstyrelsens styrelse, men detta var så klart felaktigt. Ska stå Trafikverket.

Nyupptäckt sårbarhet i IIS 6.0

Mer än 8 miljoner webbplatser kan vara sårbar för en nyligen identifierad säkerhetsbrist i Internet Information Services (IIS) 6.0. Sårbarheten har utnyttjats på Internet sedan Juli 2016 och identifierades ”in the wild”.

Den sårbara funktionen heter ScStoragePathFromUrl och är en del av WebDAV:

Microsoft Windows Server 2003 R2 allows remote attackers to execute arbitrary code via a long header beginning with ”If: <http://” in a PROPFIND request

Säkerhetsbuggen identifierades av Zhiniang Peng samt Chen Wu vid South China University of Technology Guangzhou, Kina.

Enligt tjänsten BuiltWith så IIS används IIS på 13.8% av alla webbsajter samt IIS 6.0 versionen på 2.3% av alla webbsajter vilket motsvarar cirka 8.3 miljoner sajter.

Behöver Er organisation hjälp med cybersäkerhet? Kontakta Triop AB >

På Github så kan du hitta följande exploit som demonstrerar sårbarheten genom att starta upp kalkylatorn i Windows, calc.exe:

https://raw.githubusercontent.com/edwardz246003/IIS_exploit/master/exploit.py

Givetvis ska inte IIS 6.0 användas då detta är en mycket gammal version, men troligtvis så kan det hjälpa att stänga av WebDAV för att förhindra att sårbarheten utnyttjas.

Och här finnes en Snort-signatur (källa):

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-MISC IIS v6
WebDAV ScStoragePathFromUrl overflow attempt"; flow:to_server,established;
content:"PROPFIND"; nocase; http_method; content:"|0a|If|3a|"; nocase;
http_raw_header; isdataat:1000,relative; content:!"|0A|"; http_raw_header;
within:1000; reference:cve,2017-7269; reference:url,github.com/
edwardz246003/IIS_exploit;
classtype:web-application-attack; sid:1; rev:1;)

 

httpoxy – Ny omfattande sårbarhet mot webbapplikationer

httpoxy attack

httpoxy är namnet på en nygammal säkerhetsbrist kan återfinnas i otroligt många ramverk för webbapplikationer. Denna nya bugg gör det möjligt för en angripare att styra om utgående trafik från en webbapplikation.

Buggen kan beskrivas lättast genom följande förfarande:

  1. Angriparen gör ett anrop mot en sårbar applikation och skickar med Proxy-http headern
  2. Applikationen gör en utgående förfrågan efter data och använder sedan uppgifter från angriparens Proxy-http header som proxy
  3. Angriparen kan sedan sätta sig i mitten och genomföra MITM-attack

Nedan listas några programspråk och dess uppsättning som kan vara sårbar för denna attack.

Programspråk Ramverk HTTP-klient
PHP php-fpm
mod_php		 Guzzle 4+
Artax
Python wsgiref.handlers.CGIHandler
twisted.web.twcgi.CGIScript		 requests
Go net/http/cgi net/http

Åtgärder

För att förhindra denna attack måste först och främst din applikation använda sig av ovan programspråk, ramverk och http-klient. Även så måste din webbapplikation göra utgående http-förfrågningar när en besökare gör sitt anrop.

För att ta bort HTTP_PROXY miljövariabeln som är boven i dramat så kan du som använder Nginx lägga till följande:

fastcgi_param HTTP_PROXY "";

Använder du Apache som webbserver bör du först och främst läsa denna advisory och sedan kan du använda följande direktiv för att ta bort Proxy http-headern:

RequestHeader unset Proxy

Och använder du Microsoft IIS tillsammans med PHP så bör du lägga in följande i din apphost.config:

<system.webServer>
    <rewrite>
        <rules>
            <rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
                <match url="*.*" />
                <serverVariables>
                    <set name="HTTP_PROXY" value="" />
                </serverVariables>
                <action type="None" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

Buggen har återkommit under flertalet år i olika ramverk och tyvärr så har den aldrig riktigt åtgärdats.

Säkerhetsbuggen har fått följande CVE-er:

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python

Här hittar du mer information: httpoxy.org