ru.internet.security

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

 
 textsection 8 of 12 of file WUESTE.TXT
 textbegin.section
                               5.1.13 Port scan 1
 
 Description of attack:
      Perform a port scan on the target machine with "Nmap" program to find out
 which ports are open. This is often the first thing an attacker does  to  find
 out more about the target. "Nmap" was used with the options -sT -p 440-450  -v
 -P0 -T Aggressive. This is a TCP connect scan which is the basic variant of  a
 port scan using full TCP handshakes. It is not very stealth but  still  widely
 used. Tested all TCP ports from 440 to 450 with no delay  between  each  scan.
 This port range was chosen with no special intenion.
 
 Tool used:
      "Nmap"
 
 "Zonealarm":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Sygate Personal Firewall":
      Each packet gets logged. The system log reports 3 port scan events with a
 count of 6, 4 and 10. "Nmap" reports all ports as filtered.
 
 General conclusion
      All the three firewalls do not react in a fully stealth way, but they all
 react in the same way. No port was reported as open or blocked.
 
 Counter measure
      There is no need for a counter measure, as no information leaked out.
                               5.1.14 Port scan 2
 
 Description of attack:
      Perform a port scan on the target machine with "Nmap" program to find out
 which ports are open. "Nmap" was used with the options -sT -p 440-444  -v  -P0
 -T sneaky. This is the same TCP connection scan as used in the  port  scan  1,
 but this time with a large delay of 15 s between each the single scans.  Slow-
 ing down the scan can bypass some detection engines, as they watch for a  spe-
 cific number of connections in a fixed time interval.
 
 Tool used:
      "Nmap"
 
 "Zonealarm":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Sygate Personal Firewall":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered. The system log reports 2 port scan events, each with a count of 1.
 
 General conclusion
      All ports are reported filtered. The attacker did not gain an information
 out of this attack.
 
 Counter measure
      There is no need for a counter measure, as no information leaked out.
                               5.1.15 Port scan 3
 
 Description of attack:
      Perform a port scan on the target machine with "Nmap" program to find out
 which ports are open. "Nmap" was used with the options -sS -p 440-444  -v  -P0
 -T sneaky. This time only SYN packets are sent out. This  technique  is  often
 referred to as "half-open" scan, because we do not complete the full three way
 TCP handshake. After getting a response from the target system, we immediately
 close the connection request by sending an RST packet.
 
 Tool used:
      "Nmap"
 
 "Zonealarm":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered.
 
 "Sygate Personal Firewall":
      Reports each packet as a different event. "Nmap"  reports  all  ports  as
 filtered. The system log reports 4 port scan events.
 
 General conclusion
      All ports are reported filtered. The attacker did not gain an information
 out of this attack.
 
 Counter measure
      There is no need for a counter measure, as no information leaked out.
                               5.1.16 Port scan 4
 
 Description of attack:
      Perform a port scan on the target machine with "Nmap" program to find out
 which ports are open. "Nmap" was used with the options -sX -p 440- 444 -v  -P0
 -T normal. In this scan an XMAS-scan is used. This means a special packet with
 the FIN, URG and PUSH flags set is sent. As the SYN flag is not set, this pac-
 ket will bypass stateless filters. Depending on the answer, we  can  guess  if
 the port was open or not. This method does not work every time as it is OS de-
 pendent.
 
 Tool used:
      "Nmap"
 
 "Zonealarm":
      No event messages are generated. "Nmap" reports all ports open, which  is
 wrong.
 
 "Symantec Desktop Firewall":
      No event messages are generated. "Nmap" reports all ports closed.
 
 "Sygate Personal Firewall":
      No events are generated in the traffic or system log. The raw packet  log
 does report the packets. "Nmap" reports all ports open, which is wrong.
 
 General conclusion
      This behavior makes it possible to guess which desktop firewall  is  used
 at the target machine. This information could later be used to launch an  exp-
 loit that targets a specific version of desktop firewalls.
 
 Counter measure
      This problem could only be solved by implementing a stateful packet  ins-
 pection firewall.
                             5.1.17 Mutex blocking
 
 Description of attack:
      Some of desktop firewalls use a mutex to check if there is already an in-
 stance of itself loaded. Mutex is a program object that allows multiple  prog-
 ram threads to share the same resource, such as file access, but not  simulta-
 neously. When a program is started, a mutex is  created  with  a  unique  name
 identifier. After this point any thread that needs the resource must lock  the
 mutex from other threads while it is using the resource. The mutex is  set  to
 unlock when the data are no longer needed or the routine is finished.
      By stopping the desktop firewall process and blocking its  mutex  with  a
 malicious program, it is possible to prevent the firewall from loading and  so
 from protecting the network.
 
 Tool used:
      "ZoneMutex" from "Diamond Computer Systems Labs"
 
 "Zonealarm":
      The tool kills the running firewall process. Then it  will  set  a  mutex
 with the name "Zone Alarm Mutex" preventing the real "Zonealarm" from  reload-
 ing. As long as this tool blocks the mutex, the machine will be unprotected. A
 malicious application could even implement the system  tray  icon  to  pretend
 that the original firewall is working normally.
 
 "Symantec Desktop Firewall" and "Sygate Personal Firewall":
      Unfortunately, there was no ready made attack for these firewalls  avail-
 able. As the time line for this thesis was short, it did not allow to  code  a
 custom mutex blocking for these firewalls. Therefore, this test could  not  be
 done for "Symantec Desktop Firewall" and "Sygate Personal Firewall".
 
 General conclusion
      This problem is related to the process killing issue. Because, if the fi-
 rewall is already running, we have to kill the process before we can block the
 mutex. Still it is very serious that a single call to the mutex API can  block
 the firewall from loading.
 
 Counter measure
      Prevent another process from imitating the firewall mutex. This can  pro-
 bably be achieved by using cryptographic  algorithms  to  protect  the  mutex.
 Still it is not trivial. We can think of the idea that  a  malicious  attacker
 takes the original firewall application and extracts the creation the part  of
 the mutex from this application. With this it would be possible  to  create  a
 blocking mutex, regardless of what is used to protect it.
                              5.1.18 DLL injection
 
 Description of attack:
      Make a DLL that will be automatically loaded with a trusted  application.
 Then it can use the rights of the trusted applications to start connections to
 the network. For this test a tool was used which creates a DLL that is  loaded
 with "Internet Explorer".
 
 Tool used:
      "FireHole"
 
 "Zonealarm":
      Reports nothing unusual. The packets were granted the same rights as  the
 trusted parent application.
 
 "Symantec Desktop Firewall":
      Reports nothing unusual. The packets were granted the same rights as  the
 trusted parent application.
 
 "Sygate Personal Firewall":
      Reports a changed DLL and asks if it should be blocked or permitted. This
 is done by comparing the DLL to an internal list with names and  fingerprints.
 As discussed in Section 5.1.12, it would be possible to replace this  internal
 list, so that the new DLL can be loaded without an alarm.
 
 General conclusion
      This idea is similar to the idea of injecting a thread into  the  process
 memory of a trusted application.
 
 Counter measure
      A desktop firewall should also check all the loaded DLLs of  an  applica-
 tion and keep track of them. "Sygate Personal Firewall" does this already.  Of
 course, this goes back to the problem of where and how to store the signatures
 that are checked against the DLLs, as mentioned in Section 5.1.12.
                              5.1.19 URL encoding
 
 Description of attack:
      Use the given web-browser to send a hidden string encoded in a  URL.  For
 example, opening the URL:
 
      http://www.attackerssite.com\input.php?passwd=secret&IP=192.168.0.7
 
 The browser window used to send this information might be set to be  invisible
 or to be out of the user's desktop screen, so that it is not suspicious.
      Tools like "TooLeaky" use this method.
 
 General conclusion
      This method will always work as long as a webtraffic is  allowed.  If  we
 allow a normal webtraffic to pass the firewall, then  this  method  cannot  be
 blocked. It is impossible to distinguish between a malicious  and  a  harmless
 webtraffic. As all simple mail forms use the same methods of  HTTP  posts  for
 communication as well. This really leads to a problem as no users will give up
 the possibility to browse the Internet just for security reasons.
 
 Counter measure
      Blocking the web-browser is not practicable and, therefore,  not  an  op-
 tion. Even if the firewall does stateful packet inspection, this method  would
 still be undetected as the traffic is a legal HTTP traffic.
      One thing that would help is if we block requests from other applications
 to open a URL in the default browser. But this is a one of  the  features  the
 user probably is not willing to give up. Using a webproxy would not  eliminate
 the problem.
      The final conclusion is that there is no practicable solution to  prevent
 this attack.
                                   5.1.20 LSP
 
 Description of attack:
      Install a layered service provider (LSP) [16] that will  listen  for  all
 the incoming traffic. If the LSP gets installed under the desktop firewall  in
 the protocol chain, it might be possible to read packets before they  are  re-
 jected in the chain by the firewall. When implemented to filter out  the  pac-
 kets of the attacker these special packet would never reach the firewall. This
 would make a two way communication possible without the firewall even  knowing
 what was going on.
 
 Tool used:
      "AWP LSP"
 
 "Zonealarm":
      LSP can be installed with no problem. Packets that are blocked with it do
 not show up in the LSP.
 
 "Symantec Desktop Firewall":
      LSP can be installed with no problem. Packets that are blocked with it do
 not show up in the LSP.
 
 "Sygate Personal Firewall":
      LSP can be installed with no problem. Packets that are blocked with it do
 not show up in the LSP.
 
 General conclusion
      The LSP was not installed deep enough in the chain, especially not  under
 the firewall driver, or they used  other  methods  to  get  the  network  card
 events. The firewall was still acting normally and discarding all the  packets
 before the LSP was able to view them. Therefore, this attack was not  success-
 ful.
 
 Counter measure
      None needed, but make sure that it is not possible to install an LSP  be-
 low the desktop firewall driver.
                             5.1.21 Outgoing flood
 
 Description of attack:
      Try emulating a malicious application, which attacks another target  from
 the protected machine. Therefore, a flooding tool is used  to  attack  another
 machine. The protocol is varied with TCP packets with the  SYN  flag  set,  an
 IGMP traffic and UDP packets.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Detects the tool and asks to block or allow its traffic.
 
 "Symantec Desktop Firewall":
      No event is created, no packet is seen.
 
 "Sygate Personal Firewall":
      Detects the tool and asks to block or allow its traffic. All the  packets
 can be found in the raw packets log.
 
 General conclusion
      This would be the usual scenario that gets created if a DoS attack  would
 be started from this machine. For example, when a worm tries to spread [8].
 
 Counter measure
      Outgoing floods should be noticed and blocked if unwanted or not authori-
 zed. Therefore, a stateful inspection filter is needed,  as  flood  tools  may
 send special packets.
                        5.1.22 Using 100% CPU and memory
 
 Description of attack:
      With the help of a JavaScript code it is easy to generate 100%  CPU  load
 and memory usage. The idea behind this is that it might be possible that  some
 of the events will not get logged by the firewall because  of  resource  prob-
 lems. If the firewall was not well programmed, it could also be possible  that
 the process will crash.
 
 "Zonealarm":
      The firewall did not crash and reported normally. No events  are  skipped
 during the tests.
 
 "Symantec Desktop Firewall":
      The firewall did not crash and reported normally. No events  are  skipped
 during the tests.
 
 "Sygate Personal Firewall":
      The firewall did not crash and reported normally. No events  are  skipped
 during the tests.
 
 General conclusion
      Intensely using resources of the target system seems not  to  affect  the
 desktop firewall. Of course, it renders the system itself unusable.
 
 Counter measure
      None needed.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

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