Sat, 04 Mar 2017
Recently I decided that I wanted my blog to be available inside of the Deep, Dark Onion (Tor).
First time around, I set up a proxy that I modified to access only the clear web version of the blog and to avail that inside Tor as a ‘hidden service’.
My blog is hosted on equipment provided by the kind folk at insomnia247.nl and I found that, within a week or so, the address of my proxy was blocked. It’s safe for us to assume that it was simply because of the outrageous popularity it received inside Tor.
By “safe for us to assume” I mean that it is highly probable that no significant harm would come from making that assumption. It would not be a correct assumption, though.
What’s more true is that within Tor things are pretty durn anonymous. Your logs will show Tor traffic coming from 127.0.0.1 only. This is a great situation for parties that would like to scan sites repeatedly looking for vulnerabilities — because you can’t block them. They can scan your site over and over and over. And the more features you have (e.g., comments, searches, any form of user input), the more attack vectors are plausible.
So why not scan endlessly? They do. Every minute of every hour.
Since insomnia247 is a provider of free shells, it is incredibly reasonable that they don’t want to take the hit for that volume of traffic. They’re providing this service to untold numbers of other users, blogs and projects.
For that reason, I decided to set up a dedicated mirror.
Works like this: my blog lives here. I have a machine at home which uses rsync to make a local copy of this blog. Immediately thereafter it rsyncs any newly gotten data up to the mirror in onionland.
After consideration, I realized that this was also a better choice just in case there is something exploitable in my blog. Instead of even risking the possibility that an attacker could get access to insomnia247, they can only get to my completely disposable VPS which has hardly anything on it except this blog and a few scripts to which I’ve already opened the source code.
I’ve not finished combing through but I’ve taken efforts to ensure it doesn’t link back to clear web. To be clear, there’s nothing inherently wrong with that. Tor users will only appear as the IP address of their exit node and should still remain anonymous. To me, it’s just onion etiquette. You let the end-user decide when they want to step outside.
To that end, the Tor mirror does not have the buttons to share to Facebook, Twitter, LinkedIn, Google Plus.
That being said, if you’re a lurker of those Internet back-alleys then you can find the mirror at: http://aacnshdurq6ihmcs.onion
Happy hacking, friends!
Tags: dark web, deep web, Facebook, free shell, Google Plus, insomnia247.nl, LinkedIn, mirror, onion, rsync, tor, Twitter
Permalink: 20170304.deep.dark.onion
Tue, 20 Dec 2016
Some time ago I had begun work on my own Pastebin-type project with a few goals. Basically, I wanted to eat all the cakes — and have them too.
Both an online user interface and efficient CLI usage
Messages encrypted immediately such that database access does not provide one with the contents of the messages
Messages capable of self-destructing
Database schema that would allow rebuilding the user/message relationship, provided the same password but would not store those relationships
Also, JavaScript encryption to appeal to users who don’t know much about cryptography but would like to try
The project, honestly, was going swimmingly when derailed by the goings-on of life.
One of the interesting components of the project was, of course, choosing crypto implementations. There are know shortcomings to handling it in JS but that’s still the most convenient for some users. Outside of the browser, server-side, you had all the same questions about which solution was best. Which protocol(s) should be available?
Well, I’ve just learned about a project which I would have loved to have available back then. Project Wycheproof can help you test your crypto solutions against known problems and attacks. Featuring 80 tests probing at 40 known bugs, here’s a snip from the introduction:
Project Wycheproof has tests for the most popular crypto algorithms, including
AES-EAXAES-GCM
AES-GCM
DH
DHIES
DSA
ECDH
ECDSA
ECIES
RSA
The tests detect whether a library is vulnerable to many attacks, including
Invalid curve attacks
Biased nonces in digital signature schemes
Of course, all Bleichenbacher’s attacks
And many more — we have over 80 test cases
Interesting stuff with exciting potential!
Tags: Bazel, Cryptography, Java
Permalink: 20161220.kicking.the.crypto.tires
Wed, 26 Jun 2013
The other day, I was updating one of my systems and I noticed that it had decided to communicate with me in Chinese. Since I don’t know a lick of Chinese, it made for a clumsy exchange.
It was Linux Mint (an Ubuntu variant), so a snip of the output from an ‘apt-get upgrade’ looked like this:

