63 replies to this topic

[Wonko the Sane]

Could a virus be designed in such a way, that it can be installed into an already burned CD-R, by means of a CD-Burner?

Yes.
Generally speaking Cd writers (unlike the common cd readers) have upgradable firmware, so in theory it is possible to store a virus in it, and have it write a few bytes to the written CD on-the-fly. (not unlike a BIOS virus)


Wonko

[RoyM]

Very good point there Mr. Wonko, and hardware BIOS is not something usually scanned by AV's.

[MedEvil]

Ok, that would be another way of doing it.

My idea was more along the lines, that a PE is cleanly burned to a CDVD-RW.
Now the PE is used on a computer, which has only a burner and get's infected with the very nasty Wonko virus.
The Wonko virus can for sure demage/destroy the CDVD. But can it actually add/embed itself into the CDVD?

If the session wasn't closed, that's obviously no problem.
If only one specific file, which has by chance the correct original byte order for this hack, is targeted, it is at least conceivable, imo.

[RoyM]

(very nasty Wonko virus)

Very funny stuff MedEvil, I was actually LOL'ing not just typing it.

I've heard of this rampant nasty little bug before, I'd hate to catch that one.

[Wonko the Sane]

My idea was more along the lines, that a PE is cleanly burned to a CDVD-RW.
Now the PE is used on a computer, which has only a burner and get's infected with the very nasty Wonko virus.
The Wonko virus can for sure demage/destroy the CDVD. But can it actually add/embed itself into the CDVD?

In theory yes, if the media is actually writable (CDRW and the like).
Nothing prevents to load the whole CD to RAM, then re-write it, but I presume that with the right code it is also possible to modify a small part of the CDRW.

This may include not only CDRW, but also normal writable CD's if the session has not been finalized (i.e. it is a multi-session CD). (admittedly a quite rare event, but still in pure theory, possible, I have no actual idea if making such a mixed mode bootable CD is possible at all ).

Another interesting point (pure theory) can actual bytes or bits be changed on optical media?
I mean how exactly is a 0 or a 1 (or whatever) represented in the CD "groove"?
Is it possible to overwrite a 0 with a 1 or viceversa?
Some (partially unlrelated ) matter for thought:
http://ece.wpi.edu/~hammouri/CD/



Wonko

[amalux]

This was the line that jumped out at me, it seems counter-intuitive and gives a whole new meaning to the term 'read-only'.

Normally, authoring software will master a UDF file system in a batch process and write it to optical media in a single pass. But when packet writing to rewriteable media, such as CD-RW, UDF allows files to be created, deleted and changed on-disc just as a general-purpose filesystem would on removable media like floppy disks and flash drives. This is also possible on write-once media, such as CD-R, but in that case the space occupied by the deleted files cannot be reclaimed (and instead becomes inaccessible).

http://en.wikipedia....sal_Disk_Format


Since the only proof of concept given by MedEvil dealt with writing a bit or two to UDF, it seems CD-R is equally susceptible.

[MedEvil]

Oops, sorry typed CDVD-RW but meant CDVD-R. Cause a CDVD-RW is rather obviously to alter, as one can delete and write.

I think it wouldn't even be necessary to load the whole content to RAM.
If one writes 100MB data on a brand new CDVD-RW, one can see where the data is. A quick erase does not change that look of the CDVD. After a full erase, the CDVD will look like it was filled before to the rim.

Regarding open session CDVD.
I had actually used that before. Was a Live Linux from a russian developer, which featured that very ingenius idea. It was an open session CD, so one could set it up, on first run, to ones liking and click save, to have a personalised Live Linux.

If i remember right (And i doubt i do! ), CD don't actuall encode 0 and 1 but places where a series of one of them changes to the other. It's more like: "1s start here" - "Now start 0s".
But no matter what the exact tway is, a unwritten spot can be written but a written spot can't be unwritten.

[MedEvil]

Since the only proof of concept given by MedEvil dealt with writing a bit or two to UDF, it seems CD-R is equally susceptible.

Sorry Amalux, must have been brain dead. You wrote UDF the whole time and understood ISO.

Yes, UDF can be changed even on a CDVD-R media because, just like a open multisession CDVD, UDF file systems are not read only as a whole. Only the part that is already used, can't be reused. It is marked as deleted and the new data is added in free space.
Once the media is filled to the rim, no further adding of content is possible, but files might still can be deleted / undeleted, if the file table isn't full yet.

[amalux]

Right, this stuff can make your head spin 'round for sure

My only question, since you raised it as a possibility, has been; is it possible to infect an ISO (in writable drive) while booted from it (in use). This would present a serious security threat that would need to be addressed. Your proof of concept involved a tool (eicfg removal tool) which "works by toggling the deletion bit in the UDF file table, eliminating the need for unpacking and rebuilding the ISO". Since it is equally possible to do this with CD-R media, it seems your point was moot.

