Taggat med: Apache

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.

Flertalet sårbarheter åtgärdade i Apache

Felix Wilhelm från Google Project Zero har identifierat tre sårbarheter i webbservern Apache. Apache är den nästa populära webbservern på internet efter Nginx.

Säkerhetsbuggarna är enligt följande:

  • important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
  • moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)
  • moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Den allvarligaste av dessa tre och har allvarlighetsgrad important kan mitigeras genom att sätta H2Push off i konfigg-filen för Apache. Rekommenderat är även att uppgradera till version 2.4.44 av Apache som åtgärdar dessa brister.

För mer information gällande CVE-2020-9490 kan du även se följande länk: https://bugs.chromium.org/p/project-zero/issues/detail?id=2030

Tweet från @_fel1x:

Hur många attacker stoppar en WAF?

Svar: Mellan 1 och 100% av alla attacker enligt en ny undersökning. Läs mer nedan.

Finska cybersäkerhetsföretaget Fraktal bestämde sig för att göra ett test för att se hur väl en Web Application Firewall (WAF) fungerar.

Det finns rätt många WAF-leverantörer på marknaden och Fraktal fokuserade enbart på Azure Waf Amazon Managed, AWS WAF Fortinet Managed, Azure Waf with CRS 3.1 samt Barracuda WAF-as-a-Service.

Jag kan säkert komma på minst 10 andra WAF-tjänster som ej är testade, vilket är lite tråkigt.

Testresultatet ser ut enligt följande:

Och detta resultat är rätt anmärkningsvärt. Främst för att vissa produkter enbart fångade upp 1-2% av attackerna samt andra konstigheter såsom:

  • AWS Managed WAF hanterar POST och GET olika. Följande anrop blockerades i GET men inte i POST: %2e%2e//etc/passwd
  • Barracuda blockerar om ‘ är det enda i ett anrop. Men inte anrop såsom eval(‘sleep 5’)

Slutsatsen från denna undersökning tycker jag bottna i att vi ej bör lita helt på en WAF utan att den enbart fångar mellan 1-100% beroende på vilken WAF som används.

En WAF kan fånga lågt hängande frukter och en angripare med någorlunda kunskap bör kunna ta sig förbi en WAF.

CRS står för Core Rule Set och kommer från OWASP. Azure WAF har som standard version 3.0 och den nyaste versionen är 3.1 som man själv kan slå på. Version 3.1 innehåller fixar för false positives, file upload regler, Java-attacker och mer.

Givetvis kan även OWASP Core Rule Set även användas med ModSecurity/NAXSI och webbservrar såsom Nginx och Apache.

Analys av 1177-läckan

1177 vårdguiden

Igår så tipsade en anonym person sajten Computer Sweden att miljontals inspelade samtal till vårdupplysningstjänsten med telefonnummer 1177 låg tillgängliga för allmänheten på en webbserver. Denna server har används som backup-server av företag som upphandlats av tre landsting.

Servern är en gammal Apache-server som bland annat verkade ha mjukvaran ownCloud och går under namnet NAS, Network Attached Storage. ownCloud gör att du kan sätta upp din egen molntjänst on-prem (hos dig själv).

Vid upphandlingen av leverantören så ställdes ett antal krav hur denna känsliga information skulle vara tillgänglig. Bl.a. skulle SITHS-kort användas för att komma åt informationen (se länkar nedan).

Men trots dessa krav på leverantören, hur kunde det går fel? Jag gissar på att ingen följt upp och kontrollerat kraven med hjälp av tillsyn. Skulle återkommande penetrationstester eller automatisk sårbarhetsskanning genomföras så skulle det inte troligtvis inte ha hänt. Något som bl.a. kreditkortsstandarden PCI-DSS ställer krav på.

Även så rekommenderar vi som jobbar med säkerhet både hängslen och livrem. Det som har hänt här är att företaget troligtvis kopplat något fel eller genomfört en felaktig konfiguration, jag tror inte heller att filerna legat uppe sedan 2013. Utan att misstaget genomfördes någon gång förra året under 2016. Men ett enda misstag ska inte få denna typ av konsekvenser, därav bör det finnas mer skydd exempelvis kryptering på filnivå. I detta fall kan hårddisken varit krypterad men det spelar ingen roll när webbservern visar katalogerna och gör filerna tillgängliga för nedladdning.

Har någon laddat hem filerna och lyssnat? Givetvis. Minst två personer, den som tipsade Computer Sweden samt journalisten. Även finns det stor chans att filerna cachats på diverse ställen ute på Internet. Dock kan loggfiler finnas kvar och gör det möjligt att spåra nedladdningar.

Sådana här läckor är givetvis otroligt allvarliga och kan leda till fara för liv och lem.

Tyvärr är nog detta enbart toppen av ett isberg när det gäller cybersäkerhet inom vårdsektorn.

Källor:

Uppdatering: Vi vet nu lite mer och servern verkar ha varit online sedan 2016 då någon ”stoppade in internetkabeln”.

RCE-Sårbarhet i flertalet Cisco-produkter

Flertalet produkter från Cisco använder sig av ramverket Apache Struts 2. Struts innehåller nämligen en allvarlig sårbarhet i hanteringen av XML som kommer in via dess REST-gränssnitt. Problemet är av typen deserialisering i Java och följande CVE har problemet i Struts 2:

  • CVE-2017-9805, Apache Struts REST plug-in XML processing arbitrary code execution vulnerability

Och de Cisco-produkter som berörs är i nuläget inte helt fastställt men Cisco jobbar med att undersöka vilka produkter som berörs. Minst följande produkter är sårbara för RCE (kör-kod-remote):

  • Cisco Digital Media Manager
  • Cisco MXE 3500 Series Media Experience Engines*
  • Cisco Unified Contact Center Enterprise
  • Cisco Unified Intelligent Contact Management Enterprise
  • Cisco Network Performance Analysis

Mer information finnes på Ciscos sidor här:

Och exploit hittar du här:

Samt bra redogörelse om problemet i Struts 2 och dess problem med deserialisering i Java:

Via CERT-SE

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