Month: September 2015

Hack Brief: Mobile Manager’s Security Hole Would Let Hackers Wipe Phones

Posted on

REMOTE MANAGEMENT SYSTEMS for mobile phones are supposed to make it easy for companies to wipe a device clean if it gets lost or stolen. But a vulnerability discovered in a popular remote management system used by thousands of businesses to manage employee mobile phones would allow an attacker to wipe a CEO’s phone clean, steal the phone’s activity log, or determine the executive’s location, researchers say.

The Hack

The hack involves an authentication bypass vulnerability in SAP AG’s Afaria mobile management system used by more than 6,300 companies. Ordinarily, system administrators send a signed SMS from an Afaria server to lock or unlock a phone, wipe it, request an activity log, block the user, disable the Wi-Fi or obtain location data. But researchers at ERPScan found that the signature is not secure.

The signature uses a SHA256 hash composed from three different values: the mobile device ID, or IMEI; a transmitter ID, and a LastAdminSession value. An attacker can easily obtain the transmitter ID simply by sending a connection request to the Afaria server over the Internet, and the LastAdminSession—a timestamp indicating the last time the phone communicated with the Afaria server—can be a random timestamp. The only thing the hacker needs to direct the attack, then, is someone’s phone number and IMEI, or International Mobile Station Equipment Identity. Phone numbers can be obtained from web sites or business cards, and an attacker can determine the IMEI number of devices by sniffing phone traffic at a conference or outside a company’s office, using a home-made stingray-like device. Since IMEI numbers are often sequential for corporations who purchase phones in bulk, it’s possible for an attacker to guess the IMEI’s for other phones belonging to a company simply by knowing one.

Hack Brief

Who’s Affected?

Because the vulnerability is in the management system, not a phone’s operating system, it affects all mobile operating systems used with the Afaria server—Windows Phone, Android, iOS, BlackBerry and others. Afaria is considered one of the top mobile device management platforms on the market, and ERPScan estimates that more than 130 million phones would be affected by the vulnerability. The ERPScan researchers presented their findings last week at the Hacker Halted conference in Atlanta, but say many companies who use the Afaria system did not get the message.

SAP AG, a German-based company, has issued a patch for the vulnerability, but Alexander Polyakov, CTO of ERPScan, says his company, which specializes in Systems Applications and Product security, often finds businesses with years-old vulnerabilities unpatched in their SAP systems.

“The administrators usually don’t apply patches especially with SAP [systems] because it can affect usability,” he notes. “So what we see in the real environment is, we see vulnerabilities that were published three years ago but are still in the system [unpatched]. They really need to implement these patches.”

How Severe Is This?

The vulnerability is somewhat similar to the recent Stagefright security hole that hit Android in that both attacks involve sending a text message to a phone. But Stagefright, which would allow an attacker to execute remote code on a phone to steal data from it, affects only Android phones, whereas the SAP Afaria vulnerability affects a broader range of mobile phones and devices. Although wiping data from a phone isn’t catastrophic—if there is a backup from which the phone can be restored—not all employees and businesses back up phone data. And even if phones are backed up, it can take days to restore them if an attacker wipes numerous phones at a company.

The authorization bypass vulnerability wasn’t the only flaw ERPScan researchers discovered in the SAP Afaria system. They also found hard-coded encryption keys as well as a cross-site scripting vulnerability that would allow an attacker to inject malicious code into the Afaria administrative console and potentially use it to deliver malware to employee phones. SAP has patched this flaw as well.



Malware implants on Cisco routers revealed to be more widespread

Posted on

Researchers detected 200 Cisco routers with malicious firmware in 31 countries, with the U.S. having the largest number of potentially infected routers.

Attackers have installed malicious firmware on nearly 200 Cisco routers used by businesses from over 30 countries, according to Internet scans performed by cyber crime fighters at the Shadowserver Foundation.