It is still my assertion that booting from an ISO is safe (even on writable drive) since attempting to mount, re-write and save the (now infected) ISO would result in crashing the OS your running from. Even if the image completely resides in RAM, you would still be attempting to re-write the image your working from and why bother? If it's possible to write a virus to RAM, then you don't need an ISO image to infect, just write the virus in RAM to infect the system on reboot, something I always believed to be impossible since RAM is cleared on reboot. Writing to the BIOS chip would be more likely but is outside the discussion here since it has nothing to do with ISOs vs CD-Rs.

I can (just barely) imagine a scenario where, while your working from an image in RAM, the virus secretly mounts and rewrites the inactive ISO residing on writable UFD/HDD; this might bypass the usual checks against writing to the drive directly but then this could only affect the system on a subsequent boot of the (now infected) ISO. I seriously doubt any lowlife virus writer could possess this degree of delayed gratification but even so, a quick hash check should root out this possibility before next boot (something I might actually implement).

I think the real discussion should be writable media vs read-only (the ISO is neither here nor there) and there, I agree, better to use RO media like a UFD with RO switch or at least scan it after every use, good idea anyway.

[MedEvil]

Well...
RAM is not necessarily cleared after a reset. There exist reset proof ramdisks, for instance.

Your point of a CD-R in use as systemdrive. Yes that would prevent a scenario like: making an image in RAM - modifying it - burning it back to CDVD. But this is impossible for CDVD-R anyway.

An ISO image on the other hand would not be protected by beeing used, since it would not need to be unmounted to be changed. The virus could change any file as long as the new file does not require more storage space than the original.
A simple binary patcher can do that, if you like to test yourself.

The theoretical possibility, that also a CDVD-R could get infected by a virus, would be highly tricky.
Cause the virus would had to work with the limitation in which data on a CDVD-R can be changed.
There can only pits be added, but not removed!
This limitation would require the virus to target one specific file, which has a usable byte structure.

Damaging the CDVD-R by adding senseless pits, should be no problem.

[MedEvil]

or at least scan it after every use

Not really a secure solution, as no Anti-Virus company claims a higher efficency than 97%.
Given the high number of known virii, 3% is a pretty big number they admit to miss and i'm sure they lie about that too.

It's better than nothing, but secure it aint.

[amalux]

An ISO image on the other hand would not be protected by beeing used, since it would not need to be unmounted to be changed. The virus could change any file as long as the new file does not require more storage space than the original.
A simple binary patcher can do that, if you like to test yourself.

Show me an example of real editing, not just flipping bits in UDF; I can find no evidence of virus infecting UDF. Afaik, the closest you could get to automated editing of ISO is here:
http://www.asylumnat.../post-2775.html

It's far more likely a virus would just destroy the ISO then produce something useful to its ends. In this case, no harm done to system. I have loaded many ISOs in machines crawling with nasties; often where any exposed file is immediately corrupted but never any damage to the ISO. I'm not saying it's impossible, there's probably very little beyond the scope of the possible; just that I'm not worried about it right now. I have always felt a sense of security in knowing that, booting from ISO (or CD for that matter), I'm relatively safe from whatever is infecting the host machine, it is off-line after all and afaik, no virus can remain active in a frozen system. The only real danger would be copying back infected files to the host when rebooted but this can be done from any platform. I just don't see the advantage to using CD-R over ISO/RAM, especially with all it's known limitations; if I'm proven wrong, what's the worst that happens, I re-infect an already infected machine?

[PioHS]

http://technet.micro...893(WS.10).aspx

[PioHS]

http://msdn.microsof...bedded.60).aspx

[Wonko the Sane]

Hey, we are just doing "fantasy" work here.

A CD/DVD has so many unused space that it is a possibility that you find there some space to write rather "long" pieces of code.
The issue is only "how to have those bytes read and executed",

An example (remember this is "fantasy" still) is BOOTFIX.BIN, it is executed normally everytime the PE 1.x disc is booted and it has "direct access" (read only) to the internal hard disk MBR well before any "protected mode" thingy is started.

Why isn't it possible to have it load some code from the CD itself or even write it (self-deploy itself) to (say) the first normally unused first sectors of the CD?

My previous (still largely theoretical ) approach of modifying the CD/DVD burner firmware is more elegant, as basically you can be infected by *anything* (meaning CD/DVD, executed file, Internet browsing, etc.) and once you are affected, every single CD/DVD inserted there will be re-written/modified.....


Wonko

[MedEvil]

Show me an example of real editing, not just flipping bits in UDF; I can find no evidence of virus infecting UDF. Afaik, the closest you could get to automated editing of ISO is here:
http://www.asylumnat.../post-2775.html

