Feed aggregator

Infocon: green

Video: Encrypted Sextortion PDFs
Categories: Security Posts

Video: Encrypted Sextortion PDFs, (Sun, Sep 22nd)

In this video, I show how to use my PDF tools together with QPDF and Poppler to deal with encrypted PDFs, like the sextortion PDFs that were submitted recently.   Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Security Posts

Edward Snowden in His Own Words: Why I Became a Whistle-Blower

Wired: Security - 7 hours 47 min ago
Book excerpt: As a systems administrator, the young man who would expose vast, secret US surveillance saw freedom being encroached and decided he had to act.
Categories: Security Posts

The iOS 13 Privacy and Security Features You Should Know

Wired: Security - 7 hours 47 min ago
Your iPhone just got a major security upgrade. Here are all the ins and outs.
Categories: Security Posts

Update: strings.py Version 0.0.4

Didier Stevens - 9 hours 51 min ago
This new version of strings.py comes with a new option -T to trim the strings to a given length. And also 2 bug fixes. strings_V0_0_4.zip (https)
MD5: 8B1F5A6BEBA2BC8BDFF16B99C27050E4
SHA256: 7BBAAB0E83692288BDC35BC0FBDD6B2F8A141280E506131E2818F49BEF31D01A
Categories: Security Posts

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)

Un informático en el lado del mal - 10 hours 27 min ago
El correo electrónico, o e-mail, es un caos maravilloso. Esa es una de las frases que solía utilizar yo cuando hablaba de cómo funcionaba y cómo había evolucionado, durante las charlas que di en el año 2009 con mi querida Informática 64 en la charla "Hay una carta para ti". Un caos maravilloso que usamos a diario, pero que tiene muchas lagunas de funcionamiento y apaños, de los que os voy a comenzar a hablar por aquí.

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
En este artículo, que he dividido en cuatro partes, voy a intentar hacer un recorrido didáctico y somero, sobre todas las vicisitudes que ha ido pasando, y las cosas que hemos ido construyendo sobre él y alrededor de él para terminar con alguna idea nueva. Espero que os guste, y sobre todo que os entretenga la lectura.

La necesidad de comunicación

Comunicarse es una necesidad humana. Lo utilizamos para todo. Para planificar la caza de un animal  que diera sustento a toda la banda de Homo Sapiens en tiempos de nuestra etapa de cazadores-recolectores, o para establecer una cita amorosa con una pareja que nos ha estimulado el sistema químico a través de una app de contactos en la que nos hemos dado de alta. Necesitamos comunicarnos para trabajar, para demostrar afecto, cariño, y hasta para estar enfadados con el mundo en Twitter.

El ser humano se comunica, y necesitamos hacerlo por cualquier nuevo medio en el que haya otros como nosotros, nos conozcamos o no. Es por eso que, en cada medio en el que nos hemos ido desenvolviendo a lo largo de nuestras vidas hemos desarrollado sistemas de comunicación en él. Desde mensajes en los árboles, señales de humo, o cartas escritas enviadas por mensajeros a caballo.

En la era moderna, ya con la tecnología de los computadores aquí, también lo hemos hecho. Cuando aparecieron los primeros sistemas de tiempo compartido, en los que muchos usuarios podían utilizar un mismo servidor para ejecutar sus algoritmos, apareció la necesidad de comunicarse entre los usuarios de ese ordenador central. El administrador del servidor debía enviar comunicaciones a los usuarios, tales como normas de comportamiento, periodos de indisponibilidad por mantenimiento, o actualizaciones de información sobre nuevas características en el servicio.

Por supuesto, entre los propios usuarios también aparecieron estas necesidades de comunicación. Estos podrían trabajar en grupos, dentro de proyectos que realizaban conjuntamente, para los que necesitaban compartir ideas, resultados o propuestas. Había que comunicarse a través del medio común, es decir, el servidor que daba vida a ese ecosistema creado alrededor de él.

Del e-mail al Webmail, pasando por SMTP, POP3, IMAP

