OTHER CISCO HTTPD FLAWS--A MORE SOPHISTICATED APPROACH

OTHER CISCO HTTPD FLAWSA MORE SOPHISTICATED APPROACH

In this section, we'll examine various other methods of attacking and gaining control of a Cisco device using its web server management interfaceor, shall we say, the bugs present in the web service. We'll investigate excessive information leaks as well as some common buffer overflow vulnerabilities that have been discovered in the HTTP service in the last few years . If you feel adventurous and ready to discover the flaws on your own, feel free to dig into Chapter 8, where we describe the elements of reverse engineering, debugging and writing exploits, and other useful attacker approaches to IOS. For now, let's stick with what has been already discovered by security researchers and specialists alike.

Cisco IOS 2GB HTTP GET Buffer Overflow Vulnerability

Attack 

Popularity:

2

Simplicity:

9

Impact:

10

Risk Rating:

7

This vulnerability was discovered by FX from the Phenoelit group. You can find more information about the group and the research and released tools from the web site http://www.phenoelit.de . The public presentation of this exploit was released at DEFCON X. (If you're interested, you can see the PDF slides at http://www.phenoelit.de/stuff/defconX.pdf .) As we further describe the methods of buffer overflow in Cisco IOS in Chapter 8, we won't go too deep in this section. To exploit this vulnerability, we can use the exploit provided by FX, which is available for download from SecurityFocus or from the Phenoelit site. Download CiscoCasumEst.tgz and do the following to compile:

 arhontus:~$ tar -xzf CiscoCasumEst.tgz      arhontus:~$make      arhontus:~$./CiscoCasumEst 

If all goes well, you should see the following usage printout:

 ./CiscoCasumEst      Usage: ./CiscoCasumEst -i <interface> -d <target> [-options]      Options are:      -v   Verbose mode.      -T   Test mode, don't really exploit      -An  Address selection strategy. Values are:           1 (random), 2 (last), 3 (smallest), 4 (highest), 5 (most frequent)      -tn  Set timeout for info leak to n seconds      -Ln  Set requested memory leak to n bytes      -Rn  Set number of final leak runs to n 

To make this exploit work, the Cisco device should be running both web service and echo service to place the shell code and calculate memory addresses properly. Please note that as the name of the vulnerability implies, you'll need to send 2 gigabytes of data to the device, so depending on your connection, it might take awhile. After a successful exploitation, you should get your favorite enable promptEnjoy!

Countermeasures to the HTTP GET Buffer Overflow Vulnerability

Countermeasure 

If your company security policy doesn't allow an easy way of updating devices without following 1001 different paper documents, proceedings , or other bureaucratic means, one of the workarounds for this issue is to disable HTTP access to everyone except administrative personnel. This can be done by applying access control lists to permit only desired IP addresses to access the service:

 ip http access-class <access-list number>      access-list <access-list number> permit host <authorized host #1>      access-list <access-list number> permit host <authorized host #2>      !..... add more hosts in similar way .....      access-list <access-list number> deny any 

It is also recommended that you disable the web and echo servers on the devices if it is not needed. To do so, either make sure the following line is not present in the configuration file:

 ip http server 

Or specifically disable the service by adding the following line to your config:

 no ip http server 

The recommended way of mitigating this vulnerability is to update the IOS of the routers in question to the latest available one from http://www.cisco.com . This way, you'll make sure the systems are up to date with the latest security patches.

ASSESSING SECURITY OF A CISCO WEB SERVICE

Now that we have taken a look at several disclosed vulnerabilities in the Cisco's HTTP service, we should look at some methods of assessing the security of the web service. Several frameworks and utilities will come in handy in the processsome are unfortunately proprietary, closed-source software with heavy price tags. Several good commercial tools can be used to perform the security assessment. These tools usually perform an extensive series of tests on the desired services. A number of them are available on the security marketplace to name a few, there are AppDetective by Application Security Inc., WebInspect by SPI Dynamics, and CANVAS by Immunity. These utilities are generally suitable for security-centric companies that provide various levels of network/application assessment services. They produce a nice report at the end of the day that might even be suitable for the eyes of management, who are not usually interested in technical details.

If you are a security consultant who does not mind a large amount of false positives and are not too interested in gaining knowledge and experience by performing and understanding the attacks from the inside out, these tools might provide an ideal way to move forward. However, we wrote this book for a slightly different purposeto help readers understand more about the methodology of attacking and defending, and help readers realize how, why, and for what reason various attacks exist.

SPIKE and Its Relatives

Attack 

Popularity:

8

Simplicity:

3

Impact:

10

Risk Rating:

7

This wonderful peace of software, a tool for discovering attacks, has been brought to us by Immunity. According to its readme file, SPIKE is a: "Fuzzer Creation Kit. It has a fairly interesting generic API for data marshalling. The API attempts to make duplicating an unknown protocol easier for a reverse engineer or security researcher." This tool can be downloaded from http://www.immunitysec.com/resources-freesoftware.shtml with documentation and papers section available at http://www.immunitysec.com/resources-papers.shtml . Here we'll provide the foundation material to help you use this tool for further security development and vulnerability finding and reverse engineering the services in which you might be interested.

One of the handiest tools for testing web services is SPIKE Proxy. Analysis of the web server relies on the client using the tool as a proxy when browsing various pages. Assuming that you've launched the tool by using python spkproxy.py , the SPIKE Proxy interface and assessment criteria can be accessed by opening up a browser, setting its proxy settings to 127.0.0.1:8080 , and accessing the web page http://www.spike/ . If all goes well, you'll see something similar to Figure 7-12.

