XSS using Facebook, Twitter open API – Addition

In the previous post, XSS using Facebook, Twitter open API, I mentioned that open API could be used to XSS on consumer’s web page. But, some people misunderstood it and they asked about it, It is not working on Facebook page, it is working on consumer’s page developed by open API. I posted it to show the bad case of open API and to demonstrate that it can be a threat of service providers and users.

And API were not completely opened to XSS, Service provider’s have adopted the permission model, that separate out each feature based on each permission. A user need to confirm the permission permit at the first access via each feature like login, feed, like and others. (http://developers.facebook.com/docs/reference/login/#permissions)

API Permission of Facebook
API Permission of Yahoo App

But, if a user already permitted the permission of features that the attacker want to use, there is no permission message. So, these status and other information are need to make a payload. It is similar with the development app using API.

I give an example Facebook APIs, but other service providers adopted similar API structures and features. And the effect of XSS is depend on the consumer’s circumstance, but it can be a threat on some environments. The key factor is that many consumer’s pages are not secure to protect from XSS. They should audit their pages and hide the app secret and only grant the minimum permissions.


XSS using Facebook, Twitter open API

Many SNS, App and online service providers are opening APIs that can handle a features of services and be used to expand the business area. Service providers have opened huge documents and samples on various platforms like web, app and mobile for a developer.

For example, Facebook provide APIs that can be applied on Android, iOS and web, and implemented with PHP, Java Script and other language. A developer can use it to connect the login feature with Facebook, feed the messages or apply payment on their app.

But, some APIs can be maliciously used on the developer(consumer)’s services. If a developer implement the feature using open API, it means that the API provider’s data and functions might be controlled via developer’s actions. So, API providers only permit their resources for registered developers to prevent the threat. But, the registered is not exactly mean the secure. If a developer do not have the intention to attack API and provider’s data, but developer’s app could have a vulnerability that can manipulate it. Twitter, Facebook, Google and other large-scale service providers are commonly performing security review and testing for the services. However, the API developer like a web service provider, app developer and individual are not have enough resource and considerations for the secure service.

Some APIs can handle user’s credential, profile and other information. For example, Facebook login API support the developer’s application to use Facebook authorization. The developer’s application can login via the Facebook credential and use the user information of Facebook for their services

If the developer’s application has a XSS vulnerability, the attacker can inject the well-made payload and he is stealing the credential like access token via the boards or pages. The attack can manipulate Facebook features using victim’s access token, such as collecting user’s profile and spreading malicious feeds.

This is my demonstration XSS using Facebook open API. XSS on the consumer’s web page by Login API can be used to steal access_token. XSS payload steal user’s access_token on the consumer’s web page and the attacker is able to feed a message via the stolen access_token.

1. The attacker inject XSS payload into the post of the consumer’s website.

2. Victim read the post with XSS payload and the payload will send the user’s access_token to the attacker’s server

3. The attacker feed the message to the user’s Facebook

I never mention about the detail of payload and tool, but if you see the API documents and if you have experienced API development, you can understand it easily.

[Python] Example for Sending POST request via HTTPS

When you develop a tool to interact with HTTPS server, sometimes you need a code that can sending a POST request via HTTPS. I was searching the best example for my tool, but I couldn’t. So, I made the code referenced POST via HTTP and it works well. I post the sample code.

>>> import httplib, urllib
>>> params = urllib.urlencode({'@number': 12524, '@type': 'issue', '@action': 'show'})
>>> headers = {"Content-type": "application/x-www-form-urlencoded",
              "Accept": "text/plain",
              "Other": "Header"}
>>> conn = httplib.HTTPSConnection("bugs.python.org") # HTTPSConnection instead of HTTPConnection
>>> conn.request("POST", "", params, headers)
>>> response = conn.getresponse()
>>> print response.status, response.reason
>>> data = response.read()
>>> print data
>>> conn.close()

Protect from the Illegal Modified Apps

Android and iOS with Jail Break are able to install apps without going through the formal App Store and Market. Recently, even some ways to install apps without Jail Break were released on iOS. The abnormal app distribution raise some security issues, the threat of malicious modified app and break up of DRM. These issues came from the app manipulation using reverse engineering. If you are searching it using keywords like “android decompiler”, “iOS app modify” or “apktool”, you will find out the many ways to bypass authentication, change the game money and other incredible things.

The attacker is able to distribute the modified apps to steal user’s credentials like a password and token, or manipulate service’s features and processes. For example, on the banking app, the attacker can change the code of login process that the password will send to both of the attacker’s server and the authentication server, or when a user transfer the money to others, receiving account number would be changed into the attacker’s account. The attacker should distribute the app through Black Market, SMS or E-mail.

To protect from the modified app, there are some ways like applying anti-reverse techniques or access control to check the apps’ integrity. Anti-reverse techniques make an app to resist from the analysis and manipulation, such as code obfuscation and dynamic code downloading.

  • Source code obfuscation
  • Binary obfuscation
  • Native library(C, C++ instead of Java)
  • Core module update(Frequently change the core routine )
  • Secure hardware(Trust Zone, TSM)

But, applying anti-reverse technique alone is not sufficient to prevent the service access using malicious manipulated apps. Therefore, the app’s integrity checking can be considered also. The app’s integrity checking process can be adopted to figure out whether access app was modified or not. For this, generated hash(sha-256) of app or app’s files was stored into the server, and then it will be compared with the access app’s hash to check integrity on every connection or before the sensitive feature.

App integrity check process
App integrity check process

The service provider can keep a log of abnormal connection and notify the security warning message to user.

However, even the service provider already adopted these protections, hacker may bypass the checking process and anti-reverse technique. In my research and experience, many kinds of protections were bypassed or manipulated using debugger, memory modification or other technique. For example, if the checking process was implemented to use same integrity data on every time, hacker should save the integrity data and replay it on the network or in the app. The server would accept it as a normal access. To prevent these flaws, the core process needs to protect from the access and manipulations.

So, we can consider the secure hardware like Trust Zone, TPM and UICC instead of software modules. Integrity checking module in the hardware can control the access from the outside of chip and nobody may not access without through the preshared protocol. Moreover, it can be shared and used with other apps by standardized APIs. It would be adopted not only for the integrity checking but also for DRM module to deal with the license issue.

Next, I will post about secure hardware and how can it consist with the app integrity detection.

No Needs to Find Android 0-day

Last week, I was preparing a presentation for smart phone security training,  I found out a statistics of android OS usage. The newest ratio was published in Android Developers webpage(http://developer.android.com)


As you can see, the most popular version is Gingerbread(2.3.3-2.3.7). Over 50% users still using Gingerbread, even Jelly Bean has been released. (Gingerbread released December 2010). It means, if a hacker try to attack an android smart phone, there is no reason for insist 0-day of Jelly Bean, because he can reuse the vulnerability of old android that was already exposed.


This is the vulnerability list of android publicly posted, some of them can using for remote code execution and privilege escalation. The vulnerability can be a trigger to gain an access right from remote and that can use to obtain root.

Smart malware producers already knew it, they aimed to attack most popular versions like Gingerbread and ICS. According to a survey, 28% of malwares were targeted to Gingerbread.

IT Threat Evolution: Q3 2012, SECURELIST

Even though a critical vulnerability were reported and patched it, an user would be exposed if they are not applying it.

To apply patch on Android has several barriers, 1) An user usually want to be stable, 2) Complicated patch circumstance.

