Version 1.16 of PHPCredlocker has been released and can be obtained from https://github.com/bentasker/PHPCredLocker

Release Notes

Version 1.16 is an interim release, implementing a number of key changes and security fixes.

• Minor fixes to the BTTLS implementation (keylength calculations)
• Improved protection against injected Sessions
• Added configuration option to explicitly specify the cookie domain
• Added basic support for the X-Forwarded-For header
• Fixed a Minor Information Disclosure Vulnerability (PHPCRED-35)
• Implemented new logging types
• Replaced Mersenne Twister based key generation with use of /dev/urandom
• Implemented utility script to re-generate all crypto keys

Read more…

 A minor Information Disclosure Vulnerability exists in PHPCredlocker versions earlier that 1.16.

Read more…

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

Prior Analysis

Read more…

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

Read more…

Quite some time ago, I played around with some Computrend 902 Powerline adapters and found a number of different security issues - here and here. 

Those devices are long gone, but whilst the issues I found were relatively minor (if nothing else, proximity was required) it left me a little concerned about the security of any devices that might replace them. For quite some time, I didn't need to use any powerline adapters, but eventually the need arose again (no practical way to run CAT-5 to the location and the Wifi reception is too spotty).

So I bought 2 pairs of On-Networks' PL500S Powerline adapters. Depending where you buy them from, the model number may be PL500P, PL500-UKS, or even the Netgear part number - Netgear ON NETWORKS PL500-199UKS.

I've not got as far as giving them a serious hammering from a security perspective as yet, however there doesn't seem to be much information about these devices available on the net (and what is there is potentially misleading), so I thought I'd post the information I've pulled together from prodding the devices, as well as a few common sense facts that might be being missed. As I'd have found some of the information helpful had it been available prior to purchase, I suspect others might find it of use too.

Read more…

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)

Read more…

I occasionally receive emails from people who have come across PHPCredlocker, and the question is usually the same - "Why are you storing passwords using reversible encryption?". Most emails are polite, some not so much, but they all have one thing in common - assuming that a commonly stated fact applies to all scenarios, and failing to apply a bit of simple logic that would tell them the answer - because that's the only way the system would work.

In this post, we'll be briefly looking at some of the ways in which you can store credentials, and which of them are appropriate to use (and when), in the context of building an application (web or otherwise).

I actually wrote a white-paper on this a good few years ago, but things have moved on considerably since then - Rainbow tables are no longer used, and it's now possible to cheaply use cloud services with GPUs available.

One thing that hasn't changed, however, is that you should always work on the basis that one day, somehow, an attacker will manage to get a copy of your database. At that point, how you've stored the credentials becomes very important (users re-use passwords, so it may not just be your system that gets compromised if the credentials are recovered).

Read more…

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

Read more…

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.

Read more…

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

To perform the reset;

1. Put the drivers window down and lift the bonnet (leave the key in the ignition)
2. Ensure all equipment (stereo etc) is switched off
3. Ensure all doors are closed and reach through the window to remove the key from the ignition
4. Wait 3 minutes
5. Disconnect the battery and then wait 15 seconds
6. Reconnect the battery and wait 10 seconds (Do not open any doors)
7. Switch on the ignition (but don't start the engine) and check that all tests pass
8. Hold the lock button on the key down for 10 seconds
9. Remove the key, open the drivers door, close it and check the central locking works (I had to hold the lock button down for another 10 seconds at this point)
10. Start the engine and complete the systems check

Note: When you put the drivers window up, it won't automatically go all the way up. Make sure you close it all the way before putting it down, otherwise the automatic close won't close it all the way until you next turn the ignition on and off