TLS 1.3 standard was finally published in August 2018. The authors tried to address the problems which unfortunately exist in older versions of the TLS protocol. One of the problems is a lack of protection against downgrade attacks.Continue reading
Code coverage analysis is used in software testing to discover untested pieces of an application. Gathering code coverage data may also be useful for fuzzing. Basically it may help to figure out which parts of a program were not reached during fuzzing. This info can then be used to improve the fuzzer.
Let’s try to gather some code coverage data during fuzzing. As an example, we’re going to test picotls with tlsbunny. Picotls is an implementation of TLS 1.3 protocol written in C, and tlsbunny is a framework for building negative tests and fuzzers for TLS 1.3 implementations. We’re going to use gcov for gathering code coverage data, and lcov for creating a report.
OWASP Dependency Check is a well known open-source tool which can track dependencies in your project and identify components with known published vulnerabilities. The tool supports multiple languages and platforms such as Java, .NET, Ruby and Python. One of the simplest ways how you can use Dependency Check in your project is just to run it manually. This way has at least one disadvantage: you have to make sure that you run the tool regularly. Fortunately there is a couple of ways how you can automate this process.
But unfortunately sometimes it’s not enough just to automate something. If the tool reports a vulnerability it means someone has to fix it. At least it would be good to evaluate the problem. In a perfect world, all issues are addressed immediately, but in the real world, development teams always have no time for that. Besides integrating Dependency Check to CI/CD, there may be a couple of other steps to get vulnerable dependencies updated.
Here is a brief overview which describes how TLS can be used for establishing a secure TLS connection. First, we briefly discuss what SSL/TLS protocols are. Next, we’ll talk about secure TLS protocol versions and parameters. Finally, we’ll describe how TLS can be parametrized securely.
For those who are interested in machine learning and/or security, here is a research which discusses extracting secrets from machine learning systems:
The authors say deep learning models can memorize secrets which the training data may contain. Then the authors provide a couple of algorithms which were successfully used for extracting sensitive data from black box machine learning systems. The authors also show that unintended memorization is not the result of overfitting. Finally, they discuss several ways to mitigate the problem.
According to Mr. Schneier, there is a lot more research to be done here. So good luck :)
DNS rebinding attacks have been known for quite a long time. For example, Stanford Web Security Research Team posted a whitepaper about DNS rebinding attacks in 2007. But even if it’s a well-known type of attacks, nowadays you still can find software systems which are vulnerable to DNS rebinding attacks. For example, Google Project Zero recently discovered such problems in Blizzard Update Agent and BitTorent Transmission Daemon.
OpenJDK and AddressSanitizer are well-known open source projects. OpenJDK sources contain C/C++ code which may be affected by memory corruption issues and memory leaks. Such issues may be detected at runtime with memory checkers like AddressSanitizer. Now it’s going to be easier to use AddressSanitizer for OpenJDK development to check for memory corruptions and leaks.
There are a couple of new bug bounty programs on HackeOne for popular open source libraries:
They just started on last week (Sep 22nd, 2017). You can find the rules, scope and other details on HackerOne
Those are well-known tools and libraries, and they have already gotten quite much attention from the security community. So, looks like it’s going to be challenging to discover new issues there. Looking for a challenge? This may be a good one for sure. By the way, minimum bounty is $500. Not too much, but you also are going to get some credit for making the world better.
The libraries are mostly written in C/C++, so you may want to start with fuzzing. Although, if you search for fuzzing results for the libs above, you are going to find that security researches put some effort on it. On the other hand, it’s never worse to try even harder. Someone can also contribute to Google’s OOS-fuzz project, and add support for fuzzing those libraries. OSS-fuzz already has libpng and curl, but seems like there may be some room for libcap, ImageMagick, GraphicsMagick and tcpdump.
Everybody knows about SQL injections. It’s like a celebrity in the world of software security. But there are much more many different types of injection attacks which may feel jealous about popularity of SQL injections. That’s not fair. Let’s try to feel the gap, and talk about LDAP injections.
There are a lot of articles, posts, and even books which describe a stack buffer overflow. There are a little less stuff about heap buffer overflows. But there is one more thing which you can overflow – buffers in global memory. Although all of those types of issues are very similar, let me try to fill this little gap with global buffer overflows.