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