Last Monday, FireEye subsidiary Mandiant warned about new attacks that replace the firmware on integrated services routers from Cisco Systems. The rogue firmware provides attackers with persistent backdoor access and the ability to install custom malware modules.

At the time Mandiant said that it had found 14 routers infected with the backdoor, dubbed SYNful Knock, in four countries: Mexico, Ukraine, India, and the Philippines. The affected models were Cisco 1841, 8211, and 3825, which are no longer being sold by the networking vendor.


Since then, the Shadowserver Foundation, a volunteer organization that tracks cyber crime activities and helps take down botnets, has been running an Internet scan with Cisco’s help in order to identify more potentially compromised devices.

The results confirmed Mandiant’s suspicions: there are more than 14 routers infected with SYNful Knock out there. Shadowserver and Cisco identified 199 unique IP (Internet Protocol) addresses in 31 countries that show signs of compromise with this malware.

The U.S. has the largest number of potentially infected routers, 65. It is followed by India with 12 and Russia with 11.

Shadowserver plans to start notifying network owners who have signed up for the organization’s free alert service if any of the compromised routers fall into their IP blocks.

“It is important to stress the severity of this malicious activity,” the organization said Monday in a blog post. “Compromised routers should be identified and remediated as a top priority.”

By controlling routers, attackers gain the ability to sniff and modify network traffic, redirect users to spoofed websites and launch other attacks against local network devices that would otherwise be inaccessible from the Internet.

Since the devices targeted by the SYNful Knock attackers are typically professional-grade routers used by businesses or ISPs, their compromise could affect large numbers of users.

Cisco has been aware of attackers using rogue firmware implants for several months. The company published a security advisory in August with instructions on how to harden devices against such attacks.


¿Cómo hacer ingeniería inversa de malware?

Posted on

Software malicioso puede ser virus, gusano, Troyano, Rootkit, Bot, herramienta de DoS, Exploit Kit, spyware. El objetivo del análisis de malware es tener una comprensión de la forma de trabajo de piezas específicas de malware. Hay preguntas importantes que deben ser contestadas. Al igual que, ¿cómo se infecta máquina y qué hace exactamente malware? En este artículo vamos a tratar de entender con la ayuda de Bill Smith, experto de soluciones de seguridad informática, los conceptos básicos de análisis de malware y cómo se puede empezar a hacer análisis de malware.

¿Quién analiza el malware?
Hay diferentes tipos de personas y organizaciones que hacen análisis de malware. Todos ellos caen bajo de estas categorías:
• Desarrolladores de productos de seguridad
• Los proveedores de servicios de seguridad
• Investigadores de Anti-virus
• Los desarrolladores de software
• Agencias de seguridad del gobierno

¿Por qué hay una necesidad de analizar el malware?
Las siguientes son las razones detrás de análisis de malware.
• Disponer un procedimiento de respuesta a incidentes de hacking.
• Para hacer el desarrollo de productos y la mejora de productos como anti-virus.
• Para la creación de firmas para la protección contra el malware.
• Para crear soluciones de contramedidas.
• Para hacer el análisis y resolución de vulnerabilidad.
• Para rastrear y capturar a los delincuentes que crean el malware.

¿Cómo hacer ingeniería inversa de malware?

Métodos de análisis de malware
De acuerdo con expertos de formación de seguridad informática, para hacer análisis de malware tiene que seguir estos pasos:

1. Configuración del entorno
Configurar una máquina controlada que no está conectada a la red, también debe ser capaz de restaurar esta máquina en cualquier momento.

2. Colección del Malware
Para configurar el entorno es necesario descargar el archivo de malware primero, y entonces usted necesita cambiar extensión de archivo. De acuerdo con las sugerencias de expertos en curso de hacking ético, después de bajar el archivo se puede copiar el archivo en un disco protegido ya que esto puede ayudar a aislar el malware en algunos casos.

3. Análisis de superficie
Recuperar información de superficie de maquina con malware sin ejecución. Motivo de análisis de superficie es conseguir:
• Valor Hash
• Tipo de archivo
• Strings
• Los resultados de programas antivirus

