Tag Archives: Hack

In this day and age where everything is measured, recorded, and available remotely (via a REST API most of the time!), it really bothered me that our heating oil tank measured the remaining gallons of oil by a crude plastic dip stick. It’s not accurate, there is no historical data, and there is no way to audit (for honesty, accuracy, or problems/errors).

So the problem is simple enough: Find a quick and easy way to remotely monitor the number of gallons of heating oil in a home, and alert at pre-set intervals (let’s say 75%, 50%, and 25%) of remaining oil in the tank.

After looking for commercial solutions, the cheapest one I found is $120 with a $10/year fee. In my view, that’s simply ridiculous. I decided that I could build something better for 1/3rd of the price ($40), without an yearly fee.

Hardware How-To

Start with this Instructable I created with the exact parts/steps, and with lots of pictures:
https://www.instructables.com/id/Monitor-Heating-Oil-Tank-Gallons-With-Email-SMS-an/

This should take care of the hardware side.
Continue Reading →DIY – Monitor Heating Oil Tank Gallons with Pushbullet, SMS, and Email Alerting

[ updated 10-30-2016 | Upgraded Plex to plexmediaserver-1.1.4.2757-24ffd60.x86_64.rpm and CentOS ]

Recently I tried setting up a Plex server in a docker container. The first problem was the 127.0.0.1:32400 bind which required logging in locally or port forwarding. After doing this once, I realized that you could use the Preferences.xml file, but that meant that you couldn’t truly automate this/deploy it elegantly in a docker container. And what if you wanted to run other servers — for friends? I finally figured out how to do this in the most elegant way possible.

First – Grab your Unique Plex Access Token

Login at https://app.plex.tv/web/app with your username and password
Open your javascript console (in Chrome: View -> Developer -> JavaScript Console)
and type:
console.log(window.PLEXWEB.myPlexAccessToken);

Note the token, which will look like this: “PZwoXix8vxhQJyrdqAbY”

At this stage DO NOT click log out of your account until you register the new server. Otherwise your token will regenerate.
Once you register the server, it won’t matter after that if the token changes.

Grab my Docker Image

Check out: https://hub.docker.com/r/ventz/plex/
You can pull it down by doing:

Continue Reading →Plex server on a VPS Docker setup without port forwarding

Lately, we have seen some really bad vulnerabilities in regards to SSL (Heartbleed) and Bash (later dubbed “Shellshock”), along with some slightly “lighter” linux/open source ones.

In September of this year, Google first discovered a fallback attack for SSL v3.0, and they wrote published a paper on it: https://www.openssl.org/~bodo/ssl-poodle.pdf.
Today, it was officially confirmed that SSL version 3.0 is no longer secure, and thus, it is no longer recommended in client software (ex: web browsers, mail clients, etc…) or server software (ex: apache, postfix, etc…).
This was dubbed the “POODLE” vulnerability, and given CVE-2014-3566

A “POODLE attack” can be used against any website or browser that still supports SSLv3.
Browsers and websites need to turn off SSLv3 as soon as possible in order to avoid compromising sensitive/private information. Even though a really small percent of servers/browsers are vulnerable (mozilla estimates 0.3% of the internet), that is quite large in the total number of users.

How can I check if my browser is Vulnerable?
The guys at dshield setup this nice browser check: https://sslv3.dshield.org:444/index.html For checking your browser, use: https://www.poodletest.com

Poodletest was first mentioned to me by Curtis Wilcox.
Continue Reading →OpenSSL – SSL 3.0 Poodle Vulnerability

As some of you may have heard, a very serious remote vulnerability was discovered disclosed today within bash.

A quick summary of the problem is that bash does not properly process function definitions, which can be exported like shell variables. This is a bit like a SQL/XSS injection problem — you provide an “end” to your input, and continue writing other functions/calls after it, which then get executed.

A quick example:

A vulnerable system looks like this:
vulnerable!

A patched system looks like this:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’

Continue Reading →Bash remote exploit vulnerability

UPDATE: Insecure has released v6.46 which contains all of these patches. Just grab the latest and follow the usage info here

If you don’t know what Heartbleed is, you can find out here: http://heartbleed.com/. If you don’t want to read the details above, XKCD put together a great short comic about it: http://xkcd.com/1354/

NOTE: I first put this together 3 days ago, but I am just now releasing after being asked by many people for the package and directions.

The problem: How do you scan a bit more than 5 class B’s (~328000 IP addresses) before any off the vendors (Tenable, Qualys, Rapid7) have released signatures? Easy – you build your own!
The goal was to scan as many IPs as possible at work as quickly as possible.

