BDS People & a Data Privacy issue

Over the last five months of 2013, I was intensively looking for job opportunities in the fields of Cyber Security, Software Quality Assurance, Digital Forensics, Information Assurance and Software Protection. Due to the fact that I sent my resume to a plethora of recruitment agencies, my concerns about data privacy obviously emerged as I did not want recruiters to disclosure sensitive information about me to the public. Hence, I started a search on the Internet.

Based on Google's search engine results, I found out that BDS People had been carelessly exposing about 4,000 resumes (mine included) to public access on the Internet. In accordance to the information gathered from some of the resumes that I inspected, I can confirm that people affected by this data privacy violation were job seekers who had trusted BDS People approximately between 2007 and 2013 (see the date of the resume highlighted in Figure 1. Names are blurred for obvious reasons):

Figure 1

It is important to mention that in order to access the list of 4,000 resumes I did not conduct any hacking attack on the BDS People's website. Basically, it means that no previous knowledge of web vulnerability exploitation was required to view or download any of the resumes. Essentially, the company's website contained a security hole that could have been introduced by inexperienced or neglected web developers. In short, private data of 4,000 job seekers was unrestrictedly and directly accessed via the following URL:

http://bdspeople.com.au/resumes/

SIMPLE AS THAT!!! The security hole might have been avoided by employing competent developers and testers capable of detecting a lack of use of the Robot Exclusion Protocol (or robots.txt protocol), which is a convention to prevent cooperating web crawlers and other web robots from accessing all or part of a website which is otherwise publicly viewable. Ideally and to correctly protect private data, those resumes should have NEVER been PERMANENTLY stored on a Web server, and instead, they should have logically (and safely) been secured behind an internal firewall between a DMZ (demilitarised zone) and the corporate network. Although the figure below does not exactly illustrate a HR consulting business, it depicts some of the aforesaid aspects.

Figure 2

I hope BDS People has learned something from this scheme, but I am afraid that it might still sound like a kind of Aramaic dialect. Honestly, I barely believe that BDS People possesses such an infrastructure even though they desirably should.

According to the information on their website, such a public disclosure of information (resumes) is not part of the privacy policy:

** UPON SUBMITTING THIS FORM I CONFIRM I HAVE READ THE PRIVACY POLICY AND AGREE THAT BDS PEOPLE CAN ACT ON MY BEHALF AND SUBMIT MY DETAILS TO POTENTIAL EMPLOYERS.

Hence, BDS People did NOT comply with the National Privacy Principles as set out in the Privacy Act 1988 (http://www.oaic.gov.au/privacy/privacy-resources/privacy-fact-sheets/other/privacy-fact-sheet-2-national-privacy-principles), and particularly with principles 2 (Use and Disclosure) and 4 (Data Security). Therefore, what BDS People states at http://www.bdspeople.com.au/privacy.php was temporarily FALSE as I ONLY authorised them to share my details with potential employers.  

To make things worse, the incident was not just about 4,000 resumes. There was no confidentiality in protecting more than 5,000 private e-mails addresses and phone numbers (job seekers + referees who were sadly affected too). Not to mention the whole employment history of all job seekers.

Information Assurance and Security are serious matters. Safeguarding job seekers information is to ensure confidentiality of user data. This is data in transit, both physical and electronic forms as well as data at REST in various types of physical and electronic storage. Unfortunately, BDS People did not comply with those principles.

Sadly, this confirms what I believe: there are still companies that show incompetence in securing data and business, and they might be liable to believe that disasters and adverse events will rarely occur. As a consequence, they decide not to invest on security, compromising user privacy.

This episode is ironic as I was looking for Information Assurance related jobs as well, but those behind BDS People, who should show proper qualifications to match job seekers like me and potential employers, were having data privacy and confidentiality issues. Obviously, this generated outcomes far below my expectations.

To me, there was a violation of my privacy rights so I set a formal complaint and informed the competent and regulatory authority about this incident. Some people might believe that I was wasting my time, but I cannot stop fighting for justice and fairness. Job seekers are constantly required to present themselves as immaculate candidates in order to succeed in obtaining a position (no place for errors, spelling mistakes, etc.), but a vast number of the recruiters are just ordinary agencies that provide regular services. This reminds me "...And Justice For All" (1988) from Metallica. 

Figure 3

Here is the chorus:

Justice Is Lost
Justice Is Raped
Justice Is Gone
Pulling Your Strings
Justice Is Done
Seeking No Truth
Winning Is All
Find it So Grim
So True
So Real

That's it. No improvements over the last 25 years and still getting worse.

CJ

iOS anti-forensics: How can we securely conceal, delete and insert data?

In fulfilment of the requirements for the degree of M.Sc. (Cyber Security and Forensic Computing), I have conducted research on the under-studied area of anti-mobile forensics and formulated three novel techniques: a “Concealment” procedure to enhance the security of non-protected data that is at rest on iOS devices, a “Deletion” procedure to prevent data recovery from iOS devices, and an “Insertion” procedure to surreptitiously implant false evidence into iOS devices. Findings were accepted for publication by the Hawaii International Conference on System Sciences (HICSS 2014) (ERA A Rank):

D’Orazio C, Ariffin A and Choo K-K R 2014. iOS anti-forensics: How can we securely conceal, delete and insert data?. In 47th Annual Hawaii International Conference on System Sciences (HICSS 2014), 6–9 January 2014, IEEE Computer Society Press [In press].

This publication can be accessed via http://ssrn.com/abstract=2339819.

Figure 1 shows how the "Concealment" and "Deletion" procedures impact on the decryption of files on iOS devices.

Figure 1

Both procedures generate the results illustrated in Figure 2.

Figure 2

The different between "Concealment" and "Deletion" is that the latter is irreversible. Thus, the concealment procedure might be appropriate for those users who intend to safely store private or sensitive information on iOS devices that cannot be recovered when applying digital forensic techniques (e.g, if the device is stolen, misplaced, etc.). On the other hand, the deletion procedure becomes of importance to definitely thwart criminal investigations.

A new beginning

Hi everyone,

This short post is just to clarify the purpose of this blog.
 

Since the end of 2001, I have been actively researching and writing tutorials about Reverse Engineering. It just started as a hobby which turned into a pathway to conduct extensive research on Digital Forensics for an important Spanish agency. To be more precise, I worked on decoding several proprietary data storage formats to develop software applications for the recovery of erased data contained on mobile phones, which substantially helped to extract incriminating evidence from forensic copies.

Due to those tutorials, which I used to publish, I was contacted by the aforesaid agency and my career in Mobile Phone Forensics began. The important takeaway message is that your presence in the cyber world matters and can open doors. However, the constant lack of time has essentially prevented me from bringing my work to the cyber community over the last years. Although, as a security consultant, I actively continue reversing software under simulated attacks for those companies that look forward to hardening their applications, writing detailed and step-by-step tutorials is a time-consuming task that unfortunately I cannot much longer pursue.

So well, in order to maintain my presence and let people know about my work, I decided instead to put hands on a blog focused on generally discussing digital forensic and security-related issues/topics, which in theory should be less demanding. Thus, this blog brings attention to a wide range of disciplines rather than just Reverse Engineering. I hope you enjoy it and become a recurrent visitor.

CJ