Wednesday 4 September 2013

Tutorial for Sentry MBA: the basics

This tutorial will describe the various options available in MBA settings frames. I will skip basic consideration, i.e. I assume the reader already has a basic knowledge about HTTP, proxies, headers, HTML and so on, i.e. concepts that a basic cracker should have.

In Sentry MBA in order to build a profile you need to configure 5 frames, all available from the Settings option located in the left bar:
- General Frame
- HTTP Header Frame
- Proxy Settings Frame
- Fake Settings Frame
- Keywords Frame
Moreover for form sites, you need to configure Post Wizard, that can be launched from the HTTP Header Frame,

General Frame



In this frame you can configure basic settings like timeout and combo filter options. No need to explain these ones, since they are pretty intuitive.

Snapshots
All the options except the ones relative to the general settings box are site based. i.e. they are saved in the site profile -> snapshot. The snapshot is a .ini files that contains all the site settings. Normally when you start a bruteforcer session against a site, if a snapshot exists for that site, you will be asked by MBA if you want to use the snapshot. If you reply "Yes", then the site will be bruteforced with the settings saved in the snapshot. If you reply "No", the current settings will be used, i.e. the one set by you in the various settings frames. At the end of the bruteforcer session, a snapshot with the settings used in the bruteforcer session will be saved by MBA. You can save also current settings to a snapshot by clicking on the button Save Snapshot. If you want to load a profile given to you, you must first load it by clicking on the button Load Snapshot. If for some reason you don't want to use the Snapshot system, you can disable it by unchecking the option Enable Snap Shots.

Image Database
MBA uses a custom database in order to OCR fixed captcha sites like StrongBox. This database is saved in the file imagedata.dat. You can update this database in two ways:
1) From images renamed to their captcha codes -> use the button "Update images database from directory".
2) From another database (it must comes from MBA of course) -> use the button "Update images database from file".

HTTP Header Frame
Here you select the method used by MBA to bruteforce the site.
For basic popup site you must set GET or HEAD.
For form sites you must set POST.



Basic sites
This is the difference between GET and HEAD:
- with GET the server sends Headers and Body.
- with HEAD the server sends only Headers.
Basic sites upon bad login attempts send a HTTP 401 code: take note that this code too can be associated with a not empty Body. So with HEAD method you don't have to receive this Body -> bruteforce speed will be then higher. However with HEAD method you cannot check Body on 200 codes and moreover some sites cannot be bruteforced with HEAD. So for basic site set GET unless you really know what you're doing.

Form sites
For form site, you will need to configure POST Wizard: POST Wizard can be launched by clicking on the magic wand icon that will become active when you set POST as bruteforcing method. From here you can set basic POST settings as well advanced settings like OCR settings, Ajax settings, Capture settings and Variables settings. Post Wizard options will not be discussed in this tutorial.

Proxy Settings Frame



Now i will discuss this one with greater detail since you really need to understand how MBA proxy engine works in order to get the maximum performance from MBA.
In MBA a proxy can have three status:
1) Active -> the proxy is being used by bruteforcer.
2) Disabled -> the proxy is not being used by the bruteforcer, but its status will be changed to Active when the number of active proxies becomes less than the number set in the box named "Reactivate All Proxies When Active Proxies Equals".
3) Banned -> the proxy is not being used by the bruteforcer and its status will be changed to Active only after Waiting Window activation IF the proxy has tested successfully at least one combo.

When a proxy is disabled?
A proxy is disabled when it generates a HTTP/socket error. A HTTP error can be a 404 - Not Found error or a 5xx error (server error) for example. A socket error is a TCP connection error like a connection refused or a connection timed out error (these errors are reported anyway as 404 errors even if they don't occur over HTTP). Moreover a proxy is disabled if it generates an error in the bot engine, like a 404 - Incomplete Form error or a 404 - Incomplete Source error.

When a proxy is banned?
A proxy can be banned for 3 reasons in MBA:
1) MBA recognizes the proxy as bad proxy, i.e. the proxy ignores the connection request to the site under attack and gives a fake answer.
2) MBA recognizes that the proxy has been banned by the site under attack: such proxy will be banned since it will not be able to authenticate successfully until it is unbanned by the site.
3) MBA recognizes the proxy as dead/too slow proxy.

Bad Proxies
The proxies in case 1) will be recognized as bad thanx to the AfterFingerPrinting engine: when after an attempt no keys are found on the answer (so the combo could be good or bad), MBA retries the same proxy with a random generated combo: if on the new answer a failure key is found, then the AfterFingerPrint succeded, otherwise the proxy is banned and the original combo is retried with another proxy.
Of course also proxies n case 2) will be banned by the AfterFingerPrinting engine, but case 2) proxies can be taken care of with good ban keys, avoiding the AfterFingerPrint engine activation. Other proxies recognized as bad proxies are the ones which return a 407 code, a 401 code on form sites, a 403 code or a 305 code.

