:::Innovative Security Insights:::

Author Archive

Leadership in a Collaborative Model

Here’s a short paper I wrote about leadership in an Open Source Model (Non-security related for a change).

Leadership in a Collaborative Model


Today, the internet has allowed greater collaboration amongst people. This has sparked organizations and projects which are based solely on a collaborative model. Because such a model is fairly recent, some classical ideas of leadership may not hold true in a modern context. Therefore, in this paper, I study the fairly unexplored idea of leadership in a modern collaborative modeled organization (which I define as organizations modeled around collaborative systems) and discuss the various factors that lead to its success and failure. This research is done through a study of Open Source Software Development projects, which is a prime example of organized groups built largely upon the idea of collaboration. To do this, I use various publications, papers and articles on collaboration through technology and Open Source in Business. In addition, I draw from past and present philosophers and scholars such as Marcus Tullius Cicero, Benjamin Barber, Heather Gautney and Professor Deborah Gordon as they speak about their ideas of leadership. In this paper, I will show that a collaborative modeled organization should not have a central leadership, but should rather rely on common interest among the people. In addition, I conclude that a collaborative modeled organization may be preferred when innovation is fundamental to the goals of the organization.


Leadership, Collaboration, Open Source, Innovation, Consensus 


Introduction to Malware Analysis with Edgis Security

I conducted a brief security sharing with the Edgis group (http://edgis-security.org/) on Malware Analysis. Introducing the purpose and function of Malware reversing and basic techniques such as static and dynamic analysis. Anti-analysis concepts such as packing were also discussed.

Download the slides here (PDF)

Javascript Blocker ‘NoScript’ may give you a false sense of security with default settings

The purpose of Javascript blockers such as “NoScript” for Firefox help to block javascript from running on untrusted sites. Using these add-ons give us a sense of comfort as we may assume that even if content from a domain serves us an intrusive or malicious javascript payload, we are protected (through the browser filtering out the untrusted domain’s Javascript calls).

However, with the default settings of “NoScript”, attackers can make use of trusted domains to host and deliver their javascript. Some examples where this is possible are for sites that allow the uploading of files or custom content. This includes sites storage, blogs, hosting and repository sites. i.e. Dropbox, WordPress, blogspot, etc.

Proof of Concept (POC)

For this article, I will be using DropBox, a popular file storage site, as an example.

Here, an untrusted domain attacker.com serving a javascript from DropBox. In this scenario, the user is a dropbox account user, and thus, has trusted dropbox.com.

Protective Measures (Edit)

[Thanks to Gorgio for highlighting this]

To prevent against such implementations of iframes, you may change the default settings under “NoScript Options|Embedded” and check the relevant “Forbid …” options.

If you have any insights into this, your findings and views are greatly welcome! 🙂

Note: The vulnerability and the versions of firefox and NoScript used are the most updated as of the time of this article (25/02/2012). 

Open Office may expose your password to other users

Many of us, and especially system administrators, have tons of account passwords to remember. Strong password policies make remembering passwords a even more daunting task. Thus, the practice of storing these passwords in a password-protected file/registry which may be used to keep track of password changes, and in some cases, allow other administrators to take note of the credentials to other services/servers.

How does this work?

For open office users, this could lead to the leakage of passwords to unauthorized users. This issue arises from the ‘autocomplete’ function that comes enabled with open office. How the autocomplete function works is that it will scan any document open for unique words based on a criteria, and store them in a list (which can be easily accessed through the options menu). However, what is troubling is that the default setting allows this list of words to be used after the document is closed. Therefore, opening a document containing your passwords may lead to the subsequent user being able to retrieve your passwords.

Password protect it?

How this is different from the technique of browsing through recent documents is that this will work even if the original password file is saved with a password, encrypted or deleted from the computer. Fortunately though, the list disappears upon restarting the computer or by manually closing the process through the task manager.


To protect against this specific problem in Open Office, it is highly recommended to check the option “When closing a document, remove the words collected from it from the list”. This will prevent the above from recurring.

Let’s see it

Here’s a quick demo on the issue mentioned.


Note: The information in this article is updated as of 12/12/2011.

Also, thanks to Rodney [ rod.tan.90{at)gmail[d0t]com ]who helped with investigating the issue and taking the video!


Adding that FB “friend” may compromise your account!

Note: Information in this article is dated to 15/04/2011.

Sorry for the late upload, wasn’t able to make time to sit down and get this done :). Images contained are used to bring across an idea and no harm is intended.

