• they are fast
• they are probably better tested than your code
• your code will be shorter (and less to maintain for you)

So next time you want to do something, take a look around, maybe there is a PHP function which already does what you want (or almost what you want). Admittedly, the organization (naming) of the functions is not always the most consistent, intuitive one, but the searching effort is well worth it.

Picture taken from triplezero’s photostream with permission.

Yesterday I was putting together some new templates for the webhoneypot project with a focus on PHP shells. Things like r57, c99 and their derivatives. Then I looked at more “mainstream” applications like PHP Shell or PHPTerm and I started wondering: how many unsecured instances of these are there on the web?

The answer: a quick search-engine snooping turned up a couple of hundred (~800) instances. I didn’t check all of them, but the random picks a viewed were not secured by any password. And these are only the instances the search engine has indexed! If somebody would try to guess paths by brute-force on webservers (or potentially look in the robots.txt and check out those directories), I bet that many more instances could be found.

Just so that it doesn’t seem like I’m targeting PHP: urlrepl (a mod_rewrite like addin for older versions of IIS), exposes by default the configuration interface anyone accessing the given webserver. Now, a quick search didn’t turn up any instances, but it is still a bad practice.

So there you have it: hundreds of webservers you can own easily and then do whatever you like (bug all the sites on the machine to infect their visitors, host phising websites, etc). This is a very sad state, but I don’t see how this can get better as long as we are pushing for “ease of use” and most people don’t see value in security…

Picture taken from vanRijn’s photostream with permission.

How does it work (idea taken from the glastopf project):

• When a possible RFI attempt has been found, the respective file is fetched
• The file is parsed line-by-line and if certain patterns are recognized, predefined text is outputted.

This method is based on the observation that most (automated) RFI attempts begin by inserting a basic script to output system information (like the OS version, PHP version, etc). The emulation tries to find these cases and output something realistically looking enough so that the next stage of the RFI is triggered.

What do you need?

Activating the emulation is rather straight forward – you only need to add the following two lines in your config.local file:

fetch_rfi=1
emulate_rfi=1

The prerequisites for it to function are: (a) the webserver has to have the possibility to make outbund connections and (b) one of the following methods of fetching remote files with PHP needs to be activate: the curl extension, allow_url_fopen or sockets.

Warning! Allowing outbound connections from the webserver lessens its security considerably, so you only should do it on test machines.

Have fun!

PS. A bonus tip: if you set loglevel to at least the value of 4, all requests are written to your logfile, in addition to it being sent to SANS. This can be useful if you yourself are interested in the attempts of the “bad guys” to compromise your security.

Picture taken from Cyron’s photostream with permission.

An other assumption I make is that you have a separate Linux machine. The techniques can be also adapted to Windows, but it is easier on Linux.

The first step is to make more space. Typical routers come equipped with small amount of flash (between 8 and 20MB), which isn’t even enough to install all the packages. This means that some kind of external storage needs to employed. In this example I’m assuming that an USB flash drive is used (a hidden assumption also is that the router in question has USB ports – for example some of the older WRT54Gs don’t, but ASUS 500 series do).

• After logging in with SSH, update the list of packages: opkg update (in version 8.09 the list of packages is kept in RAM, so it needs to refreshed after each reboot)
• Following (adapting) the UsbStorageHowto from the OpenWrt wiki, I installed the USB 1.1 and 2.0 modules (surprisingly both types of modules are needed to support USB 1.1 and 2.0 devices – 2.0 doesn’t offer compatibility with 1.1) and the ext3 filesystem modules:

  opkg install kmod-usb-uhci kmod-usb2 kmod-usb-storage kmod-fs-ext3
  # The insmod commands might not be necessary, because I got the message
  # "insmod: a module named X already exists" for all of them, but better
  # safe than sorry
  insmod usbcore
  insmod uhci
  insmod ehci-hcd
  insmod scsi_mod
  insmod sd_mod
  insmod usb-storage
  insmod ext3

