Posted by jpluimers on 2017/02/24
We have broken SHA-1 in practice.
This industry cryptographic hash function standard is used for digital signatures and file integrity verification, and protects a wide spectrum of digital assets, ranging credit card transactions, electronic documents, open-source software repositories and software updates.
It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.
For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract.
Posted in Encryption, Hashing, Power User, Security, SHA | Leave a Comment »
Posted by jpluimers on 2017/02/03
At testing time, the Hardkernel’s ODROID-C2 absolutely destroyed the competition in this space, so buy this:
Hardware Shopping List (links current as of 8/2/2016)
After that continue the article and start with the Initial Setup of the Kali Image
Source: How to Build Your Own Penetration Testing Drop Box – Black Hills Information Security
via: Joe C. Hecht originally shared to Single Board Computers and Virtual Private Servers (Hardware).
Posted in *nix, Kali Linux, Linux, Pen Testing, Power User, Security | Leave a Comment »
Posted by jpluimers on 2017/02/01
I need to check these against a Chromecast v2 as the below URLs are from a v1 device:
More is possible by using cURL: Chromecast Hacking Has Begun | fiquett.com
sleep 8h; while true; do
curl -H "Content-Type: application/json" http://192.168.71.113:8008/apps/YouTube -X POST -d 'v=somevideo';
Posted in Chromecast, Communications Development, Development, Google, Hardware Interfacing, HTTP, https, Internet protocol suite, REST, Security, TCP | 3 Comments »
Posted by jpluimers on 2017/01/26
Source: Inverse Path – USB armory
usbarmory – USB armory: open source flash-drive-sized computer
Roughly EUR 100 excluding, SD card, host adapter and enclousure.
Source: inversepath/usbarmory: USB armory: open source flash-drive-sized computer
Since I was talking about security anyway…. this is a nice toy for breaking open laptops or desktops when the administrator forbade the installation of software, or you want software on it executed. This is often the case with company devices, e.g. the laptops which are supplied by banks to their 3rd party suppliers. Outsourcing is cool, remember?
This is a computer on a stick which can run a Linux kernel. In combination with some USB gadget kernel modules, it can be configured to authenticate itself as any device. All you need to do is plug it in, and iterate by brute force through the device identifiers until you hit one which is accepted to be used. Store the statically linked software you want to install or run on the stick beforehand, and here you go. So if you ever need a SSH client on a “secure” Windows laptop… putty.exe FTW.
Posted by Ralf Ramge – Google+
via: Since I was talking about security anyway…. this is a nice toy for breaking open laptops or desktops when the administrator forbade the installation of… – Kristian Köhntopp – Google+
Posted in *nix, Hardware, Pen Testing, Power User, Security, USB | Leave a Comment »
Posted by jpluimers on 2017/01/24
The Let’s Encrypt certbot (formerly letsencrypt) had some trouble on my machinery.
When trying to test if Apache default default · Issue #3307 · certbot/certbot and opensuse Tumbleweed: Each time I run certbot, a line with
Listen 443 gets added to
/etc/apache2/httpd.conf · Issue #3364 · certbot/certbot were fixed, I had to run certbot directly using specific github branches.
Normally certbot queries https://pypi.python.org/pypi/certbot/json to install the latest sanctioned version of itself. Which means this won’t work to run the version from github:
git clone https://github.com/certbot/certbot.git
But the below does:
git clone https://github.com/certbot/certbot.git
git checkout -b <<branch-name>>
The last statement will run
./venv/bin/certbot but you can also hard-code that (or perform
which certbot to verify the directory is on the pat).
I used it to test with this branch:
git checkout -b origin/osrelease_like
The above are basically steps to setup a virtualenv as mentioned in Developer Guide — Certbot 0.9.0.dev0 documentation.
To undo, just run this from the
rm -rf venv
The first statement will adjust your path and the second get rid of the virtual environment including all packages that were downloaded in it.
If you forgot to remove the
venv directory, there might be old versions hanging around named like
venv.1470590779.bak where the number in the middle is the number of seconds since unix epoch (
1970-01-01 00:00:00 UTC) which you might want to remove as well.
Inside the venv environment you can use all kinds of Python tools, for instance:
pip install ipdb after which you can add
import ipdb;ipdb.set_trace() to any source line to break right into the Python debugger. There, it will drop you into debug console, which is pretty much fully fledged Python interpreter.
pip freeze to show all installed Python packages.
While testing, you can use the
--staging command-line-options to use the Let’s Encrypt staging-environment this prevent running into the live environment rate limits (the main ones at time of writing are a Duplicate Certificate limit of 5 certificates per week and a Certificates per Registered Domain limit of 20 per week, whichever limit is lower).
Posted in Encryption, Let's Encrypt (letsencrypt/certbot), Power User, Security | Leave a Comment »