5

There is an ongoing campaign of sending virus/trojans in e-mail messages faked as being from HSBC Bank, Lloyds TSB, Amazon etc.

The trojan/virus is sent in a application/zip attachment.

I've saved one such zip file and unpacked it in a directory owned by me with permission 700 on an ext4 file system

In order to scan it with clamscan, avgscan, and avast, I've saved the zip file and unpacked its contents into a directory "virus":

File: /home/users/miller/virus
Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 809h/2057d      Inode: 14155801    Links: 2
Access: (0700/drwx------)  Uid: ( 1001/  miller)   Gid: ( 1000/   users)
Access: 2013-10-03 12:57:47.484923866 +0200
Modify: 2013-10-03 12:57:46.684879168 +0200
Change: 2013-10-03 12:57:46.684879168 +0200
Birth: -

As to be expected I can rename the file or delete it. The file has permissions 600 and is owned by me:

$ stat virus.exe
File: virus.exe
Size: 61440           Blocks: 120        IO Block: 4096   regular file
Device: 809h/2057d      Inode: 14155809    Links: 1
Access: (0600/-rw-------)  Uid: ( 1001/  miller)   Gid: ( 1000/   users)
Access: 2013-10-03 12:46:37.194541504 +0200
Modify: 2013-10-01 22:01:44.000000000 +0200
Change: 2013-10-03 13:19:09.263393591 +0200
Birth: -`

But any attempt to read the file or copy it fails.

$ file virus.exe
virus.exe: writable, regular file, no read permission`

cp virus.exe copy.exe
cp: cannot open virus.exe for reading: Operation not permitted`

lsattr virus.exe 
lsattr: Operation not permitted While reading flags on virus.exe`

Even trying this as root fails.

So how is it possible to make a file unreadable even though it has "rw permission" and how can it be made readable in order to scan it with avgscan, clamscan, avast etc?


* CORRECTION ** (previous comment was for wrong zip file)

Addendum: Running clamscan on the saved attachment zip file its-self results in no virus/trojan/malware being detected, probably because the internal executable file is in an "unreadable" state.

clamscan virus.zip virus.zip: OK

Similarly avgscan and avast fail to detect any malware.

This highlights the importance of being able to read the extracted exe file and shows that clamscan is failing to detect malware.

The original name of the zip file is ORDER-N:N-1414559-3015133.zip and the original name of the executable file is Order details.exe.


* IMPORTANT ADDITIONAL INFORMATION *

To recap, if the zip file is unpacked by user miller, an exe file is created:

60 -rw-------   1 miller users 61440 2013-10-01 22:01 Order details.exe

but this is unreadable either by user miller or root.

HOWEVER, if the zip file is unpacked by root, the exe file is readable by root:

0 -rw-r--r--  1 root root 61440 2013-10-01 22:01 Order details.exe

The file command shows the following:

[15:57] koala:{virus/}# file Order\ details.exe 
Order details.exe: PE32 executable (GUI) Intel 80386, for MS Windows

So what is set that is preventing the ordinary user and root from reading the file unpacked by the user?

The file unpacked by root:

$ lsattr Order\ details.exe 
-------------e-- Order details.exe

The manual page for chattr explains:

The 'e' attribute indicates that the file is using extents for  mapping
the blocks on disk.  It may not be removed using chattr(1).

Thus on the ext2/3/4 file systems there is a catch22 situation -- the lack of readability of the file CANNOT be changed, and the solution is to unpack the zip archive as root to avoid creating the unpacked file with the "e" attribute since Linux unzip version does not have an ignore attributes switch.

If the zip file is unpacked on an XFS file system by the user, then it is readable, because XFS does not support the attribute setting mechanism.

And when avgscan is run on the exe file:

$ avgscan Order\ details.exe 
AVG command line Anti-Virus scanner
Copyright (c) 2013 AVG Technologies CZ

Virus database version: 3222/6719
Virus database release date: Thu, 03 Oct 2013 06:11:00 +0200

Order details.exe  Found Luhe.Fiha.A

Files scanned     :  1(1)
Infections found  :  1(1)

So the moral of this story is do not trust avgscan, avast, or clamscan on always finding malware in zip files -- always do the scan on the unpacked executable!

12
  • clamscan virus.exe WARNING: Can't open file virus.exe: Operation not permitted
    – J G Miller
    Oct 3, 2013 at 13:05
  • Run df /home/users/miller/virus. As user miller, run file viruses.exe.
    – slm
    Oct 3, 2013 at 13:08
  • df /home/users/miller/virus Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda9 450872512 193986816 233982680 46% /home
    – J G Miller
    Oct 3, 2013 at 13:19
  • I included the output of file virus.exe in the ORIGINAL message -- file virus.exe virus.exe: writable, regular file, no read permission`
    – J G Miller
    Oct 3, 2013 at 13:20
  • 1
    Please consider summarizing your findings (the "Important Additional Information" section) in an answer.
    – Joseph R.
    Oct 3, 2013 at 19:44

1 Answer 1

1

From what I can tell the smoking gun is this command:

lsattr virus.exe 
lsattr: Operation not permitted While reading flags on virus.exe

This is basically saying that the underlying file system is not EXT2/3/4. Given that the normal permissions can sometimes not be a factor and file attributes may well not be supported either.

Example

I have an NFS mounted share as follows.

$ pwd
/home/sam

If I run lsattr against it:

$ lsattr /home/sam/ 2>&1 | head -3
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/dead.letter
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/bashrc
lsattr: Inappropriate ioctl for device While reading flags on /home/sam/phillip_phillips_home.mp3

My guess is that the filesystem is what's denying you access to it.

3
  • This is a good point to make. However the file virus.exe is in /home/users/miller/virus which is definitely on an ext4 file system
    – J G Miller
    Oct 3, 2013 at 13:30
  • df -h /home/users/miller/virus Filesystem Size Used Avail Use% Mounted on /dev/sda9 430G 186G 224G 46% /home [15:30] koala:{~/virus/}> mount | grep sda9 /dev/sda9 on /home type ext4 (rw)
    – J G Miller
    Oct 3, 2013 at 13:31
  • @JGMiller Do you have an antivirus running that could possibly block access to the file?
    – peterph
    Oct 3, 2013 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.