Adding someone you don’t know on Facebook may not only expose your private information , but it may also lead to the compromise of your account. Facebook recently added a new feature in which users may retrieve their account if they lost their password credentials.



This process is based mainly on the knowledge of your account and a trust-based model of security, where Facebook requires your ‘friends’ to prove your authenticity. The process is fairly simple. Facebook will let choose 3 trusted friends in which they will send a ‘secret’ number to them. By entering these codes, the user will be able to complete the process of password recovery.

This is where the main problem lies. If a Facebook user adds at least 3 different and very beautiful young lady friends, which happens to be owned by a malicious user, his account can be compromised through the new password recovery feature.

Will users really add someone they don’t know?

I’d like to think that the answer to this is a ‘yes’. However, I have been proven wrong on several accounts. A while ago, I had a few friends who created a Facebook user with the name “Ah Long” (which is a common male name of a loan shark/illegal money lender), with a gender of female (Really… any more obvious?).

They went around adding people on the social network from a single institute. The results were shocking. Within a few days, we got 500-1000 users from the school who accepted our friend requests. I was appauled to know that some of the victims were my personal friends.
In addition, mutual friends also means that once several accounts in a network are compromised, the attacker has it easy.

Isn’t there already an additional layer of security in place?

A few months back, I completed this process for a friend that had his account compromised. Yes, indeed. Facebook has added an additional check which requires users to upload a copy of their identity card. Facebook also mentions that confidential information should be blanked out (i.e. SSNs, NRICs, etc.) – this gives me an impression they don’t check for photoshopped IDs.

In my opinion, it would be fairly easy to create a picture identification based on the user’s 500+ photos. If physical counterfeit IDs can be made, virtual ones should be a walk in the park.

How can we protect against this?

  1. Be wary of people adding you (or vice versa). Always double-check and do housekeeping on friends (esp. those who may have been compromised)
  2. Enable Facebook 2-factor authentication feature
  3. Set and regularly review privacy settings (privacy policies change quite frequently and may result in leakage of data)

Using Malware to Nullifying the ‘2’ of 2FA (Google Accounts)

The purposed of a 2FA system is to protect the user’s account from being stolen/accessed when logging in from a computer which may have been compromised (It works because the the attacker doesn’t have the 2FA token to login).

The following article details a possibility of how a malware can make use of certain functions provided to give an attacker persistent access to a Google account without the use of the 2FA (even after the session has ended). Also included in the article are recommendations which would protect against such an attack.

Note: For this to be possible, it will require one login on a compromised computer.

Note: This vulnerability has not been patched (as of 29/06/11). No feedback has been received by Google.

As usual, the article will be broken down into 4 sections:

I. The Infection
II. The Vulnerability
III. Make it Malicious!
IV. Recommendations

I. The Infection

The scope here is a login on a compromised computer. Therefore, for a start, let us a look at the infection. In this case, the functions of a malware required would be:

  1. Keylogger – This will allow the malware to obtain the user’s password
  2. Man in the browser – The malware will use this to perform queries without the user’s knowledge

II. The Vulnerability

The 2FA solution that Google provides comes with an option to authenticate an external device or application. How this works is that Google provides a specific password for the application which can be used on a third party email or instant messaging application. This provides the convenience of logging in without the use of a token. Thus, the main goal is to request and obtain an application password, which will allow us to access the Google account without the possession or control of the 2FA token from another system.

Thankfully, Google has a security mechanism against that. They require the entering of the password in order to go to the application password request page. However, given the knowledge and capability of the malware (as detailed in Section I), this safeguard can easily be bypassed. Thereafter, the attacker can use the requested application password to login without the use of the 2FA token.