After using the Heartbleed github project (https://github.com/FiloSottile/Heartbleed) and creating a Dancer web service around it, I realized that there still needed to be a faster way to scan for this. How much faster?

How about a /24 (254 IP addresses) in less than 10 seconds.

I have a patched version of NMAP already (6.40) that has Heartbleed checks.
Again, Insecure has released v.6.46 which has these patches. Grab that and follow these directions

Then, you can scan like this:

 

If you want cleaner results, for a script, a good way to filter the output will be with something like this:

This produced a clean 2 line result, where if it’s vulnerable, it will have “ssl-heartbleed” under each host/IP address entry.

 

How to build your own patched NMAP binary?

But what if you don’t trust my binary? Good – let me show you how to build one yourself:

Continue Reading →Ridiculously fast Heartbleed Subnet Scanner – nmap heartbleed howto and tutorial

There are many ways to exploit a web server and gain access to the file system – read or write (sometimes both). This becomes even easier when one hosts CGIs or other dynamic code – especially when that code includes user based inputs. Recently, I found one of the most elegant exploits that I have seen for this kind of an attack vector, so I wanted to go over it and share some information about how it works and what exactly it exploits.

To setup the background for this scenario, imagine a web server (ex: ‘www.example.com’) setup with userdirs, which allows CGI execution – not an uncommon situation at all. This means that ‘user1’ will have a directory like ‘public_html’, which will become directly accessible at: ‘http://www.example.com/~user1/’. For example, creating a ‘blah’ folder in ‘/home/user1/public_html’, will create ‘http://www.example.com/~user1/blah’ on the web.

At some point, ‘user1’ creates a file called ‘x.cgi’, which simply has a GET parameter called ‘file’, and if that parameter is a file that exists, it loads it via an include. Otherwise, it loads a default.html file. Let’s assume that ‘x.cgi’ is a PHP file which looks like this:

Continue Reading →Web Exploit – user modifiable Read and Execute can give you Write access

Setting up the network interfaces is something that seems to give people a hard time (clearly visible here: http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_network.html). If you follow that guide, one of the most confusing points is how the Open vSwitch fits into the existing architecture.

Assuming you are following the guide, you have 2 networks:
10.10.10.0/24 -> private
10.0.0.0/24 -> public

Your Network Controller, again per the guide, will have an internal-network interface of “10.10.10.9” and an external-network interface of “10.0.0.9”

Your starting network config (/etc/network/interfaces) file will look like this:

Now, you will first install the packages needed:

Then you will start the Open vSwitch:

Continue Reading →OpenStack – Network Controller – Open vSwitch – Network Interfaces Config

Recently, while setting up my the network controller for OpenStack, I saw this message:

# tail -f /var/log/quantum/openvswitch-agent.log

ERROR [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Failed to create OVS patch port. Cannot have tunneling enabled on this agent, since this version of OVS does not support tunnels or patch ports. Agent terminated!

What this means is that the versio of the datapath (shipped by Ubuntu) does not have the support needed to create tunnels or patch ports. This happened on Ubuntu 13.04.

Fortunately, it is VERY easy to solve this. You need to simply build your own datapath for your kernel. For this, you OpenvSwitch’s datapath source, and you need module-assistant:

You can then grab your kernel headers and any other dependencies:

I noticed that either the kernel headers do not have the version.h in the right place, or the module-assistant looks in the wrong place. You can solve this by doing:

And finally, to download, build, and install the modulle:

Now, reboot your system so that the new module is loaded, and you are ready to go. You will notice that “/var/log/quantum/openvswitch-agent.log” no longer has this issue.

The Scenario:

Let’s say you are at a coffee shop with public internet access, and you don’t want someone snooping on your traffic, so you VPN to your work. However, you also don’t want to tunnel personal stuff out of your work VPN (chat, facebook, youtube, your personal email maybe?), so the question becomes, how do you create 2 different firewalls – one that ONLY allows you to VPN and does not allow any other applications access, and one that then controls the traffic within the VPN channel so that you can utilize the connection for some apps but not others?

At this point, there are only 2 “methods” of running a Firewall on Android: having root and managing/accessing IPTables, or, the only alternative – creating a sub-VPN channel that you pipe the traffic over and filter (which does not require root). Unfortunately, the second type (without root) will not work for this, since we will need to utilize the VPN channel ourselves for our VPN, and to my knowledge, Android let’s you setup only 1 active VPN channel. So, you need 1.) a way to root and 2.) a good Firewall

Continue Reading →Firewall the Inside of your OpenVPN or L2TP/IPSec Tunnel on Android

This will be my last post about the Google Nexus S since I just purchased (and received) my Nexus 4. That said, I really wanted to give one last update on the Nexus S since it looks like things have changed quite a bit with the update process. While it looks more complicated at first, it’s actually a lot more flexible now. Here is how to upgrade your Nexus S manually to a full 4.1.2 Jelly Bean, even if you have not received it yet/are in a country where the updates are not coming in, or are on a carrier which is not pushing OTA updates.

The first step is to go to Google’s Official Factory Images for Nexus Devices

Now, you have one of four choices for sections, based on your phone:

  • If you have the (MOST POPULAR) T-Mobile or ATT (GSM) version of the Nexus S, go to: “Factory Images “soju” for Nexus S (worldwide version, i9020t and i9023)”
  • If you have the Sprint (4G) version, go to: “Factory Images “sojus” for Nexus S 4G (d720)”
  • If you have the Korean version (VERY RARE), go to: “Factory Images “sojuk” for Nexus S (Korea version, m200)”
  • If you have the NON-1Ghz (STILL RARE) version, go to: “Factory Images “sojua” for Nexus S (850MHz version, i9020a)”

Let’s assume you have the T-Mobile/ATT one since most people have that.
You will want the “4.1.2 (JZO54K)” image, which you can download from their official link:

soju-jzo54k-factory-36602333.tgz
(md5: 788233dca5954532acda63039f814b4d)

Continue Reading →Google Nexus S – update manually to 4.1.2 Jelly Bean