Taggat med: 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