Re: [PEN-TEST] HTML source code and authentication

[Chris Tobkin <tobkin () INTERSEC COM>]

> > #<form name="signon" action="/scripts/ibank.dll" method=post>
> First off, try accessing site/scripts/ and site/scripts/ibank.dll
> See if any interesting error messages are generated.

Also look into the type of web server that is being used.  Knowing how
ibank.dll works would help a potential attacker enormously.  See if you
can do neat things like ::$DATA and "." or "%20" appendings to download
the file.  By drawing some loose guesses, I'd guess "ibank" stands for
something like "Internet Banking".  Look at the rest of the site and find
out what you can about the use of this .dll.

> > #<INPUT TYPE ="HIDDEN" NAME=Func VALUE="SignOn">
> Hidden fields, as a general note, are begging for a tweak.
> Play around with the site, see what other types of "Func" values
> are there. Maybe you can disconnect other users with LogOff,
> or find a function that will let you "update your details" without
> authentication.

Looks like a placeholder for where in the process of things you are.
If you can get into the application legitimately or into a demo version,
check out what the Funky values the "Func" field has assigned to it in
other parts of the application.  If one has a value that's used only
halfway through, you may be able to jump directly in without any
authentication.

> > #<INPUT TYPE ="HIDDEN" NAME=homepath VALUE="cu3">
> Hmmm, this could be interesting. "cu3" might be some directory
> on the server, or the directory you came from, or any other
> number of related paths. How about changing it to "/" or "..",
> or just "cu2" and see if the error message gives out more
> information.

Assuming my "Internet Banking" thing is true, this may be "Credit Union #3",
so changing this may get you a completely different system or database
altogether.

> > It leaves me wondering if the referenced ibank.dll file is some
> > authentication program of some sort
> Very probably so. This dll is used to analyze the results of your
> POST command. It probably access Username/Password of some
> sort and checks if your data matches anything.
>
> > and if the availability of this
> > information simply by clicking on 'view source' is a
> > potential problem.
> Not as such. The dll will probably show up in the next URL, after you'll
> click SUBMIT, but the Hidden Fields are Bad Thing (tm).

Agreed.  User-submitted fields (including Hidden fields) should never be
treated as non-tampered or trusted.  If you stop to read the RFC's on the
HTTP protocol, you can simulate the web browser posting to the website with
just a normal telnet client -- and an SSL encrypted request with a quick
compilation of OpenSSL (s_client) or stunnel.

> > Furthermore, is there a way to obscure this information if it is risk?
> Sure. Don't use Hidden Fields, make sure you've got the right access
> controls to the /scripts directory and the ibank.dll file.

Or simply take advantage of the server's scripting engine's session state
saving piece.  PHP, ASP, and othes have it.  In perl, I've written it into a
small hash file for low traffic sites, or a basic, indexed table in Oracle
for higher traffic sites.

// Chris
tobkin () intersec com