ru.internet.security

 
 - RU.INTERNET.SECURITY ---------------------------------------------------------
 From : Marхnais                             2:5020/2173.2  18 Nov 2005  17:10:16
 To : All
 Subject : Desktop Firewalls and Intrusion Detection
 -------------------------------------------------------------------------------- 
 

 
 textsection 6 of 12 of file WUESTE.TXT
 textbegin.section
                           4.1.14 Avoiding visibility
 
 Description:     Make the process invisible for the desktop firewall.
 Required access: Local.
 Idea:            Use a kernel patch to hide the applications from API calls.
 Impact:          No filtering will be applied to the traffic.
 Leads to:        Bypass the outgoing filter.
 Variations:      Use different root-kits for Windows systems.
                           4.1.15 Resource exhaustion
 
 Description:     Consume all the available resources on the protected machine.
 Required access: Local.
 Idea:            Consume all the available resources  to  probably  crash  the
                  desktop firewall or at least temporary disable it.
 Impact:          Disabling the desktop firewall.
 Leads to:        Bypass the incoming and outgoing filter.
 Variations:      Try different resources like CPU time or memory.
                           4.1.16 Modifying log file
 
 Description:     Modify the log file of the desktop firewall.
 Required access: Local.
 Idea:            Remove the traces after a successful attack.
 Impact:          Fake log files events.
 Leads to:        Misinformation.
 Variations:      Add alarms of attack that have not taken  place.  Delete  the
                  complete log file.
                           4.1.17 Modifying rule set
 
 Description:     Modify the rule set of the desktop firewall.
 Required access: Local.
 Idea:            Edit the rule set so that any traffic is allowed.
 Impact:          Add a custom rule.
 Leads to:        Bypass the incoming and outgoing filter.
 Variations:      Add new specific rules or edit the existing rules.
                          4.1.18 Push the "yes" button
 
 Description:     Write an application that automatically pushes the "yes" but-
                  ton of the rule creation wizard when a  new  rule  should  be
                  created.
 Required access: Local.
 Idea:            Automatically create a rule for the malicious application.
 Impact:          Add a custom rule.
 Leads to:        Bypass the incoming and outgoing filter.
 Variations:      Use the wizard to create an allow-all rule.
                               4.1.19 Alarm flood
 
 Description:     Try to overflood the desktop firewall with alarm events.
 Required access: Remote.
 Idea:            Too many alarms might overwrite the older alarms in  the  log
                  file.
 Impact:          Information loss.
 Leads to:        An unnoticed attack.
 Variations:      Use different log file sizes.
                      4.1.20 Misuse a trusted application
 
 Description:     Remotely control a trusted application having it  communicat-
                  ing to the network. Use COM objects to open a browser  window
                  that is hidden. Let it access a special webpage  to  exchange
                  information.
 Required access: Local.
 Idea:            Pretend to be the trusted application.
 Impact:          Filter of the trusted application  will  be  applied  to  the
                  traffic.
 Leads to:        Bypass the outgoing filter.
                                   Chapter 5
 
                                    Results
 
      This chapter presents the results found while testing the  desktop  fire-
 walls and explains the occurred design problems of them.
                             5.1 Results of attacks
 
                             5.1.1 Process killing
 
 Description of attack:
      As a restricted user try to terminate the running desktop  firewall  pro-
 cess. When successful, this will disable the firewall and  stop  its  services
 and, thus, offer full access to the Internet. If not successful, try the  same
 with the administrator rights.
 
 Tool used:
      "Process Xplorer" from "Sysinternals" [11].
 
 "Zonealarm":
      Selecting the process Zonealarm.exe and  sending  a  termination  message
 will end the firewall processes including the "TrueVector"  service  VSmon.exe
 which does the filtering. Although during the experiment sometimes the  "True-
 Vector" did not terminate correctly. Therefore, it seems better to first  stop
 the VSmon.exe and then stop Zonealarm.exe separately.  Zonealarm  will  notice
 that TrueVector service is no longer running and  will  ask  the  user  if  it
 should be restarted, but, if we kill Zonealarm too, this does not matter.
      When the firewall was in "block all" mode, also known  as  "panic  mode",
 then after killing the process no further network connection is  possible.  It
 seems that in this case a low level driver is injected into the network  stack
 to prevent any communications. By terminating the process  the  protection  in
 the network driver will not be removed as it is not the process  itself  which
 blocks the traffic. It should be investigated what exactly gets  installed  by
 the process, to be able to see if it can be removed by an attacker.
 
 "Symantec Desktop Firewall":
      Logged in as a restricted user it is possible to kill the process IAMAPP.
 EXE. Unfortunately, this will only terminate the system tray  icon.  Examining
 the startup shows that the first process starts another tool  called  NISSERV.
 EXE. This process is responsible for the traffic filtering. Therefore, killing
 it is what we want. During the experiment it was not possible to kill it as  a
 restricted user, but it went to a state where it did not respond and  did  not
 perform filtering anymore. With an administrator rights terminating the  fire-
 wall process was not a problem.
      If this is not an option, then the idea would be to remove  the  registry
 key at:
 
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run : IAMAPP
 
 disabling the autostart of the firewall. Next time the  system  restarts,  the
 firewall will not be loaded.
 
 "Sygate Personal Firewall":
      Even when being logged on as an administrator, it is not possible to ter-
 minate the SCM.EXE process of  the  firewall  directly.  It  includes  several
 threads that constantly check for termination messages and try to  block  them
 or restart the service. This is a clever idea.
      Thus, it is not possible to terminate the process directly, but indirect-
 ly it is possible. If we list all open handles of the firewall process, we can
 see a one that is named "\Default" and is of type "Desktop". If we close  this
 handle, then soon a "Dr. Watson" message will appear and tell that the process
 SMC.EXE has generated errors and will stop now. Even when we do not  click  on
 the "OK" button of this message, after 15 s (on an idle  system)  the  process
 will terminate and leave the system unprotected. There is an option to  set  a
 password for starting and stopping the firewall service, but this feature will
 not prevent from the above explained attack as the password  prompt  will  not
 appear.
 
 General conclusion
      For all the three tested products it is possible to terminate  the  fire-
 wall process. This can be implemented by a computer virus or a  trojan  horse,
 giving it full access to the Internet after the shutdown of the  firewall.  Of
 course, it is not easy to design a process that cannot be stopped by a malici-
 ous application executed by a user since one of the requirements of a  desktop
 firewall is that the user is able to disable it when needed. This leads  to  a
 problem that an attacker could theoretically use the desktop firewall configu-
 ration utility and remove all unwanted functions, ending up with  an  applica-
 tion that shuts down the firewall process. Therefore, I am not aware of a  re-
 liable method of ensuring that the desktop firewall process is not  stoppable,
 unless we remove the right of the normal user to start and stop the firewall.
 
 Counter measure
      "Sygate Personal Firewall" is on the right way  but  should  improve  its
 service some more, so that it will be impossible, at least for a normal  rest-
 ricted user, to shut down the firewall.
                             5.1.2 Memory injection
 
 Description of attack:
      Load a malicious program into the memory space of a  trusted  application
 by allocating memory space for a function in  its  working  memory  space  and
 starting a thread there.
 
 Tool used:
      "BackStealth"
 
      Unfortunately, this version of "BackStealth" was not compatible with  the
 firewall versions of our test candidates, since it was designed for older ver-
 sions of them. As the time line for this thesis was short, it did not allow to
 code a custom memory injection for the three firewalls. This  means  the  test
 with this tool could not be performed.
      According to the information available, I assume that it would be possib-
 le to successfully inject a code into a trusted application. Generic code  ex-
 amples for this exist in different programming languages on the Internet.  For
 example, on "MADshi's" website source code for injecting  own  functions  into
 applications can be found [15]. Researches showed that some trojan horses like
 "Assasin" already use similar techniques to bypass desktop firewalls.
                        5.1.3 SYN flood 1, total random
 
 Description of attack:
      Flood the target machine with TCP packets, which have the SYN  flag  set.
 The packets are crafted with random source IP addresses, random  source  ports
 and random destination ports.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports each packet as a different event. No special event message is ge-
 nerated. No DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No special event message is ge-
 nerated. No DoS behavior occurs.
 
 "Sygate Personal Firewall":
      Reports each packet as a different event. No special event message is ge-
 nerated. The CPU utilization goes up to 100% during the attack.
 
 General conclusion
      This kind of attack cannot be reduced to a one single event  message,  as
 the events are different. Each packet has a different source  IP  address  and
 cannot be distinguished from the nonrelated traffic. Anyhow, no  DoS  behavior
 should occur.
 
 Counter measure
      Make sure that no DoS behavior occurs by observing memory and CPU  usage.
 Maybe, also block packets on a lower layer. SYN floods should be detected  and
 reported with an alarm event.
                        5.1.4 SYN flood 2, random ports
 
 Description of attack:
      Flood the target machine with TCP packets, which have the SYN  flag  set.
 The packets are crafted with static source IP address, random source ports and
 random destination ports.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports each packet as a different event. No special event message is ge-
 nerated. No DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No special event message is ge-
 nerated. No DoS behavior occurs.
 
 "Sygate Personal Firewall":
      Reports each packet as a different event. In the system log a  port  scan
 is reported several times from the same IP address. No DoS behavior occurs.
 
 General conclusion
      This attack should get reported as a port scan or as a DoS attack.  There
 is no good argument for a one or the other alarm, as it could be both of them.
 Therefore, reporting it as a port scan is not wrong, as for the desktop  fire-
 wall it looks like a port scan.
 
 Counter measure
      There is no real need to do anything against this kind of attack, as  the
 traffic gets blocked at the desktop firewall. No response will be sent back to
 the attacker.
                           5.1.5 SYN flood 3, static
 
 Description of attack:
      Flood the target machine with TCP packets, which have the SYN  flag  set.
 The packets are crafted with static source IP address, static source port  and
 static destination port.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports all packets in a one event message with  an  increasing  counter.
 The summarized count was very small, so it must have dropped some packets.  No
 special event message is generated. No DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. The summarized count  was  very
 small, so it must have dropped some packets. No special event message is gene-
 rated. No DoS behavior occurs.
 
 "Sygate Personal Firewall":
      Reports all packets in a one event message with  an  increasing  counter.
 After an irregular amount of time a new event message will be written, as long
 as the attack is going on. No special event message is generated. No DoS beha-
 vior occurs. Some packets seem to be dropped during the attack.
 
 General conclusion
      This attack should be reported as a DoS attack. Of course, it could be  a
 port scan, as mentioned in Section 5.1.4, but after monitoring  few  identical
 packets always coming from the same source port and targeting the same  desti-
 nation port, a port scan can be excluded. This behavior would not  make  sense
 for a port scan, however, it is regular for a DoS attack.
 
 Counter measure
      There is no real need to do anything against this kind of attack, as  the
 traffic gets blocked at the desktop firewall. No response will be sent back to
 the attacker. However, the attack should get reported  with  a  special  event
 message of DoS attack.
                            5.1.6 SYN flood 4, heavy
 
 Description of attack:
      Flood the target machine with TCP packets which have the  SYN  flag  set.
 The packets are crafted with random source IP addresses, random  source  ports
 and random destination ports. About 300 Kb/s of network  load  was  generated,
 which is a lot for the test network.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      After a short time CPU utilization goes up to 100% and stays there  until
 the end of the attack. Switching the "Block All" button on  will  not  protect
 the system from this DoS attack.
 
 "Symantec Desktop Firewall":
      After a short time CPU utilization goes up to 100% and stays there  until
 the end of the attack.
 
 "Sygate Personal Firewall":
      After a short time CPU utilization goes up to 100% and stays there  until
 the end of the attack. Switching the "Block All" button on  will  not  protect
 the system from the DoS attack. The firewall needs more then 60 s  to  recover
 from the attack. During the experiment the firewall still used up to  100%  of
 CPU time for 80 s after an attack of 15 s. After an attack of 30  seconds  the
 firewall needed 100 s to recover.
 
 General conclusion
      For all the three firewalls it was possible to make a remote DoS  attack.
 This makes it possible to temporary block a protected target machine.
 
 Counter measure
      A DoS attack should not be possible. Dropping the packets should be  done
 as early as possible in the stack. It is a difficult issue to deal with,  sin-
 ce, at some point of network load, there will be no possibility for the recei-
 ving network card to work properly anymore on all the packets.  This  behavior
 would also occur if it there is no firewall running on the machine. Still  the
 firewall should prevent from such attacks.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор