- Avoiding BCC Leaks with Exim
- PGP Encrypted Text Chat Via DNS
- Installing Mailpile on CentOS 6
- Generating a vanity .onion address
- Hosting TOR Hidden Services (.onions)
- CentOS: Requiring a Yubikey OTP for SSH Password logins
- Sending commit notifications using Git post-receive hooks
- Understanding the Difficulty of Assessing True Randomness
- Implementing Secure Password Storage with PHPCredlocker and a Raspberry Pi
- Implementing Encrypted Incremental Backups with S3cmd
- Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapters
- Communicating with HomePlugAV Devices using Python
- Unbound: Adding Custom DNS Records
- Android: Protecting your network data from local snooping
- NGinx: Accidentally DoS'ing yourself
- Citroen C5: BSI Reset
- Allowing your Internal Search Engine to Index JIRA Issues
- MySQL Cheatsheet
- Usurping the BTHomeHub with a Raspberry Pi: Part 6 - Conclusion
- Testing Raspberry Pi Images with Qemu
This issue is, by no means, Joomla specific - but Joomla's mass mail functionality provides a good example of what can go wrong.
The expectation that most users have, is that the list of recipients BCC'd on an email will never be visible to any of those recipients.
Unfortunately, whether or not that's the case may well depend on the Mail Transport Agent (MTA) that you are using.
Those familiar with Joomla's Mass Mail feature will know that by default, recipients are BCC'd - unfortunately, if you're using Exim (which most CPanel servers, for example, are) then you may in fact find that those receiving your message can see exactly who it was sent to.
Whether or not this BCC Leak is visible to the recipients will depend on what mail client they use (assuming they're not in the habit of looking at the mail headers anyway....), but those using Google Apps/Google Mail will have the list clearly presented to them when viewing the mail.
In a recent post, I alluded to having given a little bit of thought to ways in which clandestine communications could be achieved.
Having given a little more thought to the idea, I was unable to resist the temptation to build a small proof of concept - if only to see whether there were any obstacles that I hadn't considered.
This post is the documentation for DNSChat - a small proof of concept enabling PGP encrypted text chat using DNS Queries as a transport mechanism
I've been meaning to play around with Mailpile since the beta was released back in September. Thanks to a bout of insomnia I finally found time, though it turns out that getting it up and running on CentOS 6 is initially something of a pain.
This documentation details the steps required to install and run Mailpile on CentOS 6
DISCLAIMER: For reasons I'll discuss in a separate post, at time of writing I'd only recommend following these steps if you want to test/play with Mailpile - Personally I don't feel at all comfortable with the idea of using Mailpile in production in it's current state.
Tor Hidden Services are accessed through a web address ending in .onion. Generally speaking these appear to be random strings of letters and numbers, though they're actually a representation of the public key generated when the operator created their hidden service.
It is possible, however, to attempt to generate a keypair which will allow you to generate a desired vanity URL, though the process is essentially a brute-force of key combinations, so may take some time.
The level of effort required to set up a TOR Hidden Service (known as a .onion) largely relates to the amount of paranoia you need to exercise regarding your anonymity.
Whilst the ins and outs of Operational Security (Op-Sec) are a little too intricate for a single post, this documentation will take you through the steps required to configure a Debian server to host a .onion site with reasonable protections in place.
The increasing ubiquity of the Yubikey makes it an ideal candidate for a Two-Factor Authentication mechanism, and configuring a CentOS based server to require a push of a Yubikey is particularly easy.
By the end of this documentation, we'll have configured a CentOS server to require that a user provide the following in order to login via SSH, unless they already have a valid RSA key pair configured on the server
- Username (obviously)
- Account password
- Valid Yubikey OTP
For the sake of this documentation, we'll assume that you're using Yubico's validation servers (Yubicloud) rather than running your own (though if you are doing the latter, there's only one change in the configuration).
I make heavy use of Git, and have plugins that allow me to view my commits when viewing issues in JIRA. Unfortunately these plugins rely on Lucene indexes which has proven to be a bit of an issue when archiving projects (or maintaining a HTML fallback).
There are various post-receive hooks out there for sending mail notifications out whenever someone runs 'git push', however they're generally tailored towards notifying a group of developers.
I simply wanted the equivalent of 'git log' to appear within my JIRA activity flow on any issue which is mentioned in the commit message.
This documentation provides a python based post-receive hook intended to do just that, and also documents exactly how to go about applying that hook to all existing and future repos on your server.
I've had to explain, more than a few times, quite why it's so hard to assess whether a Random Number Generator (RNG) is compromised unless you have access to how the specific implementation works. Just because the data appears to be random, does not necessarily mean that it is actually unpredictable.
In this short piece of documentation, I'll be attempting to demonstrate exactly how a compromised RNG can appear to be generating random data, based on the tests that are available to us.
Password storage can be a sensitive business, but no matter whether you're using PHPCredlocker or KeePassX, dedicated hardware is best. The more isolated your password storage solution, the less likely it is that unauthorised access can be obtained.
Of course, dedicated hardware can quickly become expensive. Whilst it might be ideal in terms of security, who can afford to Colo a server just to store their passwords? A VPS is a trade-off - anyone with access to the hypervisor could potentially grab your encryption keys from memory (or the back-end storage).
To try and reduce the cost, whilst maintaining the security ideal of having dedicated hardware, I set out to get PHPCredlocker running on a Raspberry Pi.
This documentation details how to build the system, a Raspberry Pi Model B+ was used, but the B should be fine too
I've previously detailed howto use S3cmd to backup your data from a Linux machine. Unfortunately, because of the way that s3cmd works, if you want an incremental backup (i.e. using 'sync') you cannot use the built in encryption.
In this documentation I'll be detailing a simple way to implement an encrypted incremental backup using s3cmd, as well as a workaround if you're unable to install GPG - instead using OpenSSL to encrypt the data. Obviously we'll also be exploring how to decrypt the data when the backups are required
It's assumed that you've already got s3cmd installed and configured to access your S3 account (see my earlier documentation if not
As I posted recently, I've been playing around with some of ON Network's PL500 HomePlugAV Adapters. Given my previous experience with Powerline adapters, as part of that tinkering I thought I'd see whether they contain (or are) a security issue.
Unfortunately the news isn't great, as I can now get effective physical network access using the HomePlugAV adapters as my entry point. It does, of course require some proximity to the target network, but is otherwise pretty straight forward.
As I don't have $5,000 to spare, I did this without reading the HomePlugAV technical specification.
Responsible Disclosure: Before publishing, I contacted the HomePlug Alliance to notify them of the issues I'd identified, but have had no response
I've got a couple of pairs of ON Networks' PL 500 HomePlugAV Powerline Adapters and have been playing around with them to see how they compare to the Computrend 902 devices I played around with 5 years ago.
I'm still playing around with the kit, but thought I'd document a very basic example of how to send commands to the devices using Python - the instructions should work for any kit based on Qualcomm's INT6x00 and AR7x00 chipsets (mine use the AR7420/QCA7420) - we'll be changing one of the encryption keys (the NMK) that the devices use
When I wrote my post on configuring DNS, DHCP and NTP on a Raspberry Pi, I forgot to include information on how to add your own DNS records to Unbound (straight forward as it is). So in this post, I'll give a very brief overview.
All changes should be made in an unbound configuration file (probably /etc/unbound/unbound.conf, though you could also put them into a file in local.d, depending on your distribution - see below)
There's been a lot of news of late about the likes of NSA and GCHQ passively listening to Internet traffic. The steps in this post won't protect you from such a well resourced attacker, but will prevent others on open wifi networks and your mobile data provider from looking at the content of your phone's network traffic.
A good example of the data that can easily be collected can be seen in this recent Ars Technica post.
In this post, we'll be configuring an Android phone to conditionally connect to an OpenVPN server, dependant on whether it's associated with a specific WLAN
It turned out to be entirely self-inflicted, but I had a minor security panic recently. Whilst checking access logs I noticed (a lot of) entries similar to this
127.0.0.1 [01/Jun/2014:13:04:12 +0100] "GET /myadmin/scripts/setup.php HTTP/1.0" 500 193 "-" "ZmEu" "-" "127.0.0.1"
There were roughly 50 requests in the same second, although there were many more in later instances.
Generally an entry like that wouldn't be too big of a concern, automated scans aren't exactly a rare occurrence, but note the source IP - 127.0.0.1 - the requests were originating from my server!
I noticed the entries as a result of having received a HTTP 500 from my site (so looked at the logs to try and find the cause). There were also (again, a lot of) corresponding entries in the error log
2014/06/01 13:04:08 [alert] 19693#0: accept4() failed (24: Too many open files)
After investigation, it turned out not to be a compromise. This post details the cause of these entries.
The Body control unit (BSI) on Citroens (and Peugeots) sometimes goes batshit-insane and switches things off for no other apparent reason than it felt like it.
A reset is usually enough to resolve, but the steps need to be followed almost exactly, and the car should be thoroughly checked afterwards to make sure everything is working.
This documentation details how to perform the reset
I use a number of tools on my network, including a private JIRA install (i.e. you need to log in to view anything) and the Sphider PHP search engine (I've generated a lot of documentation over the years).
Unfortunately the two aren't exactly compatible, as Sphider has no way to log into JIRA, but I wanted my JIRA issues and comments to be indexed so that relevant items can be included in my search results. One option would be to set JIRA to public mode, but I'd rather maintain the need to log in.
So instead I created a simple PHP script - JIRA Issue Listing - to generate a list that Sphider could index, but would redirect 'real' users to the relevant issue on JIRA.
This post is the documentation for that script
I started an article on basic MySQL Tips and Tricks a little while ago, but never quite finished it. This documentation contains those tips as well as some additional techniques I've picked up
Throughout this series of articles, we've been aiming to usurp the role of the BTHomeHub on our home network, leaving it to do nothing but act as an Internet Gateway and provide a basic NAT firewall. As we've seen, it can be stubborn and insist on trying to ignore 'off' settings.
In the previous five parts, we've configured our Raspberry Pi to perform many of the functions of the HomeHub, as well as a few extras that BT never saw fit to provide. So, now we're going to step back and look at the functionality we've got.
Although changing the OS on a Raspberry Pi is quick and easy (especially if you have a spare SD card), there are times when you might want to test a system first, or simply tinker without needing a spare Pi.
This documentation details how to use Qemu to run a RaspberryPi image.