Tuesday, April 19, 2011

Epsilon: What attacks could be executed with the stolen information

Nota: Este post está disponible en Español

In my last post titled “Epsilon Data Breach” I made a brief introduction to Epsilon’s incident and made some remarks on the risks that this attack implied. In this post I want to go deeper into the possible actions that the attackers could take.

One could think that the stolen information is simply names and e-mail addresses, and that these do not represent a risk. But actually, they do represent a risk to the affected companies. This information is the key to launch a variety of attacks against them or their customers.

Let us do an analysis of the different actions that attackers could perform with the information stolen:
The first action could be as simple as selling the information to Epsilon’s Competitors, which would be very valuable to them because it contains enough data to perform a direct marketing campaign. Although this action is a possibility, it does not represent an important risk to the end users affected because, in a worst case scenario, they will be victims of SPAM.

The second action could be a phishing attack. This massive social engineering attack has as primary objective to deceive its victims by obtaining certain information, like user IDs, passwords and identity data among others. How would this attack take place? It is actually quite easy, since the attacker already possesses all the information necessary about final users.  For example, the attacker could simulate a personal e-mail from the US Bank, Citi or Best Buy, stating that customers should change their password of their home banking or on-line accounts due to the Epsilon breach.  Of course, this would be performed in a web site controlled by him, where he would be able to collect the desired information.

This attack vector was the main reason that forced Epsilon’s customers to notify their own customers about the incident, since this one represents a real risk and it is well known that a Phishing attack wave is imminent.

The third action could be a Spear Phishing attack. In contrast to a traditional Phishing, this technique is targeted to a specific organization or group with the aim to achieve unauthorized access to their systems, and is normally used as part of a mayor attack (like obtaining information stored in an organization’s corporate network).

An example of an anatomy of attack that uses both this technique and the information stolen from Epsilon could be the following:
1.      
  1. The attacker will analyze the information stolen from Epsilon in order to find one or more persons that work at a company of interest (ej. Home Depot Credit Card). To achieve this goal, he will do an extensive research using search pages and social networks (i.e. Google and LinkedIn). Once he has finished their homework, he will end up with a list of persons (victims) , that work at the targeted company, and another list of services / preferences that these people use (i.e. account at US Bank or Citigroup).
  2. Once he has the list of victims, he will design the fake e-mails. The success key factor here will be the information stolen from Epsilon, since it will give the con a feeling of authenticity. The e-mail will also contain an attachment that will exploit a known vulnerability (or unknown / zero day) in order to install a backdoor into the system (a hidden program for remote management). As an example, he could send an e-mail faking to be from the US Bank, addressed to one of the victims (using their full name) that contain an attachment that says “Promotions”.
    If the victim falls prey of the Spear Phishing by opening the attachment, the attacker would have achieved the goal of installing the backdoor that will allow him to access to the system when needed. 
  3. Once inside the corporate network, the attacker would search, with regular hacking techniques, the credentials needed to achieve his objective (i.e. steal credit card information from Home Depot Credit Card). 
  4. Once the attacker gained access to the information, he will extract it through the Internet to an external server controlled by him. Probably he will compress the information with a password in order to prevent being detected. 
  5. His final move will be to erase all the evidence of this unauthorized access.

Is this attack possible? 

If we go back a couple of weeks, we might be able to remember the RSA incident, which shows us that this kind of attack is possible and probable.

These attack vectors are the real risks that companies and end users might be exposed based on the information stolen from Epsilon. It is shown in this post that personal information, even if they are e-mail address or preferences, must be protected not only because of their value, but for their utility to launch a major attack.

What should affected companies do?

First of all, conduct and awareness and training to their employees focusing on social engineering, such as Phishing. If they use their e-mails as a form of Identification and Authentication, they should consider changing it or at least changing their passwords to a strong one (or even better, implement a two-factor authentication mechanism).

Secondly, establish an 0-800 or any toll free number in order to their customers or employees to report any strange e-mail or make inquires. This will allow the company to be alerted for any attack attempt that could happen.