Proxies banned by the site under attack
Proxies in case 2) as already said have to be recognized by configuring properly headers and/or source ban keys by analazying the responses given by the site upon banning an IP.

Dead Proxies
For each proxy in the list, MBA stores two numbers: the number of combo successfully tested (i.e. combo marked as bad, good, redirect or to check) and the number of retries.
Let's call the first number Combo_Tested and the second number Retries. First we must understand what a retry is. A proxy generates a retry for two reasons:
1) The proxy generates an error, i.e. one of the errors i mentioned when i talked about the proxies disabled.
2) The combo being tested by the proxy triggers a retry keyword match. As we'll see in the keywords section of this tutorial, we can have three types of retry keywords: Bad Proxy Reply, Bad OCR Code and finally Normal Retry. When you define a retry keyword (on header or source), by default the keyword is a Bad Proxy Reply retry keyword type, this means that when a match is found with such key, the retry is considered generated by a proxy error. An example of such rerty key would be "DNS Error". So when such retry is generated, it will increase the number Retries.
For each proxy MBA will compute the ratio:
Banned_Ratio = Retries/Combo_Tested
If this ratio becomes greater or equal than the ratio defined in the box "Ban the proxy if the ratio...", then the proxy will be banned.
Let's make an example:
We have a dead proxy which generates only 404 errors. We have set the ratio to 4. Now since for the proxy Combo_Tested = 0, Banned_Ratio would be inf. But MBA computes Banned_Ratio as Retries until Combo_Tested = 0, so when Retries = 4, the proxy will be banned. This means that all dead proxies you have in the list will be banned after they generated a number of retries equal to the set ratio. So after some time, the proxy list will be cleaned off, i.e. only alive proxies will be used.
Let's make another example:
we have an alive proxy for which Combo_Tested = 4 and Retries = 0. Now the proxy suddenly bans your ip and starts giving 403 codes. When the retries of the proxy will reach 16, the proxy will be banned, since 16/4 = 4, i.e. the ratio we set in this example.

Ok, now we know when a proxy is disabled and/or banned, so we can understand what each setting does.

Banning and Reactivation
Reactivate all proxies when...
This one let you reactivate all disabled proxies when the number of active proxies becomes less or equal than the number set here. Lower the number, greater the speed you'll reach, since MBA will keep active only the faster proxies. Anyway by configuring a number too low, you can cause proxies to be banned faster, since the fastest proxies will keep trying at increasing rate. On sites that ban proxies very quickly, you should set this number equal to zero: in this way proxies are not disabled and at each istant you will have the maximum number of active proxies. So the achieved speed will be lower, but the total combo tested will be greater.

Ban a proxy if the ratio between...
This is the ratio I talked about before. If you set this number equal to zero, you disable this feature, i.e. you will have a Sentry NO MBA behaviour; this means that the dead/too slow proxies will not be banned.
Update: I forgot to add that when this ratio is set to a number greater than zero, i.e. this function is enabled, then MBA for each proxy wait that the number of attempts becomes equal to this ratio. Only after this condition is met, then the proxy will be disabled if it generates an error. In this way MBA will reactivate only good proxies.

A proxy get a 404 - Timeout error and ratio is set to 4. For this proxy we have:
Combo_Tested = 0 and Retries = 1
Proxy will not be disabled since number of attempts = 1 (0+1).
Example:
A proxy get a 404 - Timeout error and ratio is set to 4. For this proxy we have:
Combo_Tested = 0 and Retries = 4
Proxy will be banned since number of attempts = 4 (0+4) and ratio is equal to the set one.
Example:
A proxy get a 404 - Timeout error and ratio is set to 4. For this proxy we have:
Combo_Tested = 3 and Retries = 1
Proxy will be disabled since number of attempts = 4 (3+1) and ratio is less than the set one.
So it's normal that at the start of a bruteforcing session, number of proxies disabled will be zero.

Ban a proxy if the number of combo tested...
Some sites upon banning a proxy, do not give a ban response: instead they give always a failure response regardless of the combo. Keeping active such proxies would mean marking good combo as bad. If we know for such sites number of the login attempts after which the proxy is banned, we should enter that number here.

Waiting Window
What can we do when all proxies are banned? Well most sites ban proxies for a certain amount of time, i.e. 5 minutes, 30 minutes, 1 hour...So if we test such sites and then set this time in waiting window,we can go out eating a pizza..meanwhile bruteforcing will proceed without user intervention. In fact, when all proxies are banned, waiting window will be activated: this means that MBA will wait amount of time set in Waiting Window before reactivating bruteforcing engine. Upon reactivation, if we have set correctly the waiting window time interval, most proxies will be unbanned and bruteforcing will resume at maximum speed. Take note that after the waiting window only proxies that have tested at least 1 combo will be unbanned, so dead and bad proxies will not be reactivated.

