Feed aggregator

Another PDF Streams Example: Extracting JPEGs

Enlarge (credit: Brendan Smialowski / Getty Images) The Securities and Exchange Commission (SEC) will require some financial institutions to disclose security breaches within 30 days of learning about them. On Wednesday, the SEC adopted changes to Regulation S-P, which governs the treatment of the personal information of consumers. Under the amendments, institutions must notify individuals whose personal information was compromised “as soon as practicable, but not later than 30 days” after learning of unauthorized network access or use of customer data. The new requirements will be binding on broker-dealers (including funding portals), investment companies, registered investment advisers, and transfer agents. "Over the last 24 years, the nature, scale, and impact of data breaches has transformed substantially," SEC Chair Gary Gensler said. "These amendments to Regulation S-P will make critical updates to a rule first adopted in 2000 and help protect the privacy of customers’ financial data. The basic idea for covered firms is if you’ve got a breach, then you’ve got to notify. That’s good for investors."Read 9 remaining paragraphs | Comments

Todos los años sabéis que el Mobile World Congress es una de mis citas obligadas en el calendario para visitar Barcelona. Pero hay otra cita que también es más que interesante para meter en el calendario: El IoT Solutions World Congress y el Barcelona CyberSecurity Congress que tendrá lugar la semana que viene los días 21, 22 y 23 de Mayo en la Fira de Barcelona.

Figura 1: IoT Solutions World Congress & Barcelona CyberSecurity Congress
Este es un evento centrado en la tecnología conectada y las soluciones para transformar las empresas, los procesos industriales, las ciudades, y por ende las sociedades, por medio de tecnología conectada. Así que, 5G, Robótica, VR/AR/XR, Inteligencia Artificial, Cloud Computing, Big Data & Ciberseguridad son parte fundamental de las temáticas de este mega-congreso.

Por supuesto, también las tecnologías más disruptivas como Edge Computing y Quantum, que son dos tecnologías a las que estamos poniendo mucho detalle en nuestra industria con un ojo en el presente y otro en el mañana cercano.

Figura 2: Tecnologías en el IoT Solutions World Congress y el Barcelona CyberSecurity Congress
Todos estos temas, para nuestro equipo son el día a día, ya que tanto si estás haciendo soluciones para empresas, estás innovando, o te estás haciendo proyectos de hacking o auditoría de ciberseguridad, te las vas a topar en casi cualquier momento a tu alrededor, así que probablemente son los temas de los que más leemos y con los que más nos estamos formando cada día.

El evento, por si puedes asistir, cuenta con una zona de exposición viajes de soluciones por verticales, como los Smart Homes/Buildings, la logística, Energía, Salud, o de Industria 4.0, donde tendremos desde demostraciones, hasta workshops de trabajo a los que puedes asistir con tu entrada.

Barcelona CyberSecurity Congress

Y como os podéis imaginar, todos estos avances en digitalización de los procesos empresariales en industria, ciudades, sociedades, la parte de seguridad que nos toca más de cerca es fundamental. Sin los procesos de Blue Team/Red Team y la gestión de la ciberseguridad de todos ellos, no sería posible introducir estos avances que deben proteger datos sensibles, propiedad intelectual e infraestructuras críticas frente a ataques y brechas de seguridad.

Figura 3: Actividades en el el Barcelona CyberSecurity Congress.Congreso, Hacking Village & Acces 2 Market
Así que dentro del evento tendrás el Barcelona CyberSecurity Congress un congreso con speakers de profesionales de las empresas más importantes de ciberseguridad y una zona de testing en el Hacking Village, donde los más makers disfrutarán de demos, pruebas, y ejemplos técnicos.

Además, hay un “ACCESS 2 MARKET”, que es un evento sobre "matchmaking" organizado por la Agencia Catalana de Ciberseguridad, INCIBE y European Cybersecurity Competence Center (ECCC). Este espacio se enfocará en dar visibilidad a la importancia de abordar las necesidades y retos de los CISOs, intercambiar información con los diferentes líderes del sector, expertos, inversores, proveedores de soluciones en ciberseguridad, startups…
Agenda de conferencias en el Barcelona Cybersecurity Congress
Si te interesan estos temas, quieres darte un baño de presente y futuro de la tecnología aplicada al mundo de hoy, o quieres formarte en últimas tendencias de Ciberseguridad de todos estos nuevos verticales a los que nos vamos a enfrentar, tienes una buena oportunidad esta semana en el IoT Solutions World Congress y el Barcelona Cybersecurity Congress. Os dejo aquí algunas charlas destacadas.
Figura 4: Charlas destacadas de la agenda del Barcelona Security Congress el 21 de Mayo
Si visitas el Barcelona Cybersecurity Congress este próximo 21, 22 y 23 de mayo, aquí tienes un extracto de la agenda de los tres días, que verás que hay una gran cantidad de speakers de primer nivel, y con temas más que relevantes de ciberseguridad.

Figura 5: Charlas destacadas de la agenda del Barcelona Security Congress el 22 de Mayo
Temas de Quantum, de CyberWarfare, de Seguridad Offensiva & GenAI, y un largo etcétera. Vamos, para echarse tres días tomando notas y aprendiendo de este mundo tan apasionante que es el nuestro.

Figura 6: Charlas destacadas de la agenda del Barcelona Security Congress el 23 de Mayo
Si puedes asistir, te recomiendo que te planifiques bien la agenda, que hay muchas actividades en paralelo y merece la pena que no te pierdas las que más te interesa. Aquí tienes la agenda completa del Barcleona CyberSecurity Congress.

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


Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com