Los primeros servicios de correo eran muy sencillos. Los requisitos eran bastante sencillos, ya que todos los usuarios estaban en el mismo servidor, así que no intervenían para nada las redes de comunicación en ese momento. Un usuario se conectaba al servidor por medio de un terminal para tener un shell, por lo que todo lo que hacía se producía directamente en el propio servidor. Al final, su terminal no era más que el equivalente a tener una pantalla y un teclado conectado al servidor desde una ubicación remota. Pero para el software del servidor, una vez el usuario iniciaba sesión, era como si el usuario estuviera sentado físicamente al lado de él.

Para crear un sistema de comunicaciones entre usuarios no había que hacer nada especial que incluyera ubicaciones remotas, múltiples servidores, o redes complejas de interconexión con federación de identidad. La autenticación y el enrutamiento de las comunicaciones se simplificaba al estar todos los usuarios en el mismo servidor. Para resolver el problema de comunicación bastaba con crear un pequeño programa que corriera en el servidor y al que decías a qué usuario querías enviarle el mensaje, por ejemplo a a p0344, cuál era el asunto por el que abrías esa comunicación, y cuál el cuerpo del mensaje.

En ese momento se generaba un fichero y el servicio de e-mail que corría en el servidor creaba un fichero con esta información en la carpeta de ese usuario p0344 - dentro del árbol de ficheros de ese usuario - destinada a recibir el correo. Es decir, el buzón de cada usuario era una carpeta con permisos de escritura para el servicio de “e-mail” donde se le depositaban ficheros de texto con los datos de qué usuario le escribía, cuándo lo hizo, cuál era el asunto y el cuerpo del mensaje. Metadatos que enriquecieran la comunicación electrónica.

Para enviar mensajes el proceso requería hacer algo similar. Había una carpeta de mensajes de salida que el programa, por medio de un “daemon” en el servidor leía periódicamente para ver si había algo nuevo. Cuando aparecía un nuevo mensaje, el servicio de “e-mail” lo borraba de esa carpeta, lo ponía en la carpeta de mensajes enviados para que quedara un copia, y el mensaje era copiado también a la carpeta de entrada del usuario destinatario en su estructura de ficheros particular. Sencillo y funcional.

La cosa se complicó cuando aparecieron más computadores. Ya no teníamos solo un mundo sino un ecosistema de servidores en red y teníamos la necesidad de comunicar usuarios de un servidor, por ejemplo llamado “Albeniz” con otro, por ejemplo llamado “Zipi”. En ese caso había que hacer un protocolo para que el servicio de e-mail de del servidor Albeniz, fuera el que fuera, supiera dónde tenía que enviar el mensaje cuando el usuario no existiera en su mundo y fuera de otro ecosistema, como por ejemplo del servidor "Zipi".

Para poder identificar a qué ecosistema pertenecía cada destinatario de las comunicaciones, inventamos las direcciones con la @servidor y creamos un protocolo que comunicaba el enrutamiento de mensajes entre servidores. El famoso y popular SMTP (Simple Mail Transfer Protocol) que habilitaba cada servicio de e-mail utilizando un puerto, ahora sí, en la red, en este caso el puerto 22. Así, un usuario “chema@albeniz.eui.upm.edu” podía enviar un mensaje a “chema@zipi.fi.upm.edu”. Los servicios de correo electrónico se enviaban los mensajes uno a otro a través de mensajes de red encapsulados en SMTP.

Pero un día los usuarios dejaron de utilizar plataformas de tiempo compartido como si estuvieran sentados en ellas, es decir, dejaron de conectarse a través de sesiones de terminal, y empezaron a usar sus propias estaciones de trabajo. Eso quería decir que el usuario chema@albeniz.eui.upm.es tenía en su despacho otro mundo, en el que había otro usuario, otro sistema operativo, y otras funcionalidades. Había una estación de trabajo y no un terminal, donde se ejecutaba un mundo tipo Solaris, o un MSDos, o un DRDOS, un OS2/Warp o lo que fuera.

