Sunday, June 12, 2016

My Thoughts On "no internet for the public sector"

What up.

Recently, Singapore government has decided to cut off the internet for public servants for security reasons. It was said that we are one of the prime targets. WHO ISN'T?
To read more, goto:

What are my thoughts on this?
*It was first written on a facebook comment in response to an annoying post with bad analogy. I wanted it to be a sharp and poignant comment but it ended up as a wall of text. So, I've decided to put it up just in case anyone tries to pull off another BS on how it was a good decision to cut off the internet.

No internet but haz email??? 
It's not pragmatic. Attackers will hit the systems which requires internet access and perform lateral movement from there onwards. Exposure is limited, but not eliminated. Moreover, emails are still active and IS a point of entry. AV is good at preventing known threats from entering but most malware are bespoke and mutate faster than an AV can keep up (e.g. it will be weeks before AV gets updated to prevent a APT malware. it will be months before systems get patched for zero-days). It is possible to worm through a network without requiring internet access. Yes, no internet = no beaconing back to C2 (command and control) server, but doesn't mean malware can't work. Malware can still worm through operating system vulnerabilities, performing lateral movement like a human attacker, and it's a matter of time a malware propagates and find exfiltration points to beacon or bring data out. So eliminating Internet keeps employees safe? To a certain point, but you need to truly air gap your systems i.e. no emails from the internet. But no one can truly work pure intranet email can they? Since they rely on AVs for email entry (and they better be), why don't they allow internet via proxy servers (e.g. all HTTP/HTTPS have to go through these machines for internet access.) Keeping email while eliminating internet is like stop eating ice cream to cut down calories but keep going nuts on oreo cookies thinking that they are not as sugary. This is a security architectural problem. Pulling out the WAN cable is at best naive. If government agencies want to be truly secure by this logic, PEN AND PAPER PLEASE.

A Short Note on Defense
So how to defend? Preventive and detective controls. Makes it hard and expensive for attackers to get in and maintain control. Preventive controls - the usual patch management, app whitelisting, host AV, exploit mitigation such as EMET, etc etc. But mistake not, for they will NOT prevent. They are there to be speed bumps and trip wires. E.g. if you got AV, attacker will need to evade and may avoid touching disk. This could mean powershell, dll injection, reflective dll loading, etc. If you are patched up timely, attackers need to spend $$ using their expensive zero-days. When it's used and found during forensics, it's no longer zero-day or as effective. If you got exploit mitigation, attackers need to make exploits that evades exploit mitigation. If you got logging in-place, attackers cannot perform active brute force methods as they may give off their position. If you got..ok you get what I mean. This goes the same with application whitelisting, configuration hardening and other forms of controls both endpoints and servers.

Detective controls - first harden every route except to leave one or two paths for attackers. Why do this? 1) Able to map out likely attack paths for easier detection; 2) Place more sensors on those paths for higher detection rate; 3) Decrease false positives thus allowing analysts to concentrate their effort in hunting down threat actors rather than responding to random events happening all over the network. Going further, implement Honeynet/honeypot within the network - placing systems within the organisation that no one would normally or ever access, which serves the purpose to trigger off alerts whenever a foreign threat actor logs in. This will trip up attackers when they are performing lateral movement. And yes, they WILL perform lateral movements. =) And there are more to talk about such as going beyond network and do endpoint threat detection or EDRs, basically. Hunt for IOCs instead of being event-driven. Yada yada...

The landscape has changed so much - you can no longer expect to keep attackers out. It's not about "if" but "when". Security professionals' job is to give a hard time for attackers to come in and when they do, be able to detect and triage before they do any significant damage (e.g. exfil data, service denial, make watering-hole points.). Most organisations doesn't even know that a threat actor is within their network until 6 months or until a "sale" on the darknet.

We need to do better than pulling out the ethernet cable. Don't you fucking giving up on us!


Saturday, April 2, 2016


*Warning: This has nothing to do with security. Read at your own risk! :D

Do you have issues detecting your new SSD on windows 10? You're able to detect the SSD properly on your BIOS but Windows 10's Disk Management shows up nothing? Perform 'Windows Memory Diagnostic'. Yes, it made no sense but it worked for me. After WMD is done with the 2 passes, boot in the OS and go to your Disk Management. You'll be prompt to initialize your shiny new SSD.
*This happens to my new samsung evo 850 250gb. 

Good luck, have fun! :)

smile emoticon

Tuesday, November 3, 2015

Virtualbox Guest Additions on Kali 2.0

Yello peeps.

Having problems with your Kali 2.0's screen size and needs a fix from the Virtualbox additions to get it right yet it's not installing properly? Don't fret. Try this:

Kali 2.0 not installing Virtualbox Additions properly >:|
Like many of the folks over teh internet, I had problems installing virtualbox additions in the new Kali 2.0. 
What didn't work: 
- Initially I was using the 32-bit version. Got error messages such as  "Building the VirtualBox Guest Additions kernel modules...failed". So I re-downloaded the Kali 2.0 but the amd64 version. Still got the same error messages. >:| 

What works for me:
- Initially I was using Virtualbox 4.3.10. Reading the comments, Felix emphasized that he used 4.3.30 which I suspected was the case. This is Felix's guide.

What I did - Uninstall Old VirtualBox and Install VirtualBox 4.3.32:
1) On my host machine (I'm on Ubuntu 14.02 Trusty): 
$ sudo apt-get purge virtualbox
// So that essentially uninstalled my virtualbox 4.3.10 on my ubuntu host machine
// If you're on windows, uninstall your old virtualbox. Your virtual machines should still be intact. I'm not using windows, so careful with the wizard prompts.

2) Downloaded the Virtualbox 4.3.32 from main site. If you are using older linux like mine (14.02 Trusty), you may want to use this link:

