ru.internet.security

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

 
 textsection 7 of 12 of file WUESTE.TXT
 textbegin.section
                                5.1.7 ICMP flood
 
 Description of attack:
      Flood the target machine with ICMP packets, type echo request, with spoo-
 fed source IP addresses.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports each packet as a different event. No special event message is ge-
 nerated.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No special event message is ge-
 nerated.
 
 "Sygate Personal Firewall":
      Reports each packet as a different event. Reports a DoS  attack  on  ICMP
 protocol in the system log. Regardless of the spoofed  source  addresses,  the
 firewall reports only a few source IP addresses.
 
 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.
 
 Counter measure
      None needed.
                               5.1.8 IGMP flood 1
 
 Description of attack:
      Flood the target machine with IGMP packets. The packet size  was  set  to
 1480 bytes, which means no fragments. No spoofed source IP address was used.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports all packets in a one event message with an increasing counter. No
 DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No DoS behavior occurs. The fi-
 rewall has an option to block an IGMP traffic, but I was not able to  see  any
 difference with this option enabled. Maybe, this feature only blocks the badly
 crafted packets used for a "kiss of death" attack [20] and not any IGMP  traf-
 fic in general.
 
 "Sygate Personal Firewall":
      The firewall does not support IGMP protocol. Therefore,  no  packets  are
 seen and no events are generated. During the attack 100% of CPU time is  used.
 After the attack was stopped, it recovered back to normal. If the  raw  packet
 log is enabled, then the packets will be logged there, but no  events  in  the
 traffic log are generated.
 
 General conclusion
      All desktop firewalls should be able to see and log an IGMP  traffic.  No
 DoS behavior should occur.
 
 Counter measure
      Implement IGMP filter into the desktop firewall.
                               5.1.9 IGMP flood 2
 
 Description of attack:
      Flood the target machine with ICMP packets. The packet size was first set
 to 1481 bytes and then to 65 000 bytes to have multiple fragmented packets. No
 spoofed source IP address was used.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports all packets in a one event message with an increasing counter. No
 DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No DoS behavior occurs.
 
 "Sygate Personal Firewall":
      After a short time the CPU load goes up to 100%. It generates an event in
 the system log for a DoS attack with an unknown protocol. If we have a look at
 the raw packet log, we notice that a half of the packets  are  blocked  and  a
 half of them are permitted. Because a payload  of  1481  bytes  generates  two
 fragmented packets.
      When the packet size is set to 65 000 bytes, which will generate 44 frag-
 mented packets, then 43 out of 44 packets are unblocked, as they do  not  have
 the offset bit set to 0 and the more fragments bit is set to 0. The system log
 will report a DoS attack. It seems that only fragmented packets  get  reported
 to the DoS attack detection engine.
      When pushing the "Block All" button during the attack, the CPU load rare-
 ly goes back to less then 80%, most often it remains at  100%.  Pressing  this
 button before the attack starts will limit the CPU usage of  the  firewall  to
 50% and keep it at this level during the attack. This is, of course, not  what
 normally will happen, because we do not know in advance when an attack will be
 launched.
 
 General conclusion
      The same conclusions as for the first IGMP flood attack in Section 5.1.8.
                                5.1.10 UDP flood
 
 Description of attack:
      Flood the target machine with UDP packets with random source IP addresses
 and random source ports using a packet size of 1000 bytes.
 
 Tool used:
      "HGOD_flood.exe"
 
 "Zonealarm":
      Reports each packet as a different event. No DoS behavior occurs.
 
 "Symantec Desktop Firewall":
      Reports each packet as a different event. No DoS behavior occurs.
 
 "Sygate Personal Firewall":
      Reports all packets in a one event message with an increasing counter. No
 DoS alarm is created, although the CPU utilization was 100% during the attack.
 
 General conclusion
      No DoS behavior should occur.
 
 Counter measure
      Change the implementation of the filtering engine so that no DoS behavior
 occurs.
                           5.1.11 Modifying rule set
 
 Description of attack:
      Locate where the desktop firewall stores the rule set. Modify it  to  add
 custom rules which will not be detected as suspicious, thus, giving a  malici-
 ous application the privileges that it needs to communicate to the Internet.
 
 "Zonealarm":
      Stores the rules for the applications in a file called  IAMDB.RDB,  which
 on a "Windows 2000" system can be found at C:\WINNT\internetlogs\. The file is
 machine independent. This means that we can replace this file  and  its  copy,
 the file BACKUP.RDB, with a modified version from another machine.  While  the
 firewall is running, it has this file opened in a non-shared mode. As discuss-
 ed in Section 5.1.1, it is possible to terminate  the  firewall  process  and,
 thus, end the lock on the rule file, making it possible even for a  restricted
 user to replace the rule set.
 
 "Symantec Desktop Firewall":
      Stores all the rules in plain text in the registry. The corresponding re-
 gistry key is:
 
 \HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\IAM\FirewallObjects\IPFilterRules\Rule1
 
 Here we can find all the rule related details, like the direction or protocol.
 It is simple for an attacker to insert a rule at the top of the ordering  that
 will allow any traffic through the firewall.
 
 "Sygate Personal Firewall":
      Stores the rule set in a file called STDDEF.DAT in its default  installa-
 tion catalog. The file is machine independent. This means that we can  replace
 this file with a modified version from another machine. While the firewall  is
 running, it has this file opened in a non-shared mode. As discussed in Section
 5.1.1, it is possible to terminate the firewall process  and,  thus,  end  the
 lock on the rule file, making it possible even for a restricted user to repla-
 ce the rule set.
 
 General conclusion
      The rule file is the brain of a desktop firewall. If we are able to modi-
 fy these entries, then the use of the whole firewall is at danger. In the  ex-
 periments it was possible to add custom rules for all the three  tested  fire-
 walls. This method can be implemented by a trojan horse to  add  an  allow-all
 rule, thus, being able to communicate with the Internet without restrictions.
 
 Counter measure
      The rule set can be encrypted and protected with a message authentication
 code (MAC), but all the data, especially the key that is needed to decrypt it,
 would have to be stored locally on the same machine. Otherwise,  the  firewall
 would not be able to read the rules after a reboot of  the  machine.  However,
 assuming that the secret key is stored locally makes it possible  for  another
 application to read it and further more use it to decrypt the rule data.
      If it is opened by the firewall in a non-shared mode by blocking the abi-
 lity of another process to access this file, the question arises if it is sto-
 red somewhere in memory where it could be manipulated?
      Even if this is not the case, it is possible to terminate the current fi-
 rewall process and, thus, also stop the exclusive access mode of the rule  fi-
 le, leaving it unprotected, as we have seen in Section 5.1.1.
      Another possibility is that the first time, when the  user  installs  the
 desktop firewall, it asks for a password. With this password the rule set will
 be signed using an  asymmetric  encryption  schema.  Each  time  the  firewall
 starts, it can use the public key to check the signature of the rule  file  to
 verify if the file has been altered. If the user wants to modify some rule, he
 supplies his private key, and the rule file gets updated. This could  work  if
 there was not a problem that a malicious user could simply  replace  the  rule
 set and provide the corresponding public key for it, so that the  verification
 method would accept it. The problem in this setup is that we cannot  relay  on
 any data as they have to be stored locally and, therefore, can be  altered  by
 an attacker. The public key is not authentic as it can be replaced. Moving the
 verification process to another machine is not practical.
      The rule files could be installed with  administrator  rights,  having  a
 small service running which accepts only calls from the user interface for mo-
 difying requests. In this way it would be possible to protect  the  rule  file
 from direct altering, as a normal user has not the rights to modify this file.
      But the problem is that a normal user wants to be able to change his rule
 configuration. Having a possibility for a normal user to change the rules  al-
 ways makes it possible for a malicious application to use  the  same  methods.
 For example, we can think of a modified version of  the  user  interface  that
 automatically installs an allow-all rule when started. For skeptics, think  of
 the following scenario. A malicious application makes a screenshot of the  ac-
 tual user desktop. Then it displays this picture as an image on the top of the
 everything and disables the keyboard. For a normal user this  will  look  like
 his machine has frozen. Behind this image the tool emulates mouse  clicks  and
 key strokes to the desktop firewall. This way the tool can create an allow-all
 rule like the normal user would have done it. In the end the  screenshot  pic-
 ture will be removed and  the  user  did  not  notice  that  a  new  rule  was
 installed.
      "Sygate Personal Firewall" is using another good approach. It writes  the
 rules from memory back to the file when shut down. This eliminates the problem
 of file manipulations during normal use. Unfortunately, this  method  is  only
 safe when it is not possible to manipulate the rules in memory and when it  is
 not possible to shut down the firewall process illegitimately. The latter  has
 been proven to be possible in Section 5.1.1.
      Unfortunately, I cannot provide a stable working solution for this  prob-
 lem. In my opinion, it has to be solved using an  administrator  process  that
 handles the rule file.
                          5.1.12 Replacing the binary
 
 Description of attack:
      Replace a trusted application with a malicious one that  pretends  to  be
 the trusted application. For the test "C:\Program Files\Internet Explorer\IEXъ
 PLORE.EXE" is replaced by the telnet.exe application, by renaming and overwri-
 ting it. After this an outgoing connection to TCP port 80 is initiated.
 
 "Zonealarm":
      It does notice the change of the binary and asks if it should update  its
 rule base. "Zonealarm" stores the rules for the applications in a file  called
 IAMDB.RDB, which on a "Windows 2000" system can be found at C:\WINNT\internetъ
 logs\. The file is machine independent. This means that we  can  replace  this
 file and its copy, the file BACKUP.RDB, with a modified version  from  another
 machine. While the firewall is running, it has this file opened in a  non-sha-
 red mode. As discussed in Section 5.1.1, it is possible to terminate the fire-
 wall process and, thus, end the lock on the rule file, making it possible even
 for a restricted user to replace the rule set.
 
 "Symantec Desktop Firewall":
      It does notice the change of the binary and tells that there  exist  some
 rules for "telnet" but that the file has changed its path since the last  time
 and the firewall needs to create a new rule. It recommends using the automated
 rule creating wizard, which looks at the filename and then  grants  even  more
 access to the modified "telnet" then we wanted. For example, FTP,  Gopher  and
 SSL ports were allowed. The recommendation wizard should  be  disabled  as  it
 would lead an inexperienced user to choose a wrong thing.  It  is  a  valuable
 feature for a normal configuration but can be easily misused for  a  malicious
 purpose.
      All the signatures of the applications are saved in the registry in plain
 text and without any further integrity checks. Therefore, we can easily  over-
 write the signature hash of the "Internet Explorer" with the new  hash  for  a
 malicious application. The hash is stored in a registry key located at:
 
 HKLM\Software\symantec\IAM\FirewallObjects\Applications\Internet Explorer\Appъ
 licationSignature1 Reg_Binary
 
 This hash is machine independent. We do not have to know how it is  generated,
 as we can simply generate a one on another machine and overwrite the  original
 one with the new one.
 
 "Sygate Personal Firewall":
      The replacement of the binary is reported by the firewall as an event and
 a message is displayed asking the user, if the changes are  expected.  In  the
 application list it did change the name from "Internet Explorer" to  "telnet",
 but the network connections are still blocked for the renamed "telnet".
      The question arises where "Sygate Personal Firewall" does store the hash-
 es of the applications. Nothing was found in the registry. So, I assumed  that
 they are stored in a file. With the help of file access monitor  tools  I  was
 able to trace the write commands back to the file called  stdState.dat,  which
 is located in the home catalog of the firewall installation. The program  sto-
 res the rules for each application in this file. The  file  is  encrypted,  so
 that we cannot change it. However, during the experiment it  was  possible  to
 replace this file with an stdState.dat file from another machine. If the  rep-
 lacement is done while the firewall is running, then nothing  happens,  as  at
 shutdown the program writes back the rules that it had been loaded into  memo-
 ry. But if the firewall was not running, then it will accept the new  file  at
 the next startup and present all the rules which we have configured on the re-
 mote machine. This makes it possible to replace the application rule file.
 
 General conclusion
      The rule file and hash values are the brain of a desktop firewall. If  we
 are able to modify these entries, then the use of the  whole  firewall  is  at
 danger. In the experiments it was possible to replace the application  finger-
 prints for all the three tested firewalls. This method can be implemented by a
 trojan horse to add itself to the trusted applications, thus,  being  able  to
 communicate with the Internet without restrictions.
 
 Counter measure
      For counter measurements see the attack about modifying the rule  set  in
 Section 5.1.11.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

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