Friday, March 2, 2018

Attack Execution-Business Logic
Image associée

Attacking business logic is one of the methods used to compromise a web application noting that discovering a logical flaw is a hard task because this kind of flaws does not have a specific signature as other types of vulnerabilities and it can be totally different from one application to another but attacker can try a set of possible vulnerabilities that might exist in the probed application.

1- Encrypt and disclose the key: Using the same encryption for two pair of information one is visible and the other is not. An example about that might appear in (remember me) functionality where the developer implements the same encryption key for a cookie containing session ID information and what is called screen name (the user name shown on screen). 
The main problem in the logic is that the attacker can tamper and replay what is encrypted and protected. This actually is not the problem of weak encryption but the usage of the same key with value that is visible (the screen name) which makes it easy for attacker to predict the used key and unlock the encryption of the Session ID information.   

2- Overloading dual privileges: Implementing an overloaded method for password change for administrators and normal users depending on the existence of the (old password parameter) which gives the attacker the ability to use non valid parameter list to be routed to administrator’s version.

3- Multistage manipulation: Sometimes the developer makes a bad assumption that user will follow all steps in a multistage task in the right sequence but this is not always the case as an attacker can manipulate the client to avoid passing through a specific stage which will cause sometimes a great damage.an example about this attack is manipulating a sequence parameter that hold the current stage in purchasing multistage task to purchase a digital content without passing in payment phase. 

4- Overlapped checks: Another case is the case where the business logic does not consider out of band inputs for all methods related to same input. an example is a banking web application containing transfer method dedicated to do the transfer and a pre-check method to restrict transfers for amounts higher than (10,000$) and route such transfers to be approved by senior manager. The pre-checked method considers only the check for a number higher than 10,000$ so the flaw was that even a negative number will pass through that test and the negative value will go directly to the transfer method that takes the absolute value of the number so if somebody tries to transfer (-900,0000$) the transfer will be authorized with no senior manager review. 

5- Bulk but for a while: A scenario where attacker can get benefit from bulk purchase then purchase only one item is also a flaw based on the assumption that the user will send the full list of purchased product after getting the discount. 

6- Forgotten escape: this attack is based on the assumption that a sanitization method is available and will prevent all malicious characters that might cause a problem but the developer forgot the escape which itself does not represent a problem but escaping the escape by the mean of disable the sanitization functionality. An example is the usage of an input like ( whatever \;ls ) in this case the sanitization will turn the clean input to poisoned one ( whatever \\;ls ) which will reactivate the semicolon malicious effect. 

7- Defence+Defence=? : sometimes the intersection of two defense mechanisms can be used by the attacker to initiate a successful attack. An example is the usage of an extra single quotation mark to escape a single quotation mark as a defense mechanism to prevent SQL injection, and truncation length limiter mechanism for input as a second mechanism to minimize the ability to enter unexpected amount of entry. The flaw resides in the usage of the second mechanism by the attacker to break the first. 

if the user login query was:

Select * from users where username=’user name’ and password=’password’;

Now if the attacker provides the a user name containing ( xxxxxxx….xxxx’) where 127(x) character is there and a password ( or 1=1--) the resulting query

Select * from users where username=’xxxx..xxx’’and password=’ or 1=1--’; 

Will break the login functionality as the extra added quotation by the first mechanism will be truncated by the second. 

8- Race condition: in the case of race condition the vulnerability appears only for a short period of time, it is hard to detect and reproduce, but it can open a door wildly if exploited. an example is the case of login function that mistakenly stores part of session information as a static information that are used as an identifier in other functionalities so if two users use the login functionality exactly in the same time there is a big chance that they can reach the functionalities that uses the static identifier. 
   
Authorization and Attack Execution-data stores
Résultat de recherche d'images pour "‫عملية ااختراق‬‎"

Authorization the process of giving someone permission to do or have something it defines how access is controlled in the context of what is access by whom. In authorization we can talk about three types of authorities: 

1- Vertical authority: it is about the level of access to specific functionality set for each type of users an example is the difference in authority between administrator and a normal user. 
2- Horizontal authority: this type of authority is about controlling the access in the same functionality, as example having the authority to access the web mail functionality does not mean ability to access any email account. 
3- Contextual authority: this type of authority is related to current application state which can be explained in the perspective of multistage process where available functionalities are specified according to present state. 

attacking those concentrate accordingly on breaking the access control using three methods: 
  •  Vertical privilege escalation: The focus in this method is to gain higher level of access related to more privileged type of users. 
  •  Horizontal privileges escalation: tries to compromise resources to which he is not entitled. For example, in web mail application to read other people’s e-mail 
  •  Business logic exploitation tries to exploit a flaw in the application’s state machine to have access to an important resource. For example, a user may be able to bypass the payment step in a shopping checkout sequence.  

