Pianobar

INTRODUCTION

In this post I'm going to go over Pianobar. We'll grab the latest source, compile it, set it up, and run it. Pianobar is a awesome opensource console based client for Pandora Radio.

Step One:

First we'll need to install git so we can grab the latest source from github. We're going to grab the source from git so we have the latest code, otherwise we could easily install it from the repositories. So jumping to your terminal you'll just need to

$ sudo apt-get install git

Step Two:

We need to get the latest source of pianobar. So in the terminal again type the following

$ git clone https://github.com/PromyLOPh/pianobar.git

Step Three:

We need to install the dependencies for pianobar to work correctly. Again the your terminal type the following:

sudo apt-get install libao-dev libmad0-dev libfaad-dev libgnutls-dev libjson0-dev libgcrypt11-dev

Step Four:

Now all we need to do is compile and install the git source we got earlier. So in the same directory that you were in when you used git to get pianobar just `cd` to the pianobar directory and use:

$ cd pianobar
$ make
$ sudo make install

Step Five:

At this point pianobar should be installed assuming we didn't get any errors along the way. So the next step is to add information to the config file in your home directory. Pianobar should have a directory within the .config directory, if not create it.

cat ~/.config/pianobar/config

We'll need to add some information to the config file in order to make pianobar work correctly. If there is no config file in the pianobar directory create a blank text file named 'config'.

password = pandora account password here

Adding your username and password are optional, but it saves you from having to type in your username and password every time.

Step Six:

Now to run the beauty that is pianobar for the first time. You can run pianobar by just typing pianobar and hitting enter into your terminal.

Optional steps:

So now that we have pianobar functional we can work on other things. For instance getting our plaintext password to be encrypted, keybinding, etc.

Password Encryption:

Keybinds:

If you're using a multimedia keyboard, you can add keybinds for pianobar. For my setup I have a microsoft wireless comfort keyboard 4000, and I'm running crunchbang with openbox. Openbox keybinds are located in the rc.xml config file. What we'll also need is to grab control-pianobar.sh files. Make sure you're in your .config/pianobar directory before you use the following command:

git clone https://github.com/Bruce-Connor/control-pianobar.git

First we need to know exactly what the keys do in order to map them to a command. So we'll use xev tool for that. So in  your terminal type in xev and hit enter, next hit one of the multimedia keys on your keyboard. You'll see output like this:

KeyPress event, serial 46, synthetic NO, window 0x4e00001,
root 0x370, subw 0x0, time 2488373614, (943,113), root:(1395,1057),
state 0x10, keycode 164 (keysym 0x1008ff30,
XF86Favorites), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 46, synthetic NO, window 0x4e00001,
root 0x370, subw 0x0, time 2488373806, (943,113), root:(1395,1057),
state 0x10, keycode 164 (keysym 0x1008ff30, XF86Favorites), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

XF86Favorites is what we'll need to configure our keybind. So open up your rc.xml file and navigate to where the keybind area is and add the xml portion to execute a command from the control-pianobar.sh. The button I'm setting up is the "star" button on my keyboard which I'm going to use to tell pianobar that I like that song. In the rc.xml file I'm going to add:

<keybind key="XF86Favorites"> 
    <action name="Execute"> 
        <command>/home/xplicit/.config/pianobar/control-pianobar.sh +</command>
    </action> 
</keybind>

Now all we need to do is save the rc.xml file and reconfigure openbox then test it.

┌─[*********@*******]─[~/.config/pianobar]
└──╼ pianobar
Welcome to pianobar (2012.05.06)! Press ? for a list of commands.
(i) Control fifo at /home/username/.config/pianobar/ctl opened
(i) Login... Ok.
(i) Get stations... Ok.
  0) q   2Pac (Tupac) Radio
  1) q   A Day To Remember Radio
  2) q   Eazy-E Radio
  3) q   Eminem Radio
  4) q   Mac Miller Radio
  5) q   New Found Glory Radio
  6)  Q  QuickMix
  7) q   Tate Stevens Radio
  8) q   Travie McCoy Radio
[?] Select station: q
  6)  Q  QuickMix
