Introducing the Exploit Chronicles Campaign
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 they even know what a CPU register is? "Man, that ain't nothing—they just do web stuff!" Aha, that's why they write bad code too!
Exploit Chronicles—Case studies of bad code
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.
Understanding Exploit Chronicles case studies
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.
List of episodes in this series
- Cracking Trilion CMS to gain administrative privileges
Trilion IT Services is a small website development and web hosting reseller company based in Ghana, situated at Community 12 in Tema. The company develops and maintains a content management system called Trilion CMS. The software has been installed for at least a dozen of its clients to manage their websites, spanning from simple company websites to complex web directories. In this case study of Exploit Chronicles, we are looking at how to exploit an SQL injection vulnerability in this web software to gain administrative privileges.
- An SQL injection attempt to install a web backdoor
The Bank of Ghana (BoG) is the central bank of Ghana. It was formally established on March 4, 1957, two days before the country's independence. In 2012, one Romanian gray-hat hacker compromised the systems of several African banks, most of them Ghanaian, including that of SG-SSB, UT Bank, and Fidelity Bank. But it seems not every bank learned a lesson from those incidents. So in this case study of Exploit Chronicles, we are exploiting an SQL injection vulnerability in BoG's website to install a backdoor onto the web server.
- Exploiting code logic to harvest user information
Jobs.com.gh is a Ghanaian job portal launched in 2013 by Ringier Ghana, a subsidiary of the Swiss multinational media enterprise Ringier AG. The website lists job vacancies on a daily basis and claims to be "Ghana's number 1 jobs portal." In this third case study of the Exploit Chronicles campaign, we are putting Jobs.com.gh on the radar. One distinguishing feature of this case study, however, is the absence of an SQL injection exploit. For the first time, we are exploiting a logical flaw in the design, implementation, and functioning of an application.
- ^ Lately, a lot of code monkeys prefer the use of the term "software engineer." They believe the comical title sounds more prestigious and looks better on their resumes too. However, I believe an "engineer" is someone who is legally liable to designs they implement. So if you claim to be a "software engineer" but are not willing to be sued if your software fails, then you are without question a fraudster. In some countries, for example Canada, the use of the title without an appropriate certification could result in criminal prosecution.
- ^ Looking at the number of automated software development tools and frameworks that can be found everywhere, undoubtedly one can develop a complete software (typically, enterprise applications) without writing a single line of code. Hence, not every software developer is (or can be called) a programmer. This ratiocination further proves correct a statement that I recently made in an article that, "You don't need to be a programmer to develop software."
- ^ The names are in reference to the Peter Norvig and Ron Jeffries's sudoku solver case. Upon seeing Norvig's sudoku solver in a few lines of Python code, Jeffries questioned his (Norvig's) solution and proposed a better approach—TDD. Yet, whereas Norvig demonstrated his solver in a single post, Jeffries failed to produce a working implementation in five posts and later decided to abandon the challenge altogether. Read more on the story here.
- ^ The process isn't quite as smooth as you probably read it. Sometimes, the monkeys get lost for a long time in their quest. When they finally appear, they come back with all sort of diseases. (Read viruses.) Also, the baboons often pass bad judgments. When that happens, the master steps in to help them better understand what they have before them.
- ^ Low-level exploits cover attacks such as overcoming minor restrictions in an application (for example, the MyJoyOnline Poll Vulnerability) and many forms of cross-site scripting and SQL injections, while medium-level exploits range from retrieving restricted data (such as emails and passwords, like in the terrible case of developersinafrica.com) to escalating privileges to non-administrative roles. High-level exploits, as ones of the utmost degree, will deal with cases where an attacker gains an unrestricted administrative role in or to an application where he can readily take control of the whole server/system infrastructure.
- ^ I'm sure many will disagree that this campaign is a "goodwill." If you happen to side with such ones, fine; it shows the beauty in having the right size of a nose on one's face. You are wholly entitled to that idea but that doesn't make it any less boring than watching GTV news.