Owasp Mobile Top 10 M4 – Insecure Authentication

In this post, we are going to discuss the insecure Authentication which holds the Fourth position in Owasp Top 10 mobile Risks. Android apps are facing this vulnerability when the app fails to identify the user, allowing an anonymous user to login and using default login credentials. This category includes session management issues, privacy issues related to authentication, and issues where user identification tokens are compromised. Even if the mobile app uses a weak password policy to simplify entering a password, it suffers from insecure authentication.

To exploit this vulnerability, we have different approaches like attacking activities, Brute-force attack, user enumeration and checking password policy.

Attacking Activities:

In Android apps, everything is activities if you are in login screen it’s an activity if you are in profile screen its other activity so we can able to bypass the authentication by forcing the app to show the profile activity without giving username and password. To exploit activities we need to use a drozer framework which we have already discussed in earlier blogs.

first, we need to know what are the activities are available in insecure bank app for that we need to give the below commands

dz> run app.activity.info -a com.android.insecurebankv2

From the results, we come to know that that are 5 activities which are exported and first two are related to the login process.

 Fig. 1

 Com.android.insecurebankv2.LoginActivity is for login page screen (Fig 1.) and the com.android.insecurebankv2.PostLogin activity (Fig 2) is the screen which triggers when the user logged in. so we need to use the com.android.insecurebankv2.PostLogin activity to bypass the authentication. By using drozer let we start the activity by giving the below commands

dz> run app.activity.start  --component  com.android.insecurebankv2 com.android.insecurebankv2.PostLogin

 Fig 2.

 finally, we have bypassed the login page now we can do the transfer, changing the password or viewing the statement is possible. A brute-force attack is also possible but if the app has any brute-force protection mechanism it makes hard to attack. for example, if the app gets often login request it will block the user and it will restrict the access for a while. and there is another issues like Username Enumeration which occur when a user logged and for the second time when he/she too going login in app it shows the username and also when app gets the correct username and the wrong password that time it may show password of the username is wrong so it will conform us the username, it mostly happens in WordPress logins in web applications.

How to Fix:

• Don’t export unnecessary activities or use permissions when the activity is exported
• Implement two-factor authorization if called for the sensitivity of your application
• Disable anonymous accounts
• Implement strong password policy and don’t store the password in local storage

In this post, we have discussed how to attack activities using the drozer tool, and how the way android apps are vulnerable to owasp’s insecure authentication, and how to fix the vulnerability.

OWASP ASVS 2.0 Cheat Sheet for Application Penetration Testers

The primary aim of the OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing web application security verification. The ASVS standard provides a basis for verifying application technical security controls, as well as any technical security controls in the environment that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. It is composed of 13 categories containing 168 check points to validate in your application. Of course not all are applicable but the global method is wide enough to cover most of web applications.

As a member of OWASP and regularly performing Security oriented Code-Review in various languages, the Application Security Verification Standard became the basis on which I rely to deliver security reports to my customers and a proper way to measure the confidence you can put in the application. This article is not about presenting ASVS which I trust you can discover by yourself on the website of OWASP, but it is only to share a worksheet I have been using along with the document written by OWASP.
This spreadsheet takes the shape of a checklist you can browse in order to assess the level of confidence of the application. In this article I will enclose this spreasheet and explain how I am using it. You can directly download the cheatsheet at the end of the post.
Basically the spreadsheet is really simple but I have never seen it elsewhere. You have one tab sheet for each category of the ASVS. For each category the criteria is documented with its ASVS Level and description in full text. Then your job will be to fill in the rest of the field as follow:

• Valid (Valid/ Non valid / Not Applicable)
• Source Code Reference (If the code is not valid, insert the reference to the files/lines which lack of security)
• Comment (Field to comment the vulnerability and keep track of changes with developers)
• Tool used (If the vulnerability was found using a tool , you can include the name of the tool / version and sometimes the output)

Once you’ve done that, do not forget to tag the irrelevant critieria with Non Applicable,  and the report located in the first tab sheet will be automatically generated as well as the radar graph, you can directly enclose in your analysis document or report.
Ideally this assessment should be done before any major release of your software, especially if you work with Agile methodology. It should be part of your recipy before shipping to validate this worksheet. Along the security analysis you can share this document with developers to keep tracks of change and also keep the graph at each release to see the evolution of security of your application through time.
LibreOffice Version ASVS-2-0.ods
Excel Version ASVS-2-0.xls
(I built this spreasheet using LibreOffice, I’m sorry if it looks broken in Excel… You can kickstart to offer me a MSOffice license :P)

External Security Assesment is important for all Network and applications

The most common solution to external network security assessments is scan, scan, scan…and then scan some more

One of the most common vulnerability assessment activities for all companies of all sizes is an external scan, typically targeting internet-facing websites. Because we service the vulnerability assessment and penetration testing needs of large enterprises, we know “you know” that scanning external-facing network resources is important, and an obvious high priority. But we also challenge you to understand that scanning alone is not enough, unless all you really want is a checkmark for an audit of one kind or another.