Es decir, era otro sistema informático distinto, por lo que si quería enviar correo electrónico utilizando su identidad de chema@albeniz.eui.upm.edu debía actuar como un servidor remoto más y utilizar el protocolo SMTP para conectarse con el servicio de enrutamiento de correos electrónicos en su servidor, pero eso no valía para poder leer sus mensajes recibidos. Había que crear un nuevo protocolo para que pudiera conectarse a ver los mensajes que le habían entrado en su buzón. Y así nació POP3 (Post-Office Protocol v.3), corriendo en la red por el puerto 110.

Al final un puerto no es más que una zona de memoria que comunica a un programa que corre en un servidor con los mensajes que llegan por la red. Cuando arrancamos un programa que enruta mensajes con SMTP en un servidor, lo que hace este programa es hablar con servicio que recibe el tráfico de red en host y decirle:
"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 22 como destinatario me lo pones en esta zona de memoria". Esto mismo hace el protocolo POP3, pero diciendo algo como:
"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 100 como destinatario me lo pones en esta zona de memoria". Cuando los mensajes le llegan al servicio que gestiona las comunicaciones de red en el servidor, este va colocando los mensajes en diferentes direcciones de memoria para enviárselo a los servicios adecuados en función del número de puerto que venga en el destinatario. Es decir, es como el portero de un edificio en el que viven muchos vecinos y reparte los paquetes de Amazon en los distintos casilleros de los vecinos en función del puerto, que en ese caso serán 2º A, 3º C o Bajo C. Como podéis ver por los números de los puertos de los protocolos, la necesidad de conectar servidores nació tiempo antes de la necesidad de descargar el correo del buzón a la estación de trabajo.

Y funcionó. Y se masificaron los usuarios de estos servicios. Cada vez más personas utilizaban el e-mail para todo. Ya no solo trabajo, sino también para socializar entre ellos, lo que hizo que se vierna las limitaciones de estos protocolos creados hasta el momento. SMTP y POP3 tenían que ser extendidos y su arquitectura y concepto inicial ya no eran los requisitos de hoy en día. Estos protocolos eran una evolución de la idea inicial de transferir mensajes en texto plano entre carpetas, y por eso no tenían gran funcionalidad.

Pero con la masificación de su uso se requería enviar comandos para hacer cosas en el buzón remotamente sin necesidad de descargar y enviar ficheros de texto. Si necesito crear una carpeta para organizar el correo y mover un mensaje de una carpeta a otra, descargarse mensajes de textos y volver a subirlos no tenía sentido. Por ello se creó una evolución completa para gestionar los buzones de correos, y entre las muchas propuestas, comenzó a emerger el protocolo IMAP (Internet Message Access Protocol), con una cantidad de evoluciones.

Por supuesto, desde la primera concepción del servicio e-mail en los servidores de tiempo compartido, los clientes de correo electrónico fueron evolucionando. Desde un interfaz basado en comandos, a un interfaz modo texto corriendo en sesiones de terminales, para llegar a los clientes de hoye en día. Con la creación de SMTP y POP3 aparecieron las herramientas de gestión de e-mail en estaciones de trabajo como (Microsoft Outlook – que no es de las primeras ni mucho menos) para tener clientes de correo electrónico con interfaces gráficos, y con la llegada de HTTP y las páginas web aparecieron los primeros servicios como Hotmail o Gmail. Estos, pasaron rápidamente a utilizar IMAP y hoy en día es posible gestionar tu buzón de Gmail con comandos IMAP, como hice yo hace ya muchos artículos.

Los problemas de seguridad

Como os podéis imaginar, con el aumento de la popularidad del correo electrónico, la evolución de la potencia de cómputo de los equipos en clientes y en servidores en Internet, además de la masificación del número de usuarios conectados y la velocidad de las redes de comunicación, los problemas de seguridad con el correo electrónico fueron infinitos.

SMTP y POP3 nacieron como protocolos para mover ficheros de texto plano que estaban en carpetas de un servidor. El esquema de amenazas que había cuando todos los usuarios estaban dentro del mismo servidor era mucho más pequeño que cuando tenemos dos o más servidores. Ya hay un medio por el que los mensajes deben pasar. Y deberían estar cifrados. Así que primero intentamos cifrar las conexiones entre los servidores usando un protocolo como SSL (Secure Socket Layer) para crear un túnel de cifrado servidor a servidor que impidiera que alguien pudiera interpretar el tráfico si interceptaba la señal en el medio. Así, creamos SMTP-S y POP3-S por puertos de rede distintos que la gente ya no se conoce tan de memoria.

