(EN) Adaptive(& Unconventional) Penetration Testing: The FLAW HIPHOTESYS

In @HabemusCurso in training Corporate Audit and more, specifically in Adaptive and Unconventional Penetration Testing, we are Teaching, The Flaw Hypothesis Methodology, which in my case was learned in the Master Security two years that I sucked me out of Spain then.


What is shown here is a Penetration Test UNCONVENTIONAL environments UNCONVENTIONAL and Report.

The data have been modified, but is based on a real report, so that the whole process is displayed and how this methodology is used in environments *** ****

Out of respect for  @HabemusCurso students's  what you will see is not whole as they have paid to be taught, among other things, this methodology does not know or know many people develop ...

Only I present here Hypothesis 1, that exist in this particular test and development only a small part exploitable using frute force

The report is very wide, and is in English and in Spanish, but obviously I hope you to understand, people have paid for this metodology and I can not show more than what we see. This is 0,1 a  of the total Report

The principle would be the covers and the beginning index (which I have not put), Version Control and other 'stuff' that should go in a report addressed to Engineering Level Security Managers and Customer, where we all have the same point view, Common Criteria Security

_______________________________________________________________________________________________________________________________________________________

DOCUMENTO TÉCNICO

TECHNICAL DOCUMENT

Documento nº/Document no.	Objetivo/Target
25/03/15	SECRET

Realizado/Prepared	Nombre/Name
Firma/Signature	Juan Carlos García

Empleo/Employ	Adaptive Penetration Tester
Cargo/Position	Principal Adaptive Penetration Tester

Comprobado/Checked	Juan Carlos García
Aprobado/Approved	Juan Carlos García

Fecha 1ª edición 1stissue date	25/03/15
Clas. Acceso Access class.	Secret For Your Eyes HabemusCurso Secret Unconventional Documents

Revisión/ Revision	Motivo de Modificación/ Change reason	Realiz./ Prep.	Compr./ Check.	Aprobado/ Appr.
Fecha/ Date	Capítulos, Secciones, Hojas afectadas/ Chapters, Sections, Sheets affected	Firma/ Sign.	Firma/ Sign.	Firma/ Sign.
A	Primera Edición /First Issue	Ver Portada/ See Cover	Ver Portada/ See Cover	Ver Portada/ See Cover

EDICIÓN ACTUAL DE PÁGINAS/CURRENT PAGES ISSUE

NºPag./ PageNº

Edic/Issue

NºPág./ PageNº

Edic/Issue

NºPg/ PageNº

Edi/Issue

Nº Pág./ Page Nº

Edi./Issue

NºPág./ PageN

Edic/Issue

NºPág./ PageNº

Edi/ Issue

Palabras clave/Keywords

Todas las palabras de seguridad que sean útiles para el entendimiento del Informe....

Informe: Altamente técnico ( Common Criteria )

Nivel /Level: Ingeniería

Resumen/Summary

Test De Penetración a xxxxxxxx por xxxxxx para xxxxxxx por xxxxxxx y verificando que xxxxxxxxxxxx

LIST OF FIGURES

Title Page

Figure 1: aaaaaaaa …................................................................................................................. 4

LIST OF TABLES

Title Page

Table 1: ccccccccccc................................................................................................................... 5

1. Flaw hypothesis Methodology

The evaluator team has hypothesized flaws. Such hypothesis has been based in the most of the cases from the point of view of an external attacker.

For checking if the hypothesis are true, penetration testing has been devised to the system.

Due to schedule issues, some flaw hypotheses have not been completely checked.

For such hypothesis, the evaluator team has specified which kind of vulnerabilities could be found and that these hypotheses should be checked in the future. In any case, procedures for remediate the flaw if the hypothesis is true is given.

1. Information gathering

The equipment under evaluation consists of a Windows 2000 server, which is onboard of ****** *******

This equipment is not connected to the internet, so attacks can only be devised from the local network. The station is located in the ****** ******* and a graphic interface is not available for the users, due to that, local attacks are not being considered.

The software running in the station and that can be considered attack paths are the services that open ports to communicate with the rest of the systems.

Of all the ports open, only will be considered those accessible from the nets that are accessible for a possible attacker (*********************).

The services running in the station can be categorized as follow:

· Microsoft Services: services provided by Windows 2000 server.

· Product services: services provided by known products (Oracle, TFTP32 …).

· Ad-hoc services: services created by the developer (Rockwell collins).

Fingerprinting and attack techniques that apply to each category are different.

The major differences can be found at ad-hoc services. For those services third-party studies does not exist, so the attacker should evaluate them from scratch.

From our point of view the ad-hoc services behave as a black box.

A complete vulnerability analysis with some success probability would require a lot of time. For schedule issues the evaluator team has left out this kind of attacks in the penetration testing.

For checking which services where running in the station, Shadow Security Scanner and nMap was used.

After the execution of the tools the next services were discovered: FTP, DNS, HTTP, Kerberos, Microsoft EPMAP, NetBIOS, LDAP, Microsoft-DS Active Directory, SQL.MiniSql, Oracle database, Microsoft Global Catalog, Microsoft Terminal Server y TFTP.

Other ports were open some could be traced back to ad-hoc applications checking that point in the attacked station (White box technique). But other ports couldn’t be traced back to processes in the station.