If you want to test the level of security on your Cisco device, you should use the browser to go to the IP address of the device in question and let SPIKE do the work in fuzzing HTTP requests by using various combinations of malformed HTTP protocol requests. This is done by clicking the following options: Delve into Dir, argscan, dirscan, and overflow VulnXML Tests (see Figure 7-12). Doing this will perform directory traversal, fuzzing arguments, attempts to achieve a buffer overflow by submitting strings of various lengths, and other useful tasks . What is left for you is to analyze the responses and check whether the server is still functioning. If you discover that the server stops responding or gives you something different from what you expected, you've probably discovered a bug that needs further examination and testing. For this, visit Chapter 8, where we discuss just what you need.

image from book
Figure 7-12: SPIKE Proxy interface

Of course, there is more to SPIKE than just a proxy. It has a wealth of utilities to try and test. In this section, we'll discuss another utility in the SPIKE fuzzer collection: webfuzz. To take advantage of this utility, you'll have to set up a man-in-the-middle style redirection that will intercept all the traffic that is generated by you browsing the targeted device's web interface. After you've done your share of web site crawling, you tell webfuzz to do the analysis of the web server by performing the following steps:

  1. Capture the HTTP request in the following manner:

     $ ./webmitm -t <IP/hostname of web site> -p 80 
  2. Modify your /etc/hosts (or windows /system32/hosts ) to make a redirect of your target to the web proxy on your host.

  3. Browse the web site as you would normally do. This will generate plenty of files for further processing and analysis.

  4. Use makewebfuzz.pl to create webfuzz.c .

     $ ./makewebfuzz.pl <http-request-N> > webfuzz.c 

    Replace <http-request-N> with the filenames generated from the webmitm output.

  5. Compile webfuzz.c into a binary by running $ make in your SPIKE src directory.

  6. Run $ ./webfuzz <target-IP> <port> against the web server, specifying an IP address and the port of the target device.

As an example, the webfuzz.c should look similar to this (obviously it will be different for each testing scenario):

 /* Start webfuzzprelude.c */      #include <stdio.h>      #include <stdlib.h      #include <string.h> /*for memset*/      #include <sys/types.h>      #include <sys/socket.h>      #include <signal.h>      #include "spike.h"      #include "hdebug.h"      #include "tcpstuff.h"      void      usage()      {         fprintf(stderr,"Usage: ./webfuzz target port \r\n");         exit(-1);      }      int      main (int argc, char ** argv)      {         int first;         char * target;         char buffer[1500000];         int port;         char * optional;         struct spike * our_spike;         unsigned long retval;         int notfin;         if (argc!=3)           {              usage();            }      .      .      <output omitted on purpose>      .      .       while(retval && notfin)       {          memset(buffer,0x00,sizeof(buffer));          notfin=s_fd_wait();          if (!notfin)             break;          retval=read(our_spike->fd,buffer,2500);          if (first && (retval==-1  retval==0))           {               printf("***Server closed connection!\n");           }         first=0;         if (retval)           {             printf("%.500s",buffer);           }       }/*end while read loop*/      s_incrementfuzzstring();      spike_close_tcp();      /*Use this for testing against netcat*/        /*         sleep(1);        */      }/*end for each fuzz string*/      s_incrementfuzzvariable();      }/*end for each variable*/      printf("Done.\n");        return 0;      } /*end program*/      /* End webfuzzpostlude.c */ 

Enjoy the long list of generated output that should be produced by webfuzz. It is recommended that you redirect the output to a file so that it can be analyzed later. If you see anything out of the ordinary, take a second look and perform further analysis and investigation. Perhaps you've just found yet another vulnerability in Cisco HTTP server. Have fun with this software and remember to inform the software developers if you find any bugs; this helps the development process and makes the systems just a touch more secure.

The Peach Fuzzer

Attack 

Popularity:

8

Simplicity:

3

Impact:

10

Risk Rating:

7

Peach is a fuzzer written in Python. This tool has contributed to finding and disclosing many vulnerabilities and is considered one of the most popular in the hacking and security communities alike. To use the Peach framework you'll have to create Python scripts that will include the details of fuzzing attacks performed on the server. By default, the Peach has examples of attacks located in the sample directory. To run the sample scripts, edit them to your requirements and use python <script_name> to see the tool performing the actions. Depending on the scripts you write, your output should look like this:

 $ python test-http.py      GET /index.html HTTP/1.0      Host: 192.168.15.77:80      GET /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAA      HTTP/1.0      Host: 192.168.15.77:80      GET /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAAA      HTTP/1.0      Host: 192.168.15.77:80 

This output is taken by running a sample Peach fuzzer script that was included in the sample directory. This script performs a simple check to see whether the HTTP server or the script running on the server can handle requests with long strings. The output of the tool has been omitted to save trees.

As you can see, the script files are somewhat similar to the webfuzz.c file generated by the makewebfuzz.pl script you saw earlier with the SPIKE fuzzer. The idea is comparable, and we will not repeat ourselves describing how it works. A nicely created documentation on the Peach API is available in the docs directory and should be browsed with your favorite web browser. Have fun!

Countermeasures to Fuzzer Utilities

Countermeasure 

The most appropriate measure that can be taken against the fuzzer methodology and similar methodologies should be of a proactive naturemaintain secure code and have it audited by several security-minded software developers. Other methods of circumventing similar attacks would be to design and deploy an intrusion detection system (IDS) that is ideally integrated with the active intrusion prevention mechanism, where the budget permits . This solution is not cheap by any means in terms of development, deployment, and maintenance. However, if the business activities of your company are highly dependent on the IT infrastructure, the risk assessment and the cost-benefit analysis should be able to persuade management to deploy these measures.



Hacking Exposed Cisco Networks
Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions
ISBN: 0072259175
EAN: 2147483647
Year: 2005
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net