Pero también sucedía que el esquema de identificación de remitente y de identificación del host cuando todos los servidores eran confiables y no era fácil conectarse a la red, tampoco valía. Se empezaron a suceder los ataques de suplantación de direcciones IP en los que una estación de trabajo se hacía pasar por un servidor de correo electrónico, usando técnicas de Spoofing o atacando al servidor DNS para cambiar los servidores autorizados para recibir los mensajes de correo de una organización. El esquema de cifrado era inútil frente a ellos, ya que se estaban cifrando las comunicaciones contra el propio atacante, que estaba haciendo un “man-in-the-middle”, así que pasamos a utilizar sistemas como Mutual-TLS donde tenemos no solo que cifrar las comunicaciones, sino también firmarlas por los servidores que están allí.

Figura 2: Libro de Cifrado de las Comunicaciones Digitales:
"De la cifra clásica a RSA (2ª Edición)"

Pero este proceso de enrutamiento de comunicaciones por la red solo por tramos cifrados no es obligatorio para que el e-mail funcione, y una vez que el usuario ha recibido un mensaje de correo electrónico no sabe realmente si el mensaje va a acabar cifrado en el buzón del destinatario o no, y si la comunicación por la que ha venido era un canal cifrado o no. Y por supuesto, ya que se puede suplantar a un servidor de correo electrónico con una estación de trabajo, se puede suplantar a cualquier dirección de remitente que estuviera en ese servidor. Es decir, podrían aparecer mensajes como chema@albeniz.eui.upm.edu que no hubieran sido enviados ni desde albeniz.eui.ump.edu, ni desde luego por chema.

Para ello, sería necesario que el cifrado y la firma de los correos electrónicos fuera extremo a extremos y robusta. Necesitamos no solo garantizar la comunicación de los servidores, sin la comunicación entre remitente y destinatario, para lo que utilizamos sistemas de firma digital como PGP o los certificados digitales de e-mail S/MIME.

Por desgracia, estos sistemas de certificados digitales son bastante poco usados, ya que tienes que  generar certificados en entidades confiables, configurarlos en los diferentes clientes de e-mail que uses (computadoras, ordenadores portátiles, tabletas, diferentes navegadores de Internet) , hay que renovarlos, hay que intercambiarlos antes de establecer una comunicación segura, etc... Demasiadas barreras de usabilidad para la gran mayoría de las personas que utilizan mensajería e-mail por Internet,  por lo que la mayoría de la comunicación por medio de correos electrónicos ni se cifra ni se firma.

Google intentó avisar a los usuarios cuando los correos venían cifrados en tránsito o no, con un candadito rojo como respuesta a las filtraciones de Edward Snowden en las que descubrió que la NSA estaba capturando el tráfico sin cifrar. Y, además, todos los clientes de correo electrónico marcan con un icono especial si el mensaje viene cifrado y/o firmado desde el emisor.

Figura 3: El intento del candado rojo de Gmail. Mucho candado rojo, mejor quitarlo.
Al final, como la realidad es que casi ningún mensaje llega firmado y cifrado extremo a extremo, los usuarios ven normal que un banco o su jefe les envíen un mensaje sin cifrar o firmar. Con lo que se abre el campo para los ataques de suplantación del remitente y de Phishing o los más peligrosos Spear-Phishing que se utilizan en los ataques dirigidos a personas concretas.

A todo esto hay que sumar problemas inherentes al sistema de correo electrónico más, y es que, al ser un sistema de comunicación de coste cero, se ha aprovechado para hacer captura masiva de clientes por medio de mensajes publicitarios, para hacer campañas de estafas masivas engañando a víctimas (Scam), para dar de alta sin autorización en listas de correos, o para simplemente molestar.

Necesitamos más seguridad pero... ¿Será suficiente?