2. Flaw Hypothesis

Based on the information obtained in the previous step, and in combination with the knowledge of vulnerabilities in other similar systems, the evaluators hypothesize vulnerabilities in the studied system.

The flaw hypotheses created by the evaluator team are:

· Hypothesis 1: The Windows 2000 services are vulnerable because the operative system is not maintained by the developer.

· Hypothesis 2: The installed products are not under the current versión, so they have vulnerabilities.

· Hypothesis 3: The ad-hoc services are not exposed to public testing and have not been evaluated, so they have vulnerabilities.

· Hypothesis 4: There are ports which mapping to processes is not clear, so they are open by malicious logic.

· Hypothesis 5: the password strength is not strong enough. This lead to a possible authentication direct attack by attackers.

3. Flaw testing

The evaluator test team their hypothesized flaws.

If a flaw does not exist (or cannot be exploited), the testers go back to step 2.

If the flaw is exploited, they proceed to the next step.

For execute the flaw testing the evaluators used Shadow Security Scanner, Metaexploit toolkit and hping3 to attack the discovered services in order to check the specified hypothesis.

For checking of public vulnerabilities for known services, the tool Shadow Security Scanner is used that is able to detect the vulnerabilities in the system as well as suggest mitigations.

The services that had known vulnerabilities and such vulnerabilities are covered by the metaexploit toolkit database, were tested with the tool.

Also, for some services less common (as TFTP), ad-hoc penetration testing was execute with the tool hping3.

From the flaw hypothesis point of view, the obtained results are as follows:

Hypothesis 1: The attacked Windows 2000 services have provided the usernames of available in the system.

On the other hand, several active services require authentication.

It is possible that such authentication mechanisms do not have delay/retry restrictions specified in the strength of

mechanism documentation.

Due to that fact, it is possible that an attacker could access the system whit an attack potential lower than the specified in the security target.

An user with the intention of escalate privileges and in that way bypassing the “need to know” policy, could have the advantage of know the kind of keys generated by HP protect tools (pronounceable passwords).

Hypothesis 2 The Penetration Testing...

Hypothesis 3

Hypothesis 4

Hypothesis 5

4. Flaw generalization

All the found vulnerabilities have in common its attack path, the TCP/UDP protocols.

So flaws could be generalized to applications with open ports, but this deduction is the one stated at the beginning of the evaluation.

On the other hand a buffer overflow has been found in the TFTP service.

This vulnerability could be extrapolated to the ad-hoc services, but exhaustive evaluation of such services is out of the scope of this evaluation

Strength of mechanism (HPPT)

The FTP protocol does not provide delay or password attempts limit in its authentication mechanism.

It is possible that this authentication is vulnerable to a direct attack (brute force).

In this section, an estimation of the average and maximum time to find the administration key is given.

The passwords generated by HP Protect Tools adhere to the next language:

· S -> CVC | CVCS | NN | N | λ

· N -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 (10 terminal symbols)

· V -> a | e | i | o | u (5 terminal symbols)

· C -> b | c | d | f | g | h | j | k | l | m | n | p | q | r | s | t | v | w | x | y | z 

   (21 terminal symbols)

Where S is the initial symbol.

An attacker would have in mind that due to security policies, the passwords should have a minimum length.

At the same time and complying with the security principle “Physiological acceptability” the password should not be too long, in such way that the users should write down the passwords in an insecure media.

In case that the attacker was a system user that knows the key generation policy, he would know the exact password length.

Due to the stated in the previous paragraphs, the assumption that all passwords contain eight characters will be done.

The previously stated language is reduced to the next specification:

· S -> CVCCVCNN

· N -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 (10 terminal symbols)

· V -> a | e | i | o | u (5 terminal symbols)

· C -> b | c | d | f | g | h | j | k | l | m | n | p | q | r | s | t | v | w | x | y | z

 (21 terminal symbols)

The number of elements that can be derived from this language is:

21 *5 *21 *21 *5* 21*1 0* 10 = 486202500

Accepting that each terminal symbols derived from C have the same probability of being generated (1/21) and that all the terminal symbols derived from V have the same probability of being generates (1/5)(, the language entropy is:

H (S) = log₂ (486202500) = 28.856982

The probability of hit the key with an unique try would be:

1/486202500

For find the key, in the average case, 486202500/2 = 243101250 tries are needed.

In the worst case scenario, 486202500 are needed.

To know the needed time to complete the attack, it should be checked the time needed by TFTP to generate a response.

Taking into account that the attack is deployed in the local network, a big delay is no expected. Computational time spent by the service should be added to the network delay.

It will be theorized that the total response time is 10ms = 10^-3 sec.

With this variables the needed time for deploy the attack is as follows:

· Average = 243101250  * 10^-3 =  243101,25 seg  =  4051,68 min  =  67,52 h  = 2,81 days

· maximum = 486202500  * 10^-3 = 4 86202,5 seg =  8103,36 min = 135,04 h =  5,62 days

Take into account for the measure of the attack potential that the brute force attack does not need to be executed in only one session.

It could be paused an resumed depending upon the attacker restrictions.

Etc 

Etc

Etc

Lo Prometido es Deuda !! Deuda Saldada !! :-) ;)

Juan Carlos García @secnight