Tag Archives: data security

Install Tor using apt-get on ubuntu- trusty 14.x





tor.mrd—/Users/shawnmehan


I went to turn on Tor on an ubuntu-64 “trusty” 14.x guest and ran into problems. There appears to be a bug
that critically affects the traditional methods using gpg, so here is some information on how to avoid this.


Tor is free software and an open network that helps you defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. There is a very neat Python
controller library for use with Tor called stem.

The problem

To install Tor on an ubuntu, the following instructions can be found:

$ sudo nano /etc/apt/sources.list.d/tor_repo.list

and then add the following lines:

deb http://deb.torproject.org/torproject.org trusty main
deb-src http://deb.torproject.org/torproject.org trusty main

The critical problem then occurs as you try to add the appropriate keyring and key used to sign the packages:


$ gpg –keyserver keys.gnupg.net –recv 886DDD89

$ gpg –export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add

There appears to be a bug with gpg and guests involving not correctly resolving DNS for the gpg commands. The symptom that I was getting was

$ gpg –export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add –
usage: gpg [options] [filename]
gpg: can't open `–': No such file or directory

The fail in the pipe is due to there not being anything actually exported by gpg. You can test this with:


$ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg: WARNING: nothing exported

Solution

So, take another approach. Use different packages to avoid any of this problem.


$ sudo apt-get update

$ sudo apt-get install deb.torproject.org-keyring

$ sudo apt-get install tor

which will get you something like:

The following NEW packages will be installed:
  deb.torproject.org-keyring
0 upgraded, 1 newly installed, 0 to remove and 63 not upgraded.
Need to get 5,268 B of archives.
After this operation, 7,168 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  deb.torproject.org-keyring
Install these packages without verification? [y/N] Y
Get:1 http://deb.torproject.org/torproject.org/ trusty/main deb.torproject.org-keyring all 2014.08.31+b1 [5,268 B]
Fetched 5,268 B in 0s (22.3 kB/s)                     
Selecting previously unselected package deb.torproject.org-keyring.
(Reading database ... 128038 files and directories currently installed.)
Preparing to unpack .../deb.torproject.org-keyring_2014.08.31+b1_all.deb ...
Unpacking deb.torproject.org-keyring (2014.08.31+b1) ...
Setting up deb.torproject.org-keyring (2014.08.31+b1) ...
OK

and

    The following extra packages will be installed:
  libseccomp2 tor-geoipdb torsocks
Suggested packages:
  mixmaster torbrowser-launcher socat tor-arm apparmor-utils obfsproxy
  obfs4proxy
The following NEW packages will be installed:
  libseccomp2 tor tor-geoipdb torsocks
0 upgraded, 4 newly installed, 0 to remove and 63 not upgraded.
Need to get 1,707 kB of archives.
After this operation, 8,053 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
WARNING: The following packages cannot be authenticated!
  tor tor-geoipdb
Install these packages without verification? [y/N] Y
Get:1 http://archive.ubuntu.com/ubuntu/ trusty/main libseccomp2 amd64 2.1.0+dfsg-1 [34.8 kB]
Get:2 http://deb.torproject.org/torproject.org/ trusty/main tor amd64 0.2.7.6-1~trusty+1 [1,024 kB]
Get:3 http://archive.ubuntu.com/ubuntu/ trusty/universe torsocks amd64 1.3-3 [73.0 kB]
Get:4 http://deb.torproject.org/torproject.org/ trusty/main tor-geoipdb all 0.2.7.6-1~trusty+1 [575 kB]
Fetched 1,707 kB in 2s (749 kB/s)
Selecting previously unselected package libseccomp2:amd64.
(Reading database ... 128043 files and directories currently installed.)
Preparing to unpack .../libseccomp2_2.1.0+dfsg-1_amd64.deb ...
Unpacking libseccomp2:amd64 (2.1.0+dfsg-1) ...
Selecting previously unselected package tor.
Preparing to unpack .../tor_0.2.7.6-1~trusty+1_amd64.deb ...
Unpacking tor (0.2.7.6-1~trusty+1) ...
Selecting previously unselected package torsocks.
Preparing to unpack .../torsocks_1.3-3_amd64.deb ...
Unpacking torsocks (1.3-3) ...
Selecting previously unselected package tor-geoipdb.
Preparing to unpack .../tor-geoipdb_0.2.7.6-1~trusty+1_all.deb ...
Unpacking tor-geoipdb (0.2.7.6-1~trusty+1) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up libseccomp2:amd64 (2.1.0+dfsg-1) ...
Setting up tor (0.2.7.6-1~trusty+1) ...
Something or somebody made /var/lib/tor disappear.
Creating one for you again.
Something or somebody made /var/log/tor disappear.
Creating one for you again.
 * Starting tor daemon...                                                                                                                  [ OK ] 
