Mission Fuzzable?
Fuzzing is not a new testing technique. Although it wasn’t called Fuzzing at the time, Gerry Weinberg talks about his experiences with this test technique whilst working at IBM, and on the Mercury rocket project in the 1950s.
We didn’t call it fuzzing back in the 1950s, but it was our standard practice to test programs by inputting decks of punch cards taken from the trash. We also used decks of random number punch cards. We weren’t networked in those days, so we weren’t much worried about security, but our random/trash decks often turned up undesirable behavior. Every programmer I knew (and there weren’t many of us back then, so I knew a great proportion of them) used the trash-deck technique.
http://secretsofconsulting.blogspot.com/2017/02/fuzz-testing-and-fuzz-history.html
Imagine these days rooting around in your rubbish bins for random data to inject into your systems and software. No? I didn’t think so. Well, thankfully we really don’t need to. There are a huge amount of tools to assist us with this task. But let me go back to first principles regarding fuzzing.
Fuzzing is a great way of discovering potential flaws and vulnerabilities in your systems and applications, be they web based, in the cloud, mobile or some other kind of architecture. For discovering how your systems handle unusual or extreme data input, Fuzzing is undeniably an extremely useful technique for exploratory testing approaches. As a result, it is also an essential tool for security testing, because many of the flaws that Fuzzing (or fuzz testing, as it is sometimes referred to) can surface a variety of security flaws.
As ‘exploratory testers’ it is a very useful and powerful technique to have in your toolbelt. You can rapidly use it to identify and explore a wide range of software behaviours and error conditions. You can create charters that focus on a specific form, field, parameter or endpoint, or build a strategy around fuzzing across an entire application.
Fuzzing not included!
Fuzzing, like a lot of security testing techniques, can cause potential problems for your systems and software. Here is a summary of considerations you might need to make sure you are prepared, safe and legal.
Do you have permission to run fuzz testing on your system under test?
It’s sensible to check in with your managers, operations engineers or security engineers (if you have them) to discuss the potential risks and challenges.
This might be part of a threat modelling exercises, where you have considered the kinds of testing you might want to perform.
Are there any architectural or environmental conditions you need to consider?
Some cloud hosting systems, such as Azure, AWS and others will allow you to run fuzz tools on their infrastructure. Check with your Operations engineers to explore options.
You might prefer to run this kind of testing within an isolated environment such as a locally hosted instance, virtual machine, or container such as Kubernetes or Docker.
Consider the timing of your tests
When planning your fuzz testing, consider the timing. Would it be prudent to run the tests at a time that won’t disrupt your colleagues, stakeholders and customers. Again, this could be something you plan after you’ve done some threat modelling, and started to plan your test approach.
Context is key
Remember, that any testing you perform is entirely contextual. Your business and technical priorities will derive a whole host of varying risks, so it is important to appropriately plan any fuzzing that you might do. If your context is regarding a microservice architecture, web user interface, or mobile application, your approach to fuzzing will have to adapt to that context.
Fuzz me a river
Today, many of the products that we build and work with are based around services. Theses services will often interface with other components within our platforms, but also with third party services. Data is the oil that flows between these services, it is the life blood of these services. So, being able to secure your services and the data that is at transit within them seems to be as important as securing your systems and data at rest.
Fuzzing can help you do that, by allowing you to target specific endpoints with suspect and malicious data. You are also able to target specific data items or nodes within your services, across a number of different service types, whether its old fashioned SOAP services (which would inherently be more insecure anyway), more recent REST architectures or the latest in terms of GraphQL and other modern architectures.
Tools such as OWASP ZAP, BurpSuite and Artillery all have mechanisms and libraries to assist in the fuzzing of API. Take a look and investigate which ones will suit you in your context. It might be that none of them do, so it’s a case of looking elsewhere or building your own frameworks.
The Fuzzing Club
Fuzzing can happen at any part of a software and system architecture, such as file formats and inputs, network interfaces, browsers and devices. However, Code Fuzzers can be used to explore the quality and security of the code itself. They can do this by injecting malicious parameters and creating crash conditions in your code whilst it is being built, part of your CI/CD and prior to other formalised testing processes. Talk to your development colleagues about the fuzzing that they do (if any). If they don’t, perhaps look to pair with them on introducing some fuzzing to potentially vulnerable areas of code.
This blog posts from F-Secure is a great starting point in exploring this aspect of Fuzzing –
https://www.f-secure.com/us-en/consulting/our-thinking/15-minute-guide-to-fuzzing
https://blog.f-secure.com/super-awesome-fuzzing-part-one/
Fuzzing in the Sky with Diamonds
Fuzzing on Cloud architectures is essentially fuzzing on someone else’s remotely hosted machine. If you are working within a cloud architecture, then please use the appropriate level of caution, as you would with security testing on any architecture.
AWS has built in fuzz testing as part of it’s Device Farm feature set, but they are for Android and iOS platforms running in AWS.
Microsoft’s Azure also has a number of fuzzing tools, such as RAFT or it’s code fuzzing platform OneFuzz, which is new and in development. As with all tools and other features, choose the one that is right for your context.
The Fuzzshank Redemption
It’s clear that Fuzzing is a dead useful technique, which is as versatile as you could hope for. Like any tool, it should be used appropriately and with caution, based on your context. I encourage you to explore and learn about fuzzing further. It can and will add huge value to your repertoire of testing skills. It can lead to some exciting learning, and open doors to new avenues of exploratory testing that you might not have considered before. It’s just a question of knowing when and where a technique like fuzzing can be useful. And it can certainly help you find your way through the vulnerabilities of any system you might be a part of.
The Test Doctor 
One thought on “Exploring Security – Concerning Fuzzing”
Comments are closed.