In my diary entry "Analyzing PDF Streams" I showed how to use my tools file-magic.py and myjson-filter.py together with my PDF analysis tool pdf-parser.py to analyze PDF streams en masse. In this diary entry, I will show how file-magic.py can augment JSON data produced by pdf-parser.py with file-type information that an then be used by myjson-filter.py to filter out files you are interested in. As an example, I will extract all JPEGs from a PDF document. First, let's produce statistics with pdf-parser.py's option -a: This confirms that there are many "Indirect objects with a stream" in this document. Next, I let pdf-parser.py produce JSON output (--jsonoutput) with the content of the unfiltered streams, and I let file-magic.py consume this JSON output (--jsoninput) to try to identify the file type of each stream based on its content (since streams don't have a filename, there is no filename extension and we need to look at the content): If we use option -t to let file-magic.py just output the file type (and not the file/stream name), we can make statistics with my tool count.py and see that the PDF document contains many JPEG files: Now we want to write all of these JPEG images to disk. We use file-magic.py again in JSON mode, but let it also output the same JSON data augmented with file-type information (--jsonoutput): Next, this JSON data is consumed by myjson-filter.py and filtered with regular expression (case sensitive) JPEG on the file type: -t JPEG. Finally, we write the JPEG images to disk with -W hashext:jpeg: this writes each JPEG stream to disk with a filename consisting of the sha256 of the file's content and extension .jpeg. By using the hash of the content as filename, there are no duplicate pictures: Should you want to reproduce the commands in these diary entries with the exact same PDF files I used, my old ebook on PDF analysis can be found here and the analysis on TLS backdoors done by a colleague can be found here. Didier Stevens
Senior handler
blog.DidierStevens.com (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Iba a empezar esta historia con una frase muy de otros tiempos. Algo así como "Yo no escribo para ligar". Bueno, no es verdad. He dulcificado la frase. Iba a ser más fuerte aún, en referencia al escritor del que habla este artículo, que seguro que irás descubriendo poco a poco. La historia comienza en el día de San Isidro, donde tuve una buena lista de actividades que acabarían con mi entrada en primero de primera otra vez, y mi inclusión en el club de fans de un escritor un tanto peculiar y curioso, con un "Don". Os la cuento cuento.
Figura 1: El escritor, el mago, el periodista y el hacker aprendiz
Me levanté por la mañana temprano para poder meterme en mi disciplina de deporte. No había podido hacer nada el lunes ni el martes, así que el miércoles lo tenía marcado en el calendario para salir a correr una horita y hacerme 10 Km si la rodilla lo permitía.  El día era frío. La pereza intentó tumbarme el plan. Pero soy un hacker peleón, y pude conmigo mismo. Y lo hice. Esto sólo lo cuento para presumir de que lo hice, que para mí siempre es un reto esto de dar zancadas.
Ducha, aseo, y a vestirse de acto solemne para ir a la entrega de las Medallas de Madrid en el consistorio de la ciudad, donde íbamos en representación de Telefónica, que recibía la Medalla de Madrid, como celebración de este Centenario de nuestra compañía.
Fui sin gorro. En Modo Incógnito.
Iba ilusionado porque también se la daban a mis queridos David, Rafa, Javi y Dani de Hombres G por tantas y tantas cosas que han hecho por la difusión mundial de Madrid. Y la recibía el Rayo Vallecano por sus 100 años, la Guardia Civil, la Policía Nacional y la Policía Municipal. Muchos amigos entre los premiados. Muchos amigos entre los asistentes. Carlos Jean, Rosauro, María Benjumea, el "esqui", Ángel Niño, la queridísima Carmen Iglesias a la que adoro, Santiago Muñoz Machado, mis compañeros de Telefónica, y un sinfín de caras conocidas.
Saludos. Besos. Abrazos. Acto institucional. Los detalles son confidenciales. Y aperitivo que me salté.
Me lo salté porque tenía una cita para comer con mi amigo Mago More. Uno de los pocos que está siempre en la misma frecuencia que yo. Su cerebro va más rápido que el mío, pero cuando nos juntamos intento sintonizarme con él. Hacemos muchas cosas Mago More y yo, y siempre que me dice "Tienes que conocer a esta persona" sé que tengo que conocer a esa persona. Y ese fue el motivo de que aceptara la comida casi a ciegas.
Me había dicho el nombre, pero no soy de buscar a la gente en las redes cuando la voy a conocer. Ya ves. Quién lo diría. Prefiero ir sin prejuicios y verlo con mis ojos.
Llegué al restaurante. Un restaurante Brasileño por la zona norte de Madrid donde estaba comiendo el mismísimo Roberto Carlos al mismo tiempo. Ver a Roberto Carlos siempre da buen rollo cuando has sido un fan de esa pierna izquierda y esa sonrisa constante. Me esperaba More y nos sentamos a hablar mientras venía el invitado, que a la postre nos invitó a todos nosotros a comer.
- "Ahí lo tienes", dijo el Mago More.
Miré, y vi a un tipo algo, con sudadera negra y gorra rota mirando un poco perdido por le restaurante. 
- "Si este se hubiera venido conmigo al acto de las medallas hubiéramos hecho una buena pareja", pensé. Y es que viste muy parecido a como me gusta vestir a mí. Ropa cómoda y vieja, sudaderas y poco más. Ya me dio buen rollo. Comenzamos a charlar y contarnos la vida. - "Chema Alonso, te presento a Isra Bravo", dijo el Mago More.
Ahí comenzó todo. Yo le conté mi vida. Él me contó la suya. Y rápidamente se me torcieron los ejes de coordenadas un poquito. Lo que me contaba Isra Bravo me encajaba, pero ... "¿tanto?". Pero si Mago Morelo dice es que tengo que aprender. 
Isra Bravo es un Copywriter que ayuda a las personas a que vendan más y mejor con el poder de las historias y las palabras. Y por supuesto que creo en eso. Yo lo hago siempre en mis charlas. Y escribo en mi blog desde el año 2006, en mi caso como forma de vida personal, profesional, comercial y psicológica.
Él me quería para su evento. Y me propuso hacer una prueba de su talento con MyPublicInbox.
- "Si el poder de las palabras es tan grande, supera al que más mensajes genera en MyPublicInbox durante un mes con comunicaciones de valor. Que la gente te proponga cosas interesantes por tu buzón de MyPublicInbox", dije.
- "¿Cuántas propuestas/mensajes recibes tú?", me dijo.
- "4 o 5 de media al día. Consigue de forma sostenida durante 30 días 4 mensajes de valor en MyPublicInbox" y me habrás derrotado", le dije.
El muy cabrón se puso excitado. Se le iluminaron los ojos. "Ya estoy con ganas de reventarte", me dijo. Y nos descojonamos de risa. Que los dos nos hayamos criado en barrios de Madrid fue un plus que nos ayudó a sintonizar. Y fuimos a nuestra siguiente parada.
Quedamos por la tarde de ese largo San Isidro en una cafetería cerca de Telefónica con un comunicador. Con un periodista. Así que nos juntamos por la tarde para tomar agua y café un Mago (More), un Periodista (Iker Jiménez), un Escritor (Isra Bravo) y un Hacker Aprendiz (el menda). No os cuento el final, pero la historia pinta a que los cuatro acabaremos en un sarao que está montando Isra Bravo para su comunidad. Ya os daré más detalles.
Figura 2: La cuenta de Isra Bravo en MyPublicInbox
Los abandone, regresé para ayudar con Matemáticas a Mi Hacker, escribí mi post de ayer con la ayuda de Julian Isla, y me acordé del reto con el escritor. Le creamos la cuenta a Isra Bravo de MyPublicInbox, y le reté sin mucha expectativa de que me fuera a "reventar" MyPublicInbox. 
Y se acabó el día de San Isidro, que ya había dado de sí lo suyo.
Al día siguiente me levante temprano, tenía viaje a Bilbao para estar en la Universidad de Deusto, y mucho trabajo por hacer, así que me centré en lo mío y me olvidé del día anterior. Cuando eran las 19:00 horas y acababa mi charla, miré el WhatsApp y vi un mensaje de Mago More descojonándose.
Isra Bravo había reventado "MyPublicInbox".
Había escrito un mensaje en su lista de correo, y había recibido más de 100 propuestas en un sólo día, lo que es por mucho el mayor número de mensajes que ha recibido una persona en un solo día, que ostentaba yo con poco más de una decena.
Y ahora nos va a tocar modificar MyPublicInbox, y poner cuotas de máximos de mensajes por día que puede recibir una persona, o, por el contrario, subir mucho el valor de los mensajes a Isra Bravo para reducir la cantidad, porque ha reventado el "filtro" en base a 500 Tempos con el que pusimos el reto.
Lo cierto es que me declaro fan de Isra Bravo. De lo que hace. De cómo lo hace. De cómo lo ha hecho. De cómo es. Y espero aprender mucho de él. Por supuesto, ya me he suscrito a su newsletter y me he comprado sus libros:

• El libro StoryTelling Salvaje
• El libro del Copywriting
• Escribo porque me gusta ganar dinero

Así que desde ya, estoy aprendiendo cosas nuevas. Que soy muy joven como para no querer aprender o cambiar.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)  


Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com

By Dominik Klemba and Dominik Czarnota This post will guide you through using AddressSanitizer (ASan), a compiler plugin that helps developers detect memory issues in code that can lead to remote code execution attacks (such as WannaCry or this WebP implementation bug). ASan inserts checks around memory accesses during compile time, and crashes the program upon detecting improper memory access. It is widely used during fuzzing due to its ability to detect bugs missed by unit testing and its better performance compared to other similar tools. ASan was designed for C and C++, but it can also be used with Objective-C, Rust, Go, and Swift. This post will focus on C++ and demonstrate how to use ASan, explain its error outputs, explore implementation fundamentals, and discuss ASan’s limitations and common mistakes, which will help you grasp previously undetected bugs. Finally, we share a concrete example of a real bug we encountered during an audit that was missed by ASan and can be detected with our changes. This case motivated us to research ASan bug detection capabilities and contribute dozens of upstreamed commits to the LLVM project. These commits resulted in the following changes:

• Extended container sanitization ASan API in LLVM16 by adding support for unaligned memory buffers and adding a function for double-ended contiguous containers. Thanks to that, since LLVM17, std::vector annotations work with all allocators by default.
• Added std::deque annotations in LLVM17. For details, check the libc++ 17 release notes.
• Added annotations for the long string case of std::string in LLVM18 (with all allocators by default). Check the libc++18 release notes for more details.
• We have recently upstreamed short string annotations (read about “short string optimization”), and there is a high probability that they will be included in libc++19, assuming no new concerns or issues arise. Keep an eye on the libc++19 release notes.

Getting started with ASan ASan can be enabled in LLVM’s Clang and GNU GCC compilers by using the -fsanitize=address compiler and linker flag. The Microsoft Visual C++ (MSVC) compiler supports it via the /fsanitize=address option. Under the hood, the program’s memory accesses will be instrumented with ASan checks and the program will be linked with ASan runtime libraries. As a result, when a memory error is detected, the program will stop and provide information that may help in diagnosing the cause of memory corruption. AddressSanitizer’s approach differs from other tools like Valgrind, which may be used without rebuilding a program from its source, but has bigger performance overhead (20x vs 2x) and may detect fewer bugs. Simple example: detecting out-of-bounds memory access Let’s see ASan in practice on a simple buggy C++ program that reads data from an array out of its bounds. Figure 1 shows the code of such a program, and figure 2 shows its compilation, linking, and output when running it, including the error detected by ASan. Note that the program was compiled with debugging symbols and no optimizations (-g3 and -O0 flags) to make the ASan output more readable. Figure 1: Example program that has an out-of-bounds bug on the stack since it reads the fifth item from the buf array while it has only 4 elements (example.cpp) Figure 2: Running the program from figure 1 with ASan When ASan detects a bug, it prints out a best guess of the error type that has occurred, a backtrace where it happened in the code, and other location information (e.g., where the related memory was allocated or freed). Figure 3: Part of an ASan error message with location in code where related memory was allocated In this example, ASan detected a heap-buffer overflow (an out-of-bounds read) in the sixth line of the example.cpp file. The problem was that we read the memory of the buf variable out of bounds through the buf[i] code when the loop counter variable (i) had a value of 4. It is also worth noting that ASan can detect many different types of errors like stack-buffer-overflows, heap-use-after-free, double-free, alloc-dealloc-mismatch, container-overflow, and others. Figures 4 and 5 present another example, where the ASan detects a heap-use-after-free bug and shows the exact location where the related heap memory was allocated and freed. Figure 4: Example program that uses a buffer that was freed (built with -fsanitize=address -O0 -g3) Figure 5: Excerpt of ASan report from running the program from figure 4 For more ASan examples, refer to the LLVM tests code or Microsoft’s documentation. Building blocks of ASan ASan is built upon two key concepts: shadow memory and redzones. Shadow memory is a dedicated memory region that stores metadata about the application’s memory. Redzones are special memory regions placed in between objects in memory (e.g., variables on the stack or heap allocations) so that ASan can detect attempts to access memory outside of the intended boundaries. Shadow memory Shadow memory is allocated at a high address of the program, and ASan modifies its data throughout the lifetime of the process. Each byte in shadow memory describes the accessibility status of a corresponding memory chunk that can potentially be accessed by the process. Those memory chunks, typically referred to as “granules,” are commonly 8 bytes in size and are aligned to their size (the granule size is set in GCC/LLVM code). Figure 6 shows the mapping between granules and process memory. Figure 6: Logical division of process memory and corresponding shadow memory bytes The shadow memory values detail whether a given granule can be fully or partially addressable (accessible by the process), or whether the memory should not be touched by the process. In the latter case, we call this memory “poisoned,” and the corresponding shadow memory byte value details the reason why ASan thinks so. The shadow memory values legend is printed by ASan along with its reports. Figure 7 shows this legend. Figure 7: Shadow memory legend (the values are displayed in hexadecimal format) By updating the state of shadow memory during the process execution, ASan can verify the validity of memory accesses by checking the granule’s value (and so its accessibility status). If a memory granule is fully accessible, a corresponding shadow byte is set to zero. Conversely, if the whole granule is poisoned, the value is negative. If the granule is partially addressable—i.e., only the first N bytes may be accessed and the rest shouldn’t—then the number N of addressable bytes is stored in the shadow memory. For example, freed memory on the heap is described with value fd and shouldn’t be used by the process until it’s allocated again. This allows for detecting use-after-free bugs, which often lead to serious security vulnerabilities. Partially addressable granules are very common. One example may be a buffer on a heap of a size that is not 8-byte-aligned; another may be a variable on the stack that has a size smaller than 8 bytes. Redzones Redzones are memory regions inserted into the process memory (and so reflected in shadow memory) that act as buffer zones, separating different objects in memory with poisoned memory. As a result, compiling a program with ASan changes its memory layout. Let’s look at the shadow memory for the program shown in figure 8, where we introduced three variables on the stack: “buf,” an array of six items each of 2 bytes, and “a” and “b” variables of 2 and 1 bytes. Figure 8: Example program with an out of bounds memory access error detected by ASan (built with -fsanitize=address -O0 -g3) Running the program with ASan, as in figure 9, shows us that the problematic memory access hit the “stack right redzone” as marked by the “[f3]” shadow memory byte. Note that ASan marked this byte with the arrow before the address and the brackets around the value. Figure 9: Shadow bytes describing memory area around stack variables from figure 6. Note that the byte 01 corresponds to the variable “b,” the 02 to variable “a,” and 00 04 to the buf array. This shadow memory along with the corresponding process memory is shown in figure 10. ASan would detect accesses to the bytes colored in red and report them as errors. Figure 10: Memory layout with ASan. Each cell represents one byte. Without ASan, the “a,” “b,” and “buf” variables would likely be next to each other, without any padding between them. The padding was added by the fact that the variables must be partially addressable and because redzones were added in between them as well as before and after them. Redzones are not added between elements in arrays or in between member variables in structures. This is due to the fact that it would simply break many applications that depend upon the structure layout, their sizes, or simply on the fact that arrays are contiguous in memory. Sadly, ASan also doesn’t poison the structure padding bytes, since they may be accessed by valid programs when a whole structure is copied (e.g., with the memcpy function). How does ASan instrumentation work? ASan instrumentation is fully dependent on the compiler; however, implementations are very similar between compilers. Its shadow memory has the same layout and uses the same values in LLVM and GCC, as the latter is based on the former. The instrumented code also calls to special functions defined in compiler-rt, a low-level runtime library from LLVM. It is worth noting that there are also shared or static versions of the ASan libraries, though this may vary based on a compiler or environment. The ASan instrumentation adds checks to the program code to validate legality of the program’s memory accesses. Those checks are performed by comparing the address and size of the access against the shadow memory. The shadow memory mapping and encoding of values (the fact that granules are of 8 bytes in size) allow ASan to efficiently detect memory access errors and provide valuable insight into the problems encountered. Let’s look at a simple C++ example compiled and tested on x86-64, where the touch function accesses 8 bytes at the address given in the argument (the touch function takes a pointer to a pointer and dereferences it): Figure 11: A function accessing memory area of size 8 bytes Without ASan, the function has a very simple assembly code: Figure 12: The function from figure 11 compiled without ASan Figure 13 shows that, when compiling code from figure 11 with ASan, a check is added that confirms if the access is correct (i.e., if the whole granule is accessed). We can see that the address that we are going to access is first divided by 8 (shr rax, 3 instruction) to compute its offset in the shadow memory. Then, the program checks if the shadow memory byte is zero; if it’s not, it calls to the __asan_report_load8 function, which makes ASan to report the memory access violation. The byte is checked against zero, because zero means that 8 bytes are accessible, whereas the memory dereference that the program performs returns another pointer, which is of course of 8 bytes in size. Figure 13: The function from Figure 11 compiled with ASan using Clang 15 For comparison, we can see that the gcc compiler generates similar code (figure 14) as by LLVM (figure 13): Figure 14: The function from Figure 11 compiled with ASan using gcc 12 Of course, if the program accessed a smaller region, a different check would have to be generated by the compiler. This is shown in figures 15 and 16, where the program accesses just a single byte. Figure 15: A function accessing memory area smaller than a granule Now the function accesses a single byte that may be at the beginning, middle, or the end of a granule, and every granule may be fully addressable, partially addressable, or fully poisoned. The shadow memory byte is first checked against zero, and if it doesn’t match, a detailed check is performed (starting from the .LBB0_1 label). This check will raise an error if the granule is partially addressable and a poisoned byte is accessed (from a poisoned suffix) or if the granule is fully poisoned. (GCC generates similar code.) Figure 16: An example of a more complex check, confirming legality of the access in function from figure 15, compiled with Clang 15 Can you spot the problem above? You may have noticed in figures 12-14 that access to poisoned memory may not be detected if the address we read 8 bytes from is unaligned. For such an unaligned memory access, its first and last bytes are in different granules. The following snippet illustrates a scenario when the address of variable ptr is increased by three and the touch function touches an unaligned address. Figure 17: Code accessing unaligned memory of size 8 may not be detected by ASan in Clang 15 The incorrect access from figure 17 is not detected when it is compiled with Clang 15, but it is detected by GCC 12 as long as the function is inlined. If we force non-inlining with __attribute__ ((noinline)), GCC won’t detect it either. It seems that when GCC is aware of address manipulations that may result in unaligned addressing, it generates a more robust check that detects the invalid access correctly. ASan’s limitations and quirks While ASan may miss some bugs, it is important to note that it does not report any false positives if used properly. This means that if it detects a bug, it must be a valid bug in the code, or, a part of the code was not linked with ASan properly (assuming that ASan itself doesn’t have bugs). However, the ASan implementation in GCC and LLVM include the following limitations or/and quirks:

• Redzones are not added between variables in structures.
• Redzones are not added between array elements.
• Padding in structures is not poisoned (example).
• Access to allocated, but not yet used, memory in a container won’t be detected, unless the container annotates itself like C++’s std::vector, std::deque, or std::string (in some cases). Note that std::basic_string (with external buffers) and std::deque are annotated in libc++ (thanks to our patches) while std::string is also annotated in Microsoft C++ standard library.
• Incorrect access to memory managed by a custom allocator won’t raise an error unless the allocator performs annotations.
• Only suffixes of a memory granule may be poisoned; therefore, access before an unaligned object may not be detected.
• ASan may not detect memory errors if a random address is accessed. As long as the random number generator returns an addressable address, access won’t be considered incorrect
• ASan doesn’t understand context and only checks values in shadow memory. If a random address being accessed is annotated as some error in shadow memory, ASan will correctly report that error, even if its bug title may not make much sense.
• Because ASan does not understand what programs are intended to do, accessing an array with an incorrect index may not be detected if the resulting address is still addressable, as shown in figure 18.

Figure 18: Access to memory that is addressable but out of bounds of the array. There is no error detected. ASan is not meant for production use ASan is designed as a debugging tool for use in development and testing environments and it should not be used on production. Apart from its overhead, ASan shouldn’t be used for hardening as its use could compromise the security of a program. For example, it decreases the effectiveness of ASLR security mitigation by its gigantic shadow memory allocation and it also changes the behavior of the program based on environment variables which could be problematic, e.g., for suid binaries. If you have any other doubts, you should check the ASan FAQ and for hardening your application, refer to compiler security flags. Poisoning-only suffixes Because ASan currently has a very limited number of values in shadow memory, it can only poison suffixes of memory granules. In other words, there is no such value encoding in shadow memory to inform ASan that for a granule a given byte is accessible if it follows an inaccessible (poisoned) byte. As an example, if the third byte in a granule is not poisoned, the previous two bytes are not poisoned as well, even if logic would require them to be poisoned. It also means that up to seven bytes may not be poisoned, assuming that an object/variable/buffer starts in the middle or at the last byte of a granule. False positives due to linking False positives can occur when only part of a program is built with ASan. These false positives are often (if not always) related to container annotations. For example, linking a library that is both missing instrumentation and modifying annotated objects may result in false positives. Consider a scenario where the push_back member function of a vector is called. If an object is added at the end of the container in a part of the program that does not have ASan instrumentation, no error will be reported, and the memory where the object is stored will not be unpoisoned. As a result, accessing this memory in the instrumented part of the program will trigger a false positive error. Similarly, access to poisoned memory in a part of the program that was built without ASan won’t be detected. To address this situation, the whole application along with all its dependencies should be built with ASan (or at least all parts modifying annotated containers). If this is not possible, you can turn off container annotations by setting the environment variable ASAN_OPTIONS=detect_container_overflow=0. Do it yourself: user annotations User annotations may be used to detect incorrect memory accesses—for example, when preallocating a big chunk of memory and managing it with a custom allocator or in a custom container. In other words, user annotations can be used to implement similar checks to those std::vector does under the hood in order to detect out-of-bounds access in between the vector’s data+size and data+capacity addresses. If you want to make your testing even stronger, you can choose to intentionally “poison” certain memory areas yourself. For this, there are two macros you may find useful:

• ASAN_POISON_MEMORY_REGION(addr, size)
• ASAN_UNPOISON_MEMORY_REGION(addr, size)

To use these macros, you need to include the ASan interface header: Figure 19: The ASan API must be included in the program This makes poisoning and unpoisoning memory quite simple. The following is an example of how to do this: Figure 20: A program demonstrating user poisoning and its detection. The program allocates a buffer on heap, poisons the whole buffer (through user poisoning), and then accesses an element from the buffer. This access is detected as forbidden, and the program reports a “Poisoned by user” error (f7). The figure below shows the buffer (poisoned by user) as well as the heap redzone (fa). Figure 21: A part of the error message generated by program from figure 20 while compiled with ASan However, if you unpoison part of the buffer (as shown below, for four elements), no error would be raised while accessing the first four elements. Accessing any further element will raise an error. Figure 22: An example of unpoisoning memory by user If you want to understand better how those macros impact the code, you can look into its definition in an ASan interface file. The ASAN_POISON_MEMORY_REGION and ASAN_UNPOISON_MEMORY_REGION macros simply invoke the __asan_poison_memory_region and __asan_unpoison_memory_region functions from the API. However, when a program is compiled without ASan, these macros do nothing beyond evaluating the macro arguments. The bug missed by ASan As we noted previously in the limitations section, ASan does not automatically detect out-of-bound accesses into containers that preallocate memory and manage it. This was also a case we came across during an audit: we found a bug with manual review in code that we were fuzzing and we were surprised the fuzzer did not find it. It turned out that this was because of lack of container overflow detection in the std::basic_string and std::deque collections in libc++. This motivated us to get involved in ASan development by developing a proof of concept of those ASan container overflow detections in GCC and LLVM and eventually upstream patches to LLVM. So what was the bug that ASan missed? Figure 23 shows a minimal example of it. The buggy code compared two containers via an std::equal function that took only the first1, last1, and first2 iterators, corresponding to the beginning and end of the first sequence and to the beginning of the second sequence for comparison, assuming the same length of the sequences. However, when the second container is shorter than the first one, this can cause an out-of-bounds read, which was not detected by ASan and which we changed. With our patches, this is finally detected by ASan. Figure 23: Code snippet demonstrating the nature of the bug we found during the audit. Container type was changed for demonstrative purposes. Use ASan to detect more memory safety bugs We hope our efforts to improve ASan’s state-of-the-art bug detection capabilities will cement its status as a powerful tool for protecting codebases against memory issues. We’d like to express our sincere gratitude to the entire LLVM community for their support during the development of our ASan annotation improvements. From reviewing code patches and brainstorming implementation ideas to identifying issues and sharing knowledge, their contributions were invaluable. We especially want to thank vitalybuka, ldionne, philnik777, and EricWF for their ongoing support! We hope this explanation of AddressSanitizer has been insightful and demonstrated its value in hunting down bugs within a codebase. We encourage you to leverage this knowledge to proactively identify and eliminate issues in your own projects. If you successfully detect bugs with the help of the information provided here, we’d love to hear about it! Happy hunting! If you need help with ASan annotations, fuzzing, or anything related to LLVM, contact us! We are happy to help tailor sanitizers or other LLVM tools to your specific needs. If you’d like to read more about our work on compilers, check out the following posts: VAST (GitHub repository) and Macroni (GitHub repository).

Cyber resilience is becoming increasingly complex to achieve with the changing nature of computing. Appropriate for this year’s conference theme, organizations are exploring “the art of the possible”, ushering in an era of dynamic computing as they explore new technologies. Simultaneously, as innovation expands and computing becomes more dynamic, more threats become possible – thus, the approach to securing business environments must also evolve. As part of this year’s conference, I led a keynote presentation around the possibilities, risks, and rewards of cyber tech convergence. We explored the risks and rewards of cyber technology convergence and integration across network & security operations. More specifically, we looked into the future of more open, adaptable security architectures, and what this means for security teams. LevelBlue Research Reveals New Trends for Cyber Resilience This year, we also launched the inaugural LevelBlue Futures™ Report: Beyond the Barriers to Cyber Resilience. Led by Theresa Lanowitz, Chief Evangelist of AT&T Cybersecurity / LevelBlue, we hosted an in-depth session based on our research that examined the complexities of dynamic computing. This included an analysis of how dynamic computing merges IT and business operations, taps into data-driven decision-making, and redefines cyber resilience for the modern era. Some of the notable findings she discussed include:

• 85% of respondents say computing innovation is increasing risk, while 74% confirmed that the opportunity of computing innovation outweighs the corresponding increase in cybersecurity risk.
• The adoption of Cybersecurity-as-a-Service (CSaaS) is on the rise, with 32% of organizations opting to outsource their cybersecurity needs rather than managing them in-house.
• 66% of respondents share cybersecurity is an afterthought, while another 64% say cybersecurity is siloed. This isn’t surprising when 61% say there is a lack of understanding of cybersecurity at the board level.

Theresa was also featured live on-site discussing these findings with prominent cyber media in attendance. She emphasized what today’s cyber resilience barriers look like and what new resilience challenges are promised for tomorrow. Be sure to check out some of those interviews below. New Research from LevelBlue Reveals 2024 Cyber Resilience Trends – Theresa Lanowitz – RSA24 #2 LevelBlue & Enterprise Strategy Group: A Look at Cyber Resilience For access to the full LevelBlue Futures™ Report, download a complimentary copy here. * { box-sizing: border-box; } .rowPic { display: flex; flex-wrap: wrap; padding: 0 4px; } /* Create four equal columns that sits next to each other */ .columnPic{ flex: 50%; max-width: 50%; padding: 0 4px; } .columnPic img { margin-top: 8px; vertical-align: middle; } /* Responsive layout - makes a two column-layout instead of four columns */ @media (max-width: 800px) { .columnPic{ flex: 50%; max-width: 50%; } } /* Responsive layout - makes the two columns stack on top of each other instead of next to each other */ @media (max-width: 600px) { .columnPic { flex: 100%; max-width: 100%; } }

Authored by Willem Zeeman and Yun Zheng Hu This blog is part of a series written by various Dutch cyber security firms that have collaborated on the Cactus ransomware group, which exploits Qlik Sense servers for initial access. To view all of them please check the central blog by Dutch special interest group Cyberveilig Nederland [1] The effectiveness of the public-private partnership called Melissa [2] is increasingly evident. The Melissa partnership, which includes Fox-IT, has identified overlap in a specific ransomware tactic. Multiple partners, sharing information from incident response engagements for their clients, found that the Cactus ransomware group uses a particular method for initial access. Following that discovery, NCC Group’s Fox-IT developed a fingerprinting technique to identify which systems around the world are vulnerable to this method of initial access or, even more critically, are already compromised. Qlik Sense vulnerabilities Qlik Sense, a popular data visualisation and business intelligence tool, has recently become a focal point in cybersecurity discussions. This tool, designed to aid businesses in data analysis, has been identified as a key entry point for cyberattacks by the Cactus ransomware group. The Cactus ransomware campaign Since November 2023, the Cactus ransomware group has been actively targeting vulnerable Qlik Sense servers. These attacks are not just about exploiting software vulnerabilities; they also involve a psychological component where Cactus misleads its victims with fabricated stories about the breach. This likely is part of their strategy to obscure their actual method of entry, thus complicating mitigation and response efforts for the affected organizations. For those looking for in-depth coverage of these exploits, the Arctic Wolf blog [3] provides detailed insights into the specific vulnerabilities being exploited, notably CVE-2023-41266, CVE-2023-41265 also known as ZeroQlik, and potentially CVE-2023-48365 also known as DoubleQlik. Threat statistics and collaborative action The scope of this threat is significant. In total, we identified 5205 Qlik Sense servers, 3143 servers seem to be vulnerable to the exploits used by the Cactus group. This is based on the initial scan on 17 April 2024. Closer to home in the Netherlands, we’ve identified 241 vulnerable systems, fortunately most don’t seem to have been compromised. However, 6 Dutch systems weren’t so lucky and have already fallen victim to the Cactus group. It’s crucial to understand that “already compromised” can mean that either the ransomware has been deployed and the initial access artifacts left behind were not removed, or the system remains compromised and is potentially poised for a future ransomware attack. Since 17 April 2024, the DIVD (Dutch Institute for Vulnerability Disclosure) and the governmental bodies NCSC (Nationaal Cyber Security Centrum) and DTC (Digital Trust Center) have teamed up to globally inform (potential) victims of cyberattacks resembling those from the Cactus ransomware group. This collaborative effort has enabled them to reach out to affected organisations worldwide, sharing crucial information to help prevent further damage where possible. Identifying vulnerable Qlik Sense servers Expanding on Praetorian’s thorough vulnerability research on the ZeroQlik and DoubleQlik vulnerabilities [4,5], we found a method to identify the version of a Qlik Sense server by retrieving a file called product-info.json from the server. While we acknowledge the existence of Nuclei templates for the vulnerability checks, using the server version allows for a more reliable evaluation of potential vulnerability status, e.g. whether it’s patched or end of support. This JSON file contains the release label and version numbers by which we can identify the exact version that this Qlik Sense server is running. Figure 1: Qlik Sense product-info.json file containing version information Keep in mind that although Qlik Sense servers are assigned version numbers, the vendor typically refers to advisories and updates by their release label, such as “February 2022 Patch 3”. The following cURL command can be used to retrieve the product-info.json file from a Qlik server: curl -H "Host: localhost" -vk 'https://<ip>/resources/autogenerated/product-info.json?.ttf' Note that we specify ?.ttf at the end of the URL to let the Qlik proxy server think that we are requesting a .ttf file, as font files can be accessed unauthenticated. Also, we set the Host header to localhost or else the server will return 400 - Bad Request - Qlik Sense, with the message The http request header is incorrect. Retrieving this file with the ?.ttf extension trick has been fixed in the patch that addresses CVE-2023-48365 and you will always get a 302 Authenticate at this location response: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 302 Authenticate at this location < Cache-Control: no-cache, no-store, must-revalidate < Location: https://localhost/internal_forms_authentication/?targetId=2aa7575d-3234-4980-956c-2c6929c57b71 < Content-Length: 0 < Nevertheless, this is still a good way to determine the state of a Qlik instance, because if it redirects using 302 Authenticate at this location it is likely that the server is not vulnerable to CVE-2023-48365. An example response from a vulnerable server would return the JSON file: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 200 OK < Set-Cookie: X-Qlik-Session=893de431-1177-46aa-88c7-b95e28c5f103; Path=/; HttpOnly; SameSite=Lax; Secure < Cache-Control: public, max-age=3600 < Transfer-Encoding: chunked < Content-Type: application/json;charset=utf-8 < Expires: Tue, 16 Apr 2024 08:14:56 GMT < Last-Modified: Fri, 04 Nov 2022 23:28:24 GMT < Accept-Ranges: bytes < ETag: 638032013040000000 < Server: Microsoft-HTTPAPI/2.0 < Date: Tue, 16 Apr 2024 07:14:55 GMT < Age: 136 < {"composition":{"contentHash":"89c9087978b3f026fb100267523b5204","senseId":"qliksenseserver:14.54.21","releaseLabel":"February 2022 Patch 12","originalClassName":"Composition","deprecatedProductVersion":"4.0.X","productName":"Qlik Sense","version":"14.54.21","copyrightYearRange":"1993-2022","deploymentType":"QlikSenseServer"}, <snipped> We utilised Censys and Google BigQuery [6] to compile a list of potential Qlik Sense servers accessible on the internet and conducted a version scan against them. Subsequently, we extracted the Qlik release label from the JSON response to assess vulnerability to CVE-2023-48365. Our vulnerability assessment for DoubleQlik / CVE-2023-48365 operated on the following criteria:

1. The release label corresponds to vulnerability statuses outlined in the original ZeroQlik and DoubleQlik vendor advisories [7,8].
2. The release label is designated as End of Support (EOS) by the vendor [9], such as “February 2019 Patch 5”.

We consider a server non-vulnerable if:

1. The release label date is post-November 2023, as the advisory states that “November 2023” is not affected.
2. The server responded with HTTP/1.1 302 Authenticate at this location.

Any other responses were disregarded as invalid Qlik server instances. As of 17 April 2024, and as stated in the introduction of this blog, we have detected 5205 Qlik Servers on the Internet. Among them, 3143 servers are still at risk of DoubleQlik, indicating that 60% of all Qlik Servers online remain vulnerable. Figure 2: Qlik Sense patch status for DoubleQlik CVE-2023-48365 The majority of vulnerable Qlik servers reside in the United States (396), trailed by Italy (280), Brazil (244), the Netherlands (241), and Germany (175). Figure 3: Top 20 countries with servers vulnerable to DoubleQlik CVE-2023-48365 Identifying compromised Qlik Sense servers Based on insights gathered from the Arctic Wolf blog and our own incident response engagements where the Cactus ransomware was observed, it’s evident that the Cactus ransomware group continues to redirect the output of executed commands to a True Type font file named qle.ttf, likely abbreviated for “qlik exploit”. Below are a few examples of executed commands and their output redirection by the Cactus ransomware group: whoami /all > ../Client/qmc/fonts/qle.ttf quser > ../Client/qmc/fonts/qle.ttf In addition to the qle.ttf file, we have also observed instances where qle.woff was used: Figure 4: Directory listing with exploitation artefacts left by Cactus ransomware group It’s important to note that these font files are not part of a default Qlik Sense server installation. We discovered that files with a font file extension such as .ttf and .woff can be accessed without any authentication, regardless of whether the server is patched. This likely explains why the Cactus ransomware group opted to store command output in font files within the fonts directory, which in turn, also serves as a useful indicator of compromise. Our scan for both font files, found a total of 122 servers with the indicator of compromise. The United States ranked highest in exploited servers with 49 online instances carrying the indicator of compromise, followed by Spain (13), Italy (11), the United Kingdom (8), Germany (7), and then Ireland and the Netherlands (6). Figure 5: Top 20 countries with known compromised Qlik Sense servers Out of the 122 compromised servers, 46 were not vulnerable anymore. When the indicator of compromise artefact is present on a remote Qlik Sense server, it can imply various scenarios. Firstly, it may suggest that remote code execution was carried out on the server, followed by subsequent patching to address the vulnerability (if the server is not vulnerable anymore). Alternatively, its presence could signify a leftover artefact from a previous security incident or unauthorised access. While the root cause for the presence of these files is hard to determine from the outside it still is a reliable indicator of compromise. Responsible disclosure by the DIVD
We shared our fingerprints and scan data with the Dutch Institute of Vulnerability Disclosure (DIVD), who then proceeded to issue responsible disclosure notifications to the administrators of the Qlik Sense servers. Call to action Ensure the security of your Qlik Sense installations by checking your current version. If your software is still supported, apply the latest patches immediately. For systems that are at the end of support, consider upgrading or replacing them to maintain robust security. Additionally, to enhance your defences, it’s recommended to avoid exposing these services to the entire internet. Implement IP whitelisting if public access is necessary, or better yet, make them accessible only through secure remote working solutions. If you discover you’ve been running a vulnerable version, it’s crucial to contact your (external) security experts for a thorough check-up to confirm that no breaches have occurred. Taking these steps will help safeguard your data and infrastructure from potential threats. References

1. https://cyberveilignederland.nl/actueel/persbericht-samenwerkingsverband-melissa-vindt-diverse-nederlandse-slachtoffers-van-ransomwaregroepering-cactus ︎
2. https://www.ncsc.nl/actueel/nieuws/2023/oktober/3/melissa-samenwerkingsverband-ransomwarebestrijding ︎
3. https://arcticwolf.com/resources/blog/qlik-sense-exploited-in-cactus-ransomware-campaign/ ︎
4. https://www.praetorian.com/blog/qlik-sense-technical-exploit/ ︎
5. https://www.praetorian.com/blog/doubleqlik-bypassing-the-original-fix-for-cve-2023-41265/ ︎
6. https://support.censys.io/hc/en-us/articles/360038759991-Google-BigQuery-Introduction ︎
7. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2110801 ︎
8. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2120325 ︎
9. https://community.qlik.com/t5/Product-Lifecycle/Qlik-Sense-Enterprise-on-Windows-Product-Lifecycle/ta-p/1826335 ︎

Additive manufacturing (AM) engineers have been incredibly creative in developing ancillary systems that modify a printed parts mechanical properties.  These systems mostly focus on the issue of anisotropic properties of additively built components.  This blog post is a good reference if you are unfamiliar with isotropic vs anisotropic properties and how they impact 3d printing.  […] The post Cybersecurity Concerns for Ancillary Strength Control Subsystems appeared first on BreakPoint Labs - Blog.

To consolidate all of our security intelligence and news in one location, we have migrated Naked Security to the Sophos News platform.