Monday, April 18, 2011

Epsilon: Que ataques se podrían realizar con la información extraída

En mi último post titulado "Robo de datos a Epsilon" hice una breve introducción al incidente de Epsilon y comenté cuales eran  a grandes rasgos los riesgos que implicaba este ataque. En este post quiero profundizar las diferentes acciones que podrían tomar los atacantes.

Inicialmente uno puede llegar a pensar que la información extraída son solo nombres y direcciones de correo electrónico y que en sí no representan un riesgo, pero ésta representa un alto riesgo para las Compañías afectadas, dado que son la piedra fundamental para iniciar diversos ataques contra ellas mismas ó sus clientes.

Hagamos un análisis de las diferentes acciones que podrían tomar los atacantes con la información extraída:

La primera acción que podrían tomar es la simple venta de la información extraída  a la competencia,  ya que ésta les sería de mucho valor dado que contiene datos suficientes para realizar una campaña de Marketing directa. Sin embargo, esta es la acción que menor riesgo para los clientes afectados de Epsilon, ya que en el peor caso, sus clientes serán victimas de SPAM.

La segunda  acción podría ser un ataque del tipo Phishing. Éste es un ataque de ingeniería social masivo que tiene como objetivo engañar a sus víctimas para así lograr su objetivo (obtener información, como ser usuarios, contraseñas y datos de identidad, entre otros).  ¿Cómo se ejecutaría este ataque? Bastante sencillo, ya que consideramos que el atacante posee toda la información necesaria sobre los usuarios finales. A modo de ejemplo,  éste podría simular un correo personalizado del US Bank, Citi ó Best Buy invitando a los clientes a cambiar las contraseñas de su home banking ó cuentas on-line  a causa del robo de información sufrido. Claro que estas acciones se llevarán a cabo en un sitio controlado por el atacante y así  éste obtendrá la información que desea.

Este vector de ataque fue el principal motivo por el cual los clientes afectados de Epsilon notificaron a sus propios clientes sobre el  incidente, ya que éste representa un riesgo y es sabido que una ola de ataques de Phishing es inminente.  

La tercera acción podría ser un ataque del tipo Spear Phishing. A diferencia del Phishing tradicional, este  tipo de ataque es dirigido a una organización ó grupo específico con el objetivo de ingresar a los sistemas y normalmente  se utiliza como parte de un  ataque mayor,  como ser robar información de una compañía.

Un ejemplo de una anatomía de ataque que utilice tanto esta técnica como la información extraída de Epsilon podría ser el siguiente:
  1. El atacante analizará la información extraída de Epsilon en búsqueda de una ó varias personas que trabajen en un objetivo de interés (ej. Home Depot Credit Card). Para esto, realizará un arduo trabajo de inteligencia utilizando buscadores  y redes sociales (por ejemplo Google y LinkedIn). Al finalizar esta etapa, tendrá un listado de personas que trabajan en el objetivo y los servicios / preferencias que éstos posean (ej. Cuenta bancaria en el US Bank ó Citigroup).
  2. Una vez definidas las personas, diseñará el correo electrónico a enviar. Para esto, la información extraída de Epsilon juega un factor importante, dado que le da realismo al engaño. También incluirá en el correo un adjunto que hará uso de alguna vulnerabilidad conocida (ó desconocida / Zero Day Exploit) para lograr instalar un backdoor (programa oculto de administración remota) en el sistema. A modo de ejemplo, podría diseñarse un correo del US Bank dirigido a la persona (con su nombre y apellido) que contenga un adjunto que diga “promociones”.
  3. Si la victima cae presa del Spear Phishing abriendo el adjunto, el atacante habrá logrado instalar el  backdoor  que le  permitirá  ingresar al sistema cuando lo desee.
  4. Una vez dentro de la red corporativa, el atacante buscará, mediante técnicas de hackeo tradicionales,  las credenciales necesarias para alcanzar el objetivo del ataque (ej. robar información de tarjetas de crédito de Home Depot Credit Card).
  5. Una vez conseguido el acceso a la información, la misma será extraída por Internet a un servidor externo, también bajo el control del atacante. Lo más probable es que comprima la información con una contraseña para evitar ser detectado.
  6. Para finalizar, el atacante borrará toda evidencia de su acceso no autorizado a los sistemas.

