Taggat med: Mac OS X

Årets första skadliga kod till Mac upptäckt

Det är företaget Malwarebytes som upptäckt den första skadliga koden till macOS (tidigare Mac OS X). Det är en bakdörr som går under namnet OSX.Backdoor.Quimitchin

Denna skadlig kod har identifierats hos biomedicinska forskningsanläggningar och har troligtvis utvecklas runt 2013-2014. Även så misstänker Malwarebytes att det finns en Windows-version av denna skadlig kod eftersom VirusTotal har identifierat Windows-binärer som pratar med samma C&C-server (Command and Control):

99.153.29.240
eidk.hopto.org

I övrigt använder den skadliga koden de klassiska tricken som att skriva ut en uppstartsfil för exekvering till ~/Library/LaunchAgents/com.client.client.plist

Även skrivs ett antal filer ner till disk som är skrivna i Java samt Perl. Dessa filer innehåller i sin tur kommandon för både Linux och macOS såsom xwd och macOS motsvarighet screencapture.

Nu har även Apple lagt in denna skadlig kod i det inbyggda antivirus-programmet Gatekeeper till macOS. Apple kallar denna skadliga kod för Fruitfly.

Det är i dagsläget oklart hur denna skadliga kod sprids.

IOC:er att titta efter (indicators of compromise)

SHA256: 94cc470c0fdd60570e58682aa7619d665eb710e3407d1f9685b7b00bf26f9647
SHA256: 694b15d69264062e82d43e8ddb4a5efe4435574f8d91e29523c4298894b70c26
SHA256: 83b712ec6b0b2d093d75c4553c66b95a3d1a1ca43e01c5e47aae49effce31ee3
SHA256: ce07d208a2d89b4e0134f5282d9df580960d5c81412965a6d1a0786b27e7f044
SHA256: b556c04c768d57af104716386fe4f23b01aa9d707cbc60385895e2b4fc08c9b0
SHA256: bbbf73741078d1e74ab7281189b13f13b50308cf03d3df34bc9f6a90065a4a55

Apple släpper säkerhetsuppdateringar 🔒

AppleIgår så släppte Apple en stor mängd med säkerhetsuppdateringar. Vissa av dessa uppdateringar åtgärder sårbarheter som innebär att en antagonist kan exekvera kod över nätverket, eller ”An attacker in a privileged network position” som Apple skriver.

Även en mängd lokala attacker såsom utbrytning ur Apples sandlåda.

Nätverksattackerna gäller:

  • Captive Network Assistant – Exekvera kod
  • CFNetwork Proxies – Dataläckage
  • MapKit – Dataläckage

Uppdateringarna gäller följande operativsystem och applikationer:

  • tvOS 9.2.1 for Apple TV (4th generation)
  • iOS 9.3.2 for iPhone 4s and later, iPod touch (5th generation) and later, and iPad 2 and later
  • watchOS 2.2.1 for Apple Watch Sport, Apple Watch, Apple Watch Edition, and Apple Watch Hermes
  • OS X El Capitan v10.11.5 and Security Update 2016-003 for OS X El Capitan v10.11and later
  • Safari 9.1.1 for OS X Mavericks v10.9.5, OS X Yosemite v10.10.5, and OS X El Capitan v10.11.5
  • iTunes 12.4 for Windows 7 and later

SSL sårbarhet i iOS (iPhone/iPad etc)

Apple-SSL-#fail

Ny information. Läs mer här!

Apple släppte i går en uppdatering till operativsystemet iOS som återfinnes i bl.a. iPhone och iPad. Felet som åtgärdas med denna uppdatering är att det genomförs en bristfällig kontroll av värdnamnet i certifikatet stämmer överrens med det värdnamn dit anslutningen upprättas.

Detta kan illustreras genom följande exempel där vi först testar med curl  i Ubuntu Linux som misslyckas:

Linux

Och sedan på en Macbook Pro med Mac OS X version 10.9.1 (Mavericks) där anslutningen lyckas:

Mac OS X

IP-adressen 74.125.143.94 är www.google.se.

Rolig kommentar från Twitter av Christopher Soghoian:

 

Denna sårbarhet möjliggör för en angripare att exempelvis genomföra MITM attacker.

Uppdatering: För att förtydliga. Curl använder sig av Secure Transport (aka darwin-ssl) som genomför bristfällig kontroll av värdnamnet. Från Apples länk nedan:

Secure Transport failed to validate the authenticity of the connection. This issue was addressed by restoring missing validation steps.

Felet verkar enbart uppträda när ett IP-nummer används istället för värdnamn samt så påverkar även denna bugg Mac OS X.

Detta gäller således enbart anslutningar där IP-nummer används istället för värdnamn. Det är svårt att gissa hur många SSL-anslutningar som använder IP-nummer istället för värdnamn.

Exempel 2 gällande Apples bristfälliga SSL-validering

Du ansluter till https://1.2.3.4 men ett annat SSL-certifikat än för 1.2.3.4 returneras. Allt fungerar fortfarande bra. Oklart om det gäller självsignerade certifikat eller om hela certifikat-kedjan ändå verifieras.

Läs mer hos Apple här:

Apples kryptobugg i Lion

När Apple nyligen släppte sin senaste uppdatering till dess operativsystem Mac OS (10.7.3) så glömdes en debug-utskrift kvar där lösenordet till användare förekommer i klartext.

Detta är extra känsligt eftersom FileValut, den kryptering som används för användares hemkataloger då kan återskapas. Använder du FileVault 2 så (full-disk) så berörs du ej av denna bugg.

Buggen identifierades av David Emery och beskrivs på följande sätt:

Det är värre än vad det verkar som, eftersom loggen i fråga kan läsas genom att starta upp maskinen i firewire disk-läge och läsa den genom att öppna enheten som en skiva eller genom att starta upp nya medföljande-LION återställningspartitionen och med hjälp av tillgänglig superanvändare montera filsystemet och läsa debugfilen. Detta skulle göra det möjligt att bryta sig in i krypteradepartitioner på maskiner som de inte har en aning om eventuella inloggninglösenord för.

Skärmdump från loggfilen:

Mac OS X Lion hårddiskryptering

Uppdatering: Om du vill se prestanda bör du kolla här  (PGP WDE) eller här.

Nu när Apple har släppt en ny version av dess operativsystem som går under namnet Mac OS X Lion så finns det stöd för full hårddiskryptering. Med detta menas att hela hårddisken kan krypteras och fungera mer eller mindre transparent mot program, filsystem (HFS+) och användaren.

Apple kallar denna funktion för FileVault och tidigare har denna typ av kryptering enbart fungerat för hemkataloger. Lion ser ut att använda AES-XTS.

Skärmdump: