Rice University logo
 
Top blue bar image
Comp527: Computer Systems Security
A graduate seminar: current topics in computer security
 

Archive for the ‘System security’ Category


Using WordPress? Be Careful…

September 26th, 2013 by Tanmay

It was in news that, in the past of a massive cyber-attack coordinated with a huge botnet against millions of websites based on the popular CMS WordPress, around 100000 servers were successful compromised fueling the malicious architecture used for the attack. Thousands of WordPress based websites have been hacked to compose a global scale botnet that is performing powerful DDOS attacks.

The news was reported by CloudFlare and HostGator that on April alerted the WordPress community on the ongoing massive attack launched against WordPress blogs all over the Internet, the alert was related to a massive brute-force dictionary-based attack conducted to expose the password for the ‘admin’ account of every WordPress site.

In August, 2013 researchers at Arbor Networks have discovered a botnet dubbed Fort Disco that was used to compromise more than 6000 websites based on popular CMSs such as WordPress, Joomla and Datalife Engine.

Case Study:

Pierluigi Paganini is Chief Information Security Officer at Bit4Id, firm leader in identity management, he is also a Security Evangelist, Security Analyst and Freelance Writer. Editor-in-Chief at “Cyber Defense Magazine”, Pierluigi is a cyber-security expert with over 20 years’ experience in the field, he is Certified Ethical Hacker at EC Council in London. His colleagues at TheHackerNews received a DDOS attack logs report from ‘Steven Veldkamp‘ that highlights that the victim’s website was under heavy DDoS attack recently, originated from numerous compromised WordPress based websites. It is highly probably that the ongoing attack is linked to the events occurred in April that allowed attackers to take control of a high number of vulnerable WordPress Hosts.

The attack logs from timing 23/Sep/2013:13:03:13 +0200 to 23/Sep/2013:13:02:47 +0200 revealed that just in 26 second attacker was able to perform a powerful DDOS attack from 569 unique compromised WordPress.

The list of sources used by attackers includes blogs of Mercury Science and Policy at MIT, Stevens Institute of Technology and The Pennsylvania State University.

According to statistics proposed by WP WhiteSecurity, from 40,000+ WordPress Websites in Alexa Top 1 Million, more than 70% of WordPress installations are vulnerable to hacker attacks.

Following is the statistics.

After analysis of Alexa top 1 million sites, 42,106 WordPress websites found in Alexa’s top 1 million websites. Out of which more than 50% are using old versions of WordPress which is vulnerable to attacks. Less than 5% websites upgraded to version 3.6.1 between the 12th and the 15th of September.

I think, if you are using any third party infrastructure, it is always your responsibility to keep it updated and secure. It will not only create problems for you but for the whole internet organization. As many simple hacking tools are freely available over internet also many YouTube videos, websites teach simple attacks, so we should at least be sure to keep our websites strong against such attacks. Owners of WordPress should first update their version to 3.6.1 and keep checking for newer.

Reference: http://securityaffairs.co/wordpress/18081/cyber-crime/wordpress-websites-ddos.html

Posted in Real world security, System security | No Comments »

Trends in Cyber Attacks and Sophistication of Attackers

September 22nd, 2013 by Tanmay

The European Network and Information Security Agency (ENISA) is an agency of the European Union. The objective of ENISA is to improve network and information security in the European Union.

ENISA published a new report titled ENISA Threat Landscape Mid year 2013 that provides an interesting update for the list of top cyber threats.

The ENISA Threat Landscape Mid year 2013 analyses 50 reports, and identifies the trend for main threats to:

•             Infrastructure

•             Mobile devices

•             Social media

•             Cloud services

 

 

The document highlight that cybercrime increasingly using sophisticated techniques for the attacks, the hackers are improving methods to be non-traceable and to make more resistant their malicious structures to take down operated by law enforcement.

I will strongly suggest to see this TED talk by James Lyne: http://www.youtube.com/watch?v=fSErHToV8IU

He tells many of the attacks and the frameworks/ infrastructure attackers use for increasing efficiency of the attacks.

Drive-by download means two things, each concerning the unintended download of computer software from the Internet:

1.            Downloads which a person authorized but without understanding the consequences (e.g. downloads which install an unknown or counterfeit executable program, ActiveX component, or Java applet).

2.            Any download that happens without a person’s knowledge, often a computer virus, spyware, malware, or crimeware

Drive-by downloads may happen when visiting a website, viewing an e-mail message or by clicking on a deceptive pop-up window: by clicking on the window in the mistaken belief that, for instance, an error report from the computer’ operating system itself is being acknowledged, or that an innocuous advertisement pop-up is being dismissed. In such cases, the “supplier” may claim that the user “consented” to the download, although actually the user was unaware of having started an unwanted or malicious software download. Hackers use different techniques to obfuscate the malicious code, so that antivirus software is unable to recognize it. The code is executed in hidden iframes, and can go undetected.

A drive-by install (or installation) is a similar event. It refers to installation rather than download (though sometimes the two terms are used interchangeably).

We observe that, Drive-by-exploits: browser-based attacks still remain the most reported threats, and Java remains the most exploited software for this kind of threat.

 

Some concluding remarks:

1. Cyber-criminals constantly adapt to advanced techniques. They use methods that make them untraceable and difficult to turn down.

2. As the use of mobile devises and social media is increasing, those are and will be the most targeted platforms of the attackers.

 

References:

1. http://securityaffairs.co/wordpress/

2. http://en.wikipedia.org/wiki/European_Network_and_Information_Security_Agency

3. http://en.wikipedia.org/wiki/Drive-by_download

4. http://www.youtube.com/watch?v=fSErHToV8IU

5. http://securityaffairs.co/wordpress/wp-content/uploads/2013/09/ENISA-Threat-Landscape-Mid-year-2013.jpg

 

Posted in Real world security, System security | No Comments »

Build a Remote RFID Card Reader

December 6th, 2012 by Martha

Back in May, this post at Hackaday linked to a relatively easy to build RFID reader.
It looks like it would be somewhat inexpensive (less than $100) to build.

The trend towards putting RFID chips in credit and debit cards is a little disturbing, as its fairly easy and relatively cheap for an attacker to build even a simple longer range RFID reader. While this reader doesn’t read more than a foot away and doesn’t deal with the sort of encryption that should be on your debit cards (ha), its totally possible that an actual attacker could come up with something better.

To counter this attack, wrap your RFID cards or the inside of your wallet with aluminum foil. That should make it harder for a long distance reader to read.

Posted in Articles, Real world security, System security | No Comments »

X-Ray for Android

October 17th, 2012 by bss4

