Security Posts

We're looking for any info or packets that target port 51616.   After witnessing a spike yesterday on his network and checking that our port data [1] corroborated his event, Andrew has written in asking what we know.     The most useful snapshot of port activity can be seen in this graph image.  I ran the graphs as far back as 2006 and nothing more signifcant was illustrated.   The image below highlights yesterdays events as well as a more curious spike back in March.  These counts do not seem very significant at first look, but they could clearly be telling us something.    So drop us a comment to share what you know.  We're interested to attribute this traffic to something useful. [1] https://isc.sans.edu/port.html?port=51616   (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Hace no demasiado David Barroso (@lostinsecurity) recogía en us blog una lista de los ponentes Españoles que habían participado en las conferencias de BlackHat, donde él fue el pionero que abrió la lista. Desde que él comenzara, poco a poco nos hemos ido animando a participar en este tipo de eventos de seguridad, y ya empieza a ser común que en las conferencias internacionales haya ponentes nacidos en España. 
Esto antes no era así, y me da mucha alegría ver a chavales fantásticos como José Miguel Esparza (@eternaltodo), Hugo Teso (@hteso) o Ángel Prado (@PradoAngelo) en las listas de la última Hack In The Box o anunciados para la próxima Black Hat USA 2013. Son jóvenes de una nueva generación de investigadores de seguridad mucho más proclive - tal vez por la situación económica - a salir de nuestro país, pero también mucho más preparada a todos los niveles.
Figura 1: Hugo Teso. Aquí su presentación de la HiTB que causó tanto buzz mediático
Una generación de ingenieros e investigadores de seguridad.... que está ahora casi toda fuera de nuestras fronteras o pensando en irse, porque tanto Ángel, como Hugo, como José Miguel Esparza han seguido los pasos de otros como Ero Carrera, Dreyer o Fermín J. Serna, por poner solo tres ejemplos del cada vez más largo etcétera de profesionales de primer nivel que se fueron a trabajar al extranjero. Algunos pocos con más suerte han convencido a sus empleadores para que les monten la oficina en Málaga, pero son los menos, y el resto ha tenido que emigrar fuera.
Figura 2: CVE de Fermín en la última update de Apple iTunes
Retener a gente de tanto nivel suele ser difícil para un país que no tiene un tejido tecnológico como debería tener, pero espero que algún día, todos estos emigrantes tecnológicos, puedan venir a trabajar a su tierra otra vez, que sé que muchos se hubieran quedado, aún sacrificando cosas, en sus lugares de origen si las oportunidades hubieran sido un poco menos malas.
Suerte a todos los que abandonáis vuestro país para buscaros la vida. En cuanto a los españoles que estáis en las conferencias enseñando vuestros trabajos al mundo, enhorabuena y seguid así. Los que sois de aquí seguro que ya sabéis lo que diría el Rey... (¡Ouch!)
Saludos Malignos!
Un informático en el lado del mal - Google+ RSS Informática 64 Seguridad Apple

