How to defeat the following securities with Sentry
==================================================


Case Study 1:
=============


Simonscan (Special Thanks to R@nge) for supplying some L:P's :)
---------

How ironic.  The Script guarding this site, the sentry.cgi script, is the same name as the program
defeating it.

I thought I had this site figured out and then I realized the author of this site put some pretty
good protection in his basic authentication.  So I wrote this text file.

If we run this site like a normal site, with Debugger Info checked, we will get a flood of 200 responses.

When we analyze one of these responses, we see this:


-------------------- Header --------------------
HTTP/1.1 200 OK
Via: 1.1 TRANSCORENJ1
Connection: close
Content-Type: text/html
Date: Mon, 02 Jun 2003 15:33:22 GMT
Server: Apache/1.3.22 (Unix)  (Reliablehosting.com) PHP/4.2.2
WWW-Authenticate: Basic realm="Membership Required...."
X-Powered-By: PHP/4.2.2
-------------------- End Header --------------------


The site returned all 401's on our proxies.  Why the 200 responses?  The script this site uses detects we have
entered a wrong username and password and sends this fake 200 response.

But wait, how can a site have a popup login box but returned a 200 response?  The guy who wrote the security
for this site was smart.  He realized that all you need to do to emulate a basic authentication page is to
have the line: "WWW-Authenticate: Basic realm="Membership Required....""

The response returned doesn't match the normal RFC (401 Authentication Required) which throws most bruteforcing
programs off.

So you are probably thinking now what I was thinking when I first started analyzing this site.  Just launch
Sentry with the WWW-Authenticate: line as a failure header key phrase.  This seems logical, but does not work.

Upon further testing of this site, when the basic authentication is passed, if the HEAD request method is used,
a 403 response if given. So if you use the method above, you are looking for a 403 reply.

Since a 403 response won't find the key phrase specified, it may work when you launch it in your browser using
GET method.  This is not 100% reliable because proxies can still get a 403 response because they are banned, but
it is the fastest and only way to test this site reliably using HEAD request method.

So why did you get a 403 response when using the HEAD request method?  This is because the site only accepts
resquests which use the GET response.

When you use GET request method, you'll get a 302 which redirects you through a script and then to the member's
URL.

Conclusion: This is a site which is easiest tested using GET request method.  Define a keyphrase in the source, or
just use a custom response 302 = hit.

But until now, unless you knew a "trick", you couldn't test this site using HEAD, or atleast not the main member's
url using HEAD request method.  Now you can :)


Case Study 2:
=============


Pennywize
=========

Pennywize is a third party script used by many webmasters because they want their site to be protected against
crackers.  The script effective integrates, when setup right, into the server and controls access to its protected
site.  While controlling the access to the site, if it thinks the site is being abused, it uses a strong fake
protection to protect its sites.

Quote Pennywize.com: "Once installed, Pennywize will monitor every hit to your members section. If it notices that an account is logging too many hits from different IP addresses, it will disable the account and notify you by email of its actions. The threshold of IP addresses is completely configurable by you, and can be changed at any time by you."

Well now that we know and understand the protection the script offers, how do we defeat it?

I must admit, for $169.95/month (US), Pennywize offers very good protection.  Other crackers think so also, because
the question "How do I defeat Pennywize security?" is asked quite often.

When the script detects a banned IP or a login/password which has been abused, it redirects you to a webpage saying
protected by Pennywize, IP blocked, etc.  Actually, redirect is a bad word to use because the script really doesn't
officially redirect you.  The header returned when being forwarded to the Pennywize page is EXACTLY the same as a
successful login.  So then how does the Pennywize redirect us to the "http://www.pennywize.com/blocked.html" page?

Let's analyze some data:

---------- Begin Header Data ----------
HTTP/1.0 200 OK
Date: Tue, 03 Jun 2003 22:05:32 GMT
Server: Apache/1.3.22 (Unix)  (Reliablehosting.com) PHP/4.0.6
Content-Type: text/html
Age: 1
Via: HTTP/1.1 binss_inetcache (Traffic-Server/4.0.19-12362 [c sSf ])

---------- End Header Data ----------

---------- Begin Source ----------
<META HTTP-EQUIV="refresh" CONTENT="0; url=http://www.pennywize.com/blocked.html"><!-- Your username or IP has been permanently blocked.  All requests future requests will receive a '200 OK' response immediately until the block expires -->
---------- End Source ----------

As you can see, the Header Data returned is completely normal.  The problem lies within the source of the page
returned.  The line <META HTTP-EQUIV="refresh" CONTENT="0; url=http://www.pennywize.com/blocked.html"> means to
refresh our browser with the url "http://www.pennywize.com/blocked.html".

So what can we do to defeat this protection?  There are two options that work:

The Header Data is the same as a hit's Header Data so we can't use HEAD without recieving fakes.  So check the 
"Use GET instead of HEAD" option.  Ok,

