The SLBFE Hack: More than just a Hack?
The month of April has been a busy time for both cybercriminals and infosec professionals alike. In the 25 days, that went by, PayHere was hacked while #OpSriLanka knocked several government websites offline. The latest incident involves LulzSecSL (A local offshoot of LulzSec?) breaking into an online database maintained by the SLBFE or the Sri Lanka Bureau of Foreign Employment and making the stolen information publicly available for download. (source: The Morning).
Although the hack was an act of retaliation against the Rajapakse administration and a token of support towards #GoHomeGota2022 according to the report by The Morning I cannot help but believe the incident reveals a much deeper conspiracy. It seems contractors responsible for developing and deploying the database in question reduced its security deliberately. I wish I am wrong, but I can’t rule out the possibility because we aren’t new to such data scandals (Ex: The NRMA database wipeout). Keep on reading to learn more.
The method used to hack SLBFE
According to Asela Waidyalankara, a Cyber Security Expert, the attackers used “SQL Injection” (Using a piece of SQL code to manipulate a database and gain access to potentially valuable information) to access the database. As far as I know, known SQL Injection vulnerabilities and other non-zero-day bugs can be addressed at the auditing phase of the Software Development Life Cycle. Did the developers avoid implementing these safeguards deliberately to break in and harvest the data later? Only an investigation will tell.
Passwords stored in Plain Text
While checking the data dump I downloaded I was shocked to discover the screenshot of a database table containing employee login passwords in plain text. My initial thought was the developers were clumsy, but it occurred to me later. Maybe they weren’t clumsy after all.
Maybe they decided to maintain a backdoor which would have been useless if those passwords were encrypted. It’s a vague assumption but a responsible developer shall not design a database to store passwords in plain text unless he has an ulterior motive.
Source Code not Audited at All
Even if the developers were lazy to design the database-driven application to encrypt the passwords before storing them in the database, we can’t dismiss the lack of a source code audit as laziness. Detecting and correcting mistakes in the code is one of the many purposes of an audit. The plain text passwords indicate the source code was not audited at all. An audit could have helped the SLBFE identify the SQL Injection vulnerabilities injection attacks and the presence of a backdoor if there’s one. Maybe the reason why there was no audit.
Even if there is no conspiracy, the lack of code-level protection against SQL Injection Attacks, Passwords being stored in Plain Text format, and the lack of a Source Code Audit is a recipe for disaster. The incident indicates we cannot trust the government with our personally identifiable information. Can you imagine the treasure trove of information a hacker could find if he breaks into a production server operated by the Department of Immigration and Emigration (Passport Office)?
Among the dumped data were also the details (email addresses, telephone numbers, etc.) of the Manpower Recruitment Agencies registered with the SLBFE. These email addresses can be used for large-scale spamming and phishing campaigns undermining the safety of many. Contact numbers can be used for tricking smartphone users to download malware into their devices through SMS or WhatsApp Texts. So, does the hack indicate the presence of a larger conspiracy? Time alone can confirm.
I seek to foster thoughtful and respectful dialogue. Toward that end, I require that you use your full name when commenting. Also, any comments with profanity, name-calling, and/or a nasty tone will be deleted.