• Los chicos de Flu-Project hacen un Call For Developers para lo que podría ser la segunda versión de su herramienta Anubis, pensada para la recolección de información pública como parte de tests de intrusión. A esta segunda versión la llamarían Anubis Revolution
• El framework de seguridad en redes por excelencia, Yersinia, del gran David Barroso y Alfredo Andres, se mueve a un nuevo repositorio de Github.
• La Guardia Civil presenta el libro “Por una red más segura”, escrito por Ángel-Pablo Avilés, en el que recopila las entradas y artículos más relevantes publicados en el Blog de Angelucho. Tenéis también un video "trailer" aquí con la presentación del libro. Este viernes y ayer sábado se celebraron las primeras jornadas de "Por una red más segura", en las que participó como ponente nuestro compañero Lorenzo Martinez con una charla acerca del Spam y Phishing.
• En el diario.es, detenido en Guadalajara un joven de 20 años por difundir en Twitter datos personales de Rosa Díez y Toni Cantó. El detenido, según han explicado los responsables de la operación, almacenaba además información personal de más de 1.500 personas relacionadas con el mundo de la política, el periodismo o el deporte.
• El Inteco abre el plazo de inscripción de 20 plazas para trabajar como técnico en Ciberseguridad. Para acceder al puesto, los candidatos tienen que llevar a cabo diversas pruebas para demostrar conocimientos técnicos y psicotécnicos. En la oferta se pueden encontrar tanto las bases de la convocatoria como un Anexo del puesto
• Documental de más de 15 minutos con una entrevista exclusiva a Jake Davis, alias "Topiary", uno de los miembros del grupo Lulzsec, todos ellos detenidos. Jake ha sido condenado a 2 años de carcel. En dicho documental, también se cuenta con la presencia de Mikko Hypponen, de F-Secure.
• Apple corrige 41 vulnerabilidades de seguridad en su reproductor iTunes. Alguna de estas vulnerabilidades fueron descubiertas hace más de un año. Una de ellas, la correspondiente con el CVE-2013-1000, por parte del gran Fermín J. Serna, en nombre del Google Security Team.
• Disponibles las slides en este enlace de la pasada NoSuchCon que se ha celebrado este pasado jueves 15, viernes 16 y sábado 17 en Paris. Especial mención merece la charla de Mateusz "j00ru" Jurczyk con título "Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions"
• Anunciada la lista de ponencias y ponentes para la próxima OWASP Europe Tour - Barcelona 2013, entre los que se encuentran Marc Rivero, Chema Alonso, Albert López "Newlog", entre otros muchos. Se celebrará el 14 de Junio en la Universitat Ramon Llull, La Salle. ¡Cita que no te puedes perder!

I recently came across an interesting blog post by a team member at Acunetix that addressed a challenge many enterprises are facing when it comes to securing third-party components. This is a pretty hot topic in certain circles these days, and understandably so – studies have suggested that as many as 65% of an enterprise’s mission critical applications are developed externally. Additionally, Veracode research shows that a typical internally developed applications contains somewhere between 30% and 70% of externally developed code, indicating that even internally developed apps are utilizing code originating outside of their own walls. Given these statistics, Mr. Beaver provides some great advice – involve team members truly at risk to make the risk vs. reward decision rather than leave the decision solely up to IT. However, the challenge of vendor risk management is growth significantly. In the past we’ve seen pre and post procurement assessments covering a variety of topics including the financial security of software vendors, background checks of employees, physical checks of vendor environments and scanning of perimeter components such as firewalls. Surprisingly, it is only in the last several years that we are seeing a rise in the number of enterprises making scanning of third-party software a part of the procurement process. At Veracode this effort is clear as we’re on pace to analyze, educate and help improve the security posture of software at over 1,000 vendors in 2013. As application security scanning of third-party applications becomes a standard part of the procurement process, we will see the focus move towards the root cause of issues, indentifying code level flaws in applications and driving vendors to fix those. In fact, we currently share our best practices and lessons learned with the community to help improve their vendor relationships and simplify the scanning process. While our main focus is on helping large enterprises drive security improvements in their vendor community, we understand that a comprehensive Vendor Application Security Testing (VAST) may not work for all vendors or those organizations that don’t already embrace the application security best practices in the supply chain. For those teams looking to begin a vendor risk management program, I recommend the following:

