As many have remarked at the time (a) the university had some weak webservers if it caved to such simple methods and (b) this can be done automatically with Javascript or Flash and would be very hard to track down.

Imagine the following scenario:

• The attacker inserts arbitrary Javascript or Flash content on one or more medium-to-high traffic websites. This can be done multiple ways: one can hack into CMS’s and modify the content of the articles to include the code in the articles. There are many vulnerable sites out there. Or, an even simpler solution is to buy placements for Flash banner ads and include the code in them.
• The code (a) looks up a DNS name (this makes the attack targetable) (b) launches N “threads” and starts sending requests to the given website

Such attacks would be very hard to diagnose. The requests would come intermittently from a wide range of IP addresses. Even if you could get your hands on such a computer, you couldn’t find the source of the requests easily (it’s not like the computer is infected with a malware you can find by scanning the files on the hard-disk). It can be also very sneaky, randomly executing (or not) or using geotargeting to select a subset of computers. These techniques are already in use by malicious advertisements (“malwertisements”) which are currently used to try to sell you rogue AV products. An other reason which makes finding the source hard, is the fact that AFAIK XMLHttpRequest does not send the referrer header. An other way to get rid of the referrer header is to make the request from a HTTPS site (browsers do not send referrer in this situation to avoid information leakage).

What can you do? Not very much. Prepare for the DDoS. Have a contingency plan (like a backup location in a different IP space and pointing your DNS entry there). You might be able to differentiate the requests from “normal” requests, but even so, the volume of requests can bring down the machine at the TCP level. And please, please secure your website. We have enough unsecured websites already!

Picture taken from 416style’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.

First of all, files on a webserver need to change very rarely. Executables almost never and it is useful to receive an email every time your HTML / PHP / ASP / etc files changed. A perfect fit for whitelisting, a non-starter for blacklisting.

Stepping away from the whitelisting aspect for a moment, on-access AV will be powerless with content which is not stored directly in the filesystem. This includes the recent wave of SQL injection attack, where the malicious data was in the database. Now we have several possible scenarios:

• AV is not installed on the DB server (because it isn’t a webserver :-))
• The installed AV doesn’t scan the files of the DB because of its size limitation or doesn’t find the malicious code because of the large size of the file
• The installed AV does find the malware, blocks access to the database file, thereby killing the DB server or at least making each client fail.

Either way, it’s not good.

Now getting back to the advices, the others are sound. One thing I missed is: apply the principle of least privilege to your network traffic!

• That SSH/RDP port you use to manage your system – it doesn’t have to be open to the whole world. Even better, move it to a non-standard port and limit access by IP
• If the server only needs ports 80 and 443, only allow ports 80 and 443.
• The server most probably doesn’t need to do any outbound traffic, so block it

Also, read and apply security best practices (this usually means changing the configuration) for the software you have on your server (searching for “[product name] security” is usually a good start).

All this said, if you do run a webserver on a home machine and want to make sure that your ISP isn’t blocking it, here are some ideas on how to test it:

• Use TOR to browse to it
• Use a free proxy to browse to it
• You could have used the Google translate trick, however they closed this loophole.
• However you can still use other services like ViewHTML or even the W3C validator to test connectivity.

As for other services (SSH, RDP, etc) – you could use something like nmap online to scan your host and determine if it sees the given ports as open.

Sorry for the lack of posts recently, but I’m just swamped at work and I also have to buy books from time to time. However I can say that I have several javascript and perl goodies prepared and soon I’ll post them

The recent show was a fairly good one (definitely one of the better ones), and I just want to make one comment: there is a solution for Leo’s problem with the people behind proxies (the problem was basically – for those of you who didn’t listen to the show – that because of proxies he couldn’t get accurate figures about downloads and suspected that he has a larger audience, but couldn’t prove it to the marketing people). So here is the solutions:

Point the clients (from the RSS feed enclosures and the links on the site) to a server side script (perl, php, whatever works for you) which generates the headers that disallow caching and then it generates a 302 location moved response with the actual location of the mp3 file. Now track the hits to this script rather then the audio file.