[?] Select station: 6
|>  Station QuickMix
(i) Receiving new playlist... Ok.
|>  The Last Thing I Do by Tate Stevens on Tate Stevens @ Tate Stevens Radio
|>  I'd Rather Fuck You by Eazy-E on Eternal E (Explicit) @ Eazy-E Radio
|>  Mr. Highway's Thinking About The End by A Day To Remember on Homesick @ A Day To Remember Radio

You can see all my keybinds for pianobar here.

Links and Sources:

Pianobar Project
Bruce Connor fifo script

Dynamic Subdomains with OpenVPN and PyTinyDNS

Introduction

As I have covered in a previous post about PyTinyDNS there are multiple uses for a dynamic DNS service like this. One of my side projects is hosting a private Virtual Private Network (VPN). Along with hosting my own TLDs, I also wanted to have a custom solution for dynamically assigning a subdomain to each individual client that connects to the network. This way if the user happens to get assigned a different IP, others on the net will be able to easily connect to their services without any issues.

Redis

PyTinyDNS uses redis to make dynamic additions of domains and subdomains possible without adding extra config files or restarting the daemon. PyTinyDNS also comes with an import script that allows you to add either a text file full of domains or individual domains via the command line arguments. We'll strip the functionality from the import tool and use it to assign dynamic subdomains through OpenVPN's scripting features.

OpenVPN

OpenVPN comes with built-in options to add custom scripts that are triggered by multiple events. The following are example events that you can configure in order to take advantage of endless custom solutions.

