Lawrence’s List 090216
ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.
Election fraud is something I’ve mentioned here recently. The reality we must face here is that any time a digital system is used for voting there is the possibility of fraud via some form of hacking. The risks posed by digital polling are indeed something that must be addressed and mitigated where possible. The obvious consequence of a successful hack of the election systems is that a candidate wins by unfair or untrustworthy means. Consequences run deeper though, a rigged election (whether or not the winning candidate had anything to do with the rigging) would undermine trust in the democratic process at a time when the government can least afford to look any more shady than it has these past few years. Andrew Appel has posted a series of mitigations that could be considered on the Freedom to Tinker blog. Part one discusses how officials might audit the elections to at least detect if hacking were happening. Part two discusses the US government’s take on cybersecurity and addresses how the “no one but us” concept can only hurt us.
It turns out that the rumors of a Dropbox hack are true. Just north of 68 million records have been obtained from Dropbox, it appears in 2012. These records contained usernames and hashes, the hashes come in two varieties with some of the users having bcrypt hashes in the leak and others having SHA1. Thankfully the SHA1 hashes do not include their salts, as that would have made cracking the hashes much less difficult. The bcrypt hashes do have their salts included in the leak. Linked is an independent verification of the leak.
https://www.troyhunt.com/the-dropbox-hack-is-real/
A while back I put a couple of articles on here that discussed darkweb scanning with OnionScan. It was a series, we’ve seen parts one and two and have been promised a rundown of how the graphs were made in those postings. Part three is up!
It looks like we may soon see network packet filtering support for cgroups. For those not in the know Control groups (cgroups) are a kernel feature that allow processes to be grouped and resources to be controlled for that group (think Docker). Some members of the Linux kernel development team are currently discussing possible solutions that would allow use of the Berkley packet filter, or netfilter, to control network traffic for a particular group. This would mean that filters could be applied to ingress or egress traffic of a particular, limiting what kinds of traffic that group could generate or receive. This has some nice security implications and could make a nice addition to Docker’s current capabilities.
http://lwn.net/Articles/697462/
http://lwn.net/Articles/698080/
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