Banning Window
The Waiting Winodw is normally ativated only after all proxies have been banned. But in most cases, the last proxies that remain active in the bruteforcer are the slower ones, so this means two things:
1) The speed of the engine becomes really low.
2) It would take some time for these proxies to be banned.
So the waiting window activation would take some time in these cases and moreover the number of combo tested in this time would be really low. It is opportune then to ban all proxies in order to force waiting window activation. This is banning window purpouse. We have three settings and i think there's no need to explain them.

Fake Settings Frame



Enable Content-Length Checker...
Most proxies sometimes return an incomplete source, i.e. they don't send the whole html source requested as a consequence of a connection error. When we check the keys against such sources, it could happen that no keys are matched. This would cause activation of the AfterFingerPrinting engine. If in this engine stage the proxy is able to send correctly the requested source, the AfterFingerPrinting would complete successfully and the combo would be marked then as to check. But in such cases the combo is probably bad. So if we activate this option and set the length as the minimum length of the source against which a failure key would be matched for sure, we can avoid such false positives. In fact, by enabling this option, if no keys are found on the body recieved and the length of body is less than the one set in the option text box, a 404 - Incomplete Source error is issued, the proxy is disabled, and the combo retested with another proxy. But this option works really well also against error responses, which are tipically short in length.

Enable HTML Source Checker
This option, enabled by default, let MBA detect automatically if the proxy sent an incomplete HTML source. This one should be left always enabled.

Follow Redirects
When a HTTP redirect code (3xx) is found upon submitting login information (i.e. upon calling members URL for basic sites or upon posting for form sites), the redirect is followed depending on this option. If this option is disabled, the bot engine will process headers received in the redirect response, otherwise redirect will be followed and the bot engine will process headers and source received after the redirect has been followed. You must enable this option only if it is not possible to mark correctly combo being tested based only on the headers received together with the redirect code.

Ban Proxy when ...
Some sites upon banning a proxy keep sending empty HTML sources. Normally an empty HTML source disables a proxy. However in this case you would the proxy to be banned.

Enable After FingerPrinting
This option enables/disables the AfterFingerPrinting engine I already talked about in the previous section. The engine can be activated for both form sites and basic sites, however behavior is different in the two cases.

- For form sites the engine is activated upon receiving a 200 code or a 3xx code for which no source/header key match has been triggered. The bot then, without changing proxy, repeats authentication process from the start, but with a wrong combo, i.e. a randomly generated combo. If after testing this combo the bot successfully matches a failure key, then the engine terminates successfully -> if the original reply was a 200 code, the combo is added to the to check tab, if the original reply was a 3xx code, the combo is added to the redirect tab. Otherwise the combo goes in the fake tab, the proxy is banned and the original combo is retried with another proxy. Take note that for OCR sites the engine is automatically disabled, but this is not a problem, since a proxy that let you download the captcha image is able to correctly test the site. So in order to avoid false positives you need only to configure correctly ban keys: this can be easily accomplished by cheking received source of combo marked as to check.

- For basic sites the engine is activated upon receiving a 200 code or a 3xx code or a 403 code. The 403 code is validated too since some basic sites give this code when you authenticate with a shared login. In order to avoid a proxy ban in such cases, MBA validates the 403 code too with the AfterFingerPrinting engine. For basic sites the AfterFingerPrinting terminates successfully when upon logging with bad combo, the proxy receives a 401 code. But in order to defeat some protections that randomly give fakes, for basic sites we can set another parameter: "Assume Success when...". Let's call the value of this parameter TotalSuccess and let's suppose TotalSuccess=3. This is how AfterFingerPrinting for basic sites works:
1) Bot Sends Login information with tested combo and receives a 200 code -> first good answer -> activate AfterFingerPrint.
2) Bot Sends Login information with random combo and receives a 401 code -> second good answer -> we got 2 good answers, but we must get 3 (TotalSuccess=3), so continue the process.
3) Bot Sends Login information with tested combo and receives a 200 code -> third good answer -> we got 3 good answers, we must get 3 (TotalSuccess=3), so terminate successfully the process.
If TotalSuccess = 2, the engine would stop at step 2. So greater the value of TotalSuccess, greater the protection against fakes. Take note that you'll not risk to kill a combo since all attempts are done without changing the proxy.

Keywords Frame



This frame let you configure the keys that will checked against the site responses. 