• Clarify the Goal – A simple “Scan and we’ll tell you what to fix” request can be frustrating for vendors who don’t have a clear goal. Define a policy (such as removal of all flaws in the OWASP Top 10), testing techniques (dynamic, static, manual pen testing, etc) and reasonable timelines (think in terms of months, not days) in which vendors should fix their flaws.
• Understand Market Immaturity, But Drive Maturation – Some of the more mature software vendors have very impressive AppSec practices including developer education, static analysis integrated into the SDLC, routine dynamic and penetration testing and a variety of other activities and are typically very cooperative in fulfilling security requests. While these vendors are great to work with, they’re not the norm. Don’t punish those vendors who have not committed to building security in, but make it clear that they will be expected to do so in the very near future or face potential impacts on your business relationship.
• Disparate Responses are OK (for now) – It’s often the case that security is an afterthought for vendors – they’re typically worried more about the next release, new features and keeping the lights on than providing a secure product. The goal of vendor activities should be twofold:
• Gather information your organization needs to make better informed decisions.
• Drive better practices for vendors going forward.
• Tip: Providing vendors with options to do an initial questionnaire like the vBSIMM will get your team short term self-attested answers and drive them to adopting better long term practices. Being realistic but prescriptive in your requests will help not only get initial responses but also drive longer term adoption of best standard practices.
• Work With Your Peers – Vendors are typically selling to dozens, if not hundreds, of customers. If they have to fulfill a separate security requirement for each of those they’ll quickly become frustrated. Most industries have groups that are beginning to focus on AppSec best practices in terms of vendors (such as FS-ISAC in the financial services community). Investigate these groups and begin discussing how you can work together to drive standard goals for vendors.
• Involve Procurement – Nearly every vendor deliverable must go through a procurement process that includes a variety of requirements. Work with this team to include AppSec requirements in the RFP process and include contract language that requires participation in security analysis and remediation. We make our recommend language available for free at: http://www.veracode.com/services/build-security-criteria-into-contracts.html

Securing third-party applications is becoming an increasingly popular topic in the security community. Regardless of the type of solution, enterprises are realizing they don’t control or have any idea what the security posture is for many of the products they use to run their businesses. It could take several years to drive improved awareness and adoption of secure development practices across the broader vendor community, but if businesses begin by following the above recommendations, they are taking a huge first step in making sure the applications they use aren’t putting their business at risk.

It was a watch so beautiful, so elegant, so precise, that it could only have been meant for royalty. Then it vanished without a trace.    |    Photo: David Silberman/Getty Images The tiny Simca 1000 Sedan puttered through the ...

Tomorrow Veracode co-founder and CTO/CISO Chris Wysopal, and Josh Corman co-founder of Rugged Software and Director of Security Intelligence at Akamai Technologies will be filming a video segment with Paul Roberts of The Security Ledger. The trio will be chatting about a variety of topics trending in the Appsec field including but not limited to; recent changes to the OWASP Top 10, security of third party software components, and industry culture. The two will also be answering a selection of questions submitted by members of our community. If there’s a question you’d like answered by either Chris or Josh you can submit it in the comments on this post or tweet it either @Veracode or use the hashtag #TalkingCode! Please submit your questions for consideration before 12pm EST on Friday May 17th. The video will make it’s debut on The Security Ledger in June, we’ll let you know as always once it’s live.

A signed PDF file is just like all signed files with embedded signatures: the signature itself is excluded from the hash calculation. Open a signed PDF document in a hex editor and search for string /ByteRange. You’ll find something like this: 36 0 obj <</ByteRange[0 227012 248956 23362 ]            /Contents<308226e106092a864886f7 This indicates which byte sequences  are used for the hash calculation (position and length of each sequence). So in this example, byte sequence 227013-248955 is excluded, because it contains the signature in hex format padded with 0×00 bytes. This padding is not part of the DER signature, you can change it without changing or invalidating the signature. Quickpost info

Wireless network infrastructure - for anyone in business, it’s a necessary evil and, perhaps ironically, one that isn’t short on infrastructure. You need a controller and wireless routers or access points - lots of them – enabling wireless networks to join an existing wired network. You’ll have to invest in a site planner/survey tool, or risk incorrectly guessing where the APs should go. Users need to learn the new WLAN management system, integrate it into the server...

Of 200 enterprise security professionals recently surveyed by Enterprise Strategy Group, 79 percent report Web application security attacks in the past year. In a late April Network World blog on the topic, Jon Oltsik, a principal analyst at ESG, said the study also found thieves attacked Web application features and functions such as application authentication, configuration management, application authorization and session management. Oltsik says the good news is that there’s more em...

