Over the last couple of months, I have been bitterly amazed at how some so-called Ghanaian programmers write software, especially when it comes to applications that are exposed to the Internet. Nowadays, it seems one only needs to know how to install Wordpress on a web server to call himself a "software engineer." Better yet, if you have seen Sergio Corbucci's 1966 film Django, then you are already an EC-Council certified Python hacker. By contrast, in medieval times, for instance, an apprentice had to serve for seven years before setting up as a master. Do we have a bearing today? Does good enough code even make good enough software?
Considering how the Internet has penetrated our society (and the huge amount of resources that can be found on the Web), one is inclined to believe that folks would be adequately versed in their field of practice. Sadly, that is not the case. Often does one encounter professed super intelligent programmers when they are but merely smart software developers. They follow the famed academic fallacy that programming is a subset of software development, so if you are a software developer then you are a programmer as well. Do these ones even know what a CPU register is? "Man, that isn't necessary—they just build web apps." Aha, that's why they write bad code too!
Exploit Chronicles is the name of a campaign that I'm about to start to expose bad code (and for that matter bad software) that I managed to put up with in the past year—2013. The authors of such code are mostly obsessed with superficial software development methodologies and pet theories that neither do them any good nor make their programs any better; these are the Jeffrieses. On the other hand, there are other programmers, which are not of this fold; these ones rather focus more on their algorithms and data structures, examining and reexamining the code they write for proper functioning and robustness; these are the Norvigs.
The campaign will aptly seek to expose bad software that the Ghanaian Jeffrieses are writing. Yes, it will be limited to only Ghanaian or Ghana-related open applications. Although many forms of applications (desktop, mobile, web, etc.) fall within the scope of this campaign, special attention will be given to websites. Since Exploit Chronicles will be targeting bad software but not necessarily bad programmers, it is possible that your programming hero and/or mentor may appear in the case studies. If that should happen, do well to understand that sometimes good programmers write bad code; the mileage varies, certainly, but they all do eventually.
How exactly are these bad software going to be exposed? Well, I've written a few bots to help with the job. These little beasts are of two groups: the monkeys and the baboons. The monkeys travel the web looking for sites that are vulnerable to certain common forms of attack. When they grab these sites, they give them to the baboons who, serving as judges, determine which ones are Ghana-related. The baboons then make a list and hand it over to their master. The master analyses these websites using sophisticated tools, and sometimes writing specialized exploits. When all is done, he makes known his findings in a form of a written report.
An Exploit Chronicles case study is a detailed analysis of an openly accessible application from a penetration testing or vulnerability analysis point of view. The application under study must have had at least a single flaw in its code or implementation, which an attacker could exploit to cause damage or further a malicious cause. These case studies are publicly presented in a form of written reports. Before publishing a report, however, the victim of the attack is notified and given a fair amount of time to fix the flaws. Case study reports should therefore be viewed as educative rather than simply amusing or even informative.
Of course, not every case study exploit can be considered critical. Thus, Exploit Chronicles case study exploits will be classified into three levels of severity: low, medium, and high. The level of severity of a case study can be determined from the letter suffixed to the case study number of the title of a case study report, which will be either L (low), M (medium), or H (high). For example, the case study code 105H would represent a case study number 105 where the severity level of the exploit is deemed high. The nature of these exploits would range from spoofing one's identity to gaining complete control over a computer system.
Because I'm not on a full-time job to exploit sites and write reports about them, but instead a goodwill effort I'm trying to extend to Ghanaian developers, Exploit Chronicles case studies will not be published as often as you probably may expect. All the same, I'll do my best to publish at least trimonthly, that is, once every three months. In fact, probing just a single application for flaws can take a considerable amount of energy, time, and other resources—sometimes, lasting for several days. Surely, I am no computer security expert and do not claim to be an ethical hacker either, so don't expect any kind of "professionalism" on my part.
So as you wait for the first case study, not knowing who the victim is going to be, I suggest that you rub your hands together in a spirit of positive anticipation. On the other hand, though, some will be sitting on pins and needles having chills running down their spine. It's all good.