¿Cuán factible es este ataque? Si recordamos el incidente sufrido por RSA no hace mucho, nos indica que este escenario es posible realizar y muy probable que suceda.

Estos vectores de ataque representan los verdaderos riesgos que enfrentan las compañías y clientes finales afectados por el robo de información a Epsilon. Queda demostrado que toda información personal, ya sean direcciones de correo ó preferencias, deben ser protegidas no solo por su valor en sí, sino también por su utilidad en ataques mayores.

¿Qué es lo que deben hacer las compañías afectadas?
Primero que todo, educar a sus clientes y empleados sobre técnicas de ingeniería social, como ser Phishing. Si utilizan la dirección de correo electrónico como medio de Identificación y Autentificación, deberían considerar realizar un cambio de la misma ó al menos cambiar la contraseña a una contraseña fuerte (ó en el mejor de los casos, implementar un sistema de autentificación en base a dos factores).

En segundo instancia, establecer números de llamadas gratuitas para que los clientes y empleados puedan denunciar intentos de ataques ó realizar consultas. Esto le permitirá a la compañía estar alerta ante los posibles intentos que puedan suceder.

Saturday, April 9, 2011

RSA SecurID Attack: FAQ posted by the Company

RSA posted the following FAQ on their web site regarding the attack and actions that must be taken by their customers. Although the FAQ is very helpful for RSA's customers, no more information was disclosed on what was extracted.

Following is the FAQ, the original version can be downloaded here.

 Overview
1. What happened?
recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our rsa business unit. we took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our it infrastructure and working closely with appropriate authorities. 
2. What information was lost?
our investigation to date has revealed that the attack resulted in certain information being extracted from rsa’s systems. some of that information is related to rsa securid authentication products.  
3. Why can’t you provide more details about the information that was extracted
related to RSA SecurID technology?
our customers’ security is our number one priority. we continue to provide our customers  with all the information they need to assess their risk and ensure they are protected.  Providing additional specific information about the nature of the attack on rsa or about  certain elements of rsa securid design could enable others to try to compromise our customers’ rsa securid implementations.  
4. Does this event weaken my RSA SecurID solution against attacks?
rsa securid technology continues to be an effective authentication solution. to the best  of our knowledge, whoever attacked rsa has certain information related to the rsa securid solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers.  we have provided best practices so customers can strengthen the protection of the rsa securid information they hold. rsa securid technology is as effective as it was before against other attacks.  
5. What constitutes a direct attack on an RSA SecurID customer?
to compromise any rsa securid deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their Pins. some of this information is never held by rsa and is controlled only by the customer. in order to mount a successful direct attack, someone would need to have possession of all this information. 
6. What constitutes a broader attack on an RSA SecurID customer?
to compromise any rsa securid deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their Pins. some of this information is never held by rsa and is controlled only by the customer. in order to mount a successful direct attack, someone would need to have possession of all this information.
The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their Pins. social engineering attacks typically target customers’ end users and help desks. technical attacks typically target customers’ back end servers, networks and end user machines. our prioritized remediation steps in the rsa securid best Practices Guides are focused on strengthening your security against these potential broader attacks.  
7. Have my SecurID token records been taken?
For the security of our customers, we are not releasing any additional information about what was taken. it is more important to understand all the critical components of the rsa securid solution.
to compromise any rsa securid deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their Pins. some of this information is never held by rsa and is controlled only by the customer. in order to mount a successful attack, someone would need to have possession of all this information.  
8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?
as part of our standard operating procedures, while we further harden our environment  some operations are interrupted.  we expect to resume distribution soon and will share information on this when available. 
9. Are any other RSA or EMC products affected?
we have no evidence that customer security related to other rsa products has been similarly impacted by this attack. we also are confident that no other eMc products were impacted by this attack. it is important to note that we do not believe that either customer or employee personally identifiable information has been compromised.  
10. What new information are you disclosing in this note, and why are you issuing it now?
we are not disclosing new information related to the incident. customers have asked us to provide more specific best practices and also help them prioritize the remediation steps. they also asked us to clarify some of the terms we used in the original communication.  we are responding to these requests. 
Immediate Guidance For rsa securid Customers
11. What are the top four steps I should take to protect my system?
rsa strongly recommends that each customer review the rsa securid security best Practices available on securcare online and take immediate action to address nonconforming areas in your deployment. specific areas of focus include the following: 
– secure your authentication Manager database and ensure strong policy and security regarding any exported data. (For more information see the Protecting sensitive data and Protecting the authentication Manager environment section in the rsa authentication Manager security best Practices Guide.)
– review recent authentication Manager logs for unusually high rates of failed authentications and/or next token. (For more information see the authentication Manager log Monitoring Guidelines.) 
– educate your help desk and end users on best practices for avoiding social engineering
attacks such as targeted phishing. (For more information see the Preventing social
engineering attacks section in the rsa authentication Manager security best Practices
Guide.) 
– establish strong Pin and lockout policies for all users. (For more information, see the Pin
Management section in the rsa authentication Manager security best Practices Guide.) we have also included three other security best practice guides for customers who are interested in taking additional measures to further secure their rsa securid implementations. 
12. How do I secure my Authentication Manager Database and exported data?
to protect the data stored in your authentication Manager database:
a. do not store any copies of data extracted from authentication Manager online. you should keep an encrypted secure copy offline.
b. remote access to authentication Manager hosts should be reviewed and limited.
c. Physically control access to your authentication Manager servers within your datacenter
environment.
d. use firewalls to isolate your authentication Manager network. 
For more information see the Protecting sensitive data and Protecting the authentication
Manager environment sections in the rsa authentication Manager security best Practices
Guide 