PentesterLab is an easy and straight forwards way to learn the basics of penetration testing. It provides vulnerable systems in a virtual image, and accompanying exercises that can be used to test and understand vulnerabilities. Just decide what course you want to follow, download the course and start learning. You can easily run the course...

Read the full post at darknet.org.uk

A new Trojan is infecting Facebook and distributes itself by sharing links on your behalf. This new malware attack focuses on the users' Facebook profile. The malware is a Trojan Horse transmitted through a browser plugin, detected so far in Firefox and Chrome. Tracking shows that the Trojan horse was first identified in Brazil, and its main activity is monitoring and testing whether the...

 

Our experiments in creating crucible steel with a composition similar to ancient Wootz steel are continuing. In this video, we show the process of making a Wootz ingot and our first successful forging of the ingot into a bar. Our crucibles are charged with wrought iron from wagon tires, pulverized charcoal, some O1 tool steel, calcium carbonate and glass. Watch the video for all the details.

Last Tuesday, April 23, the Twitter account of the Associated Press news agency was hacked and sent out a hoax tweet reporting that President Barack Obama had been injured by an explosion in the White House. Within seconds, Wall Street was in panic mode and US stock plunged. Situations like this illustrate once again the dangers of using weak passwords not only for home users but in corporate environments as well. Today, social networking sites are very often the first point of contact between users and companies, and special care should be taken to strengthen the security of social media accounts. When a Twitter account is hacked, the public normally thinks it has been the result of some highly sophisticated attack perpetrated with complex programs and all sorts of stealth systems only accessible to some privileged minds… Well, in reality, things are usually much simpler. In most cases, the so-called “hacker” simply guess their victim‘s password. The most complex attacks are actually those where the attacker tricks the user into re-entering their credentials in some system unaware of the fact that, in reality, they are submitting their data to a cyber-criminal (which, by the way, was exactly what happened in the AP Twitter hack). Two months ago, Burger King’s Twitter account was also hacked. Its background picture was changed to a McDonald’s image, and a message was posted announcing that the company had been sold to their rivals. It is not known what password Burger King used, but I would say “whopper” is one of the safest bets… The AP attack might look like an isolated incident, but unfortunately these attacks are far more common than it seems. In fact, the group behind the hack, the self-proclaimed “Syrian Electronic Army”, also hacked the Twitter accounts of watchdog organization Human Rights Watch, French news service France 24 and the BBC’s weather service. But it is not only Twitter accounts that are at risk. Many of us still remember the theft of a series of compromising photos from Scarlett Johansson’s cell phone for example. Preliminary investigation seemed to indicate that a hacker had been able to launch a cyber-attack on the American actress’s cell phone, accessing her personal information. Later, however, it was found out that the ‘hacker’  was simply a man with a penchant for hacking into celebrities’ accounts who had been able to guess the star’s email address password. Let me finish by offering you a series of simple tips about social media passwords that will help you protect yourselves from this type of attack:

• Size matters: The longer the password, the safer it will be.
• Do not use personal information (your name, your phone number, etc.) to create passwords.
• NEVER use the same password for multiple accounts.
• Use passwords that are a combination of numbers, letters and special characters. The more complex the password, the safer it will be.
• Change your passwords frequently.

Do not reveal your passwords or send them via email.

Los próximos días 9 y 10 de Mayo estaré en Jaén participando como ponente en las conferencias ConectaCON, que este año organizan la segunda edición de su congreso.