Tras la creación del servicio de e-mail, vimos que la necesidad de usabilidad nos llevó a crear SMTP, POP3 e IMAP, y que las primeras amenazas nos llevaron a aplicar capas de seguridad como SSL, y mecanismos de firma digital y cifrado extremo a extremo sobre sobre el servicio de e-mail, como PGP o S/MIME, pero aún estamos lejos de que poder proteger al servicio de correo electrónico de todos los problemas que se fueron creando, así que hay que hacer más.

En la siguiente parte de este artículo veremos cómo se empezaron a intentar soluciones como Sender Policy Framework, Sender ID, DKIM, o los Filtros Anti-Spam basados en todo tipo de algoritmos, desde listas blancas y listas negras, hasta Inteligencia Artificial pasando por los Filtros Bayesianos o la colaboración de usuarios para detectar Scams, Spam, Spear Phishing, y otros ataques a las personas. Pero aún así... no será bastante, así que habrá que ver qué alternativas han aplicado personas y empresas para lidiar con el e-mail.

Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************
Sigue Un informático en el lado del mal RSS 0xWord
Categories: Security Posts

Do you find MPO Polarity exasperating?

BreakingPoint Labs Blog - 18 hours 1 min ago
Harold Crick thought life was Stranger than Fiction. So I thought of Harold as I was writing…
Categories: Security Posts

How To Reduce Bandwidth Overload At The Edge

BreakingPoint Labs Blog - 18 hours 1 min ago
There is a fundamental shift currently happening in operational technology today—the shift from…
Categories: Security Posts

How to drag and drop industrial automation and control systems (IACS) traffic into your lab network

BreakingPoint Labs Blog - 18 hours 1 min ago
In my last 12 years’ experience of working in the networking industry, I’ve been lucky to work with…
Categories: Security Posts

An Introduction to Internet Encryption

BreakingPoint Labs Blog - 18 hours 1 min ago
Look at your URL bar right now. Do you see “https” in the website address? If it’s there, then be…
Categories: Security Posts

Timestamp formats - The Good, The Bad and the Plain Ugly

BreakingPoint Labs Blog - 18 hours 1 min ago
In many security or network performance applications it is necessary to capture raw packets and…
Categories: Security Posts

How Network Performance Monitoring Is Really Being Used

BreakingPoint Labs Blog - 18 hours 1 min ago
In this blog, we will explore how network performance monitoring (NPM) is really being used by IT…
Categories: Security Posts

Ixia IxFlow App v2.0 for Splunk

BreakingPoint Labs Blog - 18 hours 1 min ago
Before getting into the details, let’s get a little perspective of the challenges of the “need for…
Categories: Security Posts

Keysight World Delivers A Day of Presentations Showcasing Two IT Trends That Will Affect You in 2019

BreakingPoint Labs Blog - 18 hours 1 min ago
During early spring and summer 2019, Keysight (Ixia’s parent company) hosted a serious of technical…
Categories: Security Posts

Supplement traceroute with path discovery for easier troubleshooting

BreakingPoint Labs Blog - 18 hours 1 min ago
The cost of managing complex networks is driven up by the time and effort you must spend to…
Categories: Security Posts

iBypass and Thoughts in a Traffic Jam

BreakingPoint Labs Blog - 18 hours 1 min ago
Each of us has sat in standstill traffic, trying to understand why this major highway we drive all…
Categories: Security Posts

QueryCon 2019: A Turning Point for osquery

Has it really been 3 months since Trail of Bits hosted QueryCon? We’ve had such a busy and productive summer that we nearly forgot to go back and reflect on the success of this event! On June 20-21, Trail of Bits partnered with Kolide and Carbon Back to host the 2nd annual QueryCon, at the Convene Old Slip Convention Center in downtown New York. We beat last year’s attendance with 150 attendees from around the globe. The 14 speakers presented talks on osquery ranging from technical presentations on Linux security event monitoring to discussions of end-user research. We saw familiar faces from last year’s event in San Francisco, and we met many new teams interested in osquery. Tania McCormack of Carbon Black presented her user research on introducing osquery to new audiences. Last year’s inaugural QueryCon brought us all together in person for the first time. QueryCon 2019 strengthened our sense of community and proved a catalyst for positive change: Our productive collaboration generated community-based and technical changes that have put this project back on track. A new foundation On June 18th, the day before QueryCon, the Linux Foundation officially announced that they would be taking over ownership of osquery from Facebook. Under the Linux Foundation, the new osquery Foundation will be directed by a Technical Steering Committee (TSC) consisting of engineers and developers from Facebook, Trail of Bits, Google, and Kolide—companies that are using osquery and have committed to supporting the project. The TSC members are:
  • Teddy Reed (Facebook)
  • Alessandro Gario (Trail of Bits)
  • Zachary Wasserman (independent consultant)
  • Victor Vrantchan (from Google, but working independently)
  • Joseph Sokol-Margolis (Kolide)