• Now we format our stick with the ext3 filesystem on the Linux box we have access to. You can do it with a visual tool like gparted, or from the command line:

  sudo cfdisk /dev/sdx   #delete other partitions and create a Linux partition
  mkfs.ext2 -j /dev/sdx1 #make sure to use the correct device :-)

  You might also want to consider dedicating part of the stick to swap (since the RAM of the router is also quite limited)

• Plug in the stick into the router and mount it:

  mkdir /mnt/usbstick
  mount /dev/scsi/host0/bus0/target0/lun0/part1 /mnt/usbstick

• Now, the following steps can lead to bricking your router, so proceed with care. The basic plan is the following:
  • Copy over the /usr directory to the stick
  • Delete the /usr directory from the internal flash
  • Mount the stick on the /usr directory
  • Install the packages we need
  • Copy back the old /usr directory to the internal flash (for safety, if for some reason the flas drive can not be mounted)

  This elaborate dance in needed because opkg (the package manager) insists on having X amount of free space on / before starting the install, even if /usr (where the packages will ultimately end up) is mounted from a separate device. opkg does have options which theoretically can work around this problem, however I couldn’t use them successfully.

• To execute our plan:

  mkdir /mnt/usbstick/usr_backup
  # these commands will take some time
  cp -R /usr/* /mnt/usbstick
  cp -R /usr/* /mnt/usbstick/usr_backup
  rm -rf /usr/*
  umount /mnt/usbstick
  mount /dev/scsi/host0/bus0/target0/lun0/part1 /usr
  # now install the new packages. a few comments:
  # - nano is so that we can do some basic text editing (yeah, vi is too hard for me :-))
  # - php5-cli is needed because in the future an update capability will be added to
  #   the webhoneypot, which will be run from the command line
  # - php5-mod-curl - it is possible that this will be a dependency in the future
  # - php5-mod-openssl - the updates will be (possibly) done trough SSL in the future
  opkg install lighttpd lighttpd-mod-cgi lighttpd-mod-rewrite nano php5 php5-cli 
  	php5-mod-curl php5-mod-openssl php5-mod-pcre php5-mod-sockets
  # now copy back everything to /usr
  umount /usr
  mount /dev/scsi/host0/bus0/target0/lun0/part1 /mnt/usbstick
  cp -R /mnt/usbstick/usr_backup/* /usr/
  # and remount the stick again
  umount /mnt/usbstick
  mount /dev/scsi/host0/bus0/target0/lun0/part1 /usr

Now we have the packages installed. What follows is the fetching of the honeypot code from the repository and its installation to the router.

• First we need to fetch the honeypot from the SVN. We could do this on the router (becuase it has a subversion-client package), but unfortunately that package doesn’t support the HTTP (WebDAV) protocol (as per the SVN FAQ, SVN implements a plugin system for the different protocols and ra_dav is missing from the package provided by OpenWrt). So we do on the Linux box: svn export http://webhoneypot.googlecode.com/svn/trunk/
• We should also prepare two other files on the Linux box, which will be copied over to the router (you could create them on the router, but it is more convenient to do it on the Linux side):

  lighttpd.conf

  server.modules              = ("mod_rewrite", "mod_cgi")
  server.document-root       = "/usr/wh/html/"
  server.upload-dirs = ( "/tmp/" )
  server.errorlog            = "/usr/wh/logs/lighttpd_error.log"
  index-file.names           = ( "index.php", "index.html",
  static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
  server.port               = 80
  server.bind                = "0.0.0.0"
  server.pid-file            = "/var/run/lighttpd.pid"
  dir-listing.encoding        = "utf-8"
  server.dir-listing          = "disable"
  url.rewrite-once = ( "^/(.*)$" => "/index.php/$1" )
  cgi.assign = ( ".php" => "/usr/bin/php-cgi" )
  # debug.log-request-handling = "enable"

  php.ini

  [PHP]
  
  engine = On
  short_open_tag = Off
  asp_tags = Off
  output_buffering = Off
  max_execution_time = 5
  max_input_time = 60
  memory_limit = 8M
  error_reporting  =  E_ALL & ~E_NOTICE
  
  register_globals = Off
  post_max_size = 8M
  magic_quotes_gpc = Off
  magic_quotes_runtime = Off
  extension_dir = "./"
  enable_dl = Off
  cgi.force_redirect = 1
  file_uploads = Off
  allow_url_fopen = On
  allow_url_include = Off
  
  apc.enabled = Off
  
  extension_dir = "/usr/lib/php/"
  extension=pcre.so

  We set up lighttpd to run PHP scripts using the CGI protocol (FastCGI would be more efficient, but also more complicated). The steps were adapted from this tutorial. The php.ini file is needed for two reasons: first, Perl regex support is not compiled into the PHP binary, so we must load it. Second APC support is compiled into the PHP library, so we must disable it, since it tries to allocate 32M of memory by default, which makes PHP fail, since we have around 20M of memory in total :-). To test that your PHP installation is workin, issue the following command on the router: /usr/bin/php-cgi -v It should output some basic information about PHP (lik version, copyright, etc). If it fails because of the APC cache, it outputs error message like the one described here: [apc-error] apc_shm_create: shmget(0, 8388608, 658) failed: No error. It is possible that the chosen SHM segment size is higher than the operation system allows. Linux has usually a default limit of 32MB per segment.

• We copy all the files from the Linux box to the router (in the /usr directory, since it now represents the USB stick):

  # on the router:
  mkdir /usr/wh
  # on the Linux box - replace 192.168.1.1 with your router's IP
  scp -r * [email protected]:/usr/wh
  # on the router:
  mkdir /etc/lighttpd
  mv /usr/wh/lighttp.conf /etc/lighttpd
  mv /usr/wh/php.ini /usr/bin
  # start the webserver

• Start the webserver: lighttpd /etc/lighttpd/lighttp.conf Check that everything is working by accessing the address http://192.168.1.1/phpbb/ from you box (where 192.168.1.1 should be replaced with your router’s address)
• Now configure the honeypot however you wish. The installation document should given you a good start. To edit the configuration file, do nano /usr/wh/etc/config.local. One thing I would suggest is to add loglevel=4 to it, so that the request details are also stored locally.
• The next step would be do get a DNS name (from DynDNS for example). This is especially important if you have an IP address which changes from time to time. Also, you should submit the honeypot URL to the search engines. Have fun and please report any bugs or problems on the issue tracker.

Picture taken from mightyohm’s photostream with permission.

DShield.org is offering this honeypot for users to capture automated web application exploits. It is a very simple "semi interactive" honeypot implemented in PHP.

The core idea is the following:

• you install it on a webserver and configure it such that all requests are routed to a single file (index.php). This can be done with something like mod_rewrite or mod_alias for Apache and similar methods for other webservers (nginx for example has a built-in rewrite statement)
• URL’s of “vulnerable looking” web applications are served up to spiders.
• When a URL is accessed, it is matched against a set of regular expressions and, depending on which regex matches the longest part from the string, a static file is served up. The request is captured and sent to SANS in the background

If you want to play with it, here are a couple of resources:

• The Google Code site, including the source repository (currently it is recommended to run the SVN trunk, until we get some stable releases out)
• The Webhoneypot Google site
• The #webhoneypot channel on irc.freenode.net

An automatic update mechanism for the templates is in the works, however it is not working yet. The documentation is also a little out of date, but we are working hard on refreshing it. In the future we will probably include some more emulation (the idea was taken from the Glastopf project) to elicit responses from automated RFI/LFI scanning bots. Also look forward to a tutorial on how to run it on routers running OpenWrt.

Picture taken from Tavallai’s photostream with permission.