La charla se titula "Offensive Man-in-the-Middle", y es una aproximación un poco más ofensiva de lo habitual al clásico "Man-in-the-Middle" en el que tradicionalmente se pretende obtener información de forma pasiva o, como mucho, levemente activa (downgrade attacks y similares). En esta ocasión vamos a ver como realizar modificaciones en el propio contenido de las conexiones, de tal forma que consigamos obtener más información, o incluso llegar a tomar el control de la máquina, todo ello sin que se percate de nada de lo ocurrido.
Pero bueno, esto solo es mi charla, los asistentes a la ConectaCON de este año podrán disfrutar de charlas de gente como: Lorenzo Martinez, Juan Garrido, Pepelux, Dabo, Bernardo Quintero, Daniel Medianero, Alejandro Nolla y Dani Kachakil. Un par de ellas ya tuve la oportunidad de verlas en el cumpleaños de este blog que celebramos hace unos meses, y os aseguro que son muy interesantes y divertidas.
El horario de las charlas podéis encontrarlo AQUÍ o podéis directamente buscar la información que necesitéis en la web oficial del congreso AQUÍ.
El evento es gratuito y al ladito del fin de semana, así que no tenéis excusa para no pasaros a pasar un par de días con nosotros y aprovechar el viaje para hacer turismo por la zona el fin de semana. Yo al menos pienso hacerlo :P
Os dejo el video promocional de las conferencias, que a mi personalmente me ha encantado, aunque falta algún ponente por añadir que se ha incorporado a última hora.

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'