Attack requirement: 

A. Different privileges to different users on functionalities 
B. Different privileges to different users on resources. 
C. Privileged user used functionalities are in the same application containing configuration and motoring it 

Attack Process: 

A. Configure Burp as a proxy and disable interception, browse all the application’s content within one user context. If the target is to test vertical access controls higher privileges account should be used. 

B. Be sure to map all functionalities by checking Burp’s site map. 

C. use the context menu to select the “compare site maps” feature. 

D. To select the second site map to be compared, you can either load this from a Burp state file or have Burp dynamically re-request the first site map in a new session context. 

E. To test horizontal access controls between users of the same type, you can simply load a state file you saved earlier, having mapped the application as a different user. For testing vertical access controls, it is preferable to re-request the high-privilege site map as a low-privileged user, because this ensures complete coverage of the relevant functionality.

 F. To re-request the first site map in a different session, you need to configure Burp’s session-handling functionality with the details of the low-privilege user sessin (for example, by recording a login macro or providing a specific cookie to be used in requests 

G. It is necessary that define suitable scope rules to prevent Burp from requesting any logout function.

Data storage is one of the main components of most of web applications, it contains the information about the key business functionalities in addition to users account information which makes it a delicious meal for an attacker. Data storages have many types that rely on multiple technologies, it can be as simple as plain text file or sophisticated Data base management system like Oracle.

No matter what used Data stores are it can become vulnerable if the attacker finds a way to interface the data store through the application functionalities or being able to access it directly in case of Data remote access availability. Injection is one of the common types of attacks that commonly executed to compromise data stores, it generally depends on the nature of interpreted languages characterized by parsing and executing instructions in the run time. PHP, Perl, SQL and LDAP are well-known examples of interpreted languages used in web application development. 

The main idea that helps in compromising interpreted language is being able to inject special characters or instruction that have grammar match in the language syntax. 

The following listing a simple SQL syntax that retrieve user records that has a matching user name and password to those entered in quotations. 

Select * from users where username = ‘usrName’ and password = ‘pass’   

If the application that include this syntax is vulnerable to injection by mean of absence of sanitization functionality for entered values, the attacker will be able to enter the value of ( admin’- - ) in the user name and any password to gain administrator account privileges as the resulting code that is going to be executed by the interpreter is:

Select * from users where username = ‘admin’- -‘ and password = ‘anyPass’   

The (- -) is the special syntax to begin comment in SQL, which means that the interpreter will ignore everything after (--) and will retrieve the admin record.
 
Password management exploit
Image associée

In many situation developers do not focus on protecting privileged pages from privileged users so the mistakes that are covered in main login page reappear in the change password, forget password or remember me option.

Mistakes like allowing unlimited number of false login, providing different message depending on bad or valid password and checking the validity of password before matching with new password. 

Another issue raise when dealing with Forgotten password, a weak method might lead to use challenge questions that are much more easier to break, like pet name or first name for mother..etc. Another source of danger as mentioned is the option of remembering the password which can be reflected using cookie based approach through non encrypted or weak encryption that might allow the attacker to understand the identifier used and generate similar one. 

Attack requirement: 

A. No or weak locking policy 
B. Verbos messages for false and valid login 
C. Storing password locally through weak identifier 

Attack process: 

A. For change and forgot password process is totally similar to brute force process 
B. As for the password remember option user should check for cookies and any stored non encrypted or weakly encrypted value or identifier by capturing and examining the sent request after activating remember me option using a tool Like Burp proxy. 
C. If the identifier can be easily generated, generate different identifiers and iteratively check if this will allow compromising other accounts using Burp to achieve that.  

Impersonation Functionality


In many cases, application implements an impersonation functionality in order to be able to control a user account by a privileged person in the organization.an example is the case of a bank customer account and an account supervisor where the supervisor has the privilege to access the customer account and execute tasks on his behalf. The main issue related to impersonation that the functionality is treated as hidden functionality with minimal control over access or as a back door that can be accessed through simple password.

Attack requirement: 

A. The impersonation functionality is using a back door or hidden functionality 
B. Minimal control on the access through that functionality (vulnerable to brute force or bad password)  

Attack process: 

Use the same process applied in brute force attack or bad password depending on the case 

Other issues

Other issues related password might be things like vulnerabilities caused by inefficient handling of errors in login process or multistage login. The storage of non-encrypted password values might also represent a serious problem which makes the usage of MD5 or SH1 necessary to eliminate such threat.

Web application Authentication methods
Résultat de recherche d'images pour "Web application Authentication methods"

Authentication as mentioned earlier is the process or action of proving or showing something to be true, genuine, or valid Authentication in web application is done through different methods the most common are:

  •  HTML Form based authentication: this is the most common method to apply authentication in a web application. The used credentials are mostly the user name and a password but sometimes in critical application extra credentials are applied like the usage of special pin code or a key generate by one time password device. 
  •  Other methods might be depending on HTTP based basic or digest authentication where HTTP basic sends credentials encoded unencrypted with base64 encoding in time where digest method uses hash function to encrypt credentials and nonce value from the server this is why basic HTTP authentication should be used only if the channel is secure with   (Https). Those methods is usually used on local networks not on the internet.
  • Client SSL certificate with or without a smart card but this can represent a distribution problem 
  •  Some application uses Windows-integrated authentication using NTLM or Kerberos and authentication services like windows passport.  

Attack bad passwords

Not having a special password complexity enforcement functionality can make attacking through the password very easy as many password are predictable or could be a common dictionary word or even empty or has the same username value.
 Some users tend to leave the default or preconfigured password which makes the attack much easier.

Attack requirement:

 Week or no password

Attack Process

a- Try empty and default values for password.
b- Try common dictionary password.
c- If you own an account or self registered try short passwords, user name like passwords to check if that is permitted to disclose the password rules 

Brute force attack

Leaving login process to be repeated unconditionally will make authentication vulnerable to brute force attack which will end in braking authentication with the speed that a penetration system can iteratively try different possible passwords.

Attack requirement:

A. No or client side only check for number of login fails.
B. Not very gonium powerful password.
C. If a self-registering account Is available better to create an account. 
 

Attack process: 

A. Before going directly to automate the attack explore the locking policy manually beginning by trying at least (10) bad password values on the same account, check any messages and accessibility of the account with the right password. 
B. If the account was locked, try to monitor any cookie to discover it the locking is based on client side information that you can manipulate. 
C. See if the system allows you to login with right user name and password, if yes you can keep guessing. 
D. Monitor to find any difference in response between bad login and successful one to depend on when start in automated phase. A Burp comparer tool can provide a good way to do that  
E. Use an automation tool to iteratively try different user names and password. (Burp is an example) 
F. Monitor results and collect broken account information. 
G. Different messages can be a very good pointer that you did a bad guess the user name only or both credentials. 
intercepting messages from Flash, Java applet and Silverlight
Résultat de recherche d'images pour "Java applet and Silverlight"

Browser extension that technologies permit the execution of a code in a sandbox, It was used originally to provide simple improving on the presentation of the web application like creating animation or vivid contents , with much of flexibility and power these technologies provide developers used it to create full component and applications.

After all those components are used in the web pages and need to interact using the web protocols so exchanged information are transmitted over Http and usually in objects or complex structures. Attacker can compromise the messages exchanged with those extensions and refactor it. 

Main target of the attack is to initiate attacks like SQL injection, buffer overflow or manipulate parameters to have application related gain. Attack requirement 
  •  Extension interacts with server through Http
  •  No special encryption is used to preserve messages confidentiality. 

Attack process

1. Capture the request initiated by the page using a proxy like Burp.
2. Depending on the type of extension use the right deciphering method to unpack the message sent.

  •  Java applets use Java serialization which can be deciphered using aplugin on Burp (JDSer).
  •  As for Flash it normally uses (AMF Action Message Format) whichis supported by default by Burp.
  •  Silver light uses (WFC windows communications foundation) andSOAP (NBFS) message format that can be deciphered using a plugin named (WCF Binary Soap Plug-In) by (labs@gdssecurity.com)

3. A special tab will show the object content sent in the ciphered message.
4. Alter the message as requested and forward the request.
5. Capture the response and see deciphered contents. 
  

Decompile Flash, Java applet and Silverlight

  This attack depends on disclosing the business logic executed in a browser extension like Java applet, Flash or Silverlight component Java applets and SWF file contains bytecode that can be decompiled to recover the original source through tools like JAD for java applet, Flare for flash and Telerik Just Decompiler for Silverlight XAP files. (software are available in supplementary materials)

Attack requirement 

  •  Targeted functionality fully executed on the client side. 
  •  Low complexity of application bytecode. 

Attack process

 1. use Flare, JAD or Telerik decompiler depending on the type of component. The result will be ActionScript source for Flare or Java for JAD. 
2. review the source to identify any attack points that will enable you to reengineer the Flash object and bypass any controls implemented within it. 
3. modify the decompiled source to change the behavior of the applet, recompile it to bytecode, and modify the source code of the HTML page to load the modified applet in place of the original. 
Attack Execution the client

Image associée


1 Attack the client

If the mapping and analysis level showed flaws on the client side it will be a good idea to begin there. The client (browser) is easily reachable by attacker and can be compromise and manipulated to initiate a full attack or partial attack as base for other types of attacks.
Due to the many types of possible client attacks the coming parts will explain some possible attack execution scenario on client and examples about each type.

2 Two types of attacks  

  No matter what technologies are used in attacking client side, all attacks will take one of two main types: Exploits and Trickery. 
In Exploit attacks a malicious code is executed on the client side and its host due to resident vulnerability and of course the countermeasure can simply be getting rid of that exploited vulnerability, from the other hand the trickery attacks are based on behavior of human operator after getting seduced by an attractive message or offer to make action that disclose important information or be used to access the information or allow the attacker to install a software that can be used later to extract data from client machine

3 Flash Cookies (LSO)


Flash uses what is called Flash Cookies for client-side storage which Is a text file with the extension (.lso) being able to access and manipulate this file will give the ability to change the behavior of the flash object.

Attack requirement:
A. Being able to access the LSO file
B. No validation for data retrieved from the LSO files stored on the client. 

Attack process
A. Access the LSO file.
B. Use the LSO editor to change an invalidated value that might give higher
privileges 

Example: 
This example will allow the attacker to get higher discount rate on a purchase done through a flash object.   

A. Locate the LSO file.
B. Use LSO editor to change the discount value
C. As soon as the flash object retrieve the local storage from the lso file it will apply the new discount rate if no validation where done by the server. 














Attack analyzing

Image associée

 Attack analyzing stage 


Benefiting enumerated information to specify the attack surface and going through a full feasibility study to decide if the resources including information and time required to execute the attack are in hand and serve the main attack purpose. 

Analyzing and understanding the meaning behind the collected information is essential to be able to move on to execution stage. The main purpose of analyzing stage is to:  
  •  Specify attack surface: figuring what are possible scenarios to execute the attack and compromise the application
  •  Specify the feasibility of each scenario from resource and time point of view 


Attack analyzing – Specify attack surface 

With lot of information attacker should know exactly where to begin from, the experience is essential in this level and can save lot of time. The number of attack points can be very big, so the following is a good practical check list to begin from to extract the attack scenarios list:

  •  Client side validation: a fast and good place to begin from is specifying if the input validation is done on client, server or both sides.an easy entry might be related to a client side only input validation
  • Search collected information for any sign of possible SQL injection, Database issue, root database account or any code or discovered comment that might give partial or full access to the database.
  •  Available upload or download functionalities with path traversal vulnerability that give the ability to benefit relative path that use double dots ( ..\ ) to enable manipulation files or folders outside the root directory by manipulating the parameters. 
  •  Check for ability to display user supplied data cross site scripting or possibility of injecting or storing a cross site scripting on uploading a file or open editors. 
  • Check ability to use invalidated parameters pushed to pages that do redirects to check Invalidated Redirects and Forwards or dynamic redirects.
  •  Login issues and possibility of using brute force attack: any hints found about passwords or comments about user name can be added to attack dictionary which might minimize effort and time needed to break in. 
  •  Isolate available information that might help in escalate privileges like cookies and session state information. 
  •  Using collected info try to identify non encrypted communication channels 
  •  Identify interfaces to external system it might represent an information leakage point
  • Analyze all generated error message for information leakage. 
  •  Identify any pages that interact with mail server to try command or email injection 
  •  Identify the usage of native code that might be a potential vulnerability for buffer over flow.
  •  Identify any known structure , folder names , themes from known third party application which can open the door to search for known vulnerabilities
  • Identify common vulnerability in the used web server.   
For web application security. You can benefit from many available tools to help to scan the application and give a good initial picture about the attack surface.

Attack analyzing – feasibility & priority 

At the end of this stage the attacker should have a list of possible attack scenarios with priority for each attack type. The resulted priority is guided by the complexity, purpose of attack and extra needed information. Attacker should create a list of possible attacks along with estimated requested resources then to specify priority.

Factors that affect prioritization can be related to the purpose or to needed resources. Attacker can use a prioritization table that reassemble to the following: 

Weights given to each factor might differ depending on the importance of each factor to the attacker but a rough estimation can be generated by average of factors estimated as percentage.