Security Community

TrueCrypt security history (from isTrueCryptAuditedYet to Oct 2015)

TrueCrypt was a popular tool for encrypting volumes with strong cryptography before integrated solutions like BitLocker for Windows and encrypted .dmg volumes using the Disk Utility in Mac OS X. Linux had an historically good support for a number of implementations like the old loop-AES, Cryptoloop and the current dm-crypt / LUKS. Still a lot of people use TrueCrypt and there is plenty of interest in the software: this include forks, audits, licensing issues, and.. vulnerabilities. The main reason was it’s cross-platform support.

First you need to know that now TrueCrypt is abandonware, as developers discontinued it and suggest users to move to other solutions, as seen from their official statement:

The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP. Windows 8/7/Vista and later offer integrated support for encrypted disks and virtual disk images. Such integrated support is also available on other platforms. You should migrate any data encrypted by TrueCrypt to encrypted disks or virtual disk images supported on your platform.

The latest available build is 7.2 but do not download it as it’s stated as not secure by the original developers:

Our story starts October 2013, when Matthew Green suggested an audit of TrueCrypt that led to the Open Crypto Audit Project founded by crowfounding with a huge success ($16,579 on FundFill and $46,420 on Indiegogo for a total of $62,999). Thanks to a matching donation by the Open Technology Fund (till now $125,998 of total budget) the iSec team was engaged in a 5-6 week long assessment to verify the security of TrueCrypt in it’s 7.1a incarnation.

The audit started in December 2013 and there was an initial report from iSECpartners of nccgroup on February 14 2014, titled “Open Crypto Audit Project: TrueCrypt Security Assessment“. It’s written by Andreas Junestam and Nicolas Guigo, 32 pages long and highlight zero high impact issues, four medium, four low and three informational issues. The iSEC team did not like the code at all and there were some crypto-related concerns but no backdoors were identified.


Then the bomb, on May 2014 the TrueCrypt team release 7.2 and discontinue the product, but the Open Crypto Audit Project can’t stop. In particular on March 13 2015, iSEC release the final “Open Crypto Audit Project: TrueCrypt Cryptographic Review” report. It’s a 21 page document written by Alex Balducci, Sean Devlin and Tom Ritter and highlights two high impact issues, zero medium one low and one undetermined. The analysis was not a complete code review but the most important portions were audited.


The findings were related to the random number generation, inability to detect tampering of the volume, the method used to mix the entropy of keyfiles was not correct and several AES implementations were vulnerable by cache-timing attacks but mitigated by fixes introduced by Google’s Zero Project regarding ability to flip bits in adjacent DRAM rows.


In the meantime between February 2014 and March 2015 other issues are made public:

  • TrueCrypt bug in serpent implementation (March 2 2014)

Little (or none?) of the suggestions are implemented in the official 7.2 version but after the discontinuity announce of TrueCrypt two forks arise (VeraCrypt and CipherShed) and implement them. Developers at VeraCrypt and CipherShed are not friends and don’t lose time in bashing each other. Only VeraCrypt has a released version, while CipherShed has the goal to rewrite the 100% of code to solve licensing issues but is still at the “rebranding” stage of development. Still you can use a completely different implementation, like DiskCryptor but IMHO without the community and commercial audit plus.

And we come to the present day, with two high impact and exploitable vulnerabilities found by the Google Security Research for the driver user by TrueCrypt, VeraCrypt and CipherShed to create a system drive on Windows:

Summarizing, great effort has been pushed into TrueCrypt’s codebase and there is at least one valid fork (VeraCrypt) you can install and use if you need cross-platform support. If you want to encrypt your own data alone use the native Full Disk Encryption solution provided by your OS and you will probably be safer.

For any suggestion and comment @isgroupsrl on twitter :)

–Francesco Ongaro
CEO of ISGroup

Security Community

Situation in Switzerland and Internationally

Extract from Federal Strategy Unit for IT FSUIT; Federal Intelligence Service FIS; Reporting and Analysis Centre for Information Assurance MELANI

Since the Stuxnet worm became known in the second half of 2010, there has been an increased focus on the security of SCADA software. The basic difficulty with SCADA systems lies especially in their history: originally, they were sealed-off, independent, and proprietary systems, 24 granting external access at most to the manufacturer for maintenance purposes via a dial-up modem.