As highlighted, we can see that through obtaining this password, we can gain access to the account indefinitely, unless the user revokes the password. However, there are several considerations:

  1. A user will not frequent the application password request page once his applications are locked in
  2. Google does not send you an e-mail/text message when a new application has been authorized
  3. In the case of infection, man-in-the-browser can hide the evidence of a breach

III. Make it Malicious!

Weaponizing the exploit in a malware:

  1. Detect user login (Log user ID and password)
  2. After user logs in, use password retrieved to request password application)
  3. Send application user ID and password to the attacker
  4. The attacker is given access to the account without user knowledge

Although there is no weaponized exploit at the moment, there is a high possibility that such a function would be easily exploitable and integrated into exploit kits, especially with the leakage of Zeus source code.

IV. Recommendations

1. Use of token required for critical functions

The current implementation for critical functions (i.e. requesting application password) requires that the password to be re-entered. However, in the case of an infection, this password is regarded as known information to the attacker, giving access to important functions to the attacker. After all, it is the purpose of 2FA to offer protection against such malware attacks.

Therefore, in order to limit what an attacker can do with a session, it is necessary to require the token be used for such critical functions.

2. Inform the user when there is a new application added

Once a user approves his/her applications, it is highly unlikely that he/she will revisit the application password request page to check on the approved applications. Also, there is no indication to the user that an application password has been requested.

Therefore, through informing the user via Text Message (Phone), he/she would be aware if an unauthorized request has been made, and he/she can revoke the password immediately.


Do feel free to share and discuss your opinions and suggestions.


– Brandon

Using Google’s trust to exploit users and spread malware

About 2 weeks ago I happened to find this issue within one of google’s web applications which allows a user to run malicious scripts in the background by linking a google domain link (i.e. http://www.google.com/…) to an unsuspecting user. The problem here lies in the Google Images feature from google.

Note: This vulnerability has not been patched (as of 8/11/10).

However, I have informed Google about it. Their reply is as follows:

“While it’s possible this could be used to trick some users into visiting a site they wouldn’t ordinarily click, it would be impossible to provide a useful service without doing this.”

This article will be broken down into 4 sections:

I. How the vulnerability works
II. Vulnerability PoC Video
III. Impact of the vulnerability
IV. Possible solutions

I. How the vulnerability works?

  1. When clicking to preview an image using the Google Images application, the user is brought to a domain http://www.google.com/imglanding?q=…. with all the variables to point the user to the image referenced.
  2. Upon clicking, the image is loaded in the foreground while an <iframe> is loaded in the background with the domain of the picture. (Note: The top page is still google)
  3. The iframe loads the domain content containing the malicious javascript and the malciious code is processed by the browser in the background without any user interaction required.

II. Vulnerability PoC Video

The video below shows an example of a malicious link presented to the user. In the event that the user clicks on the link, he will be brought to the google site, and the malicious code will load from the domain of the image without any user consent or intervention. The video shows the malicious script redirecting the user to another website where he is prompted to download a malicious file.

III. Impact of the Vulnerability

As long as Google crawls the page for the image, the attack will be possible. This vulnerability can lead to a one-click infection of a user’s web browser through a trusted google domain link. This may result in the breach of trust of a link from a google domain. Besides providing the ‘malicious’ google domain links, it may also possible to use Search Engine Optimization (SEO) attacks to spread malware through this vulnerability.

IV. Possible Solutions

I have thought of several possible solutions to counter this issue. Some of which are:

  • A safe website parser/loader on the server end to allow showing of the website to the user, but not processing redirect or other potentially malicious script functions and data.
  • A warning message can be put to the user before he is redirected, or loads the site. The warning could appear when the user clicks close on the picture (which will bring him to the original site that was loaded in the background. For example, Facebook has a feature for its redirect page, http://www.facebook.com/l.php?… where it warns the user before loading the page.

Facebook Link Redirection Warning

Do feel free to share and discuss your opinions and suggestions.


– Brandon


Hi guys, a lot of people have been asking me if I have a blog at a lot of the previous security conferences. Therefore, I have decided to make one. What i’ll be putting up here will range from technical stuff to topics on a higher level, including some of my personal findings.

Hope that this blog will provide you with an interesting read. Cheers!

– Brandon