4. Análisis en tiempo de ejecución
En este paso se puede ejecutar malware y observar su comportamiento. Puede utilizar varios métodos de análisis automatizados o manuales. Puede utilizar las herramientas de observación en el sistema de sandbox para su análisis. Todo el ambiente se puede ser dedicado o aislado OS nativo o sistema virtual explica Mike Stevens, especialista del Mike Stevens, experto de formación de seguridad informática.

5. Análisis estático
En el análisis estático debe leer el código en el archivo binario y entender su funcionamiento. Usted necesitará el conocimiento del sistema operativo, básico de lenguaje ensamblador, técnicas de lectura eficientes y técnicas anti-análisis. Si está packed el código binario tendrá que hacer unpacking. Además para entender el binario, usted tendrá que descompilar o hacer disassemble/debug del binario.

Puede utilizar siguientes herramientas para el análisis estático:

IDA Interactive DisAssemble: Se desensamblar más de 50 arquitecturas

Hex-rays Decompiler: x86/ARM binario a codigo de C.
VB Decompiler: Binario de Visual Basic a código fuente de Visual Basic.
.NET Reflector: .NET binario a código fuente de .NET.

OllyDbg: Muy famoso x86 debugger
Immunity Debugger: x86 debugger de Python

Para entender el código, puede comenzar con las API de Windows de MSDN Library y entender lo que hace el API. También puede comprobar que hacen argumentos y condiciones. Mientras se utiliza un Disassembler, se puede leer, cambiar el nombre y comentar instrucciones para entender el código. Usted puede aprender más sobre Disassembler en curso de formación de hacking ético.

6. Codificación (ofuscación) en Malware
A veces el programador de malware hace ofuscación del código para hacer que sea difícil para que usted pueda hacer el análisis del código.
Nombre de archivo, nombre de la entrada del registro, dirección del servidor almacenada en el binario se codifican como strings. Además paquetes de datos de HTTP pueden ser codificados utilizando diferentes métodos. Algunos de los métodos de codificación son
• xor (exclusive or)
• ror/rol (rotate right/left)
• base64
• RC4
También todo los malwares estos días usan C&C servidor (servidor de comando y control) para obtener los comando, devolver los resultados y datos. Los hackers pueden crear servidores C&C utilizando servidores hackeados, sitios web o cuentas de correo electrónico. También se pueden utilizar Twitter y Facebook cuentas como servidor C&C, de manera que no podemos rastrearlos. Pueden aprender cómo crear servidor C&C utilizando cuentas de redes sociales durante la capacitación de la seguridad informática de iicybersecurity.

7. Prevenir análisis de Malware en tiempo de ejecución
Algunos tipos de malware son lo suficientemente inteligente como para detectar la actividad de análisis por lo tanto tienen una lógica para evitar el análisis por los analistas de malware explica experto soluciones de seguridad informática. Algunas de las técnicas utilizadas para detectar análisis de malware son:

Debugger: Para comprobar si hay debuggers, el malware revisa por puntos de interrupción, manejo de excepciones.
Máquina virtual: Para comprobar si hay máquina virtual, el malware revisa por la interfaz, el comportamiento de la CPU, Herramientas de soporte (como el Virtual box).
Herramientas de análisis: Para comprobar si hay herramienta de análisis de malware como IDA Pro, el malware revisa por el nombre de la ventana, el nombre del módulo.

El malware veces también puede comprobar el nombre del ordenador, el tamaño del disco, la posición del cursor para evitar el análisis de malware. Después de detectar que se realiza el análisis de malware, lo hace algo diferente o no hace nada.
Vamos a cubrir más detalles en profundidad sobre análisis de malware en el próximo artículo con la ayuda de Mike Stevens, profesor de formación hacking ético.

Google Details Plans to Disable SSLv3 and RC4

Posted on