Accordingly, these systems hardly ever have functions to protect them from electronic attacks. Recently, programmable logic controllers and process control technology have become increasingly networked, increasingly use standardised protocols and technologies, and are even sometimes reachable via the Internet. Using a special computer search engine (in contrast to website search engines such as Google, Bing etc.), it has become significantly easier to find such devices.

The media presence of Stuxnet apparently awakened the interest in industrial control technology and SCADA systems among many security experts as well. Since then, various vulnerabilities in such products have been found and reported on. Methods have been discovered allowing systems to be taken over remotely, to download or upload any kind of file, to shoot down specific services or controllers, 29 to infiltrate and launch code, and to simply inject false data to which the controllers then react as if they were correct.

The big difference compared with traditional computer software is that manufacturers so far have little experience in resolving vulnerabilities, and that the software of the components is only rarely updated by the operators. In the case of continuously running processes, this can only be done during specific maintenance windows. The effects of patches on the overall process may often be tested only to a very limited extent in advance. The principle “don’t touch a running system” entails that failures and breakdowns may quickly give rise to high costs.

SCADA systems are increasingly often connected with the administration systems of companies in order to make business decisions on the basis of real-time data, and data are increasingly exchanged via the Internet. Advocating the strict separation of operational and administrative systems is probably a good idea, but is likely illusory and impractical. Instead, the associated new dangers and risks must be identified, assessed, and strategies for identification and repair in the event of an incident must be developed. However, there are various measures for avoiding interference: e.g. by using a VPN for remote access, a firewall with white listing, and signing of the control code and configuration.

Security Community

How to not do a live-hacking reportage

Today while reading ITSEC news (we publish only a fine selection of them on an article caught our interest: it was a television reportage about a live-hacking session performed by a security company called Compass Security AG ( for one of their SCADA customers. This type of marketing material is always entertainment but this was more entertainment than the average! The video is available at the URL and has already been broadcasted. Take a look at the following frame.

Nmap, as featured in TV

Noticed nothing? Err.. Is that public address space?

Well, it’s clearly not a wise move to publish a routable IP address, belonging to a customer infrastructure and probably the command center for their SCADA gears, together with it’s open port information (5900/tcp open VNC)! It seems a clear call to army for the random cracker who wants to burn some bits over his internet pipe! For the most careful watchers: surely you noticed the Siemens logo in a background browser window and below a “Servlet login” link.

The nmap terminal is a journalism classic, as seen in movies, unreadable green characters on a dark background, is able to make the ITSEC illiterate’s fantasies run wild. But a security company leaking data? In it’s own marketing video? Leaking data is a customer role!

$ whois 46.14.XXX.XX

% Information related to ' -'
% Abuse contact for ' -' is ''

inetnum: -
netname: CH-CYBERNET-20100928
descr: Swisscom (Schweiz) AG
country: CH
admin-c: SG7777-RIPE
admin-c: CHCN1-RIPE
tech-c: CHCN1-RIPE
mnt-lower: SUNWEB-MNT
mnt-routes: SUNWEB-MNT
mnt-domains: SUNWEB-MNT
source: RIPE # Filtered

The IP belongs to a /16 netblock managed by Swisscom AG and a reverse tell us that they are static IP customers (perhaps single IP ADSLs?).

$ nmap 46.14.XXX.XX -p 5900-6000 -PN

Starting Nmap 5.21 ( ) at 2013-07-03 14:25 CEST
Nmap scan report for (46.14.XXX.XX)
Host is up (0.091s latency).
Not shown: 100 filtered ports
5900/tcp open vnc

Nmap done: 1 IP address (1 host up) scanned in 3.60 seconds

The VNC service is still there, so now we have a better idea about the technique used to penetrate that SCADA dashboard.

$ vncviewer 46.14.XXX.XX
Connected to RFB server, using protocol version 3.3
Performing standard VNC authentication

Better to stop here :)

Thanks for leaking our address space!

 Thanks for leaking our data!

We have no idea if that IP is of an actual customer or belongs to an honeypot.. In the first case the Penetration Test was not very successful as the customer did not follow the remediation plan by fixing it’s vulnerability correctly; exposing administrative interfaces, especially VNC services to the Internet is a really bad idea. In the second case we are happy to throw more data to the analyst!