Wednesday, April 6, 2011

Robo de datos a Epsilon

Note: This post is available in English.


El 30 de Marzo, la empresa de marketing on-line Epsilon, fue víctima de un ataque que comprometió los datos del 2% de sus clientes. La Compañía notificó el 1ro de Abril a sus clientes por medio de un comunicado donde informaban que “Un incidente fue detectado el 30 de Marzo, donde los datos de un grupo de clientes de Epsilon fueron comprometidos por un acceso no autorizado a los sistemas de correo de la Compañía. La información obtenida fue limitada a direcciones de correo y/o nombres de clientes.”. Información sobre cómo fue realizado el ataque no fue mencionada aún por la Compañía.
Algunos de los clientes de Epsilon afectados hasta el momento son: 1-800-FLOWERS, AbeBooks, Air Miles (Canada), Ameriprise Financial, Barclay's Bank of Delaware, Beachbody, Best Buy, Capital One, Chase, Citigroup, Disney Destinations, Hilton Honors program, Home Depot Credit Card, Home Shopping Network, JPMorgan Chase, Marks and Spencer, Marriott, McKinsey Quarterly, Target, TD Ameritrade, TiVo, US Bank y Walgreen's.
Los clientes de Epsilon notificaron a sus propios clientes sobre la información comprometida, recordándoles que nunca se les será solicitado por correo electrónico información personal. A modo de ejemplo, AbeBooks envió el siguiente correo a sus clientes “… les recordamos que AbeBooks nunca le preguntará a sus clientes por información personal ó de su cuenta por medio de un correo. Tengan precaución si reciben un correo que les solicita este tipo de información ó los invita a visitar un sitio web donde su información personal les es solicitada”.
¿Cuáles son los riesgos que implica este ataque? Los atacantes tienen información más precisa sobre los nombres, correos y preferencias (hoteles, bancos, etc.), aumentando de esta manera las probabilidades  de éxito de un ataque del tipo de Ingeniería Social (ej. Phishing) dirigida a una o varias personas. Por este motivo, es probable que veamos más casos de Phishing en los próximos meses. Por este motivo los clientes de Epsilon le deben notificar a sus propios clientes sobre el incidente y elevar el nivel de conciencia sobre este tipo de ataques.