There is a fellow, that goes by the name of Hiren, who distributes a CD strangely in an archive. Why? Because the archive contains next to the ISO image a program, which can patch the ISO to another keyboard layout.

It's far more likely a virus would just destroy the ISO then produce something useful to its ends.

Like i said before, there are no virii known, to target specificly computer technicians.
The closest to that, i've ever seen, are virii, who stop the user from downloading, installing or running anti-virus software.

Regarding you're feeling safe.
When nuclear power plants were first introduced, it was said, that they are so secure, that only 1 desaster every 10000 years is likely.
3 mile island - Tschernobyl - Fukushima - Wow call my Methusalem, i'm between 20000 and 30000 years old!

I trust in Murphys law. Everything that can go wrong, will go wrong.

[MedEvil]

A CD/DVD has so many unused space that it is a possibility that you find there some space to write rather "long" pieces of code.
The issue is only "how to have those bytes read and executed",

That is actually no problem. If there is enough unused space to store the virus, all one needs to do is, bend the pointer in the directory from another file to the virus and one's in business. Finding a suitable pointer for such a hack should be rather trivial compared to actually finding a file in which the virus could be embedded.

[Wonko the Sane]

That is actually no problem. If there is enough unused space to store the virus, all one needs to do is, bend the pointer in the directory from another file to the virus and one's in business. Finding a suitable pointer for such a hack should be rather trivial compared to actually finding a file in which the virus could be embedded.

Then, you have at least the first 17 16 sectors available in most cases, 17 16 x 2048 i.e. 34816 32768 bytes to store the code.
There is also the "overburn area".
But this wouldn't "pass" MD5 hashing.


Wonko

[MedEvil]

I doubt that the first 17 sectors could be used, as they are not only outside the file system, but negative outside the file system. The overburn area might also does us no good. In a finalized CDVD this area is outside the filesystem. No idea if a pointer to such a point would even be accepted.
On the other hand, when we are talking boot files here, we're might in luck as the BIOS does almost no checking.

[Wonko the Sane]

I doubt that the first 17 sectors could be used, as they are not only outside the file system, but negative outside the file system. The overburn area might also does us no good. In a finalized CDVD this area is outside the filesystem. No idea if a pointer to such a point would even be accepted.
On the other hand, when we are talking boot files here, we're might in luck as the BIOS does almost no checking.

Well, yes and no.
The first 17 16 sectors are accessible (of course they are outside the file-system), allright by direct access, after all we are talking theoretically of a virus, something that will be probably written in assembler and that will use not a filesystem kind of access.


Wonko

[MedEvil]

Well, yes and no.
The first 17 sectors are accessible (of course they are outside the file-system), allright by direct access, after all we are talking theoretically of a virus, something that will be probably written in assembler and that will use not a filesystem kind of access.

It would need to be in the file system, if it should be loaded by the starting OS or if that pointer bending hack is done.
What you're proposing is more like a boot sector virus, i think.

[Wonko the Sane]

It would need to be in the file system, if it should be loaded by the starting OS or if that pointer bending hack is done.

Why?
I mean, in a fully booted NT system, provided your CDROM gets drive letter D:, what you get with:

dsfo .D: 0 34816 C:myfirstCDsectors.bin

BTW, I was wrong, it's 16 empty sectors, i.e. 32.768 bytes available, correcting previous posts


Wonko

[cdob]

Then, you have at least the first 17 16 sectors available in most cases

Do we use use CD-R media still?
First 16 sectors are part of ISO image. The writer does write first 16 sectors too. It's not possible, to overwrite sectors.

A example: boot catalog at sector 15:
http://www.msfn.org/...et-of-floppies/

Given a CD-R, pad ISO image to whole media. Write all sectors at CD-R.

Avoid Packet writing media like DVD+RW and DVD-RAM: a single sector can be overwritten

Editing is ISO9660 or ISO13346 (UDF) image is simple.
I'm using a hexeditor to change menu.lst inside a ISO9660 image.


Contrary UEFI is more likely target for malicious software.

[MedEvil]

Do we use use CD-R media still?
First 16 sectors are part of ISO image. The writer does write first 16 sectors too.

Yes, we do and it was never a question if the first 16 or 17 sectors are part of the ISO image, just if they are part of the CD, which can be reached from the file catalog.

It's not possible, to overwrite sectors.

Why not? One can't remove pits, but one should be able to add some. That'S how UDF on CD-R works.

Why?
I mean, in a fully booted NT system, provided your CDROM gets drive letter D:\, what you get with:

dsfo \\.\D:\ 0 34816 C:\myfirstCDsectors.bin

The question is not if the virus can be written there, but if it can also start from there.

[Wonko the Sane]

I haven't really read, let alone understood this (not that necessarily IF I read it I will be able to understend it ):
http://www.laesiewor...Storage_CD.html
but it seems to me like one of the very few place where to find some relevant info.


Wonko