In theory, there is the evolution from bug over to weakness, vulnerability and finally the exploit. Errors in code and application behaviour are interesting for any serious developer. Security researchers also look for bugs and ways to make code do something it wasn’t designed for. In the absence of critical failures in applications, the process of reporting bugs and getting them fixed everything is smooth and less prone to heated discussions (YMMV, some software projects feature persons with very strong opinions). All of this changes when the code can be remotely exploited. Enter the recent CVEs regarding the Microsoft® Exchange server. CVE-2021-26855 is as bad as it sounds. It is a remote code execution with low complexity requiring no user interaction and no privileges. Disclosure of bugs impacting security has a long history. Knowing
The Twitterverse, various blogs, and some news portals published discussions about a bug in libgcrypt. The code contained a loop which could read past the end of a buffer. The error condition was found by using a test suite. Given the C code base of libgcrypt cases like this can often be found by using the static code analysing features of modern compilers. If you read the ticket concerning the particular overrun bug, then you will notice that it contains more than just the error description. The reason for emotional discussion around bugs are the many ways to find them. Modern compilers contain a lot of helpful tools to audit your code. Even if the compiler lacks auditing/testing features, you can resort to other tools such as Valgrind (which turned 20 years of age
Most programming languages and frameworks have support for serialization of data. It’s quite handy for storing things to disk (or other media) and transporting them around a network for example. The process can be reversed, aptly called deserialization, in order to obtain the original pieces of data. Great. Even though this process sounds simple, there is a lot that can go wrong. First of all data can be manipulated. Subtle modifications can cause havoc when the data is touched. There is a lesser known class of bugs around deserialization and serialization techniques. Matthias Kaiser has some insights to share. Java deserialization vulnerabilities are a bug class of its own. Although several security researchers have published details in the last ten years, still the bug class is fairly unknown. Early 2015 Chris Frohoff and Gabriel
Have you ever looked closely at the tools you use on a daily basis? Taking things apart and putting them back together is an integral part of understanding the universe. Scientists do it all of the time (well, at least some do, there are things that can’t be put together easily once taken apart). So lets focus on components and how they interact. ASN.1 and libraries that deal with it are popular components. Few people get a kick out of ASN.1, so they use code that does it. It’s just an example for parts that handle data being sent to and received from other systems. We live in a networked world, so communication is a crucial part of modern software. So to use business lingo: Most software works by delegating tasks to third-party code.
Our friends from BSidesLondon have set up a challenge for you. It’s a little ELF binary with some odd properties. That’s all we will tell you. Have a look for yourself. In case you are forensically inclined, we might have a little Call for Papers email for you. There is a lot of strange code around in the Internet and other networks. Decoding what code does without getting your san(d)box blown apart is a fine art. We are interested in getting in touch with researchers in the field of malicious software and digital forensics. Software developers need to know what you have seen. So if you got some ideas, research, or interesting content, drop us your email address.
Reverse engineering is a fundamental tool of information security research. The news coverage of the past year have given black boxes a bad name. David Guillen Fandos introduces methods for binary reverse-engineering in his presentation at DeepSec 2013. Binary instrumentation is used for performance evaluation, CPU emulation, tracing, and profiling. It can also be used for malware and threat analysis. David’s tool called spin is able to characterize and identify security-critical functions by applying conditions. If you are into reverse engineering or simply are curious, take a look at the video from his talk:
You have probably read one of the many reviews of security tools published in the depths of the Internet. A lot of magazines feature articles with the headline „Top n Tools for $TASK“. While reviews are a nice way of being introduced to new things, especially tools and software, you have to be careful when it comes to reviewing the security aspects of code or your new favourite tool. First of all you cannot analyse the security design and possible flaws by reading the FAQ section of the project web site or the user manual. You have to evaluate the code and the components it uses. Don’t be fooled or distracted by encryption for it doesn’t necessarily secure anything. Getting a security design right is very hard, and sprinkling cryptography over serious design flaws
Prior to every DeepSec conference we offer two-day trainings, and we regularly advertise trainings on secure software development. Attending security-centric workshops is really not meant as a humiliation. Modern (and not so modern) software development deals with a lot of code and dependencies. Even if your code is clean and well-written there’s a chance that something you rely on isn’t. This happens a lot with library functions (think DLLs) and thus can happen in high level programming languages, too. A training focussing on security will sharpen your „spider sense“ and you will be able to detect sections of code that can go wrong more easily. This is also true for reading documentation. Take a look at CVE-2012-2122. In essence you can get access to some MySQL database servers by repeatedly trying to access an