Por otro lado, Alliance Data, la Compañía Matriz de Epsilon, reafirmó ayer el ataque  y el robo de datos sufrido por su subsidiaria. En su anuncio, confirmaron que “información personal, como números de seguridad social, tarjetas de crédito ó información de clientes no fueron comprometidas. Epsilon se encuentra trabajando con las autoridades y expertos externos para realizar una investigación con el fin de identificar a los culpables del incidente mientras se implementan protocolos de seguridad adicionales en sus operaciones de correo”. Es sabido que el FBI se encuentra trabajando en el caso.

Alliance Data, en su anuncio también establece que el mayor riesgo para ésta y Epsilon es la pérdida potencial de clientes. Estos son los riesgos corporativos que realmente afronta una compañía al no implementar los controles correspondientes. No es solo el valor del activo que fue afectado, sino los costos indirectos que estos atraen, como ser pérdida de imagen y ventas entre otras.
Por Agustin Chernitsky

Epsilon Data Breach

Nota: Este post está disponible en español.

On March 30th, Epsilon, an online marketing firm, was victim of an attack that resulted in a data breach that affected 2% of their clients. The Company notified their customers on April 1st through a public release announcement where they stated “On March 30th, an incident was detected where a subset of Epsilon clients' customer data were exposed by an unauthorized entry into Epsilon's email system. The information that was obtained was limited to email addresses and/or customer names only”. No other information explaining how the attack took place was released.
Some of the Epsilon’s customers known to have been affected so far are: 1-800-FLOWERS, AbeBooks, Air Miles (Canada), Ameriprise Financial, Barclay's Bank of Delaware, Beachbody, Best Buy, Capital One, Chase, Citigroup, Disney Destinations, Hilton Honors program, Home Depot Credit Card, Home Shopping Network, JPMorgan Chase, Marks and Spencer, Marriott, McKinsey Quarterly, Target, TD Ameritrade, TiVo, US Bank and Walgreen's.
Epsilon’s Customers started to notify their own customers of the data breach and remind them that they will not be requesting personal information through e-mails. As an example AbeBooks sent the following e-mail “…As a reminder, AbeBooks will never ask customers for personal or account information in an e-mail. Please exercise caution if you get any emails that ask for personal information or direct you to a site where you are asked to provide personal information”.
What are the risks of this data breach? The attackers have more precise information on names, e-mail addresses and customer’s preferences (hotels, banks, etc.), increasing the chances of a successful targeted Social Engineering attack (such as Phishing). So it is likely that we will see more Phishing activity in the following months. This is why Epsilon’s customers should notify their own customer on the incident and raise the awareness level on these types of attack.


Alliance Data, a parent Company of Epsilon, issued a press release yesterday stating "No personal identifiable information (PII) was compromised, such as social security numbers, credit card numbers or account information. Epsilon is working with authorities and external experts to conduct a full investigation to identify those responsible for the incident while also implementing additional security protocols in its email operations." It is known that the FBI is working on the investigation.


Alliance Data also states that the biggest risk to them and Epsilon is the loss of potential customers. These are the risks that a Company faces when proper security controls are not implemented.  It is not only the value assigned to the asset, but the indirect costs associated with them, like the loss of image or sales between others.


By Agustin Chernitsky

Monday, April 4, 2011

RSA Víctima de un ataque cibernético: Cómo sucedió

Nota: Esta nota está disponible en inglés


