[ Sharing ] More ITW Exploitation of Internet Explorer ‘Unicorn bug’ found

These few days i have seen friends asking me whether i have seen any sites during work using CVE-2014-6332.
Sad to say, i can’t talk about work. So today i will talk about what i’ve seen during my free personal time.

[ How it starts ]
So what is this vulnerability known as CVE-2014-6332?
This is an interesting bug as it exploits Internet Explorer versions 3 through 11. This means that most if not all of Internet Explorer users are vulnerable unless they are using patched systems. It was first disclosed publicly by @yuange75 here back in 01st August 2014 : http://hi.baidu.com/yuange1975/item/c667f900cf0e2fc02e4c6bed
However he found it long long ago.

I guess it’s only a matter of time that “malware writers” start using this knowledge and use it as part of their cybercrime. I’m not from any AV companies nor ThreatIntel team selling “APT” news, but i do want more people to know that there are now several compromised website(s) that are using this CVE-2014-6332 vulnerability to install malware on the computers of its unsuspecting visitors.

[ Compromised Website details ]
The very first one that i found is from www[.]uyghurweb[.]net
The page source contains 2 interesting thing that caught my “eyes”.

The 1st one is “http://122[.]10[.]91[.]20/2013/frame.js” but it’s down when i tried to grab it.
The other being the other JavaScript(s) in the page.

The one that is more interesting is “js/udg.js” as it’s actually redirecting visitors to another website serving “CVE-2014-6332

As you can see, the exploit is hosted on the domain “http://www[.]owner[.]com[.]tw
If you have seen the source of “new.htm” as shown below.
owner.com.tw.01
It looks almost identical to the one shared by @yuange75. I suppose this malware writer is quite lazy to change anything to it.

I actually found a total of 7 but some are sensitive to be shared. One of it was disclosed by ESET here:
http://www.welivesecurity.com/2014/11/20/first-exploitation-of-unicorn-bug/
The other 3 non-sensitive sites that i’ve found are from:
http://finance[.]cedare[.]int/luz.htm
http://www[.]edicot[.]com/lulz.htm
http://www[.]e-ctasia[.]com/lulz.htm

But interestingly for these 3, all are showing “Hacked by LulzSec” and the following is found in the page source.

My guess is the first one is probably not related to the other 3. But one thing is for sure, there are more of these websites serving “CVE-2014-6332” as we speak.
I’ll probably blog about the payload later.

[ Conclusion ]
Although i do not have the mass amount of data as AV companies or ThreatIntel companies to offer IOC (Indicators of Compromise), but i guess if i can find a few website(s) within a week. I suppose it’s is just a matter of time before ExploitKit(s) integrate this vulnerability to their existing toolkit. Since most of the Internet Explorer versions were affected, I guess user(s) of Internet Explorer should just update IE NOW!!!!!.

Happy Reversing
Jacob Soo

[ Super Funday Mini Series : LINE Forensic Artifacts – Android Edition ]

This is the 2nd article in the “Super Funday Mini Series” about recovering forensics artifacts from mobile applications for your digital forensics investigations.

Today, i’ll be covering about LINE Forensic Artifacts – Android Edition.
However, as i was writing this. I think lots more information could be uncovered if i were to reverse the application.
LINE (version 4.7.1 is the version which i did my testing on) is a cross-platform application that allows users to do voice call, send messages and share images with their contacts using Windows, iOS, Android, Blackberry, Nokia Asha, MAC OSX and Windows Phone devices.

[ Tool Used ]

[ Why are LINE Artifacts Important to Your Mobile Forensics Investigations? ]
Much like other IM (Instant Messaging) applications, LINE contacts, messages, and attachments are valuable to forensics investigators who are looking to recover evidence for a variety of different investigation types. Whether you’re analyzing the mobile device of a suspect or a victim, these chat artifacts can contain valuable information to help solve a case.

In order to gain access to the more important LINE artifacts, forensics investigators must root or get a physical acquisition of the Android device.
Some of the more important LINE artifacts in Android can be found at:

The “naver_line” file is a relatively simple SQLite database with 25 tables:

Inside the “contacts” table, each contact are given a unique identifier, “m_id”.
This table will include the contact’s name in addressbook, message status, timestamps, and other details.
Chat history in Line are kept under “chat_history” table. This table contains the messages along with timestamps and other relevant data.
Included in this table is message content, timestamps for sent and received messages, status, state (whether the message has been delivered, read, etc.) and attachments (if applicable).

If you start a “Private Chat”, it will also be stored unencrypted in “chat_history” like the image shown below.
LINE.003

Image 0 : Screenshot of “Private Chat” entry in LINE’s “naver_line” DB

However, the “Private Chat” entry will reside in that table for 1 minute before it’s being removed after the receiver reads the message.
In my experiment, i notice that the timer to remove the message will end a few seconds earlier than the timer on the sender’s end.
So what this means is that after the receiver starts reading the message, it will sync back to LINE’s server. LINE’s server will inform the sender and the timer will begin.

What is interesting is that it is not deleted after 1 minute. The entry is removed but not permanently until some time later.
I extracted out the DB and still managed to recover the “Private Chat” message as shown below:
LINE.004

Image 1 : Screenshot of “deleted messages” which are not “deleted” immediately in LINE

The deletion of the “Private Chat” are controlled by the “Parameter” column in “chat_history” table.

If you were to view the “naver_line” DB, you will also notice that a typical private message is easily identified when you search for a user’s ID followed by “+private” as shown below
+private
or in my case
ua7e104955a98f119841feb96da47a0ef+private
followed by “1415376903” which is the timestamp of the message in Epoch timestamp

All messages appear together in the “chat_history” table, which can be challenging to sift through if multiple conversations occurred at the same time. To analyze these conversations properly, forensics investigators need to refer to both chat_id, which will identify who the conversation was with, and from_mid, which will indicate which party sent or received the message. Additionally, the “read_count” & “sent_count” column will indicate how many people were given message and how many had read the message.

The “naver_line_private_chat” SQLite database contains the following 3 tables:

A typical entry will look like this.
LINE.002

Image 2 : Screenshot of “naver_line_private_chat” in LINE

Another interesting DB is “line_general_key_value”, there is a “key_value_blob” table containing “PRIVATE_CHAT_PRIVATE_KEY” & “PRIVATE_CHAT_PUBLIC_KEY”
Probably need to fully reverse this application to see where this was used.

Even though there is an option to remove all the chat messages under
“Settings” -> “Privacy” -> “Clear Chat Messages”
It seems like it didn’t “Vacuum” the SQLite Database as required. Thus forensics investigators are still able to retrieve some valuable information from the Databases.

[ Timeline of LINE’s user ]
Another interesting artifact could be found under the following location:
/storage/sdcard0/Android/data/jp.naver.line.android/storage/obse/post/
Inside this folder, there are many files with random filenames.
These files contain the “messages” that a LINE user wrote under “Timeline”.
I have not reversed the application yet to fully understand what the struct will look like.

While this week’s blogpost seems not too comprehensive.
I do hope this “Super Funday Mini-Series” will be sufficient for others to pick up and further expand on the information that i’ve shared today.
Hopefully, i will find time to reverse this application and “find out the truth” on other parts which i didn’t cover today.

Happy Reversing,
Jacob Soo

[ Super Funday Mini Series : Viber Forensic Artifacts – Android Edition ]

This is the start of a series of blog posts about recovering forensics artifacts from mobile applications for your digital forensics investigations.
This series will be my tribute to LookOut Security for all the help they rendered, all the people there are very nice to me, especially Tim Strazzere, Marc Rogers, tamakikusu and Caleb Fenton. Thanks a lot.

Today, i’ll be talking about Viber Forensic Artifacts – Android Edition.
Viber (version 5.0.2.12 is the version which i did my testing on) is a cross-platform application that allows users to do voice call, send messages and share images with their contacts using Windows, iOS, Android, Blackberry, Symbian and Windows Phone devices.

[ Tool Used ]

[ Why are Viber Artifacts Important to Your Mobile Forensics Investigations? ]
Currently, smartphones are used worldwide by billions of people to communicate and keep updated with the latest news.
Smartphone users spend the majority of their time on their devices sending emails, surfing the web, updating their social network status and/or chatting with others using various applications.

