02 July 2002

A5.com's SARA Scan Results of 169.100.98.0-26
INTRODUCTION

A5.com was tasked to perform a Security Auditor's Research Assistant (SARA) security scan on hosts on the 169.100.98.0-26 sub-nets. The SARA scan was performed to identify potential security vulnerabilities in the 169.100.98.0-26 sub-domain. The SARA scan was completed on 2002/07/02 and its scan mode was set to heavy. The version of SARA was Version 3.6.2 .
DISCUSSION
SARA is a third generation security analysis tool that analyzes network-based services on the target computers. SARA classifies a detected service in one of five categories:
A total of 25 devices were detected of which 3 are possibly vulnerable.

Figure 1 summarizes this scan by color where the Green bar indicates hosts with no detected vulnerabilities.
Grey indicates hosts with no services.
The Red bar indicates hosts that have one or more red vulnerabilities.
The Yellow bar indicates hosts that have one or more yellow vulnerabilities (but no red).
And the Brown bar indicates hosts that have one or more brown problems (but no red or yellow)
Green   20
Grey   2
Red   2
Yellow   0
Brown   1

Figure 1 Host Summary by Color
The SARA scan results are distributed as three appendices to this paper:
 
Host: isdnbox.mydomain.com 


General host information: 

    
Vulnerability information: 





Host: news.mydomain.com 


General host information: 

    
Vulnerability information: 





Host: pc1.mydomain.com 


General host information: 




Host: pc10.mydomain.com 


General host information: 




Host: pc11.mydomain.com 


General host information: 




Host: pc12.mydomain.com 


General host information: 




Host: pc14.mydomain.com 


General host information: 

    
Vulnerability information: 





Host: pc18.mydomain.com 


General host information: 




Host: pc19.mydomain.com 


General host information: 




Host: pc2.mydomain.com 


General host information: 




Host: pc20.mydomain.com 


General host information: 




Host: pc22.mydomain.com 


General host information: 




Host: pc23.mydomain.com 


General host information: 




Host: pc3.mydomain.com 


General host information: 




Host: pc4.mydomain.com 


General host information: 




Host: pc42.mydomain.com 


General host information: 




Host: pc5.mydomain.com 


General host information: 




Host: pc50.mydomain.com 


General host information: 




Host: pc59.mydomain.com 


General host information: 




Host: pc6.mydomain.com 


General host information: 




Host: pc61.mydomain.com 


General host information: 




Host: pc7.mydomain.com 


General host information: 




Host: pc8.mydomain.com 


General host information: 




Host: pc9.mydomain.com 


General host information: 






END OF SECTION