Smartphone has many new features and it’s becoming an innovative stuff. But essentially it’s a phone, so some of ordinary users are expecting stable voice call and unchanged interface as a traditional feature phone. They would never apply patch before facing a big problem or someone asking to apply it.

And, as we know that, Google has released Android, then Smartphone manufacturers like Samsung, HTC update and modify the original source to develop their own device. This environment make confusions like “who is in charge of developing a patch”, “How distribute and apply patch for users”. To fast patch, the clear controller is needed. They have to analyze the vulnerability, develop the patch, distribute and inform it. But, Android platform has many stakeholders than iOS (iOS is only controlled by Apple), therefore they need a time and procedure to check the responsibility like kernel bug or application bug, effecting to all version or only special device and so on. Furthermore, restart smart phone to apply patch is a another hurdle. A phone should waiting a call 24 hours, so restart and shutdown are not a good condition. Some people who are not interested in IT device and security wouldn’t restart their own Smartphone for patching.

When we make the mobile security strategy for company or users, we have to consider it, every device is not a full patched android. And Android platform and Smartphone manufacturers need to improve their patching environment.

Galaxy S3 Vulnerable to Remote Reset

Ravi Borgaonkar has demonstrated Galaxy S3 remote factory reset at the Ekoparty security conference in Argentina. He sent a reset message via NFC, web page or QR, and the target Galaxy launched factory reset without an user’s confirm.