Why does this work? Because with this the conversation looks like this:

• Client requests the script file.
• Proxy sees the headers and says: I won’t cache this.
• Client sees the 302 response and does an other request to fetch the file from the new location.
• The response will have headers that allow caching, so the proxy will cache it.
• Now an other client comes. The first three steps will be the same, but at the last step the proxy kicks in and says: I already have this file and give the file from the cache.

The benefits of this method are: better download tracking and the same bandwidth utilization as before (so you let proxies do their thing basically as opposed to the solution where you deny caching of your material). The drawbacks: there are maximum number of redirects a client is willing to follow, so if you use this method in addition with other redirects (from podtrack for example), you might create a larger number of redirects than the client is willing to handle and it just gives up. An other potential problem would be that people figure out the actual location of the audio file (it’s not rocketscience after all) and start downloading from there. However this will be probably a small percentage of the audience. If you’re still concerned, you can make it so that you only deliver the content if the client has the right referrer header. This of course has the drawback that some people turn off referrer tracking. A combined solution might that that you only require referrer headers from people who are behind a proxy (based on the request header).

A final note: please, please give the script the same name as the audio file (and use mod_rewrite for example) so that when I do a save-as on the file I don’t get some generic name like redirect.mp3 as the file name.

Update: one example of implementing this is by podtrack. While I think that their site is … (I’m trying to find a word here which isn’t to derogative) and wonder why anybody would use IIS instead of apache, they got this much right (you can check for example by downloading a podcast tracked by them with curl and the -v option. There you can see that the first connection (made to their redirect server) replies with:

HTTP/1.1 302 Found
Date: Mon, 23 Oct 2006 12:33:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Location: http://www.esanity.co.uk/podcasts/23-10-06-boagworld.mp3
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 173

while the original podcast location in my case replies with:

Content-Length: 27704743
Content-Type: audio/mpeg
Last-Modified: Sun, 22 Oct 2006 22:54:03 GMT
Accept-Ranges: bytes
ETag: "de6dcef82cf6c61:9e4"
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Mon, 23 Oct 2006 12:33:44 GMT

• The first (and the more important one, although in security every item is important) was only recently publicized and involves sending an invalid header to Apache, which responds with an error page. I’ve got this one from the SecuriTeam blog. If the default error pages were not changed, they will include the invalid header, so a cross-site scripting attack is possible. To test if your site is vulnerable, you can use curl like this: curl http://localhost/asdf -H "Expect: <script>alert('Vulnerable');</script>" -v -i. If the output contains the alert, your server is vulnerable. To worsen the situation, you can use Flash or XMLHttpRequest to create these types of requests (although not with Firefox, which disallows the transmission of this header). Now don’t start filtering on Mozilla browsers, because user agents can also be spoofed. The two possible workarounds are: create custom error pages (harder if you host multiple sites) or enable mod_headers and use the following global rule: RequestHeader unset Expect early (tested with Apache 2.2.3 on WinXP). This might slow your webserver a little down as described in the documentation, but at least you’re not vulnerable until you update Apache.
• The second is a lesser problem, and involves the possibility of stealing cookies if the site has a XSS vulnerability even if the cookies are marked HttpOnly: It involves sending a TRACE request to the webserver. This request is usually used for debugging, and echoes everything back, including the cookie headers. Again Flash or XMLHttpRequest can be used to craft these special queries. A more detailed description of them can be found here: http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf. To test if your vulnerable, telnet to your webserver and enter the following commands:

  TRACE / HTTP/1.1
  Host: localhost (replace it with your host)
  X-Header: test
  
  (two enters)
  

  and you should see everything echoed back to you. As described here, you can use mod_rewrite to filter this attack, by adding the following rules:

  RewriteEngine On
  RewriteCond %{REQUEST_METHOD} ^TRACE
  RewriteRule .* - [F]
  

  And it is also a good idea to make sure that your sites are not vulnerable to XSS