A complete job of assessing the hardness of your external network includes multiple steps. Here are four of the main steps that you should be familiar with:

1. Anonymous information gathering to discover all Internet-facing assets a hacker could identify as potential entry-points into your network
2. Scanning of your internet-available network access points and web servers for known vulnerabilities (non-credentialed)
3. Verifying scan-result findings through in-depth manual pen testing attack techniques (both credentialed and non-credentialed)
4. Providing deeply informed remediation guidance and advisory services for identified/verified vulnerabilities

Why is BriskInfoSec approached to discuss external vulnerability assessment work with large enterprises?

BriskInfoSec is approached by our large enterprise clients to assess the security of their external-facing network assets for many reasons, but chief among them are dissatisfaction with their own internal tools, their present provider, and/or their own internal team’s ability to effectively manage all of their external testing work efficiently over time in a consistent and professional manner. These kinds of situations frequently result in an assignment for someone in a company’s security staff to search out alternatives; which then open up an opportunity for BriskInfoSec to present our highly-disciplined, in-depth approach to assessing the security of their external-facing network assets as compared to their present approach.

What do these companies discover when comparing BriskInfoSec approach to external security testing with their own present approach?

Because BriskInfoSec is driven by an across-the-board corporate culture that’s passionate about delivering the highest-value findings and recommendations possible, we do more than the basic steps, we do all the steps on your behalf; and then even more than that. If you assign mid-to-low-level-importance projects to others, fine, we see that frequently. But if you have a set of high-value software assets or critical points-of-entry into your network, working with BriskInfoSec always begins with an education about scanning versus penetration testing:

• Scanning and penetration testing are not the same thing, no matter how much the marketing folks working for the scanning tools manufacturers and scanning service providers make it sound that way
• Scanning is never enough, it is only an initial step in the entire assessment process
• Just the scanning step alone done effectively needs multiple scanning tools and multiple over-lapping scans run against the same resources in order to accomplish a thorough job of the scanning step
• Scanning the same resources  with different tools (as just recommended) naturally returns different results in different data formats
• Correlating and normalizing all this desperate scanning data requires special technology: like our proprietary CorrelatedVM™ platform that’s used by all of our pen testers and available (in part) to you through our CorrelatedVM Portal at no additional cost
• Scanning identifies potential vulnerabilities, and the different scanners may recommend different remediation actions – but BriskInfoSec’s CorrelatedVM platform fixes that problem as it correlates and normalizes all the scanning data from multiple scanning products and multiple rounds of scanning into the best set of recommended remediation actions
• Potential vulnerabilities identified by the initial scanning effort need to be verified by experts to eliminate false positives, and to thoroughly analyze the remainder, while also probing for any unidentified vulnerabilities the scanners could not find – this is work that only an expert pen testing company like BriskInfoSec can deliver 

In-depth pen testing to final reporting of findings and recommendations is what sets BriskInfoSec apart, and why we are given the critical responsibility of assessing the security of your most high-value/high-risk external-facing network assets.

The power of CorrelatedVM comes at no cost to you and provides real benefits that only BriskInfoSec can deliver

CorrelatedVM™, our proprietary vulnerability assessment and pen testing management platform, will be utilized for your external network penetration testing service when you hire BriskInfoSec. The CorrelatedVM platform and your complimentary access to its SaaS-based customer portal set our deep-dive pen test work and customer-facing deliverables light years apart from all other pen test services. This one-of-a-kind, powerful platform has been continually enhanced and used exclusively by BriskInfoSec’s elite team of pen test consultants on every pen test engagement for over a decade now.


Once you see our team in action with the CorrelatedVM platform, and what CorrelatedVM can offer your organization in the way of automating and disciplining your external vulnerability assessment efforts, you’ll realize how it solves presently unsolvable problems that will profoundly benefit all of your vulnerability management programs going forward.

Contact us for conduct external security testing against your applications and Network with affordable price info@briskinfosec.com

OWSAP WebGoat - vulnerable web application Attack

WebGoat Week 9

Exploit Unchecked Email
This lesson has two steps: first you are to send a malicious script to the website admin and second you are to send a malicious script to a ‘friend’ from OWASP.
So the first thing you are going to do is put the input shown below into the Questions or Comments textbox and click send:
<script>alert(“XSS”)</script>


Next we need to send it to a ‘friend’ from OWASP.
Again put the script into the same textbox as before but before you click Send open up Tamer Data and start the tamper service. Intercept the request and change the to field to another email address.

You can see here that the email was going to webgoat.admin@owasp.org (40 is the ASCII for @, you need to put the % for URL encoding). So let’s send this to friend@owasp.org. You will need to enter this:
Friend%40owasp.org

Click the OK button and you should see this:

