Hacking By Numbers: The Developer Course
Sensepost presents a whole range of courses, and as a company that specializes in security and that does presentations and courses at the annual Blackhat conference I must say they really know what they’re talking about when it comes to security, or pointing out the lack thereof rather. I was fortunate enough to attend their 3 day Hacking By Numbers: Developer course, which is aimed at illustrating common weak points in systems that are built-in by developers, so that developers can create the awareness to code fewer security holes.
Here’s a list of things I learnt:
- It takes no special black magic voodoo to become a hacker. Anybody with a decent amount of development and OS knowledge already has a lot of tools available to them to start hacking
- You dont have to stay up all night to be a hacker. This is a normal day job for some lucky people out there
- It’s a very straight forward process. Break the objective down into small bit-sized chunks and start working at solving them. Soon enough you might just get your hands on the admin username and password and are free to do as you please.
- Developers don’t realize the stupid mistakes they build into their code. One starting point is the error messages produced by a system. Some of them tells you exactly what you need to know to breach a system.
- It’s amazing what you can learn when you change your point of view, and see the same thing from a very different angle. A very cliched statement I know, but I realized that time and time again throughout the 3 day course.
There’s a lot to be learnt from somebody whose daily bread and butter depends on pointing out the mistakes that we make as system architects, designers, and developers, and I will definitely recommend anybody with a high profile internet facing system to attend one of their courses.
There are many very straight forward, simple things we can do to make our systems more secure, but between the constant rush to meet deadlines and always trying to catch up with the source code documentation, security tends to be even more of an after thought than the typical culprit documentation.