3) After installation, your virtual machines WILL crash as you're still on the old extensions. Within the virtualbox  GUI, click HELP -> CHECK FOR UPDATES. Mine returned a "network operation failed..unknown reason", so I closed the update window but got a pop up instead, asking if I would like to install the new extensions to replace the 4.3.10 old ones. So I agreed and re-downloaded and installed the extensions via the GUI.

4) Reboot the machine (may not be necessary but I wasn't able to unload and reload the vboxdrv so what the heck, i restarted my host machine.)

5) Boot back into my Kali 2.0 amd64 and tried the new VBoxLinuxAdditions. VIOLA! =D Happy me.

So what was the problem initially?
Just old version of Virtualbox didn't work. Felix said 4.3.30 works for him. I installed 4.3.32, works for me. :) 

Still having problems?
Try reinstalling your dkms on your linux host machine:
$ sudo apt-get install --reinstall dkms
And reboot your machine.

Hope this helps.

Peace out,

1. Felix's guide on install Virtualbox Guest Additions on the Kali 2.0
2. Virtualbox download links for older machines:

Thursday, October 29, 2015

2 LOWs can make 1 HIGH

Hello Peter, what's happening?

I have a day job that requires me to risk rate security vulnerabilities pretty much all the damn time. :D The risk rating portion isn't too bad but it's not hard to get challenged for the certain rating you give. Anyway, the main point of this post is: LOW doesn't mean OK-LETS-NOT-GIVE-A-SHIT. A combination of two LOW-rated vulnerability items could bring about a serious security breach.

For example, two LOW-rated issues:
Vulnerability ONE: Information disclosed in Perfdump file
For Oracle iPlanet Webservers, sysadmin can choose to dump out system performance information on a file named '.perf' in the webroot using the PerfDump functionality of the webserver.

According to Oracle's guide [1]:
"perfdump is a Server Application Function (SAF) built into Web Server that collects various pieces of performance data from the Web Server internal statistics and displays them in ASCII text. The perfdump output does not display all the statistics available through the command-line statistics or the Admin Console, but it can still be a useful tool. For example, you can still use perfdump even if the Administration Server is not running. You can view the perfdump output through the CLI, which is enabled by default, or you can view the perfdump output through a URI, which you have to enable. If you enable the URI, you must control access to the perfdump URI, otherwise it can be visible to users."

You'll get information displayed in ASCII text in the file.

webservd pid: 29133

Oracle iPlanet Web Server 7.0.9 B07/04/2010 02:06 (SunOS DOMESTIC)

Server started Fri Jul 14 14:34:15 2006
Process 29133 started Fri Jul 14 14:34:17 2006

Current/Peak/Limit Queue Length            2/237/1352
Total Connections Queued                   67364017
Average Queue Length (1, 5, 15 minutes)    4.52, 4.73, 4.85
Average Queueing Delay                     13.63 milliseconds

ListenSocket ls1:
Acceptor Threads          1
Default Virtual Server    https-test


You can also obtain the following information:
Process  Status    Client     Age  VS          Method URI                                      Function

29133    response  115  https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  8    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  4    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  4    https-test  GET   /perf                                     service-dump
From the above, you would obtain information such as IP addresses, HTTP Methods and the URLs&Parameters information on the clients that are connecting to the web server (or simply, people using/browsing the application hosted on the webserver). How helpful :) but no, no serious problems...yet.

Now let's introduce another vulnerability:
Vulnerability TWO: JSESSIONID disclosure in the URI
In my career, I've seen this issue a couple of times. Well, no sweat, no debate and everyone would agree it's a LOW or maybe (with MUCH arguing) at max a MEDIUM risk as there is no direct impact. But what happens if the session ID gets exposed on..say.. a Perfdump file? 

An example on what could be exposed in the PerfDump file:
Process  Status    Client     Age  VS          Method URI                                      Function

29132    response  115  mahapplication  GET   /admin/index.jsp?jsessionid=1A530637288A03B07119A44E8D532428             admin-portal

Ok. Ermm. Houston, we have a problem. 

Vulnerability ONE and TWO on their own wouldn't pose much of a security threat, however, putting them together could be a 'PWN' rated issue. If the webserver is in production serving web contents to the internet, any one on the internet would be able to gain access to[NOT-REAL]/.perf to obtain the application session ID of a authenticated user (or in this case, possibly the web administrator) by repeatedly requesting this PerfDump file over a period of time. When the user performs a request, the 'jsessionid' would be exposed and be reflected on the PerfDump file. The attacker could then harvest the 'jsessionid' from his requested-over-time PerfDump recon logs to hijack the session.

How to prevent this from happening, you asked? 
Do not ignore your LOWs and FIX. EVERY. SINGLE. DAMN. THING. :)
I use to suggest "You know what, this isn't a big of an issue. Meh, you can let it slide." After that day, I would say: "This isn't a big of an issue. But you know what, fix it anyway."

And ladies and gentlemen, this is my 2-cent contribution to the LOW2PWN community. Thank you very much.


1. Perfdump -
2. OWASP on Session Management -

Saturday, May 17, 2014

Hack Your Homeplug?


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 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
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? :)

1. Special thanks to Zibri -
2. Homeplug chipset hardcore specs -
3. The 'faifa' tool -

For fun but not much profit,
Jeremy S.

Tuesday, April 22, 2014

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:

Yours sincerely,
Jeremy S.

Saturday, April 19, 2014

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
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.

Injection payload:
<button onclick="location.href=''" id="1" value="1"/>BreakToProtect's Button

 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 '' 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:
The fix was done at the backend - users do not have to worry about using older versions of Feedly.