As expected, Google formally announced its intent to move away from the stream cipher RC4 and the SSLv3 protocol this week, citing a long history of weaknesses in both.

Adam Langley, a security engineer for the company, announced the plans through a blog post on Thursday. While there isn’t a concrete timeline, Langely insisted that Google is looking to do away with support for RC4 and SSLv3 in all of its frontend servers, Chrome, Android, webcrawlers, and SMTP servers, in the medium term.

The fact that the company is looking cut ties with both mediums shouldn’t come as little surprise.

The Internet Engineering Task Force condemned SSLv3 in an Internet Standards Track document over the summer, calling it “not sufficiently secure,” adding that “any version of TLS is more secure than SSLv3.”

As Langely notes in the blog, RC4 is 28 years old, and while it fared well in the early goings, it’s been the target of multiple attacks over the years, including some that can lead to TLS session compromise and cookie decryption.

Google Details Plans to Disable SSLv3 and RC4
Google Details Plans to Disable SSLv3 and RC4

As part of the switch Google also announced a collection of minimum standards for TLS clients going forward. According to the post, Google will eventually require the following of devices:

  • TLS 1.2 must be supported.
  • A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that’s being connected to.
  • The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
  • At least the certificates in must be trusted.
  • Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.

Langley notes that devices that don’t meet the requirements won’t stop working anytime soon, but acknowledges they may be affected by TLS changes later down the line, up to the year 2020.

“If your TLS client, webserver or email server requires the use of SSLv3 or RC4 then the time to update was some years ago, but better late than never. However, note that just because you might be using RC4 today doesn’t mean that your client or website will stop working: TLS can negotiate cipher suites and problems will only occur if you don’t support anything but RC4,” Langley wrote.

Langely announced cursory plans to deprecate RC4 earlier this month in a post to the mailing list, confirming that the cipher would be disabled in a future Chrome build, likely stable around January or February 2016.

The company has already taken one step towards nixing SSLv3: a month after last fall’s POODLE attack it did away with support for the fallback to SSLv3 in Chrome, a move that went hand in hand with the company’s phasing out of the SHA-1 cryptographic hash algorithm.


MWZLesson POS Trojan borrows code from other malware

Posted on

Security experts at Doctor Web have discovered a new PoS Trojan dubbed MWZLesson that borrows code from other popular malicious software.

Security experts at Dr. Web have discovered a new PoS Trojan that was designed by mixing code from other malware.

The new PoS Trojan, dubbed Trojan.MWZLesson, was designed reusing the code of other popular malware, including the Dexter PoS and the Neutrino backdoor.

“This code was borrowed from another Trojan designed for POS terminals and named Trojan.PWS.Dexter. The malware sends all acquired bank card data and other intercepted information to the command and control server.” states the blog post published by Dr. Web.


Like its predecessors, MWZLesson compromises the POS terminals, scraping the RAM memory to search for credit card data. Once infected the PoS system, the malware communicates with the server over the HTTP protocol, it steals card data and sends it to the command and control server through GET and POST requests.

Trojan.MWZLesson can intercept GET and POST requests sent from the infected machine’s browsers (Firefox, Chrome or Internet Explorer). Such requests are forwarded to the command and control server run by cybercriminals.” continues the post.
Trojan.MWZLesson can update itself, download and run additional files, find specific documents, and even mount an HTTP Flood attack.

The experts at Dr.Web discovered that the Trojan.MWZLesson also implements features to avoid detection and eradicate other malware that infected the PoS malware.

“Trojan.MWZLesson checks for virtual environments and debuggers and gather information on the infected machine. The newly discovered PoS malware is able to remove other malware present on the machine and is able to exfiltrate different kinds of data.”

The discovery of the Trojan.MWZLesson confirms the great interest of the criminal crews in infecting POS terminals and their abilities in recyclying code of older and efficient malware.  


Russian hacker Responsible for Massive Data Breach Finally Pleads Guilty

Posted on