This change was exciting news to a growing list of companies who rely on osquery for endpoint protection. As we reported in April, osquery outgrew its original home as a Facebook project, and its community’s expectations and needs now exceed what Facebook can be expected to manage on its own. A new community-based governance model was needed, and conference attendees were eager to discuss the change. We hosted a panel discussion with Facebook’s lead osquery maintainer, Teddy Reed, and representatives from the new osquery TSC.   Facebook’s Teddy Reed led a panel discussion and Q&A with members of the osquery community about plans to transfer stewardship of osquery from Facebook to an open-source foundation.   How the foundation will work The Linux Foundation functions as a steward for osquery, providing various funding and management platforms. (Learn more about their stewardship model here.) The new osquery TSC will guide and maintain the project with the help of contributions from the greater community, and Trail of Bits will commit to biweekly office hours for public comment and transparent project governance. Meanwhile, Facebook will turn over credentials and control of funding, infrastructure, hosting, and engineer review to a new committee of maintainers (of which Facebook will remain a member). The organizations on the TSC are contributing significant engineering time to establish build and release processes, and a forthcoming funding platform on CommunityBridge will allow sponsorship. Technical decisions The TSC has a significant backlog of contributions to work through, but we’re already seeing a massive acceleration of activity on the project. First, osquery core will be updated to feature parity with osql, the community- oriented osquery fork by Trail of Bits. The initial goal is a monthly release, with alternating “developer” and “stable” releases. Another big priority is to merge all major independent efforts and private forks into a single canonical osquery that everyone can benefit from.
Once Trail of Bits resolves the technical debt that has accrued on the project—build toolchains, dependency management, CI systems—it will maintain these components and focus on client-driven engineering requests for osquery. Other stakeholders are also contributing a backlog of Pull Requests, which will be prioritized and merged as soon as possible. A proliferation of committed PRs One way to track the health and activity of a project on GitHub is by Pull Requests. Over nine months, from September 2018 to the day before QueryCon, there were roughly 35 PRs merged to the osquery project, with only a few from the community outside Facebook. In just the 12 weeks since QueryCon, nearly 90 PRs were successfully merged (representing about 113 commits). More importantly, the majority of those contributions were from outside Facebook. Trail of Bits alone is responsible for approximately 44 of the PRs merged this summer. Some highlights from our recent contributions:
  • #5604 and #5610: The new osquery Foundation version of osquery was kicked off by merging the Facebook and Trail of Bits versions of osquery. This meant we restored CMake build support and set up the public CI, which were key improvements brought over from the osql fork.
  • #5706: We refactored the build scripts so that all of osquery’s third-party library dependencies will build from source on Linux. This absolves the need for the project to host and distribute the correct versions of pre-built binaries for these libraries (a job that previously relied on Facebook); improves compatibility across different varieties of Linux; is a prerequisite for our goals of reproducible builds and offline builds; and, finally, avoids incompatibilities arising from system-installed versions of these dependencies.
  • #5696, #5697, and #5640: We fixed and vastly improved the table for querying the certificates stores on Windows. It is now possible to use osquery to list all per-user certificates, whether they are in a registry hive or on the filesystem, and whether or not those users are even logged in at the time of the query. Searching your fleet for anomalous certificates is an important security monitoring and incident response capability, as it can be an indicator of compromise.
  • #5665: We fixed several bugs that we found with the use of dynamic analysis (fuzzing and Clang’s Address Sanitizer). Soon, we plan to incorporate both static and dynamic analysis passes into the CI system, for proactive detection of code vulnerabilities in osquery. This is a best practice that Trail of Bits recommends for all of our clients, and we’re happy to contribute it to the security of osquery.