X-Ray is an Android app developed by Duo Security (http://www.duosecurity.com/) that scans your device for vulnerabilities that could be potentially exploited. It focuses on privilege escalation vulnerabilities: the sorts that would make the attacker root.

App scanning vs. system scanning:

X-Ray does not scan apps, it scans the device’s firmware (or ROM) comprising, among other things,  the underlying kernel, third-party native libraries and any system binaries.


Source: http://www.arm.com/images/androidStack.jpg

In Android’s software stack (see picture), this means the linux kernel, certain library components e.g., WebKit, libc among other things. System binaries that are utilitarian in nature e.g., logcat, adb are also part of the ROM that X-Ray app scans.

As one can see, it is clear that X-Ray chooses a different layer of the software stack altogether to scan for vulnerabilities. Mobile anti-virus apps rely on scanning applications per se while X-Ray scans the underlying system software whose vulnerabilities the malicious apps exploit. The argument put forward by the authors of X-Ray is that fingerprinting malicious apps can get out of hand considering the fact that slightly different variants of known malware are engineered on a regular basis and catching up with this not only requires time and effort but does not do a good job: malware that has not been fingerprinted yet can evade anti-virus checks. Note that there are a large number of app developers whose code needs to be fingerprinted and on a platform like Android, the inertia for becoming a developer being low, anyone/everyone could be an app developer.

Accountability:

On the other hand, system software (kernel, open-source libraries etc.) operate in a more controlled environment: people who maintain these things are fewer in number albeit distributed. For instance, issues in Android’s linux kernel ought to be tracked by Google, OEM’s like Samsung and/or Carriers such as T-Mobile; open-source libraries are maintained by known entities whose responsibility it is to track and resolve known (security) bugs. This means that, unless a vulnerability is solely at the application layer, one could attribute a given security bug to a known entity where the bug exists. From then on, it’s the entity’s responsibility to fix this bug and not let malware writers exploit it. In contrast, classical anti-virus solutions only tell the end-user if an app is malicious or not; the blame is solely on the app developer. The end-user does not have the knowledge of where the fault for the malware lies: Is the malware writer (app developer) doing something nasty on my phone or is he/she simply exploiting a known fault in the system software?

X-Ray scans the system software and (with user’s consent) collect information on what vulnerabilities persist on a phone’s ROM. Assuming the app becomes popular with the users and many install them and consent to the app collecting security related information, it would be interesting to see if and how the blame is shared among different entities. For instance, to what extent is Carrier X to blame for not shipping a security patch for a known bug? This, in turn, could motivate a collective petition on the users’ part seeking immediate remediation from the entity who is to blame. The authors of X-Ray concede that the incentives for a given entity to expend effort pushing a patch are skewed: let’s say a device A from carrier X has a known unpatched vulnerability; while X gets to work on updating all device A’s, a new device running the latest ROM (patching the known vulnerability) is out and users have started upgrading to this new device, perhaps more due to wanting a newer phone that wanting a more secure phone. How does this incentivise X? Questions like these require a more broader study on the cost-benefit aspects of patching and patch deployment.

Conclusion:

Personally, I feel X-Ray is a step in the right direction. From their website, I gather that they have some preliminary dataset from about 20,000 Android devices that have installed their app, and they have found that over half of these have unpatched vulnerabilities. For those interested, one of the main chaps behind the app, Jon Oberheide, has an upcoming webinar next week. See http://info.duosecurity.com/webinar-mobile-vulnerabilities

Posted in Android, System security | No Comments »

On the security implications of C2DM

September 29th, 2012 by bss4

When I read about Google’s Android Cloud to Device Messaging (C2DM) framework—its successor is named Google Cloud Messaging (GCM) for Android [1] —back when it was introduced, I thought it was a security faux pas on Google’s part. In short, the GCM framework allows Android app developers to register with Google’s push notification service which allows the former to send short messages to end-user devices on which the former’s app has been installed. The message is sent from the app developer’s (remote) server via Google’s servers to the device. Conforming to Google’s open policy, there is no vetting: any app developer can choose to use GCM as long as he/she declares the relevant permissions in the manifest and the end-user approves the same during application install process. To make matters worse, attackers could simply repackage a good app, embed it with a C2DM-based channel and use the latter maliciously. In our first class presentation on [4], Lee and I spoke of how prevalent repackaging and its subsequent deployment on third-party app markets is, in the malware writers community: The study found that 86% of malicious apps found in third-party Android markets are repackaged.

With a hunch that I was right, I searched Google for “exploiting c2dm” and the first result was a paper titled “Cloud-Based Push Styled Mobile Botnets…” [2]; why not? The paper has been selected for this year’s Annual Computer Security Applications Conference (ACSAC). But first, a bit about C2DM…

C2DM

An app developer, say Charlie, signs up with C2DM by providing a username, password and the package name for his application. The following protocol ensues:

a) Charlie’s application, say its called BotMeister, registers itself with a C2DM server providing Charlie’s C2DM username and the device ID of the phone on which it is installed. Note that a device ID uniquely identifies a phone. Also, this step presupposes that BotMeister has been installed by the user who has consented to the app’s C2DM specific Android permissions [1].

b) The C2DM server provides a unique registration ID to BotMeister which identifies the device it is running on. (Are you thinking why they don’t reuse device ID?)