Buenas, Ejecutar trabajo con los clientes me hace siempre replantearme las cosas, esepcialmente dado que soy de los que cree firmemente que la mejor manera de mejorar es aprender remangándonse en el terreno y usar ese conocimiento en trabajos venideros. Y en estos escenarios, cuanto más complejo, mejor. Si existe un campo hoy en día dentro de la seguridad donde las cosas están poco claras y donde muchos caminan cual veletas, ese es el mundo de la ciberseguridad. Aunque no soy muy amante del sufijo ciber -independientemente de que esté aceptado por la RAE o no- creo que a muchos les puede servir para centrar la conversación. Yo prefiero hablar de operaciones de seguridad, o lo que viene a ser lo mismo, la traslación del mundo de operaciones en el ámbito de TI o los negocios a las actividades necesarias para mantener la seguridad de un entorno determinado. Un poco más abajo explicaremos de qué va esto, y por qué esto no es una colección adicional de buzz words de las muchas que tragamos día a día. Cualquiera que lea noticias, siga blogs o comparta en Twitter información sobre operaciones de seguridad habrá notado que desde el año pasado este es un campo en ebullición. También por desgracia, salvo las excepciones del malware para ciber espionaje o ciber ataques, léase Stuxnet, Duqu o The Flame, casi todo el debate se centra en cuestiones triviales que de poco o nada sirven a las empresas que quieren afrontar con mejores garantías la problemática de la ciberseguridad. Y digo con mejores garantías porque en este mundo en el que vivimos, y como todos ya sabemos, protegerse al 100% es imposible. En casa podemos lograr cómodamente un buen estado de seguridad, ya que podemos parchear cuando nos da la gana, no tenemos que mantener aplicaciones y sistemas que están fuera de soporte, no tenemos que someternos a una disciplina de gestión de cambios, ventanas de cambios en producción, ciclos de pruebas eternos, técnica de sistemas, no tenemos cientos de IPs expuestas al tráfico de Internet y sitios Web públicos, no tenemos que lidiar con 200 vendedores distintos y otras 200 maneras de hacer las cosas, no tenemos que integrar negocios que hemos comprado, no tenemos que segregar negocios que hemos vendido, no tenemos que formar equipos virtuales con gente que habla en 10 idiomas distintos, con 10 maneras y culturas de trabajo distintas, no hay necesidad de escribir casos de negocio para resolver problemas, no hay que lidiar con la aprobación de partidas presupuestarias, no hay que mantener 100.000 estaciones diseminadas en 40 países ... podríamos estar horas enumerando aspectos que hacen que la seguridad en casa sea una cosa, y que la seguridad corporativa sea otra bien distinta. En resumen: no dependemos de nosotros mismos. Precisamente el eterno y erróneo intento de intentar solucionar en la empresa las cosas como las solucionamos en casa es una de las causas principales de que los problemas para corporaciones sean importantes, crecientes y cada vez más difíciles de resolver. Cuando hablo con mis clientes les traslado la idea de un cambio de mentalidad que a muchos les impresiona en un principio y que resulta difícil de digerir: yo lo llamo el estado permanente de compromiso. Seamos honestos: por mucho test de intrusión que hagas, por mucho antivirus que corras y por mucho IDS que tengas desplegado, los amigos de lo ajeno van a encontrar siempre la manera de entrar. Son demasiadas las variables que tenemos que controlar para pretender que podemos controlarlas todas. Es imposible y hay que partir de esa base para construir mejor seguridad. Añadamos a esto el hecho que los vectores de ataque, que eran puramente técnicos en el pasado en su amplia mayoría, están ahora centrados en las personas, lógicamente con el apoyo en la explotación de tecnología. Por eso hace 5 años era aceptable tener una granja de IDS/IPS, y confiar la seguridad a San Firewall, San Microsoft Update y San Test de Intrusión, y hoy en día confiar la seguridad sólo en esos sistemas es una pérdida de tiempo. Agreguemos al cóctel la pérdida del perímetro, que ya no existe como tal, la integración de business partners en las redes corporativas y la explosión de ofrecimiento de servicios que tradicionalmente eran de back-end en frontales web para la interacción con usuarios, que demamdamos más y más servicios en nuestros dispositivos. Quizás la consecuencia más dramática del estado permanente de compromiso es la asunción, por dolorosa que sea, de que la prevención no es suficiente. Aunque sigue siendo buena idea prevenir, la prevención siempre termina fallando, y es entonces cuando es preciso tener medidas reactivas en plaza para intentar reducir el impacto de un evento de violación de la seguridad. Pero tampoco vale sólo con correr una consola SIEM escupiendo alertas, porque nuevamente, los mecanismos preventivos van a fallar, y cuando lo hagan, vas a tener un problema. No hay soluciones fáciles a estos problemas. Los nuevos escenarios requieren nuevas maneras de hacer las cosas. Tener definido un mapa de amenazas es la parte básica, hay que identificar de manera cristalina qué queremos proteger, cómo y de qué. Este paso tan sencillo es ciencia ficción para muchos, y lógicamente, sin esta base es imposible intentar organizarse para afrontar las amenazas reales que puedan estar acechando a la vuelta de la esquina. Pero aquí no acaba todo. A todos se nos llena la boca con ArcSight, enVision o Q1, y muchos son los que corren estos SIEMs, pero, ¿cuántos tienen realmente un sistema adaptado a los tiempos modernos? ¿Cuántos SIEMs ha ahí fuera corriendo todavía los clásicos casos de usuario inútiles, como intentos de fuerza bruta, o logins en horario fuera de oficina? Si queremos tener garantías de mínimo impacto, quizás convenga tener a mano fuentes creíbles de información de amenazas. Esto es lo que veréis anunciado como threat intelligence, y viene a ser información, generalmente generada por terceros, que emplearemos para detectar lo más cerano al tiempo real amenazas de seguridad que se van descrubriendo y sobre las que normalmente no tenemos visibilidad. Y sí, aquí si juega un papel importante un SIEM potente para articularlo todo: información de seguridad que emana de nuestros sistemas, integración con fuentes de inteligencia externas, plataformas de análisis automatizado de malware, y todo ello conjugado con casos de usuario específicos para nuestras pretensiones: recordad lo que hemos escrito sobre escenarios más arriba. Pero una vez más, esto no se resuelve con un SIEM únicamente, la correlación es vital en escenarios compejos de ataque, con lo que resulta también crucial establecer cómo hacer dicha correlación con datos cercanos al tiempo real y con datos no tan cercanos. Y para terminar de complicar las cosas, y nuevamente me remito al estado permanente de compromiso, aún con todas estas cosas los malos van a encontrar la manera de entrar. Hay que saber reaccionar, lo que implica tener procedimientos de respuesta ante incidentes sólidos, entrenarse con escenarios red flag, tener habilitada una disciplina forense para el análisis de brechas de seguridad, instruir a los usuarios en temas de concienciación ... y todo esto hay que coordinarlo de una manera centralizada, suficientementre flexible y orientada a los resultados. Es lo que conocemos como un centro de operaciones de seguridad, o SOC, que para más inri, no vale con articular de una manera técnica, ya que es preciso, como en cualquier otra área del negocio, gestionar con aspectos económicos y administrativos, lo que implica métricas, programas de mejora, evaluación de la respuesta de los operadores, del escalado y gestión de los incidentes, KPIs que se hayan establecido .... y ese larguísimo etcétera. Como resulta fácil comprobar, dar el salto cualitativo de una manera de gestionar las operaciones de seguridad centrada en la tecnología hacia una manera eficiente y centralizada de gestionar un centro de operaciones de seguridad donde atendamos la problemática de las personas y los procesos además de la tecnología no es nada sencillo. Es harto complicado, para ser más concretos. El nivel de inversión y de cambios es tan brutal que muchos, directamente, miran hacia otro lado. Prefieren seguir confiando en test de intrusión, actualización de antivirus y parches en sus exploradores. Y rezando por las noches para que al día siguiente no sean ellos los que salten a los titulares. Un lujo que podrías permitirte en casa, pero que te acabará hundiendo en el mundo de los negocios. Es hora de cambiar el chip. Tú decides. BONUS 10 consejos prácticos para implementar un SIEM/SOC Os dejo una lista de cosas que veo en el terreno y que pueden daros una idea de cómo no afrontar la problemática de la ciberseguridad. El orden no implica importancia: todas estas cosas son vitales.