Setting up torsocks (1.3-3) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up tor-geoipdb (0.2.7.6-1~trusty+1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...

Now you have Tor installed, just start it.


$ sudo /etc/init.d/tor start

Starting tor daemon...

It also appears that there is some confusion as to the defaul port the service is running on. I found it to be running on 9050, not 9150 as some
articles are reporting. I haven’t yet found an easy way to determine this but trial-and-error proved it to be true.


Recent OS X security vulnerabilities

Serving up some issues for OS X that were catalogued on Dark Reading. There are some serious concerns. I missed the keychain vulnerability which is very worrisome. I know a good many who are using password safes with standard copy and paste UX in their use.

The past several months have been full of bad news for Mac and iOS. Here’s a quick rundown of the highlights:

  • Keychain vulnerability: Reported to Apple a year ago, revealed to the public in June, and still not fixed, researchers discovered a vulnerability in Keychain on Mac OS X. Attackers could poison Keychain and steal the data it stores, which included passwords and tokens for a variety of applications, including iCloud and Facebook.
  • Gatekeeper vulnerabilities: At the Black Hat Las Vegas conference in August, Synack director of research Patrick Wardle detailed proof-of-concept exploits that circumvent Gatekeeper, Apple’s mechanism for preventing unsigned code from running on Mac. At the Virus Bulletin Prague conference in October, Wardle showed that Apple did not repair the problem with OS X El Capitan, released Sep. 30, and told Forbes that “Gatekeeper is no obstacle at all.”. A researcher snuck unsigned malicious code past Gatekeeper by wrapping it into a signed installer package. Gatekeeper only checks the installer package, not what’s in it — so it’s vulnerable to what is essentially a basic piggybacking attack that any good lesson in social engineering cautions against.
  • DYLD_PRINT_TO_FILE vulnerability: Discovered in July, patched in mid-August, this was a bug in an environment variable in Mac OS X Yosemite that enabled root access.
  • Tpwn vulnerability: Publicly disclosed in mid-August before it was patched, Tpwn was a memory corruption bug in the kernel of OS X Mavericks through Yosemite, that would allow local privilege escalation and grant attackers root access.
  • KeyRaider: In late August, the KeyRaider iOS malware stole 225,000 legitimate Apple accounts and slammed devices with ransomware, data theft, and phony purchases. The malware was secretly wrapped into unauthorized iOS apps, downloaded from a China-based third-party website, and thus it only affected jailbroken iOS devices.
  • AirDrop vulnerability: Disclosed in mid-September, a vulnerability in both Mac and ioS — patched in the new iOS 9 — lets attackers bomb any iOS and Mac device within Bluetooth range with malware, via the Airdrop file-sharing feature.
  • XCodeGhost: In late September, attackers showed they could hit non-jailbroken iOS devices too. XcodeGhost is a Trojanized version of Apple’s application development software, Xcode. Attackers uploaded it to Chinese cloud storage service Baidu Yunpan — a regional, third-party alternative to the Apple Store where download times are shorter for iOS and Mac developers in China. Innocent app developers then used XcodeGhost to write apps and upload them to the official App Store, never knowing that those apps were malicious. Originally, it was thought that only about 40 apps were infected with XcodeGhost, but that number was later increased to 4,000, including WeChat, ride-hailing app Didi Kuaidi, and music sharing app NetEase Music.
  • YiSpecter: In early October, researchers at Palo Alto Networks discovered about 100 apps in the iTunes App Store abusing Apple’s private APIs — used only by Apple itself and not available to app developers — in order to circumvent the Store’s security tools. YiSpecter download, install, and open applications, replace on-board apps with unwanted downloads, and force apps to show advertisements.
  • Yanked apps: Last week, Apple pulled some ad-blocking apps from its App Store after discovering that some of those apps installed root certificates that expose all traffic, including encrypted traffic, from the device to the application. Apple is allowing the app developers to resubmit to the store after they make alterations.

Don't put your auth tokens in your R source code

I’ve been working with the great open data source which is BLS. You can get some of the data with the v1 API, but to use the v2 API you need to have a token. That simply takes a registration and a validation. Cheers to BLS. And cheers to Mikeasilva

So, now you have your API token and you want to go grab some data into some R and cook it up. So you might do something like:

install_github("mikeasilva/blsAPI")
payload <- list('seriesid'=c('LAUCN040010000000005','LAUCN040010000000006'),
                'startyear'='2010',
                'endyear'='2012',
                'catalog'='true',
                'calculations'='true',
                'annualaverage'='true',
                'registrationKey'= 'MYVERYOWNTOKENREGISTEREDTOME')
response json

Sadly, when you check your code into github, or share it with someone else, they have your API token. A better way exists, padawan. Go to your home dir


> normalizePath("~/")

in the R console will tell you if you don't know. So will a simple
cd

in a shell, but if you know what a shell is you knew that already :). In your home dir, edit a new file called .Renviron, unless it already exists, which questions why you are reading this post. In .Renviron, you can enter key-values per line:


BLS_API_TOKEN=11111111122222222333333333
GITHUB_TOKEN=11111111133333333322222222
BIGDATAUSERNAME=BIGDADDY
BIGDATAPASSWD=ROCKS
KEY=VALUE

and, beautifully, you can grab any and all of these values in your R code with the following:


myValueOfInterest <- Sys.getenv(KEY)
typeof(MyValueOfInterest)
[1] "character"

so you can easily pass it as a parameter to those connections. All much better than embedding it directly into the source. N.B.: If you happened to include your home dir as part of your project dir, don't commit the .Renviron. Also, go change your project directory to something more sensible like a child dir. While you're at it, look at some of the other methods available via Sys, e.g.:


Sys.setenv()
Sys.unsetenv()

Now your interaction with the v2 API is more like:


payload <- list('seriesid'=c('LAUCN040010000000005','LAUCN040010000000006'),
                'startyear'='2010',
                'endyear'='2012',
                'catalog'='true',
                'calculations'='true',
                'annualaverage'='true',
                'registrationKey'= BLS_API_TOKEN)
response <- blsAPI(payload)
json <- fromJSON(response)
response json