rec.autos.simulators

http://www.racesimcentral.net/
ad&BID=4&TID=4630&SID=27811

Thats shaun from Magnetic Fields.
(and yes, they want todo a new rally game)

For those who clicked on only the non wrapped part of the URL, they would
have ended up with a CGI script error page, detailing almost every aspect of
the Web Server's configuration. The page is yelling "come in and hack me"

Disgusting.

http://www.activescore.com/cgi-bin/rally/UltraBoard/UltraBoard.cgi?ac...

Either way, I'd KILL for Magnetic Fields to make a new rally game. I did
read that post a while ago though.. Heck, anyone could be making a rally
game right now and i'd be happy.

Mike
http://mikebeauchamp.com

The RallyX in LFS is very good, but its just a few corners, and not really a
rally stage. Oh how I wish there was a new rally Sim with the physics of
LFS.

Actually, If possible I'd prefer even better physics that LFS does for the
rallyX circuit. Whilst the physics on the sealed are brilliant, the car
handling on the AutoX circuit isn't quite as good. As someone else has
mentioned, there is no modelling of the effects of the tyres digging into
the dirt. This is very important when rallying, as it gives the tyres much
more grip when going sideways than in a straight line. This is why throwing
a car sideways on dirt is faster than taking a clean racing line.

err, no.

not really

90% of the info is available to anyone who knows
how http works.

A cracker you clearly are not :)

iksteh

">

Nope - I'm an IT Security architect and consultant. I design secure Internet
gateways.

As such, I'm looking at that page from a strategic perspective. One of the
fundementals of IT security is to publish the least amount of information
possible about your infrastructure. That page violates that structure by
publishing information regarding the directory structure etc, of the web
site. Of greater concern is the fact that this page is obviously designed
for internal troubleshooting purposes, and yet is being published
externally. That in itself is a cause for grave concern, as it indicates
that something has gone wrong in the design stage.

If something like this happened on projects that I'm involved with, heads
would roll. Maybe security isn't such a concern with these types of web
sites, and issues that I would consider to be of major concern aren't
considered as such by the administrators of that site.

This is the information you can get about the server from the error page.

DOCUMENT_ROOT      /www/activescore
GATEWAY_INTERFACE  CGI/1.1
PATH               /usr/local/bin:/usr/bin:/bin

SERVER_NAME        www.activescore.com
SERVER_SOFTWARE    Apache/1.3.26 (Unix) FrontPage/5.0.2.2510

This is not enough to even get /close/ 'hack' anything!!  In fact, most of
it you can find in other ways or simply guess (eg, their PATH is very
common).

The rest of the stuff is about the client or standard HTTP headers.

Don't get your knickers in a twist.

--
Joseph Birr-Pixton

I'm all for security through obsurity but 80% of that info
is sent by the client.  The rest are largely defaults and
the version of the bulletin board software is accessible from
the main interface.

As I said, the only risk posed by the actual information on
the page is the information about Frontpage extensions
available on the apache server.  The paths are default
n*x paths which could be found on any of 10 OS's and 100
different versions.

As for a "design phase error" - dependant on the application
it could as simple as removing the debug flag from a config
file or a one line change in the perl script.

Misconfigurations annoy me because of what they are - stupid
mistakes which shouldn't be made.  This could be as simple
as someone debugging some code and forgetting to reset the
flag.

I just think you are overestimating the damage that info
could be used to do, as well as underestimating how much
of that information would be readily available to any
technically savvy malicious user anyway.  You might stop the
script kiddies by hiding pages like this but IMHO security
resources are better spend hardening network infrastructure
and deploying good monitoring systems.  I agree that
needlessly giving away your network architecture is a
bad idea, but the error page hardly did that.

iksteh

Actually, yes it is.  Take it from a security professional, you don't want to be
advertising this kind of information about your server...

It's a UNIX box.  It's IP address is 216.71.52.165.
It has Frontpage extensions installed.  It's running an older version of
Apache which is vulnerable to several hacks.  It has Perl version 5.006.
It's document root is /www/activescore, which means for a directory
transversal attack I need to use ../../passwd and ../../shadow to get some
pertinent files...(if UltraBoard is vulnerable to those attacks, I don't have my
Bugtraq database readily available right now to take a look).

That kind of info you DON'T want to be releasing to the general public, although
some of that info can be had easily with a little 'snooping'...  ;]

The main problem is that if you have a properly configured IDS set up, the effort of
trying to "snoop" that information out of the server could be detected and stopped.
However, in this case, you've just made the attacker's job a whole lot easier...and the
sysad for this box never even knew it...

Cheers!

?? Jan Kohl ??
::: computer security consultant :::
the pits - http://www.theuspits.com
castle graphics - http://www.castlegraphics.com

You've made it easier yes, but most of what you mention is not exactly
tricky to find out is it ?.  "Terrible security flaw", no I don't
think so, unwise yes !.

Take care

S.

A new rally game will have the be the next coming of the messiah before I
buy it--IF it has shitty short invented stages that are always useless (and
you already know the titles I am referring to).

Marc

http://www.activescore.com/cgi-bin/rally/UltraBoard/UltraBoard.cgi?ac...