I’m pretty sure I caused it — but there’s no telling what I was working on and how it slipped past me. Anyway, it’s not a difficult problem to fix but I imagine it could look like big trouble.
So, here’s what I did:
> locale
The important part of the output was this:
LANG=en_US.UTF-8
LANGUAGE=zh_CN.UTF-8
If you want to set your system to use a specific editor, you can set $EDITOR=vi
and then you’re going to learn that some programs expect the configuration to be set in $VISUAL
and you’ll need to change it there too.
In a similar way, many things were using the en_US.UTF-8
set in LANG
, but other things were looking to LANGUAGE
and determining that I wanted Chinese.
Having identified the problem, the fix was simple. Firstly, I just changed it in my local environment:
> LANGUAGE=en_US.UTF-8
That solved the immediate problem but, sooner or later, I’m going to reboot the machine and the Chinese setting would have come back. I needed to record the change somewhere for the system to know about it in the future.
> vim /etc/default/locale
Therein was the more permanent record, so I changed LANGUAGE
there also, giving the result:
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=”en_US.UTF-8”
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=”en_US.UTF-8”
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
And now, the computer is back to using characters that I (more-or-less) understand.
Tags: Chinese, CLI, LinuxMint, locale, terminal, Ubuntu
Permalink: 20130626.terminal.suddenly.chinese
Tue, 04 Jun 2013
Recently, I ordered a Yubikey and, in the comments section of the order, I promised to write about the product. At the time, I assumed that there was going to be something about which to write: (at least a few) steps of setting up and configuration or a registration process. They’ve made the task of writing about it difficult, by making the process of using it so easy.
Plug it in. The light turns solid green and you push the button when you need to enter the key. That’s the whole thing!
Physically, the device has a hole for a keychain or it can slip easily into your wallet. It draws power from the USB port on the computer, so there’s none stored in the device, meaning it should be completely unfazed if you accidentally get it wet.
Let’s take a look at the device.
> lsusb | grep Yubico
Bus 005 Device 004: ID 1050:0010 Yubico.com Yubikey
We see that it is on Bus 5, Device 4. How about a closer look?
> lsusb -v -s5:4
Bus 005 Device 004: ID 1050:0010 Yubico.com Yubikey
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1050 Yubico.com
idProduct 0x0010 Yubikey
bcdDevice 2.41
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 30mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 71
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
There’s not a great deal to be seen here. As it tells you right on Yubico’s site, the device presents as a keyboard and it “types” out its key when you press the button, adding another long and complex password to combine with the long and complex password that you’re already using.
Keep in mind that this device is unable to protect you from keyloggers, some of which are hardware-based. It’s critically important that you are very, very careful about where you’re sticking your Yubikey. Even Yubico cannot protect us from ourselves.
Tags: \o/, password, security, Yubico, Yubikey
Permalink: 20130604.yay.yubico.yubikey
Tue, 07 May 2013
Thanks for visiting my little spot on the web. This is a Blosxom ‘blog which, for those who don’t know, is a CGI written in Perl using the file-system (rather than a database).
To the CLI-addicted, this is an awesome little product. Accepting, of course, that you’re going to get under the hood if you’re going to make it the product you want. After some modules and hacking, I’m pleased with the result.
My posts are just text files, meaning I start a new one like:
vim ~posts/`date +%Y%m%d`.brief.subject.txt
Note: the back-ticks (`) tell the system that you want to execute the command between ticks, and dynamically insert its output into the command.
In this case, the command date
with these parameters:
- (+) we’re going to specify a format
- (%Y) four-digit year
- (%m) two-digit month
- (%d) two-digit day
That means the command above will use Vim to edit a text file named ‘20130507.brief.subject.txt’ in the directory I have assigned to the hash
of ‘posts’.
(using hash
this way is a function of Zsh that I’ll cover in another post)
In my CLI-oriented ‘blog, I can sprinkle in my own HTML or use common notation like wrapping a word in underscores to have it
underlined, forward-slashes for
italics and asterisks for
bold.
Toss in a line that identifies tags and, since Perl is the beast of Regex, we pick up the tags and make them links, meta-tags, etc.
Things here are likely to change a lot at first, while I twiddle with CSS and hack away at making a Blosxom that perfectly fits my tastes — so don’t be too alarmed if you visit and things look a tad wonky. It just means that I’m tinkering.
Once the saw-horses have been tucked away, I’m going to take the various notes I’ve made during my years in IT and write them out, in a very simple breakdown, aimed at sharing these with people who know little about how to negotiate the command line. The assumption here is that you have an interest in *nix/BSD. If you’ve that and the CLI is not a major part of your computing experience, it probably will be at some point. If you’re working on systems remotely, graphical interfaces often just impede you.
Once you’ve started working on remote machines, the rest is inevitable. You can either remember how to do everything two ways, through a graphical interface and CLI — or just start using the CLI for everything.
So let’s take a little journey through the kinds of things that make me love the CLI.
Tags: blogitecture, Blosxom, BSD, CGI, CLI, firstpost, hash, Perl, Vim, Zsh
Permalink: 20130507.greetings