A new stable release During a community workshop at the end of the conference, osquery users and TSC members discussed the best path to the next stable release. Prior to QueryCon 2019, the most recent major cross-platform release was August 2018. Seven days after the conference, Trail of Bits’ Alessandro Gario provided a pre-release of the new version of osquery. For the past nine months Facebook had refactored osquery around Buck, a build system created and used by Facebook that had long been problematic for the greater community. Our pre-release restored CMake support, CI and packaging, and a few fixes not related to the build system. Now the first full stable release of osquery is out! It’s a significant effort to improve the build system for the future of osquery, ensuring that:
  • Building osquery from source will no longer rely on Facebook to maintain and host the downloads for pre-built dependencies
  • The osquery project once again has a public-facing Continuous Integration server, automatically testing all proposed contributions to detect any developer mistakes or regressions
  • All contributors can use their preferred build tools: developers inside Facebook can use their build tool, Buck, and developers in the greater community can use the standard build tool, CMake
  • An all-new custom build toolchain for Linux will enable broader Linux support, and eventually reproducible builds
New features for osquery users:
  • The process_events table detects more kinds of events, on Linux
  • More powerful query syntax: osquery now supports a regex_match function to allow searches over a particular column of a given table
  • Initial support for eBPF-based event tracing, on Linux
  • New macOS tables for detecting T1/T2 chips, querying the list of running apps, and listing the installed Atom packages on macOS or Linux
  • The certificates, logged_in_users, and logical_drives tables on Windows are all greatly improved
  • Initial implementation of a new high-performance eventing framework that will enable more types of event-based monitoringImproved ability to profile and benchmark tables’ performance
  • New detections added to the macOS query pack
But wait, there’s more! Dozens of bugs have been squashed, additional security hardening mitigations have been turned on, certain performance cases have been improved and resource leaks plugged, the documentation has been updated…we could go on and on. For a full list of changes in this release, refer to the comprehensive change notes. QueryCon and beyond The hosts of the QueryCon 2019 posed for a team group shot! We had so much fun hosting QueryCon this year and we want to thank everyone who attended. This event was a catalyst for positive change in our community thanks to the thoughts, discussions, and passion of this year’s attendees. We can’t wait to see how osquery improves now that its development has been unlocked. What’s next for osquery? We want you to tell us! If you’re using osquery in your organization, let’s talk about what features and fixes should be next. Thanks to a revolutionary meeting of the minds, we now have the power to make it happen.
Categories: Security Posts

Does your government take cybersecurity seriously enough?