The demonstration was using factory reset code that user can reset their own phone through dialing particular number. The code is “*2767*38XX#”(I remove some code). The reset could succeed using this code with “tel:” via any remote triggers.

It’s not a complicated vulnerability, but easily use to attack denial of user’s SmartPhone. May be other manufacturers has similar code to reset, they need to check their reset process.

[Add another test clip]

E2E(End To End) Encryption for Secure Communication

When a user’s PC was attacked from a malware, exploit or attacker, an attacker can control the PC, and gain user’s credentials and input data. If an user try to login into the website, such as banks, mails and SNS, their login inputs(ID, Password, Account PIN) can be logged and sent to the attacker.

Focus on keylogger issue, there are many types of keylogger, kernel keylogger, user mode keylogger, COM hooking, DOM, BHO hooking and other keylogging methods. And keyloggers are continuously developed and adopted high level techniques.

To protect user’s PC from the client side attack, financial institutions offer the anti-keylogger, communication security solution and personal antivirus in Korea. And to prevent inputs keylogging, they applied the E2E(End To End) encryption. It means applying encrypted communication for significant user inputs like password, PIN, account information and others from the end of user PC(keyboard device driver) to the application server. Therefore, plaintext of these inputs are not stored in user’s application and web browser, even as memory.

E2E is similar with security communication, SSL, it’s only extended client end point from web browser or application to device driver level. If we adopt H/W encryption device that connected between PC and keyboard port, E2E can be more extended to H/W level.

To adopt E2E on the website(or application), the anti-keylogger and the security communication solution are interacted each other for exchange key and transfer encrypted data. The anti-keylogger is operating on kernel and user mode to protect keylogging, and the security communication solution is operating on web browser(or application) and transfer section to secure transfer.

On the E2E process, first, the anti-keylogger need an encryption(session) key to encrypt user inputs, so the key is exchanged between the anti-keylogger and the server. Next, the anti-key logger is encrypting user inputs from a keyboard using the key and send it to the security communication solution. The security communication solution is encrypting received data using key that pre-exchanged for communication encryption and sending encrypted data to the server. The server will decrypt encrypted data twice(communication decryption and anti-keylogger decryption), and the server is checking and processing the user inputs.

User inputs that applied E2E is securely transmitting from the keyboard driver to the server, therefore user inputs were not leave as a plaintext from the application to the server.

But, As you know that attackers continuously try to develop low-level keyloggers, such as i8042 keyboard driver hooking keylogger and others using bypass methods. H/W based E2E can offers more secure communication, but it has a cost and installation issues. S/W  anti-keylogger and E2E are needed to improve and patch to resist new attacks.

From the news, VISA will launch encryption service for their merchants to prevent storing private and payment information. (Link : Visa to launch encryption service) I think they will apply E2E encryption from the cardreader to the application server and the core process of payment will move to operate on the server.(My personal prospect)