Reference Links:

• webboard.oreilly.com - WebBoard marketing + free demo CDs.
• Demonstration forum - Test here, login 2600, password 2600.
• Advanced Web Programming - Richard M. Smith's page.

Introduction

O'Reilly's WebBoard software first came to my attention when I discovered that my high school (along with various sections of TAFE) were using it in classrooms. Having looked at it for a while and played around, I discovered a couple of interesting bugs, with some interesting possibilities.

By the way, if you would like to have a play with the software, you can find a public demonstration at the O'Reilly site above.

Vulnerabilities

• Unauthorised Paging

  The first problem found with the software was that users who had disabled paging in their preferences were still able to be paged. The programmers merely removed the page link from the current users listing (the paging screen) where a particular user had disabled paging. Rewriting a pager enabled user's page-link to instead target a pager disabled user is as simple as acquiring the pager disabled user's user id number from their 'view profile' link (the 'User' column on the current users/paging page).

  So for example, I see user Administrator online with no paging enabled. Looking at the target of the user's 'User' column link reveals the following URL -

  http://hemi.demi.semi.random.number.com/~boardname/userpeek?31337

  Now armed with the user's user id number (31337), I can rewrite a valid page link ...

  http://hemi.demi.semi.random.number.com/~boardname/pageuser?7035

  ... with the paging 'disabled' user's user id number. Thus we arrive at the following:

  http://hemi.demi.semi.random.number.com/~boardname/pageuser?31337

  This will send the page message, however it's not a very useful hole (because the user will not see your page until they turn paging off). Not to worry, the next problem is more exciting.

  
  

• Arbitrary Content Insertion

  That's right, you can insert HTML and all of its friends in to your fellow-user's browser to be parsed and (in the case of the various <script> languages) .. executed. This leads to many interesting applications of this hole -- but first, how it works.

  This attack only works because insufficient input checking is done upon paging content, and because that content is dumped straight in to the target user's next page. The position in that page in which your paging content is dumped presents a slight challenge (see code segment, below) though insertion of appropriate content will ensure a customised message and arbitrary code, with no HTML parsing quirks. Indeed, it is possible to 'cloak' your message in many browsers (at least Netscape) and your target wont know that they've been paged at all.

  <script language="JavaScript">
  <!--
  alert('00:00:00 AM\nUser Name has paged you:\n\nMessage.');
  //-->
  </script>
  

  Firstly, you need to 'break out' of the javascript quotes. You have a couple of options, however you are restricted in that after your input, the WebBoard script will append the following text -

  ');
  //-->
  </script>
  

  You also have a one-line restriction (not a problem, since carriage returns are not normally significant in HTML) unless you want to see \n appearing left, right and centre.

  Suppose our goal should be to silently insert some code (ie: No errors should appear in the target's browser, and the page will still parse fine in as many browsers as possible). My solution negates the paging action (which you may or may not care to do), in addition to accomplishing this goal. The query follows...

  --> </script> contentgoeshere... <script> <!--

  This will generate HTML in the target user's browser like this -

  <script language="JavaScript">
  <!--
  alert('00:00:00 AM\nUser Name has paged you:\n\n-->
  </script> contentgoeshere... <script> <!--');
  //-->
  </script>
  

  Because the javascript statement is never finished, it is never executed. Furthermore, in my (limited) testing no error has been generated.

  
  Applications

  You can find out a lot of details about the target's host and network setup with the arbitrary insertion vulnerability.

  • Internet IP Address

    Easy to acheive, all you have to do is create a connection to a host that you control. For example, creating a 1x1 GIF89a image that is transparent and inserting an appropriate HTML <IMG SRC="http://your.server/file.gif"> tag would be a good start for auto image-loading browers. For others, a <SCRIPT SRC="http://your.server/file"> style script-request would probably do quite nicely. Note that this may be the IP address of a proxy server.

  • LAN IP Address

    Using javascript (such as that written by Richard M. Smith -- see link above) it is possible to request the host's IP address and have it delivered to you (eg: via email). Untested.

  • (False?) Domain Name

    This is the target's idea of its own hostname. Note that on Windows 9x (at least), and some linux distributions, inventing false domain names is encouraged/forced during default TCP/IP setup. Even if false, you still may value this name for guessing machine names for SMB-related attacks, however.

  • Remote Operating System

    Using javascript (such as that written by Richard M. Smith -- see link above) it is possible to request the host's OS and have it delivered to you (eg: via email). Untested.

    Also, you can find the OS from HTTP headers of induced requests to your own servers (see Internet IP Address, above) -- although this is often spoofed.

  • SMTP Gateway

    Using javascript (such as that written by Richard M. Smith -- see link above) it is possible to send email, thus deducing (from SMTP headers) the target's SMTP gateway address and software. Untested.

  
  

• Spamming

  It would be trivial for a spammer to write a script to extract email addresses from a WebBoard server. Luckily, WebBoard has a 'hide my email address' option in the user preferences.

  It is similarly trivial for a spammer to write a script to spam users of WebBoard via mass-paging.

Solutions

• In terms of unauthorised paging, something along these lines...

  if($targetuser[allowpaging] == TRUE) {
  page the user
  }
  else {
  display error
  }
  

  ... around the paging code in the pageuser program would fix the problem.

• The cause of the insertion problem was that the programmers did not follow the number one security rule -- deny all that you do not explicitly allow. Non-alphanumeric characters should all be denied, bar spaces and regular punctuation (which should be properly escaped).

• Spamming can't really be fixed -- it's a problem with the web model. Countermeasures such as maximum users' paged per IP per minute, and HTTP 1.1 source (referrer) verification could provide very basic protection. Their potential problems might outweigh their usefulness, though.

Conclusion

"Nothing opens the lines of communication like WebBoard. Since its first release, WebBoard from O'Reilly Software has promoted communication, information sharing, and the entire concept of electronic community. Now, with the release of WebBoard 4.0, communication has become easier than ever." - webboard.oreilly.com opening paragraph

I studied irony as part of my satire topic area for the HSC (end of high school assessments in NSW, Australia) this year. I was short of examples. Maybe if I hadn't let my schooling get in the way of my education, I might have had an extra one.

Sigh.