1. Este es un tema que requiere cambiar a las personas, tecnología y procesos. No dejes estas tareas en manos de personas que sólo son hábiles con el nmap y el Nessus, o sólo con el Powerpoint.
2. Desconfía de implantadores que no tengan credenciales. Pídelas. Y verifícalas. Montar un SIEM/SOC es algo que no está al alcance de cuaquiera que clame ser consultor de seguridad. Requiere experiencia en el terreno, y preferiblemente, en el mismo vertical donde tú vas a implementar. Esto no es un proyecto de una semana y media.
3. Haz tus inversiones de manera escalonada. No quieras hacerlo todo en 6 meses, o te atragantarás. Y lo que es peor: el CFO se atragantará también. Construye un pla creíble que ofrezca resultados escalonados, que te ayudarán a vender mejor lo que haces en la organización, lo que al final te posibilitará accesoa presupuesto de manera incremental.
4. Mide tus posibilidades. Si esto se te escapa de las manos, acude a gente externa para que te ayude. Lo mismo aplica a la operación, si no tienes gente en casa que pueda hacerlo, ya que construir un 24x7 requiere sudor y euros, contrátalo fuera. Sin dudarlo.
5. Si escoges primero la tecnología y tratas después de que todo gire alrededor de ella, acabarás estampándote contra la pared. Hazlo al revés: primero entiende tu negocio y luego selecciona la tecnología que te ayude a protegerlo. Suena elemental pero es la primera causa de fallo en estas integraciones.
6. Cuando hables con tu CFO, déjale claro que esto es un tema que requiere no sólo CAPEX, sino también OPEX. Que nadie se lleve a engaños, un SIEM/SOC además de inversión inicial requiere financiación continua.
7. Presta mucha atención a los casos declarados en el SIEM. Cuando no estén documentados desde la A a la Z, para cubrir cada uno de los riesgos principales del negocio, alerta roja. Cada operador del SOC tiene que tener muy claro qué hacer en cada uno de los casos y sus etapas, revisa con tu integrador otras implantaciones similares antes de contratar, y no te cortes un pelo a la hora de pedir estas cosas como prueba de que se ha implantado algo creíble y no un spaghetti inútil de alertas.
8. Invierte en ajustar y en probar. No esperes, ni de lejos, que estas integraciones sean 100% exitosas cuando concluya el despliegue. Nada más lejos de la realidad.
9. Cuando selecciones tecnología, presta mucha atención a la integrabilidad de las plataformas que quieras someter a disciplina del SIEM/SOC. Es normal tener en casa muchas tecnologías distintas que no hablan entre sí, salvo que tengas un middleware decente, así que pídele a tu integrador que te explique con pelos y señales cómo piensa conectarlo todo. Y que te explique qué viene out of the box, y qué hay que desarrollar. Costes ocultos a la vista ...
10. Por último, entrena los casos de reacción ante indicadores de compromiso hasta la saciedad. Son lo que marcan la diferencia a la hora de lidiar con lo verdaderamente complicado, aka lo que puede hundirte.