The infamous Russian hacker, Vladimir Drinkman, has admitted his contribution in what has been regarded by the Justice Department as “the largest such scheme ever prosecuted in the United States.”

Vladimir Drinkman has pleaded guilty and faces court trial along with four other defendants. The group was accused of hacking corporate computers including machines owned by firms such as Diners Singapore, Nasdaq, JCP, 7-Eleven, Dow Jones, Jet Blue, Ingenicard and Visa Jordan and stealing around 160million credit card numbers. Due to the hacks that they conducted, the corporate sector suffered great losses (approximately $300million), which doesn’t include the losses suffered by private individuals whose credit card data was also stolen.

Russian hacker Responsible for Massive Data Breach Finally Pleads Guilty

Drinkman initially pled not guilty after being caught while he was travelling to Amsterdam in 2010. He was immediately sent back to the United States to face the trial. However, this year he changed his tune completely when he was brought to a New Jersey district court in front of Chief Judge Jerome Simandle.

The US Department of Justice maintains that this group of hackers used to monitor the computer systems of hackers for months on end and then they used to exploit the identified SQL database vulnerabilities to infiltrate their networks. Usually, they would leave open a backdoor to compromise the network later. They used to exploit the security holes to install “sniffers,” a type of malware that gather and pilfer user data like the Social Security numbers, credit card numbers and similar crucial information from the targeted computers. These details were then sold to shady online entrepreneurs, who in turn would sell them on different online forums.

Reports suggest that Drinkman and his fellow hackers were extremely careful in their feats since they used encrypted channels only to communicate and even used security software to enhance the layer of protection. They also used to alter the network settings of their victims to prevent their actions from being logged into the computers. However, despite all these measures, Drinkman and co are now behind bars and are facing a maximum penalty of 30 years in prison. Since Drinkman has pleaded guilty his sentence might be lesser than that of his aides. But, we cannot be sure about their sentences until the group actually get convicted on 15th January 2016.


NATO Will Check for Backdoors in Microsoft’s Products

Posted on

Microsoft has taken NATOonboard in its program which presents information about vulnerabilities and provides access to source code.

A Security Agreement between NATO and Microsoft has been signed, which gives NATO the authority to vet the source code of Microsoft’s products for backdoors.

This deal can be regarded as an extension of the 12-year cybersecurity partnership that Microsoft has had with the NATO Communications Information/NCI. This also marks the agreement of Redmond Company’s latest Government Security Program/GSP

A similar deal between EU and Microsoft was signed in June this year after which the Windows developer established its second European Transparency Centre in Brussels. This facility has been opened to allow governments to have a safe place to review its source code.

NATO Will Check for Backdoors in Microsoft’s Products

Microsoft explained that this deal will give the NCI agency powers to access technical information and documentation about the products and services of Microsoft along with product vulnerability information and threat intelligence.

Koen Gijsbers NCI Agency General Manager said,


GSP was launched by Microsoft in 2003 and since then, the program has evolved greatly. Over time, it’s been transformed into a series of resources that offer government officials controlled access to its Transparency Centers, its source code and Microsoft’s vulnerability and threat intelligence services.

Currently, the products that can be vetted by NATO include different versions of Windows, Windows Servers, Windows Embedded and Lync SharePoint 2010.

After this recent development with NATO, Microsoft now has the backing of 44 agencies participating in this program from 26 governments across the globe.

According to sources at Microsoft, the GSP will also facilitate participants in planning for deployments of Windows 10 and the movement of services to the cloud.

This agreement was publicly signed at NATO’s annual cyber conference and it further progressed in the organization’s initiative called NATO-Industry Cyber Partnership. This initiative was launched in 2014. It aims to engage academia and industry partners with the 28 allies of NATO and enhance its defenses against hack-attacks that might damage its physical infrastructure.

This is not the first time when NATO has has gone in deal with an institution to tackle cyber threats. NATO is also assisting Jorden to fight-off ISIS cyber attacks.