c) BotMeister sends the registration ID in (b) along with its C2DM username (same as Charlie’s C2DM username) to Charlie’s server. Google obviously doesn’t want Charlie’s server to know end-user’s device IDs. No wonder C2DM server generates a new Unique ID for the device.

d) Charlie authenticates to a C2DM server with his credentials after which he is handed an auth token by the server; subsequently, Charlie packages the auth token, his message and the registration ID in (b) and sends it back to the C2DM server to be relayed to a device where BotMeister is installed. Note that, Charlie can only send a message to one device at a time. GCM, however, allows multicast messages.

e) Finally, the C2DM server forwards the message to the device ID that maps to the registration ID contained in the message. If a C2DM connection is not active on the recipient,  it stores the message and sends the message when the device eventually establishes a connection.

Given the basic protocol of C2DM, it is not hard to conceive of a botnet framework built on top of it. Charlie’s BotMeister can do bad things on devices it is installed on by using information contained in a C2DM message. Firstly, the message could be a malicious payload that escalates privileges on the device; secondly, C2DM could simply be used to create and subsequently remote control bots (Charlie’s victims) from Charlie’s Control and Command (C&C) server. The paper talks of the latter. Now, a bit about the paper.

C2DM Botnet

The botnet functionality itself isn’t interesting; the authors of the paper build a botnet by the book e.g., collect user info. What is  interesting is that their framework strives to be as stealthy as possible to evade detection. Also, they attempt to make their bot design both scalable and fault tolerance.  It is stealthy in the following way: The framework cleverly modifies step (c) in the C2DM handshake protocol (preceding section) by making BotMeister communicate to Charlie’s server via a C2DM server. The idea is that, a defense to the proposed attack might inspect URLs to which BotMeister is communicating. By relaying the reply via C2DM, the recipient as seen by the device is a C2DM server, not Charlie’s.

Scalability is necessary in C2DM because, one is allowed to send at most 200,000 messages per day. GCM, however, does not have a daily quota: more the merrier. Scalability is addressed by proposing a variant of the C2DM handshake protocol where Charlie has registered with multiple usernames and uses each to create a subnet of bots.

Fault tolerance is necessary because, Google could deregister a C2DM username that is seen to be doing bad things. The scalability solution helps tolerate disruptions to a certain extent, since Charlie could use alternate usernames that have not yet been banned. Also, it is possible for Charlie to have alternate C&C servers as back up, making detection of malice more difficult.

 Prototype

The authors’ prototype is a neat example of a real-world botnet framework using C2DM. Apart from the things mentioned above, the authors present an evaluation of the prototype that shows that not only does their framework utilise resources optimally (small network bandwidth, power consumption) but also makes application of classic anomaly based intrusion detection techniques difficult because of seemingly small differences in resource usage between a normal and an infected device. For more, read the paper 🙂

Summary

C2DM/GCM for Android introduces a new attack vector in the Android ecosystem. The discussed paper provides a real-world prototype of a botnet framework based on it. Conceptually , C2DM/GCM bloats up the already unmanageable Trusted Computing Base [3] (comprising of Linux kernel and Android middleware) of Android by adding remote entities to it that engender no trust at all. Consequently, even if Google hardens their operating system, attackers can control the device remotely.

Also, Google is not the only platform that offers such a push notification service to developers. Apple, Microsoft, Blackberry and Symbian all have similar push notification frameworks that beg to be examined more closely.

References:

[1] Google Cloud Messaging for Android: http://developer.android.com/guide/google/gcm/index.html

[2] “Cloud-Based Push-Styled Mobile Botnets: A Case Study of Exploiting the Cloud to Device Messaging Service”, S. Zhao et. al., http://www.cse.cuhk.edu.hk/~pclee/www/pubs/acsac12.pdf

[3] Trusted Computing Base: Wikipedia, http://en.wikipedia.org/wiki/Trusted_computing_base

[4] “Dissecting Android Malware: Characterization and Evolution”, Y. Zhou et. al., http://www.csc.ncsu.edu/faculty/jiang/pubs/OAKLAND12.pdf

Posted in Android, Articles, C2DM/GCM, System security | No Comments »