South Korea Cyberterror on March 20th – News –

***Updated on march 26th***

[English]

South Korean Attack & Malware Analysis
http://www.infosecisland.com/blogview/23032-South-Korean-Attack-amp-Malware-Analysis.html

South Korean Banks, Media Companies Targeted by Destructive Malware
http://blogs.mcafee.com/mcafee-labs/south-korean-banks-media-companies-targeted-by-destructive-malware

[Korean]

Wowhacker Report

http://wowhacker.org/files/0320_cyberterror_stolenbyte.pdf

NProtect Report
http://erteam.nprotect.com/408

Ahnlab
http://asec.ahnlab.com/926

Each report are continuingly updating, Korean reports have more detail and correct information. I’ll keep updating.

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.

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)

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.

http://www.cvedetails.com/

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.

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)

VoIP Packet Analysis using WireShark

WireShark is a useful tool to analyze VoIP(Voice over Internet Protocol) and it provides SIP analysis functions. Let’s start learning about this.

To analyze the VoIP network transport, WireShark can be used to capture the packet and to extract the voice data. The first step before analyzing is to capture the VoIP packet, it needs ARP spoofing or other ways to capture the other device’s VoIP packet.

SIP Authentication

SIP Authentication, when a user is authenticating VoIP with username, password, these packets are as follows.

Username is sent a plaintext, but password is operated with other data(as follows) and hashed. This hash data is sent a value of ‘response’ header.

Response Operation
Response = md5(A1:nonce:A2)
A1 = unq(username-value) “:” unq(realm-value) “:” passwd
   = md5(username:realm:password)
A2 = Method “:” digest-uri-value
   = md5(method:url)
#SIP Authentication mechanisms are described in ‘HTTP Authentication: Basic and Digest Access Authentication’(RFC 2617)

Extract the Voice Call Data 

To Extract the voice call data, you can use extract feature of Wireshark.

When you done capturing packet, select the menu “Telephony” → “VoIP calls”

You can see the VoIP calls, talk times, source(sip or phone number), destination and state sections on the dialog. There is only 1 call on my example. Select call and click the “Player” button.

Next click “Decode”!! Start changing packet data to voice data.

Now, you can see the voice call data and you can also listen the voice of calls. First wave is a voice from opponent and second wave is your voice. Click an each waves and play.

If the voice call data were encrypted like SSL, this decode function is not working. This function can only analyze not encrypted RTP data.