(#312598) GM - IDOR drives to SQLi on myConfig tool Status

It has been determined that private resources can be accessed without authentication.To understand how the application works, simply navigate through the affected domain, all resources redirects to the authentication panel without exception, so it is understood that the functionality of the application is to access the authenticated part as a user.

After detecting that the application used Oracle BEA Weblogic for the error responses so typical of this software, it proceeded to bruteforce the .jsp files in primary URL:

https://null.gm.com/myconfig/index.jsp > https://null.gm.com/myconfig/*.jsp

Resulting in a 200 OK in some cases. One of the most interesting resources found was the following

https://null.gm.com/myconfig/status.jsp (CODE:200|SIZE:6004)

If we click on the previous link, we will see how we can access the status of the application, which in turn redirects us to the authentication page. However we can use the BurpSuite to avoid redirecting to the authentication panel:

Request:

GET /myconfig/status.jsp HTTP/1.1
Host: null.gm.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Accept: text/html, */*; q=0.01
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate

Part of Response:
<li class="ui-accordion-header ui-helper-reset ui-state-default ui-corner-all">
<a alt="news.jsp" href="?p=0">News</a>
</li>
<li class="ui-accordion-header ui-helper-reset ui-state-default ui-corner-all">
<a alt="issues.jsp" href="?p=1">Tasks</a>
</li>
<li class="ui-accordion-header ui-helper-reset ui-state-default ui-corner-all">
<a alt="information.html" href="?p=2">Information</a>
</li>
<li class="ui-accordion-header ui-helper-reset ui-state-default ui-corner-all">
<a alt="support.html" href="?p=3">Support</a>
</li>
<li class="ui-accordion-header ui-helper-reset ui-state-default ui-corner-all">
<a alt="alertMessages.jsp" href="?p=4">News Messages</a>
</li>
Therefore, this led us to obtain more resources from the private part of the application:

news.jsp
issues.jsp
information.html
support.html
alertMessages.jsp

Now enter to this URL:
https://null.gm.com/myconfig/news.jsp

You will see the next JavaScript code:

<script type="text/javascript">$("document").ready(function() {
$(".unsolvedIssue").click(function() {
tid = $(this).attr("id");
$("#mainContent").load("issues.jsp?i=" + tid);
window.location.hash = "issues.jsp?i=" + tid;
});
Cufon.replace('h1,h2,h3');
$(".unsolvedIssue").bind("mouseenter mouseleave", function() {
$(this).toggleClass("ui-state-default");
});
$(".searchTid").keydown(function(e) {
if (e.keyCode == 13) {
tid = $(this).val();
//alert("SELECT id FROM ticket WHERE id = '"+tid+"'");
$.post("checkSql.jsp", {sql: "SELECT id FROM ticket WHERE id = '"+ tid.replace(/'/g,"") + "'", admin: "y"}, function(html) {
//alert(html);
if ($.trim(html) != "true")
$(".findIssueAnswer").hide().text("Could not find any issue with that number! Try again.").show(100);
else {
href = "issues.jsp?i=" + tid;
if (href.indexOf("#") != -1)
href = href.substring(1);
$("#mainContent").load(href);
window.location.hash = href;
}
});
return false;
}
});
$(".unsolvedIssue").css("cursor", "pointer");
$("#changeInfo").hide();
$("#userGuide").hover(function(){
$("#changeInfo").show();
},function(){
$("#changeInfo").hide();
});
});</script>

It seems that the developer has left an SQL query in the code:

$.post("checkSql.jsp", {sql: "SELECT id FROM ticket WHERE id = '"+ tid.replace(/'/g,"") + "'", admin: "y"},

Conclusions:
The default error messages led to the detection of the technology used by the application (BEA Weblogic Oracle). The indirect access to authenticated resources gave us the possibility to see other private resources in the application and also resources with SQL query.
It was decided not to exploit the vulnerability as it is evident.

Impact

An attacker could access private resources of the application in search of failures for later exploitation, or steal private information.

#

Note:This is the original report sent to hackerone, in the following post it will be explained in more detail.

XSS Cookie Based ( Self XSS or Indirect XSS)

Recently in one of the many reports that I usually send to hackerone weekly, I found an XSS in a parameter of the Cookie, after reviewing my report, the company to which I reported said XSS decided that XSS was out of scope, because it was a Self-XSS.

In my point of view it is not a Self-XSS, since a Self XSS is based on you should to manipulate the source code of a user's browser and add that malicious code, I define it seems to match the definition of Wikipedia:

"Self-XSS is a social engineering attack used to gain control of victims' web accounts. In a self-XSS attack, the victim of the attack accidentally runs malicious code in his / her own web browser, thus exposing it to the attacker."

In order to understand the problem, we will perform the vulnerability.

On the one hand, an unauthenticated user is able to inject JavaScript code into one of the Cookie parameters, which could allow a persistent XSS in the browser cache of the victim. We can see this in the next example:

GET / HTTP/1.1 Host: www.vulnerable.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64;
Trident/5.0) Connection: close Cookie: vuln=</script></script>alert(1)</script>

The affected parameter of the cookie in this case is Vuln, inserting the sequence <script> <script> alert (1) </ script> returns the following response:

HTTP/1.1 200 OK Server: www.vulnerable.com Date: Thu, 31 Aug 2017 16:21:36 GMT Content-Type: text/html; charset=UTF-8 Connection: close Cache-control: no-cache, no-store Vary: Accept-Encoding Content-Length: 68020 ..] </script> <script>window.vulnerable_page_name = "boom"; window._tracking_segments_cookie = "bid|</script></script>alert(1)
</script></script>" ..]

Once the XSS is executed, it is saved in the browser cache, since it is a cookie and has been set to <script> <script> alert (1) </ script> value, erase your browser's cache will remain there.

I suggest that it is possible to exploit this vulnerability through cURL, using the following command:

curl -i -s -k -X $'GET' \ -H $'User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64;
x64; Trident/5.0)'\
-H $'Referer: www.vulnerable.com' \ -b $'vuln=</script></script>alert(1)</script> ' \ $'https://www.vulnerable.com/'

They respond as follows:

"Hi 

The exploit you describe is a "self-XSS". As cookies are set server-side and sent to/from the client via headers (as you noted via the use of the '-b' parameter on CURl), it would require a MITM or endpoint compromise to intercept the cookie headers.

Kind regards,
"

They in that part are right, without a proxy or without compromising an a priori endpoint and without further information it is not possible to set the cookie through a GET request ...
Once I have this answer I decide to investigate on how to get a full XSS through this vulnerability, so I am going to analyze the entire Web in search of a "Token session in URL" vulnerability, the objective is to set the cookie to through a GET request from the URI for example:

GET /index.html;vuln=</script></script>alert(1)</script> HTTP/1.1
Host: www.vulnerable.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64;
Trident/5.0) Connection: close

Basically if this had worked we would have two vulnerabilities, the first is the sending of sensitive information through a GET method, Burp calls it "Session Token in URL", on the other hand if it is possible to set the cookie through a GET , we would be talking about "Session Fixation" vulnerability. However, this vulnerability could not be exploited since it was not possible to set the value of the parameter vuln of the cookie. On the other hand, we do not compromise any endpoint nor can we make the user navigate through a proxy, so the only option we have is through a third party. That is to say, for the effective exploitation of this vulnerability, a domain external to the organization is required to be redirected to the domain of the organization and the XSS can be exploited.

Once this is understood, there are several vectors of attack:

1) Attach an HTML to a malicious email with the aim of the user to download it, and click on the link (method more tedious) since as we know it is not possible to insert JavaScript code in an email, at least in the managers (eg, Outlook, Gmail ...)

2)Create a page controlled by you, which redirect and set the cookie to the domain of the organization (simpler option than the previous one)

3) As it turned out, the page was also vulnerable to attacks by Clickjacking, therefore this vulnerability could be used to redirect to the domain of the organization.

An example of the code that could be used to exploit this vulnerability through a third party could be the following:

"<a href="https://www.vulnerable.com" id="ref">
$("a#ref").bind("click", function() {
$.cookie("vuln", "</script></script>alert(1)</script>");
});"

In no case is the web console of the user to be compromised, so in my opinion these types of vulnerabilities are not considered Self-XSS type, it would be something like DOM XSS based attacks, 4 example a XSS Indirect Reflected.

What do you think?

Thks.

Download all APK from Google Play - Device/Country bypass (Android 6 Marshmallow)

As we all know Google Play has multiple filters whose main objective is to verify whether the application to download (APK) is compatible with our device, however as I have seen there are also filters by country, limiting downloading the APK to the country where it is used. The clearest example we can have in international organizations that have different APK depending on where the headquarters.

The objective of this article will be to evade the principal restrictions or filters determined by Google Play.

Maybe someone us there said someone there websites that evade these restrictions allowing download any APK, but the reality is different, they are sites with their own repositories, previously downloaded from Google Play, with this means that if the application has not been previously downloaded you can not download this APK from those sites.

1.Bypass device filter:

Before you start talking about the filters, you must set the stage for action, ie the type of device to use (virtual or physical). In the case of using a virtual machine recommend:
Mobile Security Framework (MobSF) with Xposed Framework to spoof your device, but if the application uses GPS MobSF may not be useful. For this reason I decided to use a physical device, in my case a terminal with Android Xiaomi MI4 to force device filter on Google Play.Let's see if your device is not compatible with the download of certain applications. Then you will see something like that on Google Play:

The only solution is to spoof our Android device to avoid this restriction. If you use MobSF you can use Xposed Framework and spoof your Android virtual machine. You can also install Xposed Framework on your physical Android device, I could not incompatible with my kernel version 3.4.0. Therefore, and after rooting my physical device, install an application that allowed me to spoof my device.

I will not go into details about the application. Once  spoofed we can check in the device manager of Google. By other hand, Google Play will automatically recognize the new device, make sure you have installed Google Play services on your Android device.

I changed my Xiaomi MI4 LTE by OnePlus One... and magicly I have OnePlus MI4LTE. If you check your new user-agent will see a Real Phone + Spoofed Phone agent combination.  Therefore, if we could do MitM to Google Play with BurpSuite (for example) and modify the user-agent, and with this we could spoof the device also. Although it is easier to change the User-Agent in the system, with the application shown above.

Now you can check Google Play to see the new state...

2.Bypass country filter:

To skip this filter, I followed the following steps:

1) Create a Gmail account in the country where you want to download the APK.

2) Create a virtual phone that country for use in my new Gmail account.

3) Locate a free VPN connection in the country where you want to download the APK.

4) Download a GPS simulation software to place in that country.

Well, with this and we can download all the APKs available in the repository of Google Play, although the process may seem tedious, it is not much and will be very useful in the future.

Note: If you use virtual machine with Android, remembers take snapshots.

If you want know more about Google Play filters:

https://developer.android.com/google/play/filters.html?hl=en

Thanks to:
@bitsniper

Analizing BurpLoader.jar (Larry Lau version)

All who are dedicated to this IT security, know that there are key tools, especially when making a web pentesting. One of these key tools is the Burp Suite.

However, there are many versions online, and one of the most famous is that of Larry Lau. This version has been controversial, since many doubted the legitimacy of it. This post is not intended to "hack" version of Burp Suite pro, but BurpLoader deobfuscate, decompile, and verify whether or not the existence of malware into the jar file. It has carried out an analysis to Burploader.jar version version 1.6.38.

Once understood the purpose of this post, let's get to work.

The first step is to extract the .jar file class, the BurpLoader, for this will open the .jar file compressor for example WinRar. After removing the .class will proceed to visualize the code to address the problem in the best way possible. We will use the jdecompiler and the .jar file decompiler Burp As shown in the following image we are only able to see the bytecode:

As you can see in the picture above, we can not see the original source code, but you can see the bytecode. So now we need some bytecode decompiler to find out exactly what makes this source code. The code can be recompiled with Eclipse, however I have used a simpler tool called Procyon-decompiler. Procyon run and you look at the part of the obfuscated bytecode ldc(load constant):

As was seen in the picture above, the ldc is obfuscated. It should then proceed to find out what was the algorithm I use Larry Lau to obfuscate the code, so it can use jedit, obtaining the following results (BurpLoader.class):

Therefore we conclude that the algorithm used is ZKM8.0.1E (http://www.zelix.com/). To deobfuscate this code to need the 5 digit key that can be found very easily with jedit, between others.

Now we need some software that embeds the option to deobfuscate code with ZKM, we disclaim by DirtyJoe, software for Windows.

Subsequently, after applying the correct algorithm to deobfuscate:

I do not think it necessary to go into details, once you have the .class deobfuscated must return to the first steps in order to decompile this class. Getting the license using Larry Lau in his Loaders. But it was impossible to determine the existence of malware, since we could not compile the decompiled .java above, since we lacked dependence burp_extras.jar

Understanding "tamper" option in Sqlmap (II)

In the previous post, we explained the reason for using tamper sqlmap option. However, due to the large number of tampers available, it is necessary to construct a table where you can see where we can use every tamper, because I could not find a table on the internet where you reflect the type of database manager data used in each tamper, between others:

TAMPER	MySQL	MSSQL	Oracle	PostgreSQL
apostrophemask	*	*	*	*
apostrophenullencode	-	-	-	-
appendnullbyte	*	*	*	*
base64encode	4,5,5.5	2005	10g	-
between	5.1	-	-	-
bluecoat	*	*	*	*
apostrophemask	9.0.3	2000,2005	-	9.3
charunicodeencode	4,5.0 and 5.5	2005	10g	8.3,8.4,9.0
charencode	*	-	-	-
commalessmid	*	-	-	-
concat2concatws	*	*	*	*
equaltolike	*	*	*	*
greatest	< 5.1	-	-	-
halfversionedmorekeywords	5.0 and 5.5	-	-	-
ifnull2ifisnull	*	*	*	*
informationschemacomment	4,5.0,5.5	2005	10g	8.3,8.4,9.0
lowercase	5.0	-	-	-
modsecurityversioned	5.0	-	-	-
modsecurityzeroversioned	*	*	*	*
multiplespaces	*	*	*	*
nonrecursivereplacement	*	*	*	*
overlongutf8	5.1.56,5.5.11	2000, 2005	N/A	9.0
percentage	4, 5.0,5.5	2005	10g	8.3,8.4,9.0
randomcase	*	*	*	*
randomcomments	*	*	*	*
securesphere	4,5.0,5.5	2005	10g	8.3,8.4,9.0
space2comment	-	-	-	-
space2dash	4.0,5.0	-	-	-
space2hash	>= 5.1.13	-	-	-
space2morehash	-	2000, 2005	-	-
space2mssqlblank	*	*	-	-
space2mssqlhash	*	*	*	*
space2plus	4,5.0,5.5	2005	10g	8.3,8.4,9.0
space2randomblank	-	*	-	-
sp_password	*	*	*	*
symboliclogical	*	*	*	*
unionalltounion	*	*	*	*
unmagicquotes	4, 5.0,5.5	2005	10g	8.3,8.4,9.0
uppercase	*	*	*	*
varnish	*	-	-	-
versionedkeywords	>=5.1.13	-	-	-
versionedmorekeywords	*	*	*	*
xforwardedfor	*	*	*	*

(*) It might work for all versions. 
(-) Does not apply

While the ultimate goal of using the tamper data, to evade firewalls and filters possible application, should know to what kind of database manager apply one or the other tampers.

The reason not add the Microsoft Access data base is evident, this type of database is not relational, so using Sqlmap for such SQL injections might be a waste of time.However Sqlmap has a specific tamper for Microsoft Access databases, called appendnullbyte.

Moreover, there are some tampers that are unique to evade WAF, for example:

securesphere: Useful for bypassing Imperva SecureShere WAF.

varnish: Useful for bypassing WAF Protection of Varnish Firewall.

Some tampers only work for certain specific Web programming languages, such as:

charunicodeencode: Only for ASP or ASP.NET.

In short, there are many ways to bypass filters and firewalls. Although it will be difficult to find such deficiencies in large companies dedicated to it. Although we can always develop a script that can bypass such restrictions.

Other links that may be of interest to bypass filters, in this case XSS:

https://www.exploit-db.com/docs/38117.pdf

In the following post we use appendnullbyte tamper to Microsoft Access databases and try to explain in as much detail as possible the problem of SQL injections against these databases.

Regards,

Understanding "tamper" option in Sqlmap

In today's post, we will see the meaning of the "tamper" option in Sqlmap tool. By the time we just enough to know that there are certain data filtering mechanisms and certain web application firewalls that will hinder us much homework, when implemented correctly SQL injection attack.

To better understand the data covered, it will proceed to stage it in the following example. As you can see below, when a vulnerability is detected SQL code and then tries to exploit, the server returns the same sentence without spaces:

REQUEST:
GET /index.html?id=' AND 1=1

Host: X.X.X.X

User-agent: Mozilla/5.0 …

Connection: close

RESPONSE:
HTTP/1.1 200 OK

Server: X

Connection: Close

The SQL syntax is incorrect when SELECT * FROM productos WHERE ID='AND1=1....

As shown in the above example, the server responds as "The SQL syntax is incorrect" after eliminating the spaces of the sentence. Tampear would require data so that 20% be added to each space.

Although default hexadecimal sqlmap becomes the content of the petition, this example helps us to understand why to the "tamper" option.

Applying the above concept to our previous example, that the judgment was valid should be as follows:

REQUEST:
GET /index.html?id=%27%20AND%201=1

Host: X.X.X.X

User-agent: Mozilla/5.0 …

Connection: close

RESPONSE:
HTTP/1.1 200 OK

Server: X

Connection: Close

OK

As you can see in the previous answer, so that the SQL statement is correct, they should to use tamper option to convert all to hexadecimal data. However, Sqlmap does by default, but is a good way to understand why of tamper option.

I guess by now, you're thinking, and as I used to tamper option. How could identify this?.

Everything depends more, if our client uses WAF(Web Application Firewall), and the version of manager database software.Sometimes we believe that the filters themselves implemented by the manager of the database, are a WAF, but not always.

Sqlmap further it incorporates a feature that allows the detection of the best known to date WAFS this will help us in verifying the existence or otherwise of such firewalls:

--check-waf

#You can find more information in the following official link sqlmap:

https://github.com/sqlmapproject/sqlmap/wiki/Usage

Once identified first type of WAF (if web application has any), the programming language used to develop web, and the type and version that uses the manager of the database, and are ready to choose the tamper option more appropriate.

Since the purpose of this post is to understand the Tamper Sqlmap option and I think is quite clear. I will simply say that there is much information on the Internet regarding what kind of tamper option is used depending on the above parameters.

Regards,