Sunday, June 26, 2016

PHP 7's security improved unserialize() function

PHP 7 has introduced options parameter in infamously abused unserialize function.   This options parameter enables developers to explicitly define allowed classes to prevent potential code injections.

Hope other languages can inherit from this approach.

Saturday, May 21, 2016

Testing for existence of 2nd channel notification for modifications to account settings

With ever increasing account compromise via stealth Phishing attack or other means,  it is always a norm that at some point, user accounts may get compromised.

When that happens,  users do not have any ideas when their accounts were accessed in unauthorised manner, which settings were changed (such as change of password/email, disabling of notification), which transactions (pertaining to shopping card/payment sites), login from unusual countries/browsers,mobile devices, ...etc

Thus, it is highly desirable that at least all Internet facing applications should have 2nd channel notifications for the above unintended unauthorised access so as to minimize damage made to user accounts. 

Friday, March 25, 2016

Testing for existence of controls to prevent Self-XSS scam

Prevention against Self-XSS scam should be taken into account if the application is of high value, interconnected with multiple users through forum, messages and the like.

Below is one of screengrab of prevention tip from Facebook:

Sample Code: 
console.log("%cExtra Large Yellow Text with Red Background", "background: red; color: yellow; font-size: x-large");



Self-XSS operates by tricking users into copying and pasting malicious content into their browsers' web developer console.[1] Usually, the attacker posts a message that says by copying and running certain code, the user will be able to hack another user's account. In fact, the code allows the attacker to hijack the victim's account.

Saturday, March 19, 2016

Testing for default auto generation of credentials

Over the years, in some applications we pentested, credentials are auto-generated.   For the worst case scenario,  some of those applications never enforced expiration of passwords to life-time (aka only upon user's demand).

When we analysed a large of number of samples, we found the following common patterns:

Common username patterns:

1. Derived from small number of digits such as 6, 7, 8
2. Derived from first name, last name

Useful tool:

Common password patterns:

1. Derived from small number of digits such as 6, 7, 8
2. Combination of small number of first alphanumeric characters  and digits such as (xwuc7482) and vice versa

Testing for Cryptographic algorithm and hash misuses

Over the years, we have experienced security-aware applications used various forms of encryption/encoding.  In such applications,  we found programmers incorrectly implement cryptographic schemes, either disclosing keys in client-side, keys in json format in server response.

Some of the tools we used:

Bletchley: (analyze -


Friday, February 26, 2016

Patching DWR to hide exception error message

by Ye Yint Min Thu Htut 

Over the years,  we have been feeling itchy with Direct Web Remoting framework (DWR - 's infamous error message:

From compliance perspective, this may trigger disclosure of detailed error messages.  Yet developers are NOT in any control over it in any means.  

We realised the only way to fix it is to directly modify the source.  We managed to fix it.

Watch the video below to patch it yourself just to make our claims work.  We will not distribute JAR file as this may lead some guys to accuse us of  distributing potentially backdoored JAR files.

Video: Patching DWR 3.0.1

Video: Patching DWR 2.11

Sunday, April 14, 2013

Microsoft Internet Explorer 10 - Client-side protection from Password Reveal Button

There has been a privacy concern on Microsoft Internet Explorer 10 -  Reveal Password button feature (aka eye symbol icon).  IE users can disable this feature via group policy. Web developers can disable it via  IE browser specific "::-ms-reveal"  pseudo element.

From developer's perspective, the first solution is out of reach as user's group policy settings cannot be controlled.  Unfortunately, the second option works only in IE 10 document mode. It will not work if a web site is rendered as a lower version of IE for compatibility reason (i.e. 7, 8 , 9).

For the benefit of those who may first be puzzled how to protect, we just coded a few JavaScript lines that can seamlessly mask user password characters in password input field. This solution allows developer to retrieve the password via a JavaScript variable call.


Demo Video:

Try yourself:

Sunday, January 6, 2013

From CSRF Protection Bypass to Shell

If the CSRF protection was not implemented in a secure manner, this could lead to attacker having high privileged functions like an administrator user to perform malicious attacks on the server.  Nowadays' open-source applications provide excessive functions to administrator users, arguing that the user type is trusted and user login function is protected with anti brute force mechanism.


Monday, December 24, 2012

[ClickJacking Demo] Chaining Multiple Vulnerabilities via ClickJacking

Video Link             PDF Link

"Clickjacking for Shells" by Andrew Horton is an excellent demonstration of ClickJacking attack. In his demonstration, he leveraged the ClickJacking vulnerability to install vulnerable WordPress plugin. From it, he utilized Cross Site Scripting vulnerability in that plugin to upload a PHP shell script.

Lessons Learnt

1. ClickJacking attack when utilized with other attack vectors is awesome. It just depends on the creativity how the attack will be carried out.

2. Web applications should never allow language specific shell scripts to be uploaded even for administrator users.  This fact is largely underestimated by nowadays' open-source developers.

Monday, September 10, 2012

Cross Domain Data Access via JavaScript:

The Analysis

In 2008, we prepared a quick short demo  about "Cross-Domain Autcomplete Data Access" or "How Bad Guys Steal your Login Info Smartly". 

Let's learn about another not-so-old cross-domain vulnerability in Firefox 4 - Firefox 11 discovered by Jordi Chancel, Eddy Bordi, and Chris McGowen.  The bug relied on the Firefox's  processing of the JavaScript "" API.   The proof-of-concept exploit comprised of two components:
  • A client-side page that does a redirection trick with JavaScript API - history.back(), history.forward() and 
  • A server-side page that does a redirection trick with  JavaScript API - history.forward()  and a server-side timing redirection to an ARBITRARY web site 
Brandon the explained the root cause in a simple way in the  Bugzilla post:
When using and some APIs to navigate the opened document, it is possible to navigate the opened document to a different site, while the location bar doesn't stay in sync with the new location.
The visible part was attacker's controlled web site with contents from his targeted web site. The background end result was being able to inject his controlled scripts into his targeted web sites. 

As we can learn from Chris's demo,  the execution of the JavaScript at the localhost was actually triggered at an off-site site,, according to his mentioned script domain.domain property.   

The vulnerability went far beyond the URL spoofing.  In a normal URL spoofing vulnerability, the script execution ties only to the localhost itself. 

The issue was filed under Mozilla Advisory 2012-27 and CVE-2012-0474.

Lesson Learnt

Apparently, this trick was used as URL spoofing test vector since the early days of Firefox 1.x/2.x and Internet Explorer 6.x.  It is surprised to see new versions of Firefox re-introduced the old issue. 

Finding zero-day or browser-based flaws give invaluable advantage to attackers as they do not need to exploit web applications; hence decreasing the chance of their attack being noticed and increasing the likelihoods of their attack against victims being successful.

It has been recommended to use a single-browser based approach on accessing critical web sites.  This advice was not feasible for those web 2.0 applications which have plethora of complex third-party integration. For example, you have to use your Google account to post comments or purchase applications from Google store.  

However, critical applications such as Banking should not rely third-party systems to do their operations so users can use the "single-browser, single domain" approach to safely use the service.