As such, it’s getting important for people working in the field of #DFIR to investigate mobile applications such as the likes of Viber as part of the source for evidence, and the ability to recover data from this application will potentially become important to their investigations since Viber is widely used as shown by the numbers of installs indicated in Google Play Store.
viber.005

Image 0 : Screenshot of stats

For Android, most Viber artifacts relevant to forensic investigations are stored within SQLite databases, similar to other smartphone chat applications.
In order to gain access to the more important Viber artifacts, investigators must root or get a physical acquisition of the Android device.

Some of the more important Viber artifacts in Android can be found at:

These databases store details on the Viber user’s contacts, messages and attachments sent and received through the Viber application.

[ The Artifacts About The Viber User ]
Often in times during forensics investigation, we want to gather as much information about the user as possible. Information such as email used, phonenumber, contacts, activated SIM serial.
Viber stores information about:

We can cross verify some of the information with the .userdata file found in the location below.

[ The Key Artifacts That Need to Be Found When Investigating Viber ]
While doing mobile forensics, there are some key artifacts that we need to find in order to gain more insight about the Viber user.

1) Viber Contacts

Viber stores user contacts within the “viber_data“, SQLite database.

There are several tables in the SQLite database such as the following:

In a table called “phonebookcontact“, this list contains valuable information for all the Viber user’s contacts.
The table contains the following columns for each contact in the table.
_id, native_id, display_name, phonetic_name, phone_label, low_display_name, starred, viber, viber_out, contact_lookup_key, contact_hash_version, has_number, has_name, native_photo_id, recently_joined_date, joined_date, numbers_name, deleted, flags.
viber.001

Image 1 : Screenshot of viber_data SQLite DB

Right now, i have not determine how “contact_lookup_key” and “contact_hash” are generated and what is the purpose of these columns.

Another interesting table, “calls“, is useful for investigators to know whether that Viber user made or receive any calls. The calls are not limited to Viber to Viber users. It also contain information on Viber Out.

The table consists of these columns:

Some of the findings i made are:

  • The values in “duration” is measured in seconds
  • The timestamp in all the tables are in Epoch timestamp.
  • The values in “viber_call_type” means the following:
    * 1 – viber user to viber user call type
    * 2 – viber out call type

2) Viber Messages

Given that Viber is a IM with call capability, it’s likely that the most valuable evidence will be found in the conversation(s).
Earlier on, we mentioned that there is another SQLite database, viber_messages.
This DB comprises of the following tables:
android_metadata, conversations, group_conversations_extras, kvdata, messages, messages_calls, participants, participants_info, public_messages_extras, purchase, sqlite_sequence, stickers, stickers_packages

The particular table(s) which we are more interested in are “conversations“, “messages“, “participants“, “participants_info

All messages appear together in the “messages” table, which can be a uphill and challenging task if we were to sift through several conversations that could have occurred simultaneously.
To analyze these conversations, we need to always refer to “conversation_id” and “group_id“, which will help us in identify who the conversation was with
Additionally, if want to know whether the Viber user has read a given message (a value of 0 means read while 1 means unread) in the “read” column.

In the “participants_info” table, we can gather information on who are the friends of this Viber user and possibly the Geo-location if they had enabled that.

3) Viber Attachments

Viber also supports the transfer of photos. Photos – sent from either the camera or gallery – are stored on the mobile device.
It is also worth noting an attachment can include a “description” entered by the sender of the attachment. The “description” might or might not contain important information.

We can find out the exact location of all these photos in the “extra_uri” column in the “messages” table.
viber.002

Image 2 : Screenshot of attachments location in Viber

[ Recovering Clear Message History ]
There is a “Clear Message History” in Viber for users to delete all the messages.
While this may appear true if you use SQLite Browser to view the SQLite DB as shown here.
viber.003

Image 3 : Screenshot of deleted messages in Viber

However, if you were to open the SQLite DB with Notepad++ or any other hex editor, you may see this instead.
viber.004

Image 4 : Screenshot of “deleted messages” which are not “deleted” in Viber

As you can see, we managed to get back the supposedly “Deleted Messages”. 😀
While this might not be those super advanced articles. I do hope this “Super Funday Mini-Series” will be sufficient for others to pick up and learn more stuff about mobile forensics.

Happy Reversing,
Jacob Soo