Appendix D Vulnerability List by 
Severity 



   
Root Access via Buffer Overflow 
(RED) 


   
User shell Problems (RED) 


   
User writing file problems (RED) 



   
Target for Abuse(YELLOW) 


   
Possible Vulnerabilities 
(BROWN) 


   
Limit Internet Access ? (BROWN) 



    

      

      


      END OF SECTION
      

      Appendix E Vulnerability Tutorials 

      

        
  
  
  
        DNS Vulnerabilities
  
        
  
        Impact
  
        
  
        There are numerous vulnerabilities in Domain Name Servers (DNS) that are 
  documented in the CERT 
  Advisories. The two principal areas are: 
        
  
          
    
        • A remote intruder can gain root-level access to your name server. 
    
        • A remote intruder is able to disrupt normal operation of your name 
    server. 
        
  
        Problems
  
        
  
        BIND 4.9 releases and BIND 8 releases prior to 8.2.3 do not properly bounds 
  check a memory copy when responding to an inverse query request. An improperly 
  or maliciously formatted inverse query on a TCP stream can crash the server or 
  allow an attacker to gain root privileges. 
        
  
        BIND 4.9 releases and BIND 8 releases prior to 8.2.3 do not properly bounds 
  check many memory references in the server and the resolver. An improperly or 
  maliciously formatted DNS message can cause the server to read from invalid 
  memory locations, yielding garbage record data or crashing the server. Many 
  DNS utilities that process DNS messages (e.g., dig, and nslookup) also fail to 
  do proper bounds checking. BIND 4.9 releases and BIND 8 release prior to 8.2.3 
  have a variety of security issues. You can review them and BIND 
  Security. 
        
  
        Resolutions
  
        
  
        To resolve these problems, upgrade to the latest version of bind. If this is 
  not feasible, you can apply a patch, or use a workaround, described in the 
  various CERT Advisories. Refer to 
  SecurityFocus bid 2302 and 
  bid 2304 
        
  
        
  
        CVE References(s):
  
        
  
          
    
            CVE-2001-0497 CVE-2001-0013 CVE-2001-0012 CVE-2001-0011 
      CVE-2001-0010 CVE-1999-0849 CVE-1999-0848 CVE-1999-0837 CVE-1999-0835 
      CVE-1999-0833 CVE-1999-0024 CVE-1999-0011 CVE-1999-0010 CVE-1999-0009 
      
        
  
      

        

        



          

            

              

                

                

                

                  

                  

                  

                    

                    



                      

                        

                          

                            

                            

                            

                              

                                

                                



                                  

                                  


                                    
  
  
  
                                    Possible DoS (fraggle) Problem
  
                                    
  
                                    Impact
  
                                    
  
                                    Your machine may be vulnerable to certain types of Denial of Service 
  attacks (Fraggle, Smurf and Papasmurf). These DoS attacks 
  affect Windows 95 and Windows NT 4.0 machines. These attacks will cause a loss 
  of connectivity to the Internet and may slow network activity to a crawl. 
                                    
  
                                    Background
  
                                    
  
                                    The Fraggle attack, and other attacks of this type, such as 
  Smurf and Papasmurf, is the most recent in the category of 
  network-level attacks against hosts. Smurf, and Smurf type 
  attacks, begin when a hacker sends a large amount of ICMP 
  echo (ping) traffic to a subnet broadcast address ( say, for instance, 
  xxx.xxx.xxx.255 - the 255 number marks this as a broadcast address). This 
  traffic will have a spoofed return address. This spoofed address will be the 
  address of the intended victim of the attack. When individual machines on the 
  network receive the ICMP echo requests, they will reply with an echo reply. 
  These replies will all go to the address spoofed in the original ICMP echo 
  requests. On networks with a large number of systems, the traffic generated 
  could be voluminous indeed. The system, which is the victim of the attack (as 
  indicated by the spoofed IP address) quickly, becomes overwhelmed by incoming 
  traffic, and will almost certainly lose connectivity to the Internet. 
                                    
  
                                    Actually, there are two victims of this type of attack when it is run: the 
  network that is exploited to generate the ICMP traffic (called the 
  intermediary, or "helper" network) and the system indicated by the spoofed IP 
  address. 
                                    
  
                                    The Fraggle DoS attack is essentially based on the same concept as 
  the Smurf attack (namely that generating huge amounts of network 
  traffic will disable a machine or cause it to lose connectivity to the 
  Internet), but uses UDP instead of ICMP. Although it is not as serious as some 
  other attacks of this type, it will still generate a huge amount of network 
  traffic. Here is how it works: a hacker is armed with a list of broadcast 
  addresses, to which he/she sends spoofed UDP packets. Usually the packets are 
  directed to port 7 on the target machines, which is the echo port. Other 
  times, it is directed to the chargen port (a port that generates a number of 
  characters when queried). Sometimes a hacker is able to set up a loop between 
  the echo and chargen ports, generating all that much more network traffic 
  (this attack generally works on NT boxes). 
                                    
  
                                    The result of this attack is, as stated earlier, a massive amount of 
  traffic on the network. Whole networks may crawl to a stop and individual 
  systems may lose connectivity to the Internet and/or, in some cases, crash. 
  
                                    
  
                                    The Problem
  
                                    
  
                                    The Fraggle attack, and its variations, may affect individual 
  machines as well as entire networks. Affected networks and/or systems will 
  become bogged down with large amounts of network traffic, and users on 
  affected systems may lose connectivity to the Internet. The Smurf 
  attack and its many variations have been known to last for a period of hours 
  up to a day or more. 
                                    
  
                                    Resolutions
  
                                    
  
                                    The key to protecting against, and suppressing these types of attacks, is 
  to ensure that your network will not be used as an intermediary. This may be 
  done by configuring routers to not allow IP directed-broadcast transmissions 
  (on Cisco routers, use the "no ip directed-broadcast" interface command). All 
  routers, which provide routing to large multi-access broadcast networks, in 
  other words LANs with more than 5 to 10 devices, should be configured in this 
  way. This resolution is indirect, but is, at this point, the surest method for 
  eliminating these types of attacks. 
                                    
  
                                    Unfortunately, there is no sure method for protecting against being the 
  ultimate target for Smurf type attacks. For the Smurf attack, 
  the surest and safest fix is to configure routers to turn away all incoming 
  ICMP packets. Unfortunately, this will render several ICMP dependent services, 
  such as ping and traceroute, unusable. Other router configuration methods do 
  exist, and you may read about them in PSI's Filter 
  Configuration page. Other methods, such as ICMP filtering and dropping 
  excess packets at network border routers, are not foolproof but may help 
  alleviate the symptoms of Smurf type attacks. These methods are 
  described in WinPlanet's Smurf 
  Exploit page, and also in InterNIC rfc2267. If you 
  suspect that you have been the victim of a Smurf attack, you may want 
  to download the Smurf 
  Logger, which will allow you to log future Smurf attacks (and other 
  information, such as the broadcast address being used as the intermediary). 
  
                                    
  
                                    As with the Smurf attack, the Fraggle attack is particularly 
  hard to defend against. Some suggestions include blocking broadcast UDP at the 
  router, and perhaps blocking UDP at all terminal servers as well (to prevent 
  malicious network users from flooding out the network). Read the Smurf 
  information above for more information on router configuration tips and border 
  router packet filtering techniques that may prove useful in defending against 
  these types of attacks. 
                                    
  
                                    Where can I read more about this?
  
                                    
  
                                    Visit Rootshell to read about the Fraggle 
  and Papasmurf 
  Denial of Service attacks. 
                                    
  
                                    You can read more about the Smurf attack at Rootshell's Smurf 
  page. Another good source of information is Craig A. Huegen's Smurf Whitepaper. Be 
  sure to also to read the Smurf information in CERT Advisory 
  98.01. 
                                    
  
                                    
  
                                    CVE References(s):
  
                                    
  
                                      
    
                                        CVE-1999-0514 CVE-1999-0103 
                                    
  
                                  

                                    

                                    



                                      

                                      



                                      



                                        

                                        



                                          

                                          


                                          END OF SECTION