When the keys are checked?
1) For basic sites the keys will be checked right after calling the members URL. If you selected the GET method, source and header keys will be checked. If you selected the HEAD method, only header keys will be checked since with HEAD method no body is sent by the server.
2) For form sites the keys will be checked after Posting and after calling the form redirect URL (take note that form redirect URL is optional). In post stage, both header and source keys will be checked; in form redirect stage only source keys will be checked since in this stage the bot automatically follows 3xx redirect codes, so it is possible to mark correctly the combo by using only source keys.

In which order the keys are checked?
MBA checks first header keys and then, if not match has been got on header keys, it checks source keys.
In order MBA checks Success, Ban, Failure and finally Retry keys.
- On a success match, the combo is marked as good, the result stored in the "Hit Tab", the hit is saved automatically in the history and finally the bot proxy switched.
- On a Ban match, the proxy is banned, the combo is retried and the bot proxy switched.
- On a Failure match, the combo is marked as bad and the bot proxy switched.
- On a Retry match, the combo is retried and the bot proxy switched. If the type of the retry key is Bad Proxy Reply, then the proxy that generated the retry is disabled.

What about advanced matching rules?

Basic Mode
Right click on a Keyword Box -> Select Add (Basic).
This is the basic way, you must set only the keyword. For example if you set "logoff" as success source key, then the combo being tested will be marked as a Hit if on the received Body the keyword checker will find the word logoff. The checker is not case sensitive, so logoff will match bot logoff and Logoff for example.

Advanced Mode


Right click on a Keyword Box -> Select Add (Advanced)
The keyword Wizard will be lauched. From here we can set advanced matching options. Let's explain first the options that can be used by all keys.

Two keywords match
You see form the screenshot that in wizard you can set two keywords. Second keyword is optional. However if you set both first and second key, a match will be generated only if both first key and second keys are matched.
Example:
First key: logoff
Second key: join
This advanced key will be matched only if on the answer both keys logoff and join will be present.

For each key we can define some special matching rule.

Not option
If this option is checked, then the relative key will generate a match only if the key is not found on the answer.
Example:
First key: logoff
Second key: join - Not option checked
This advanced key will be matched only if on the answer the key logoff is present and the key join is not present

Equal option
Equal: If this option checked, then the relative key will generate a match only if the received answer is equal to the key.
Example:
First key: OK - Equal option checked
Second key: empty (i.e. the key box is leaved blank)
This advanced key will be matched only if the answer is equal to the string OK, i.e. OK1 will not give a match. This option is useful to gain accuracy in keywords checking against ajax sites who give very short answers.

Not + Equal option
If both options are checked, then the advanced key will generate a match if the answer is different from the relative key.
Example:
First key: 0 - Not and Match options checked
Second key: empty
This advanced key will be matched only if the answer is different from 0, i.e. all the strings other than 0 will give a match.

Variables and Jolly Chars
Moreover for each key you can use jolly chars * and $. * will macth any string, while $ will match any not empty char.
For example l*off will match logoff, log off, light off and so on.
log$off will match log-off and log off, but not logoff.
Finally you can use <USER> and <PASS> for each key: this ones will be replaced with the username and the passwrod of the combo being tested.

Header Keys
For header keys, you can also define in which header the keyword will be checked. For example if you set the header to Location, then only the location header will be checked for keyword match.

Example:
First Key: member - header field set to Location
Second key: empty
This advanced key will match any header for which in location the key member is present, i.e. it will macth any HTTP redirect that relocates the client to an URL that contains the word member.

Example:
First Key: <USER> - header field set to Set-Cookie
Second key: empty
This advanced key will match any header for which a cookie is present with the username of the combo being tested in it.

Example:
First Key: 30$ - header field set to HTTP
Second key: 305 - Not Option checked - header field set to HTTP
This advanced key will match any header with a redirect code different from 305, i.e. this is the way in MBA to match a true redirect.

Example:
First key:

Code:
:$
- header field set to Set-Cookie
Second key: empty
This advanced key will match any header where there is a Set-Cookie field that starts with : followed by any not empty char. But since all Set-Cookie fields starts with : followed by something, this is the way to tell MBA to match any answer that set a cookie.

Retry Keys
Finally for retry keys we can set the retry type:
- Normal: when a Normal retry key is matched, the proxy for which the key has been matched will not be disabled.
- OCR: when an OCR retry key is matched, the proxy for which the key has been matched will not be disabled and the retry will update the OCR recognition rate.
- Bad Reply: when a Bad Reply retry key is matched, the proxy for which the key has been matched will be disabled.
Take note that all retry keys are by default of Bad Reply type. Moreover if you want an accurate measurement of OCR recognition rate when you're testing an OCR site, you must define the OCR retry key as Bad OCR Code.


Download Here

0 comments:

Post a Comment