This poster is a simplified version of consequences related to not being compliant with PCI DSS requirements and fine structure by credit card provider.
PCI DSS Cost of not being compliant poster
Tuesday, February 18, 2014
Sunday, February 16, 2014
Transfer of Evidence or a DNA of an Event
In this page, we'll be focusing on evidence or data location as a process based discovery where we have to triage the event in question. In any digital system, humans interact with an operating system by using applications in turn the operating system interacts with the hardware. Thus, relevant evidence transfer must take place at each of these interaction points.
Let's start with a reference to this theory that has been used in forensic science, Locard's exchange principle. Edmond Locard (1877-1966) was the founder and director of the Institute of criminalistics at the University of Lyons in France. Locard believed that whenever a criminal came into contact with his environment, a cross-transference of evidence occurred. He believed that "every criminal can be connected to a crime by dust particles carried from the scene." (Saferstein, Richard, Criminalistics, Seventh Ed., 2001)
Therefore, relevant evidence can connect a person to a crime scene by blood, semen, saliva, and hair, to paint, explosive, drugs, impressions, and chemicals. In digital device interaction or even network communication, the basic premise is that where ever we go ( browse or launch an application ), we will carry some evidence with us and leave some behind. We cannot interact with digital devices without a transfer of evidence occurring.
- UA - User to Application ( i.e user starts IE browser )
- AOS - Application to Operating System ( i.e. IE browser stores recently typed URLs in the registry )
- UOS - User to Operating System ( i.e. user interrupts the boot process to load kernel drivers for a SCSI drive )
- OSH - Operating System to Hardware ( i.e. OS saves a file to the physical drive or temporarily stores data in physical memory )
- UH - User to Hardware ( user changes the hard drive jumper or sets the thumb drive switch to read only )
Note: In a network environment, the data path crosses network devices where transfer takes place as well.
To demonstrate this visually, I have designed a tripple helix structure of the interaction between user, application, and OS. The most challenging evidence to validate and present as an admissible evidence is UA, UOS, UH. AOS, OSH, and network device artifacts are easier to classify as admissible evidence since they are not hearsay, but business records.
- AOS - Application to Operating System ( i.e. IE browser stores recently typed URLs in the registry )
- UOS - User to Operating System ( i.e. user interrupts the boot process to load kernel drivers for a SCSI drive )
- OSH - Operating System to Hardware ( i.e. OS saves a file to the physical drive or temporarily stores data in physical memory )
- UH - User to Hardware ( user changes the hard drive jumper or sets the thumb drive switch to read only )
Note: In a network environment, the data path crosses network devices where transfer takes place as well.
To demonstrate this visually, I have designed a tripple helix structure of the interaction between user, application, and OS. The most challenging evidence to validate and present as an admissible evidence is UA, UOS, UH. AOS, OSH, and network device artifacts are easier to classify as admissible evidence since they are not hearsay, but business records.
Monday, February 10, 2014
Back to basics - Metadata
Metadata can be crucial information to find out information about the stored data that can be under "attack" by those practicing eDiscovery. We know about locally stored data's metadata while the same data generated metadata in transit is getting less focus. We can find out file system and application generated metadata and feel very comfortable with this known knowns. Transmitting this same data can generate metadata on the network that we know, but the full extent of the collected data related to the content is unknown as it is getting further and further away from the local system. What information is collected in the cloud can be very vague and lesser known or not known at all to the local data owner. Thus, it adds another layer of uncertainty.
Back to basics - File slack
In this post, I wanted to revisit the concept of partial file recovery do to overwrite of unallocated clusters and the concept of RAM slack value in investigations. Unfortunately, I see less and less explanations of basic concepts like this for those entering this field.
In this case, file1.txt saved on a drive with cluster size 3, or 1536 bytes per cluster. Therefore, the file will require 4 clusters to store where the last cluster will only store 52 bytes. The last cluster consists of 3 sectors where the first sector needs to be completed to 512 bytes to complete the sector. It needs 460 bytes of data that it will grab from RAM and the last two sectors will remain untouched. The RAM slack and the disk slack will remain the same until file1.xt is modified or deleted. RAM slack and disk slack become protected that might contain pertinent data without the knowledge of the user. When file1.txt is deleted, all the 4 clusters become unallocated, so available to overwrite. Here, file2.txt is saved that will require 3 clusters. So, the fourth cluster of file1.txt will remain unallocated until another file overwrites it or file2.txt content expanded to the next cluster. File2.txt will overwrite the first two clusters and 28 bytes of the first sector of the third cluster. 484 bytes will be grabbed from RAM to fill the cluster with a complete 512 bytes of data and the last 2 sectors in the third cluster will retain the previous file's content. The fourth cluster will also have 52 bytes of file1.txt retained, but we can only recover 1024 + 52 bytes of file1.txt that used to be 4660 bytes long. Here e have two partial sectors with data from RAM that might contain keywords or passwords of applications. Notice the difference between the logical and physical size.
In this case, file1.txt saved on a drive with cluster size 3, or 1536 bytes per cluster. Therefore, the file will require 4 clusters to store where the last cluster will only store 52 bytes. The last cluster consists of 3 sectors where the first sector needs to be completed to 512 bytes to complete the sector. It needs 460 bytes of data that it will grab from RAM and the last two sectors will remain untouched. The RAM slack and the disk slack will remain the same until file1.xt is modified or deleted. RAM slack and disk slack become protected that might contain pertinent data without the knowledge of the user. When file1.txt is deleted, all the 4 clusters become unallocated, so available to overwrite. Here, file2.txt is saved that will require 3 clusters. So, the fourth cluster of file1.txt will remain unallocated until another file overwrites it or file2.txt content expanded to the next cluster. File2.txt will overwrite the first two clusters and 28 bytes of the first sector of the third cluster. 484 bytes will be grabbed from RAM to fill the cluster with a complete 512 bytes of data and the last 2 sectors in the third cluster will retain the previous file's content. The fourth cluster will also have 52 bytes of file1.txt retained, but we can only recover 1024 + 52 bytes of file1.txt that used to be 4660 bytes long. Here e have two partial sectors with data from RAM that might contain keywords or passwords of applications. Notice the difference between the logical and physical size.
Sunday, February 9, 2014
Back to basics - data structures
Many forensic analysis starts with a button click, but validated by looking at recoded data structures on storage devices in its native format. Non-programmers have a hard time learning and understanding what we mean by stored data. In this post, I wanted to show a code that can be compiled and run to see exactly how data is stored based on the given data type.
#include <iostream>
#include<string>
#include<fstream>
using namespace std;
typedef struct zoltan{
int age;
string fName;
string lName;
float earnings;
bool isGraduated;
}me_t;
int main(){
me_t student;
student.age=34; //change the RED values and experiment
student.earnings=34.45;
student.fName="Zoltan";
student.lName="Szabo";
student.isGraduated=true;
ofstream output_file("students.data", ios::binary); //change the output file name if needed
output_file.write((char*)&student, sizeof(student));
output_file.close();
return 0;
}
As we can see, age is an integer data type with a value of 34 hat was saved as hex value 22 00 00 00 since it is a 32 bit value stored in little endian format. Reading it as hex value 00000022 will give us 32 decimal. The string values for the first and last name are structures with default of 15 character array storage ( 0f000000 ) and a value that stores the current size of the used characters as an integer right before the size value. The floating point and boolean values are stored next. Unused available bytes are filled with a so called "garbage value", in this case, cc. There are 4 bytes before the string values that current state of this paper did not explore further at this time.
#include <iostream>
#include<string>
#include<fstream>
using namespace std;
typedef struct zoltan{
int age;
string fName;
string lName;
float earnings;
bool isGraduated;
}me_t;
int main(){
me_t student;
student.age=34; //change the RED values and experiment
student.earnings=34.45;
student.fName="Zoltan";
student.lName="Szabo";
student.isGraduated=true;
ofstream output_file("students.data", ios::binary); //change the output file name if needed
output_file.write((char*)&student, sizeof(student));
output_file.close();
return 0;
}
As we can see, age is an integer data type with a value of 34 hat was saved as hex value 22 00 00 00 since it is a 32 bit value stored in little endian format. Reading it as hex value 00000022 will give us 32 decimal. The string values for the first and last name are structures with default of 15 character array storage ( 0f000000 ) and a value that stores the current size of the used characters as an integer right before the size value. The floating point and boolean values are stored next. Unused available bytes are filled with a so called "garbage value", in this case, cc. There are 4 bytes before the string values that current state of this paper did not explore further at this time.
Back to basics - Signed integers
In this post, I wanted to visit the concept of signed vs. unsigned integers from a forensic point-of-view. Many investigators are trained to use tools to view cases from the software vendor point-of-view without understanding basic computer science concepts.
I wanted to look at symbolic links, look at the MFT record for the created hard link, and examine what happens when a long filename link with a hard link created that also have a long filename. These steps were repeated at least three times using Microsoft Windows [Version 6.1.7601], NTFS version 3.1.
1. Created test file with a long file name since hard links do not work on folders.
2. Created a hard link to the test file and named the link also a long file name.
C:\temp>copy con testingLongFilename.txt
hello again
^Z
1 file(s) copied.
C:\temp>mklink /h hardlinktolongfile.txt testingLongFilename.txt
Hardlink created for hardlinktolongfile.txt <<===>> testingLongFilename.txt
C:\temp>dir
02/09/2014 07:51 PM 13 hardlinktolongfile.txt
02/09/2014 06:24 PM <SYMLINK> hello [c:\temp]
02/09/2014 06:25 PM <SYMLINKD> hello2 [c:\temp]
02/09/2014 06:26 PM <JUNCTION> hello3 [c:\temp]
02/09/2014 06:44 PM 7 testfile.txt
02/09/2014 07:51 PM 13 testingLongFilename.txt
3. The resulting MFT record was examined and noticed the MFT record reflects the long and short file names noted by the first two $30 FileName attributes, but the hard link only had a single $30 attribute. The file names of the source and target resides in the same resident MFT record where the length of the NTFS name record shows 0x88.
Note: Microsoft documentation lists flags 0x01 for NTFS and 0x02 for DOS file name flags,
but did not list the 0x00 for hard link filename flag ( red circles ) .
So, in interpreting 0x88, it can be read as 136 or -120 depending on the data type.
Recipe - Two's complement to find the signed decimal value of a Base-16 ( Hex ) value
1. Convert to binary
2. Add -1
a. If the result starts with a one, the result is negative
3. Flip the result bits
128 64 32 16 8 4 2 1
128 64 32 16 8 4 2 1
1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0x88 |
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | +(-1) |
1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | result |
0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | flip bits |
-120 | ||||||||
Thus, the hex value 0x88 can be interpreted 136 as unsigned integer and -120 as signed integer. Signed integers are used in the MFT table entries for the cluster runs, so be careful with interpretation. In this case, the attribute length is 136 bytes.
Subscribe to:
Posts (Atom)