Report Writing 101: Scope
How to keep your boss happy
Hello all. Some double-post action for you all this weekend to catch up with. Today’s subject is always a classic. Everybody needs to know how to write a report. Here is some BowTiedCrawfish wisdom for you all:
Everybody is either ADHD, OCD, or SOB. Assume your boss is all three.
There’s something about higher-ups and their adamancy for well-done paperwork. They like staring at data, too, I’ve learned.
I’m assuming I’m not alone in this, but after an assessment concludes, I spend up to 2 days writing the report. I constantly ask my coworkers and boss to proofread what I’ve got written down towards the end, too. You don’t want to be chewed out for having a poorly written report.
Report writing sucks, too. You want to do the cool stuff like creating exploits and writing tools and reversing malware. Don’t let that “ugh” effect make your report writing lackluster.
Lastly, report writing isn’t just for people like me who stare at IDA all day. You don’t even have to be a cybersecurity nerd to get something out of this post (and following posts in the series). I won’t drill grammar into your head in these posts, but I will discuss the mindset behind a certain part of a report, i.e. “what am I looking for here”.
What’s in a Report
My job is a mix between red-teaming and blue-teaming, and most of my reports have to do with the red-teaming side. When I go through and assess a product’s integrity, I write a report to notify both the team responsible for the product (I will call them the “blue team”) and my own team of my findings.
Obviously, the blue team wants to know what the heck is wrong, if anything, with their product. My team wants to know what was found in case of anything arising in the future. Say, for example, I find some functions that aren’t encrypted and which can be modified for malicious use. I would put that into my report. Should there be a problem in the future with the product concerning those functions that weren’t encrypted, my team and I are not responsible for the problem as it was listed in the report for the blue team to fix. It is not our responsibility for the blue team to fix their product. However, it is our responsibility to find these exploits first, before any bad actors do.
This gives a report a sort of “archival” effect, which can add context to any future issues. Perhaps the issue that arose isn’t specifically those unencrypted functions, but it may be an issue related to function encryption. Context is key!
This is going to be a multi-part series pertaining to certain parts of a report. I will also try to keep this in sequential order. Of course, your first step is to establish…
The Scope
You’ve certainly heard this word before in the context of reports and assessments and all of that other jazz. “The Scope” is the context of the report. We’re going to bring back Freaky Foresters Inc. for an assessment to be done on one of their products (which I have made up on the spot).
Hi red team. Freaky Foresters have produced a new product to their app suite called Luminux, which is a subscription-based service that allows users to automatically assign a lux (brightness) to every outlet-attached light bulb in their house.
Summary: Luminux is a set of WiFi devices that fit between an outlet and a wall plug which can be accessed wirelessly through our Luminux app and Windows client. Adding each device is as simple as pressing a button which attaches itself to the WiFi of the house. Subscription to the model is $10/mo with a maximum of 32 devices accessible at a time. Users label each device when it is added through the app and can access it from anywhere to turn lights on/off or darken/brighten them.
Hardware: 8x WiFi gadgets per package. Maximum of 32 useable within a network.
Software: iOS and Android App. Windows client application.
Sounds like a scam but I couldn’t think of anything else.
If you are “pen-testing” this product, what would you try and break? We have a hardware team, so skip that. I’m too much of a noob to do mobile penetration tests yet, so for now the only solution in scope for me is the Windows client application.
In Scope
Think like a hacker. Where are points of interest? Where will data go from at-rest to transmission? Think both analytically and discretely. Think as broad as the network and as narrow as application integrity.
This is what I would list as “in-scope”:
Client-side resilience
Injection protection
Anti-tamper
Anti-debug
Anti-reverse
Code obfuscation (if appl)
Memory obfuscation (if appl)
Code integrity
Server-side resilience
Value constraints
Rate limiting
Network integrity
External access
Device limit
Product integrity
Client authentication
Storage of secrets
Value constraints
There is probably more, but that is what I can think of off of the top of my head. I’ll explain them more in depth.
Client-side resilience
This tests how resilient the client application is against tamper and abuse. This will test how well a program can handle tools like injectors, debuggers, disassemblers, etc. Many products we see don’t have anything like these unless it’s really warranted. However, it is good to list these as it is something to point to should the blue team complain about abuse. “Hey bro you didn’t encrypt anything and we told you”.
Server-side resilience
First thing that stuck out to me was the subscription model. Should you figure out how to mimic the network messages to the devices, you could skip the subscription feature entirely and just manually adjust your lights without paying. Secondly, you could also redirect any networking traffic that would go to the server-side host and try and pretend to be the server, thus giving yourself a free subscription. This is more or less client-side issues, but since it’s a server-side validation, I added it here.
Value constraints are fun. Say, for example, you had a username and password to sign up with from the app. The app would have a text box and not let you add an email longer than say 30 characters. You could just patch over the limit that the text box enforces (assuming there is not code integrity checks) and send a 500 character-long email address to sign up with. If there is no server-side check for length, you can spam and fill up their database with junk. This could also go for anything else that would be presumably stored on the server (i.e. names of the devices that are added). Character lengths could be manipulated as they are registered onto the server.
Rate limiting is just DOS potential. Nothing too special here.
Network integrity
This is the user’s network. Can I access any devices from outside of the user’s WiFi? Can I capture the user’s password by sniffing their network traffic? Maybe their password? Can I DOS their lightbulbs? What a fun thought.
The request listed 32 devices. Can that number be increased? What if the network subnet only allows 16 devices at a time?
Product integrity
Client authentication is an overlap of how the services stores the auth data. It would be annoying to log in every time I wanted to turn my kitchen light off, so let’s assume that you remain logged in with a session token. Perhaps that token can be stolen and used with another device. This also falls in with storage of secrets.
Value constraints again. Other things to validate could be the lux of a device. There is surely an upper limit, perhaps it could be bypassed to cause light bulbs to burst or start an electric fire.
Out of Scope
This is optional, but you could also list what is explicitly out of scope. Let’s assume we don’t have access to the software on the server-side. That would be out of scope.
Time Frame
Our assessment time frames usually range from 2-6 weeks depending on size/complexity and how many engineers are working on the product. If you think you’ll need more time, let people know early. Don’t wait until the last few days to say that you need another 2 weeks.
Verified
Once you finish your scope contents and time frame, you will (hopefully) send it to the blue team for feedback before you get started. They can inspect what you have listed and ask why you have something that is or isn’t listed in/out of scope. This should be done within the first day or 2 depending on the size. You can always append to your scope later, but make sure the blue team is aware of any changes!
Wrapping It Up
Here is a reply to Freaky Forester’s Inc.
Hello (team member who sent email), my name is BowTiedCrawfish and I will be the engineer undertaking this integrity assessment for Luminux.
We have allotted 4 weeks for this assessment.
The following items are in-scope for the assessment:
Client-side resilience
Injection protection
Anti-tamper
Anti-debug
Anti-reverse
Code obfuscation
Memory obfuscation
Code integrity
Server-side resilience
Value constraints
Rate limiting
Network integrity
External access
Device limit
Product integrity
Client authentication
Storage of secrets
Value constraints
The following items are out of scope for the assessment:
Hardware mechanisms
Please look over the scope materials. If you have any questions or concerns about the scope or duration of the assessment, please reply-all to this email.
In a real assessment we have a lot more context to add to scope, but for this example I just kept it simple and discrete.
Secondly, the scope is usually shared in a Google document too, rather than just shoved into an email. That would be a bit of a headache to keep up.
This is a huge post. Sorry about all of that but this something that everyone needs to learn regardless of your niche.
Next report post will discuss what to write down during an assessment.
Go!
-BowTiedCrawfish