Saludos,

Os voy a contar un truco muy sencillo -pero muy útil- para quitar la voz a vuestras canciones favoritas con Audacity, y de esta forma poder hacer el ridículo en karaokes improvisados, malograr con vuestra voz versiones apócrifas de canciones o iniciaros en el mundo de los mashups Lo primero que necesitamos es una canción en WAV o cualquier formato que entienda el Audacity (MP3 puede valer). Yo he elegido “Hotel California” de “The Eagles”, por ejemplo. Una vez abierta con el Audacity, veremos que es una canción stereo, con dos canales: Si usamos el zoom, podremos ver la forma de la onda en cada uno de ellos y cómo son ligeramente diferentes: Nos basaremos en el siguiente principio para eliminar la voz: si sumas una onda y su versión invertida, la anulas. Dado que la voz es mono (suele haber un solo cantante con una sola boca) normalmente, estará copiada igual en los dos canales, así que al invertir uno y sumarlo con el otro, se anulará. ¿Cómo hacemos esto? Muy fácil, separamos la pista stereo en dos canales mono: Seleccionamos solamente una de las pistas: Y aplicamos el efecto de inversión: Finalmente volvemos a juntar los canales en una pista estéreo: Y exportamos el resultado a un MP3. Si lo hemos hecho bien, tendremos una versión de “Hotel California” en la que no se escuchará la voz y podremos arruinarla con nuestros alaridos. Realmente este método no es perfecto y si nos fijamos bien, todavía quedará algún resto de la voz en nuestro MP3. Esto es debido a los filtros y efectos de post-producción que se emplean para mejorar las canciones, que no afectan por igual a los dos canales y por tanto dejan trazas que no se anulan al sumar una onda con su inversa. En algunas canciones estos efectos son tan extremos que la voz permanece totalmente audible después de emplear este método ;-( Una vez eliminada la voz, podemos pensar en cómo se haría para quedarnos solamente con la voz y juntar la voz a la música sin voz de otra canción para inventar nuevas y estrambóticas versiones de música comercial. ¿Se os ocurre cómo podría hacerse?

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.

This year Dino Dai Zovi and I are teaching our Assured Exploitation class again at the CanSecWest conference. This is a two day training on March 7-8, focusing on on the advanced exploitation techniques required for developing state of the art exploits for the latest Windows 7 systems. Why do we feel that this course is necessary? Many security professionals have mastered stack overflows and heap spraying, but these techniques are no longer sufficient for developing exploits in 2011. Reliable exploitation on Vista and Windows 7 requires advanced techniques such as heap layout manipulation, return oriented programming and ASLR information leaks. In addition, robust exploitation necessitates repairing the heap and continuing execution without crashing the process. The goal of our Assured Exploitation course is to teach the principles behind these advanced techniques and give the students hands-on experience developing real-world exploits. Here is a list of the topics that we indend to cover in the 2011 edition of the class: in-depth review of GS, ASLR, DEP, SafeSEH and SEHOP exploitation mitigations heap implementation details and manipulation of the heap state (including Windows 7) building primitives for heap layout control in new applications bypassing DEP and ASLR return oriented programming and shellcode development implementing a universal bypass of DEP and ASLR in Internet Explorer 8 multistage stack pivots The training will be based on a series of hands-on exercises that will incrementally guide the students through building their own exploits for the recent Aurora vulnerability, with capabilities far exceeding those of the publicly available samples. At the end of the course, the students will have the skills to reliably exploit Internet Explorer 8 on Windows 7 with both ASLR and DEP enabled. To register for the course, please visit the CanSecWest website. We encourage you to register early because the class size is limited and prices are going up next month.