Information Warfare (hackers) v the Software Developer
I hear you fancy yourself a software developer? Great! Me too. But what is your take on hackers and the craft of cyber warfare? Do you think you write hack safe code? Fact is, people are out there that want to
- Remotely control systems that you control,
- Exfiltrate your data, and
- Otherwise compromise the integrity of your technology.
What they want to to is all fine and dandy, but surely this can’t happen to my code, right? Well, wrong.
If you are writing router software or Operating System software, you know the importance of creating safe, secure code. But how about a game programmer? Is it really necessary to put the extra effort in to make your code safe? You bet it is.
Maybe your code is just the way the hacker gets on the system, looking for more gold at the end of the tunnel. We’ll talk more about this and examine even more questions you may have about hackers and protecting your code and your customers in this paper. Remember, the best security is built into the system, not bolted onto the system.
Exploiting the SDLC presentation
Information Warfare and Your Responsibilities as a Software Developer – Introduction to understanding hackers and protecting your software against attack (click here for presentation) was created to promote awareness and motivate the software developer into further research. It is not exhaustive, and does not cover all potential vulnerabilities. It is only an overview of hacking, and a few common vulnerabilities that can be easily addressed by the software developer.
Tons of tools – use them!
- Network & systems testing
- Nessus (tenable, https://www.tenable.com )
- Retina (eEye, now beyondtrust)
- MS Baseline Security Analyzer (Microsoft)
- Metasploit (RAPID7, https://www.metasploit.com/ )
- Static analysis scanners
- Security AppScan Source (IBM)
- Flawfinder (Dwheeler)
- FindBugs (findbugs.sourceforge.net)
- RATS (Secure Software Inc)
- Owasp Orizon ( https://www.owasp.org )
- Disassembly & debugging
- IDA – debugger & disassembler (hex-rays)
- OllyDbg (ollydbg.de)
- gdb (GNU Debugger)
- Password “auditors”
- LC4 (@stakes)
- John the Ripper (Openwall)
- L0phtcrack (L0pht Heavy Industries)
Safe coding practices & Development rules of thumb
- Complexity is the enemy of security
- Keep your code as simple as possible
- Avoid obscure code and undefined behavior
- Use minimal privileges for deployed applications
- Don’t require user to have root priv if not strictly required
- Catch all bugs and questionable results
- Your software needs to catch anomalies
- Test & apply tools early and often
- Protect at the unit level, plus protect again anywhere you like (like in the client side browser), but keep the unit level protections (e.g., don’t trust the user!)
- Never trust the client nor user
- nor network nor file system nor DLLs nor cookies nor anything else that is not part of your executable, and sometimes not even that (hacker could nop the authentication routine)
- This includes both inputs and outputs
- Perform sanity checks on server side, not client
- Don’t volunteer too much information
- Expect adversity, even if your program is simple
- Your program may simply be the vector into the intended system
Happy reading! And remember, let’s be safe out there… you are part of the cyberwar.