Bypass Client Side JavaScript Validation
For this lesson you are given seven JavaScript validation mechanisms, all of which must have valid values in to submit successfully. You are told that both client-side and server side validation occur on these mechanisms; break the client-side validation.

Open WebScarab and check off request intercepts make sure to have everything highlighted.  Now go the page and hit submit. Go to the WebScarab window and check the encoded url tabbed, and you will see the values. Simply modify them, in the screenshot below I simply added the @ to each field and then press accept.


Session Management Flaws
Hijack a Session
For this lesson you are attempting to gain access to a user’s session.
You will need the jhijack tool available at http://sourceforge.net/projects/jhijack/.  Go head and startup WebScarab and set your proxies. Turn on request intercepts, view hidden fields and finally launch the Jhijack.  Now reload the page and we will look at webscarab.

Let’s take a moment and configure out jHijack. We need put our Host, and port into it first.  In the example below we see the IP address of this particular VM and port number, yours maybe different. Now we need to find a success message of some kind. So far we have noticed in Webgoat, that every time we complete a mission we get a “Congratulations” so let’s use that in our Grep (it’s case sensitive).  The last part we need to fill in is the URL.  See below.

Now we need to go back to WebScarab and select the Session ID tab (if you don’t see it make sure you are using WebScarab in it’s full version. Select previous requests and choose the appropriate url (picture below).  Now select the cookie weakid and remove it.

Go to the bottom of the screen and hit test. You should receive this success message.

Now we need to collect some data. Set the fetch number to 50 and hit fetch. Go up to the Analysis tab and set the session ID and you should receive the list of cookies out there.  We want to look specifically at the Session ID numerical value. Not that it is incrementing by 1.  Now, there is a gap there, between 19400 and 19402. That’s an open session so let’s focus on that.

The second part of the values has a large gap between them so we need to “guess” at what that value is, but we have JjHijack to make this really simple. Copy out the one above and below the target and  paste them into a notepad. Doing this makes it easier to see and copy.  See the example below. Notice the [] is a range.

Now it’s simply filling in the missing information in jHijack. Go back to WebScarab and gather the JsessionID, parameters and  enter them in. Note we want to place a $ at the end of our WEAKID value. Finally, take the range and enter that in.  Then hit hijack. See below.

We refresh the page one last time and go back to the WebScarab intercept and swap out the weakid.

And hit accept and we have our congratulations message.

Spoof an Authentication Cookie
For this lesson you are told to login using either webgoat/webgoat or aspect/aspect as the username/password combination. Next you are told to edit the cookie to change your identity to alice.
So first off log in as webgoat and click the Login button.

On the top of the webgoat page you should see a link that says Show Cookies. Click on the Show Cookies option and you will see the cookie that was created when you logged in as webgoat.

The authorization cookie or the user webgoat is 65432ubphcfx as shown above.
Go ahead and click the Logout button and then login with aspec/aspect next:

Click on the Show Cookies link again (might have to click twice) and you should get your authorization cookie:

For this authorization cookie we see that aspect has a value of 65432udfqtb.
So the different between the two logins is the letters after 65432.
The key to this attack is that the username is a really basic cipher. Let’s take a look at these authorization cookies versus their usernames:

The first thing that I noticed was that both the aspect and webgoat ciphers both start with u as the first character. The second thing that I noticed is that both webgoat and aspect both end in t. Next you can see that the last character of the webgoat cipher is x and x is one letter ahead of w. Also u is one character ahead of t which explains why both ciphers tart with u. The cipher pattern is a reverse of the login name and all letters are shifted up one. Now that we know this we can begin editing the cookie to change our login name to alice.
To do this lets first do the cipher by hand:

Ok now open up Firebug and edit the cookie value so that it is 65432fdjmb
To do this right click on the AuthCookie value when the menu for it is expanded and click Edit:

You will see a popup window called Edit Cookie. Change the value to the one we determined for user alice:

Click the OK button and refresh the page.

 

Best example for OWASP- SECURITY MISCONFIGURATION

Security Misconfiguration is one of the top 10 OWASP risks for web application that may give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.
Out of several vulnerability checks mentioned on OWASP Security Misconfiguration page, one of the check is following:
Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?
Recently, while doing doing vulnerability assessment at random for some of the top financial websites, I came across this vulnerability:
At this stage, if a user enters the mobile number, he is proceeded with normal registration page.
However, now change the URL manually, and you get an error stacktrace such as following. Notice the change. I changed from execution=e2s1 to execution=1234.

Above stacktrace reveals so much information about the platform in general. Following are some key details:

1. Application Server is Apache Tomcat 6.0.26
2. Component model is based on spring framework
3. Registration is using Spring Web flow
4. Server side programming is based on Java, most probably.

Above can be used by hackers to know about the system very easily, and explore the security holes in various softwares/technology mentioned above to attack.
Solution:
Application server logging shall be configured to show a generic error page against such stack traces.