• --up (Executed after TCP/UDP socket bind and TUN/TAP open.)
• --tls-verify (Executed when we have a still untrusted remote peer.)
• --ipchange (Executed after connection authentication, or remote IP address change.)
• --client-connect (Executed in --mode server mode immediately after client authentication.)
• --route-up (Executed after connection authentication, either immediately after, or some number of seconds after as defined by the --route-delay option.)
• --client-disconnect (Executed in --mode server mode on client instance shutdown.)
• --down (Executed after TCP/UDP and TUN/TAP close.)
• --learn-address (Executed in --mode server mode whenever an IPv4 address/route or MAC address is added to OpenVPN's internal routing table.)
• --auth-user-pass-verify (Executed in --mode server mode on new client connections, when the client is still untrusted.)

The only event that we need to watch in order to add custom A PTRs to PyTinyDNS is --client-connect. Go ahead and create a directory to store the custom script in.

$ mkdir /etc/openvpn/scripts

Now at the bottom of your OpenVPN server.conf, add the following lines.

script-security 2
client-connect '/usr/bin/python /etc/openvpn/scripts/connect.py'

The Script

The following is a quick Python script used to add the correct subdomain based on the user's common name used in the client's certificate.

#!/usr/bin/python
import redis
import os
 
def insert_record(domain, ip, redis_server):
 r_server = redis.Redis(redis_server)

 try:
  r_server.hset('pytinydns.domains', domain, ip) 
 except:
  pass

def main():
 redis_server = 'localhost'

 try:
  insert_record(os.environ['common_name'] + ".myvpn.net.",os.environ['ifconfig_pool_remote_ip'],redis_server) 
 except:
  pass

 return 0

if __name__ == '__main__':
 main()

The reason for the pass statements is that we must return the value 0 or OpenVPN will deny the client entry. If records are not being added, check to make sure that the server is running and that it is in fact running on localhost.

Now you need to restart OpenVPN in order for the changes to server.conf to go into effect.

$ sudo service openvpn restart

Considerations

Using the default configs with PyTinyDNS, non locally resolved domains are forwarded to the system's default DNS server. In order to avoid information leakage of local common names, you could implement a method to not forward any requests with a particular domain name or disable this option completely by setting the PyTinyDNS option "Resolve_Nonmatch" to no.

Debunking the False Security of Cardless ATMs

According to CNN, FIS financial services is launching a new way for customers to access cash without an ATM card or debit card. This technology has been piloted by three banks in the recent months using a mobile application called “Cardless Cash Access”, and is slated for widespread implementation by mid-2014. They claim it is safer than using an ATM card. First, lets review the process described there to withdraw from an ATM without the use of a card:

1. Log into an application on your mobile device that interacts with your bank
2. Place an order for your cash
3. Upon arrival to the ATM, use the application to scan a code on the ATM to prove you are physically there
4. The ATM sees that you are there and relinquishes the requested cash

This methodology was reviewed by Mary Monahan of Javelin Strategies & Research, and she labeled it as more secure than traditional ATM cards for the following reasons:

• Because there is no card, there can be no “card skimming”
• In the event your phone is stolen, the application still needs additional log-in information and PIN information

A card skimmer is a small hardware device that can be inserted into an ATM to record the information on the ATM card when it is inserted into the machine. Her full analysis of FIS' program, “Cardless Cash Access”, is behind a pay gate; I wasn't about actually pay money for something that should be completely free information. Besides, she's wrong.

Construction of an ATM “card skimmer” is difficult, and placing one is risky to any potential attacker. Retrieving one could be even riskier. I'd argue that this technology is even less safe than online banking. Online banking can be unsafe due to the fact that malware and software viruses can record information on a victim's computer, allowing criminals access to bank accounts; however, the criminals in question have to jump through many hoops to actually turn this online access into cash that they can use. Usually they lose some of the money in the process, and there's a trail leading back to them. To avoid this they use scams to trick yet more victims into withdrawing and depositing the cash for them, usually with something like western union, so that transactions cant be “charged back” or otherwise tracked back to the criminal.

With the advent of mobile malware, I've uncovered a hypothetical way that criminals could cause much more severe damage. Similar to computers, mobile phones can be vulnerable to keylogging attacks. A keylogger is a piece of software that allows an attacker to record the buttons pressed on a keyboard, or in this case, the software keyboard on a smart phone. Smart phone keyloggers already exist, and are nothing new. Also similar to computers, proxy software can be installed on a mobile phone. Proxy software is software that allows a user to use a computer or mobile device to make it look like they are coming from the device the proxy is on, as opposed to their real location.

So what relevance does this have to “Cardless Cash Access”? Its simple, really. An attacker could create a piece of malware that infects a person's smart phone with both a proxy and a keylogger. From there, he could record the information entered into the application. After that, it would be trivial to install the application on his own mobile device, log in, request cash, and scan the ATM code. Suppose for a moment that this didn't work, for whatever reason (like the application being locked on a per-user basis to a particular phone). At this point, the attacker could use a proxy in the malware to impersonate the victim's phone, upload the scanned key to the application from the victim's phone, resulting in the ATM dispensing the cash anyway. Not only does this make it easier for cybercriminals to access the data required without physical intervention, it also makes it easier for a criminal to turn his access directly into cash without using a scam or jumping through the various hoops required while using a skimmer. There is also much less risk involved to the criminal. To hide his or her identity and “cash out”, the criminal only need bring a can of black spray paint to the ATM camera.

I talked with a mobile malware analyst, Matt McDevitt, to get an idea of how easy it would be for a malware author to write such a virus, and to determine the likelihood of such an attack. He responded saying that it would be incredibly easy for a malware author to write and deliver such a virus, and that the likelihood of such a virus being written is extreme. He further went on to say, "another [malicious] provider could come out with a trojanized version of this application". What he means here is that someone could unpack the "Cardless Cash Access" application, backdoor it, and then pack it back up for shipping to unsuspecting users. There is also the risk of a supply chain attack, which is by far more sophisticated, but not impossible. Supply chain attacks are used by some of the world's brightest computer criminals. If the master copy of "Cardless Cash Access" to be distributed to all of the end users were to be compromised, the entire financial grid could become at risk.

I was able to come up with several ideas for making this model more secure, however they all involve more “big brother” type things. For example, a thumbprint scanner at the ATM could work just as well, or using the cellular GPRS data to confirm that the user is actually physically in the same cellular grid that the ATM was located in would be a good start. However, many privacy advocates (including myself) prefer disabling GPRS and dislike giving their thumbprint to machines.

Moving on, there is another feasibility problem with the “Cardless Cash Access” program. Sometimes there are cellular connectivity problems in the areas ATM's are located in. To address this, FIS has proposed an “offline mode” that would allow usage of the application on the phone regardless of connectivity problems. This is nothing but an opening for “replay” attacks in which an attacker could record the data from an “offline mode” transaction and “replay” the data into an ATM, making it dispense the cash.

In conclusion, this cardless ATM methodology removes much of the risk of getting caught from criminals intent on stealing money. While Mary Monahan is quoted as saying, "The phone is becoming a security blanket; the more you can do with it, the better,”; attackers have been using mobile devices as a proverbial malware playground. With mobile malware on the rise, the less control a phone has over your real life, the better.