AlienVault Blogs - Wed, 2019/09/18 - 15:00
Photo by Katie Moum on Unsplash Cybercrime is global, but the response isn’t. Governments in the west are slowly waking up to the importance of cybersecurity, and are (equally slowly) helping businesses to safeguard data and home users to protect their homes from cyberattack. Look outside Europe and the US, though, and the picture is radically different. African countries, in particular, are underprepared for the impact of cyberattacks, and lack the governmental expertise to deal with them. This is an issue for citizens of these countries, but also for us in the west. Poorly prepared countries act as safe havens for cybercriminals, and hackers (some of them state-sponsored) can use these countries to stage cyberattacks that directly impact users in the west. Cybercrime: a global view Though you wouldn’t know it from the press coverage, large cyberattacks don’t just affect the west. Africa, for instance, actually has a huge problem with cybercrime. Recent reports from Botswana, Zimbabwe and Mozambique show that companies are increasingly falling victim to cybercrime. The global WannaCry malware attack of May 2017 hit South Africa hard, and companies in that country typically lose R36 million when they fall victim to an attack. This situation is mirrored across the global south. It is made worse by the fact that developing nations do not have governmental policies for dealing with cyberattacks. This makes companies and home users in these countries particularly vulnerable. It also means that hackers can route their activities through these countries, which have neither the technical nor the legal expertise to catch them, let alone punish them. Though government policies on cybercrime vary widely across the globe, many of the largest attacks of recent years rely for their success on their global reach. The Mirai Botnet, for instance, managed to infect IoT devices across a huge range of territories and countries, and this global base made it incredibly difficult to stop. Attacks like this have made the IoT one of the largest concerns among security professionals today. Given this context, it is time for governments – in all countries and at all levels – to do more when it comes to managing cyber risk. Managing risk The approach that governments take to dealing with cyber risk is a critical factor in the success of these programs. Too often, governments take a ‘hands off’ approach, issuing advice to citizens and businesses about how to avoid falling victim to an attack, and then expecting them to protect themselves. This approach is somewhat similar to the one governments take to smoking: tell citizens it is bad for you, and they will stop doing it. And if they don’t, they are only harming themselves. This approach does not work when it comes to cyberattacks, because they often rely on millions of computers being poorly secured. Managing cybersecurity, in fact, is more like managing road safety: rules must be put in place, and these rules must have consequences if they are not followed. At the moment, both in the west and elsewhere, this is difficult for governments to implement. That’s because tech is an incredibly fast-moving sector, with new companies and new services appearing all the time. Legislators, often with little knowledge of emerging technologies, are not capable of passing laws quickly enough. To make matters worse, there are no industry-wide standards for security, and this leads to huge differences in the vulnerability of different providers in the same sectors. There are plenty of examples of this: the security Issues of public WiFi are well known, and security researchers like Gary Stevens, CTO at HostingCanada.org, have raised concerns about the often overlooked security vulnerabilities of some popular web hosts. “As more people are able to bring their website online, the threat surface grows exponentially thanks to cheap hosts,” Stevens said in an email interview. “My research consistently shows that discount web hosts, which everyone loves to buy from, have an average uptime of less than 96.5%.” With excessive downtime equated with increased security risks, Stevens pointed out that anything below 99% was considered unusable for business. “Even something as basic and boring as your choice of web host can set you up for a malware infection.”  Helping the average user There is another approach, though, and one that could be very effective in reducing cybercrime. It involves dealing with cybersecurity in a similar way as governments respond to outbreaks of infectious diseases like the flu or measles. This metaphor is a very useful one, because the most common forms of cyberattack operate in a very similar way to infectious diseases. They will infect people (or computers) whose defenses are compromised, and then use this as a base to spread out and cause havoc. With this approach in mind, it becomes very clear how governments can easily do more to protect citizens against cyberattacks. They could pay for mass-information campaigns, for instance. Something as simple as a poster on the bus, reminding people to update the software on their phones, would go a long way to protecting these same people against cybercrime. Some local governments are beginning to realize this. New York has recently started providing this kind of support to its residents, for instance. The program aims to teach the average user some basic skills, like how to spot and get rid of a malware infection, and helps them to recognize phishing scams and other forms of common cyberattack. Stopping more sophisticated attacks is more difficult, of course, but even this will be a lot easier if there is a level of consciousness and technical expertise among the general population. Behavior and security Treating cybersecurity as a social problem, rather than a technical or personal one, could be a highly effective way forward for governments. Programs like these require no great technical expertise within government institutions, and can be expected to have major impacts on the rates of cybercrime. At the broadest level, governments should aim to change the way that people act online. In the same way that citizens had to be taught how to reduce the spread of infectious diseases in the early 20th century, the early 21st century requires that we all learn new ways of behaving. Harnessing these behavioral principles could be a powerful way of reducing society-wide vulnerability to cybercrime, and would be cost-effective for governments.
Categories: Security Posts

IDA 7.4: IDAPython and Python 3

Hex blog - Thu, 2019/08/01 - 09:34
IDA 7.4 will still ship with IDAPython for Python 2.7 by default, but users will now have the opportunity to pick IDAPython for Python 3.x at installation-time!
Categories: Security Posts

IDA 7.4: Turning off IDA 6.x compatibility in IDAPython by default

Hex blog - Thu, 2019/08/01 - 09:32
IDA 7.4 will ship with the IDAPython “IDA 6.x” compatibility layer off by default. Please see this article for more information!
Categories: Security Posts
Syndicate content