1. We can analyze the source of the returned fake and pick out a Failure Key Phrase to use.  So we check the
   "Define Failure Key Phrase" option under GET Request Method panel and fill in a Key Phrase. Let's choose:
   "url=http://www.pennywize.com/blocked.html".  (Remove the quotes, they are just there for purpose of clarity
   in this document.)  Once that is done, we can now successfully run any Pennywize site without worrying about
   fakes.

2. Putting a valid fake into the HTTP Debugger we can successfully get the Byte Count returned by the fake reply.
   Once we have this information, we can check the "Assume fake when Content-Length is < x bytes.  The HTTP
   Debugger returned a Byte Count of 239, so 250 would be a safe value.  This method is not 100% accurate because
   a webmaster can easily make his member's page "Click Here To Enter" on a blank page and be under the byte count
   of our 250 bytes.  This is extremely rare but in theory can happen.



Case Study 3:
=============


meganqt.com
-----------

I saw on Soldier's Battlezone that someone was having problems with this site.  "Pennywize hell" was what I remember
hearing.  So, I thought this was a good chance to show Sentry's power.  I ran the site using Sentry, regular default 
options using HEAD request method.  Sure enough, I got a bunch of fakes leading to pennywize block sites, I let it 
run for about 12-15 hits and then aborted the test.  With the Debug option on, I was able to look at why I had fakes
and what I may be able to do about them.  Let's look at the Header Data returned on a few of them:


---------- Begin Header Data ----------
HTTP/1.1 200 OK
Date: Sat, 07 Jun 2003 06:43:20 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
Connection: close
Content-Type: text/html

---------- End Header Data ----------

---------- Begin Header Data ----------
HTTP/1.0 200 OK
Date: Sat, 07 Jun 2003 06:43:20 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
Last-Modified: Sat, 07 Jun 2003 06:33:08 GMT
ETag: "6a0b75-1e54-3ee18724"
Accept-Ranges: bytes
Content-Length: 7764
Content-Type: text/html
X-Cache: MISS from netmax.taxmax.net
Proxy-Connection: close

---------- End Header Data ----------

---------- Begin Header Data ----------
HTTP/1.1 200 OK
Date: Sat, 07 Jun 2003 06:37:41 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
Content-Type: text/html; charset=iso-8859-1
Age: 0
X-Cache: MISS from pantuflo.kristina.es
Connection: close

---------- End Header Data ----------

---------- Begin Header Data ----------
HTTP/1.1 200 OK
Via: 1.1 PROXY
Connection: close
Content-Type: text/html
Date: Sat, 07 Jun 2003 06:44:09 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b

---------- End Header Data ----------

---------- Begin Header Data ----------
HTTP/1.1 200 OK
Via: 1.1 SERVER-LANZA
Connection: close
Content-Length: 7764
Content-Type: text/html
Date: Sat, 07 Jun 2003 06:44:26 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
Last-Modified: Sat, 07 Jun 2003 06:33:08 GMT
ETag: "6a0b75-1e54-3ee18724"
Accept-Ranges: bytes

---------- End Header Data ----------

---------- Begin Header Data ----------
HTTP/1.0 200 OK
Via: 1.0 MAILSERVER
Content-Type: text/html
Date: Sat, 07 Jun 2003 06:44:28 GMT
Server: Apache/1.3.22 (Unix)  (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b

---------- End Header Data ----------


After a close examination, you can clearly see that some Header Datas are more detailed than others.  For example, two
of the returned Headers had the line Content-Length, Last-Modified, and ETag.  Manually checking these two combos, they
really were hits.  When we check some of the other combos which returned the smaller Header, we are sent to a fake
page.  So what can we do to prevent fakes from this site?

The option Recieved Header Key Phrases -> Define Success Key Phrases can now be checked.  We know a Header Key Phrase
we can use to determine if we got a hit or not.  We also know a Failure Key Phrase, we know that all bad responses
always have a 401 reply code.  Add a Success Key Phrase as "ETag" and a Failure Key Phrase as " 401" (reason for the
space before the "4" is because we don't want to mix the HTTP Response up with another number returned from the server.
There are none in this example but there could be in others.)

Ok, now we have a Failure Key Phrase checked and one is added, and Success Key Phrase checked and one is added.  We
are now ready to run the test.

After the test finished, you should not have one fake reply and only hits to a once "tough" site.



Final Notes / Conclusion
========================

These three examples are how I want crackers to think when using Sentry.  I know this tool can be used if you like
to push buttons and think you are cracking, but please put some thought into what you are actually trying to
accomplish and you should be able to really see the potential Sentry's flexible fake protection can do.

I wrote this text because if this text wasn't written, few people would understand how to use this tool effectively.
This is the first completely customizable fake engine ever written.  Take full advantage of the Debug option and your
mind and you'll become successful.

Have fun and thanks for using my program.

Sentinel