Tal como escribí en mi último post con titulo “RSA Víctima de un ataque cibernético” el día 30 de Marzo, RSA fue víctima de un ataque del tipo Amenaza Avanzada Permanente (Advanced Persistent Threat), que logró extraer información de los servidores de la Compañía. El tipo de información extraída no fue hecha pública por la Compañía, pero sí  se estableció que estaba relacionada con los productos de autentificación de dos factores SecurID. Según la Compañía, la información extraída no permitiría realizar un ataque con éxito sobre los usuarios del producto SecurID,  pero podría ser utilizada para reducir la efectividad de implementaciones de autentificación basadas en dos factores como parte de un ataque mayor

Hasta el viernes pasado, RSA no había realizado más declaraciones públicas sobre como fue el ataque, pero un artículo de Uri Rivne en el Blog oficial de RSA dio pistas sobre cómo éste fue realizado.

Como comenta Uri en su Blog, el atacante en un período de dos días inició por correo electrónico un ataque de Phishing . Este correo, con el tema “plan de reclutamiento 2011”, tuvo como objetivo  a un grupo reducido de empleados sin privilegios. Una de las víctimas abrió un archivo Excel adjunto al correo y éste instaló un backdoor por medio de la explotación de una  vulnerabilidad desconocida (ó zero-day exploit)  en el  Adobe Flash (vulnerabilidad CVE-2011-0609).

Una vez instalado el backdoor, el próximo paso fue permitir el control remoto de la computadora afectada. En este caso, el atacante instaló una herramienta de administración remota que se conectaba en forma reversa, siendo difícil de detectar (la conexión se realizaba desde adentro hacia afuera). Luego, el atacante buscó usuarios con mayores privilegios por la red interna que posean acceso a la información deseada. Esto último fue realizado con metodologías de hackeo normales.

Según Uri, el atacante tomó todas las credenciales de acceso de la computadora comprometida, y luego desde ahí ataco usuarios sin privilegios administrativos en sistemas los críticos y por medio de ataques de elevación de privilegios obtuvo acceso a  usuarios con los privilegios adecuados.

Finalmente, hackearon  los servidores que contenían la información deseada con las credenciales apropiadas,  la comprimieron, cifraron y la movieron a un servidor interno. Posteriormente, la extrajeron por medio de FTP a un servidor hackeado de un proveedor de servicios de hosting.

El resto de la historia ya es conocida.

Por Agustin Chernitsky

RSA SecurID Attack: How it happened

Nota: Este post está disponible en español.

Like I wrote in my previous post titled “RSA SecurID Attack” on March 30th, RSA was victim of a Advanced Persistent Threat (APT) attack, which achieved the goal of extracting information from the Company’s servers. Although the type of information is not publicly specified by RSA, it was said to be related to the SecurID (3) two-factor authentication products. According to the Company, the information extracted does not enable a successful direct attack on any of their RSA SecurID customers, but it might be used to reduce the effectiveness of the current two-factor implementations in a broader attack.

Until last Friday, RSA was keeping for itself any details on how the attack took place, but finally a blog post by Uri Rivne in RSA's official blog gave up some cues on how it happened.

According to Uri, the attacker sent two phishing e-mails over a two-day period. This e-mail, which was targeted to a small group of employees (considered low profile users), contained a subject of “2011 Recruitment Plan”. One of the victims opened the attached Excel file which contained a zero-day exploit that installed a backdoor exploiting an Adobe Flash vulnerability (CVE-2011-0609) (1).

Once the backdoor was installed, the next logical step was to allow remote control of the machine. In this case, the attacker installed a remote administration tool in reverse-connect mode, being difficult to detect. Then the attacker hunted throughout the network for users with more privileges, which had access to the target information. This was done with regular hacking methodologies.


According to Uri, the attacker acquired all access credentials from the compromised user, and then attacked non-administrative users in targeted systems, and then with privilege escalation attacks gained access to high value targets.

Finally, they hacked into the servers of interest with appropriate credentials, moved the target data to an internal server where they compressed and encrypted it. Once this was done, it was extracted through FTP to an external compromised hosting provider.
The rest of the story is already known.

By Agustin Chernitsky

Notes:
(1) Adobe has released a patch.