Perfect Forward Security Whitepaper
04 Sep 2014 - Pratik Guha Sarkar
Encrypted communication channels were created so nobody could read confidential communications - this means not only during the conversation, but also any time after it. But adversaries have the ability to monitor, record, and attack communication retroactively. Disclosure of state sponsored monitoring of electronic communications and the threat of retroactive decryption of traffic of millions of people has created an urge for an extra layer of security and privacy for all electronic communications.
iSEC has published a whitepaper that looks into how Forward Security can be used to protect online communication - but covering much more than just TLS. Besides explaining the groundwork, we also explore the difference between Forward Security and Perfect Forward Security and mechanisms outside any specific implementation, modeling a generic protocol and building it up showing how Forward Security can be achieved. And on the implementation level, we also cover how to enable Forward Security in protocols you have deployed in your network today - giving a simple explanation, real life applications, advantages, and implementation in protocols like Off-the-Record (OTR) Messaging, Secure Shell (SSH), Wireless Protected Access II Protocol (WPA2-EAP-PWD), Virtual Private Networks (VPN), and of course TLS.
Tor Browser Research Report Released
13 Aug 2014 - Tom Ritter, Andy Grant
As part of our work with the Open Technology
we recently worked with the Tor Project to see
how Tor Browser stands up in terms of modern exploit mitigations, and what
could be done to make it harder to develop exploits for.
Tor Browser is based on Firefox, so it inherits the strengths and weaknesses
of Firefox — but one of the things Tor Project is working on is a security
slider that will let
people disable features of the browser depending on their security posture.
If you're extra paranoid you'll ratchet it all the way up and disable
things like obscure font rendering features only used in South East Asia.
Tor Project has published a blog
that summarizes the report from their point of view and links to a number of
issues on their bugtracker and other documentation.
This project was more of a research engagement than a security assessment — a
lot of this engagement was identifying features that should be placed on the
slider, and making recommendations for where they should land. But we looked
at a lot of other more general hardening items too. We checked the status of
DEP and ASLR on Windows and Mac, and found an interesting lack of exception
handling on the Windows build, due to the MinGW build process (this throws
SafeSEH and SEHOP out the window). We also went through, with the cooperation
of the Mozilla Security team, and categorized over a hundred past security
vulnerabilities in Firefox into feature category and bug type (Use-After-Free
wins the latter overwhelmingly.) We analyzed a few public and private
exploits, and also investigated enabling assertions in certain classes in
Firefox. We have a skeleton patch for the latter, but it's more a proof of
concept than something we think they should use. One of the other major items
was looking at replacing Firefox's memory allocator (jemalloc) with a more
hardened allocator (PartitionAlloc from Chrome). Fortunately, Mozilla makes
this pretty easy, so most of the work is in adapting PartitionAlloc and making
full use of its partition features. There are several other parts to the
report, including looking at protocol handlers, media formats, and making
regression tests for DOM object exposure.
We had a ton of fun working on this project and we'd like to thank Mike Perry
at Tor for working with us so closely, OTF for sponsoring the work, and all
the people inside iSEC and the security community we talked about this project
with who gave us ideas — especially Chris Evans from Google (the author of
PartitionAlloc). The report clocks in at about 30 pages, but with the
appendices (which have patch files), it balloons up to a whopping 150 pages.
You can find the report, and all the patch files in our publications
ZigTools: An Open Source 802.15.4 Framework
04 Aug 2014 - Mike Warner
ZigTools is a Python framework, which was developed to reduce the complexity in writing additional functionality in communicating with a Freakduino (a low cost Arduino based 802.15.4 platform). Features such as initializing the radio, changing channels, sniffing network traffic, sending raw data and processing that data can be written in just a few lines. This allows developers to focus on writing more complex and feature rich applications without worrying about low level communications between the radio and system.
- Sniffed data is saved in a pcap format, which can later be dissected by popular applications
- Replay packets directly from pcap file
- All aspects of the packet can be modified, allowing developers to test Layer 2 and 3 functionality of 802.15.4 and Zigbee systems
iSEC Partners is pleased to publicly release this version of the ZigTools framework at Black Hat USA 2014 Arsenal, a tools/demos area.
Tool Release: You'll Never (Ever) Take Me Alive!
09 May 2014 - Tom Ritter
A year ago, we released You'll Never Take Me Alive — a tool that helps protects Full Disk Encrypted Windows computers from DMA and cold boot attacks.
YoNTMA runs as a background service and begins monitoring your computer any
time the screen is locked. If the power cable or Ethernet cable is
disconnected from the system while your laptop is locked, YoNTMA will
immediately hibernate the machine to ensure that the disk encryption keys do
not remain in RAM. This ensures that if a thief walks off with your powered-on
laptop, your encrypted data stays protected.
It's been a great tool that I've used happily, but when I got a new Macintosh, I ran up against Issue #3 — there's no Mac version! Until today. We're releasing a new version of YoNTMA for Macs. The source is still open and the .dmg can be downloaded from Github. Due to some tricks of how Macintoshes hibernate, you'll need to provide your administrative password (just once) to update the power management settings to enable a secure hibernation. Or, if you're paranoid, you can run those commands yourself and re-launch the app — don't worry, you won't hurt my feelings.
The only issue we're aware of is a lingering issue in OS 10.9; that said, while I've experienced this issue in the past, I'm currently running 10.9 and haven't had issues in the past few months. Feel free to test and if you have problems, open an issue on Github.
DIBF Tool Suite
16 Apr 2014 - Nicolas Guigo
Introducing iSEC Partners' Windows driver testing suite. The source, binaries
and example output are available at
under the GPLv2 license. Currently three tools are included:
DIBF - Dynamic IOCTL Brute-Forcer (and fuzzers)
This tool encompasses two distinct features. It guesses the IOCTL values that
the driver accepts, and also their valid size limitations, and stores the
results are in a file for future reuse. The second feature is composed of 3
dumb fuzzers: a pure random fuzzer, a sliding DWORD fuzzer and a fully
asynchronous fuzzer. Any combination of the 3 fuzzers can be run sequentially,
and numerous options can be set from the command line, including time limits
for each fuzzer run, the maximum number of failed requests in a row
(indicating further fuzzing might be pointless due to lack permission for
instance) and the verbosity level. Any fuzzer run can be stopped cleanly with
ctrl-c, and upon completion cumulative statistics are displayed. See the
README and usage for more information on all options and features.
IOSEND - sending single IOCTL to a driver
This is a tool intended for proofing vulnerabilities and is meant to be used
in conjunction with a hex editor. Once the request of interest has been
crafted in the editor, this utility will send it to the driver using command
line parameters. The response gets sent to stdout.
IOCODE - simple encoding/decoding utility for IO codes
This very simple tool encodes and decodes windows IOCTL control codes. It
provides a user-friendly way to deal with IO encoding of device types,
function number, transfer method and access type.