Last Updated: 2014-05-29 03:09:40 UTC
by Johannes Ullrich (Version: 1)
Earlier today, the popular disk encryption tool Truecrypt was essentially removed from Sourceforge, and replaced with a warning that Truecrypt is no longer secure and people should switch to Bitlocker (with instructions as to how to do this). The source code was updated and essentially all functionality was removed but the installer will now just show a message similar to the one displayed on the homepage.
What you probably are asking first about: What does this mean for me if I use Truecrypt?
At this point, there are many rumors, and few facts. It is my recommendation (as always) to stay calm. One thing you want to do right away: Get a copy of the last working version and burn it to CD (actually: 3 CDs) in case it is no longer available and you need to access offline media that are encrypted using Truecrypt. Find out what your alternatives are. In Windows you have Bitlocker, in OS X you got FileVault and in Linux you got LUKS. Sadly, these are not compatible with each other. You will need to find a replacement for portable media that need to move between operating systems. PGP/GnuPG comes to mind as an option.
Now back to what we know so far:
Recently, a community effort was launched to review the Truecrypt code, in particular to check for backdoors and incorrectly implemented crypto algorithms. As far as I know, no significant issue was found to date.
This very much smells to me like a compromised Sourceforge repository. Truecrypt uses Sourceforge for all of its content. At this point, sit back, don't visit the Truecrypt Sourceforge page or download the crippled version, but don't panic (yet).
But, via twitter and e-mail, some additional disturbing facts came in that make this look worse then a simple web site compromise:
- The new "decrypt only" binary was signed with what looks like a valid Truecrypt code signing key (I believe GRC.com investigated this)
- The PGP signature was valid as well
- The Truecrypt development team is anonymous, and so far, no word if the code review team was able to reach them.
Correction about the earlier note that Sourceforge was compromised: Turns out that they asked users to change passwords NOT because of a compromise, but because they changed the hashing algorithm.
Last Updated: 2014-05-28 02:04:54 UTC
by Rob VandenBrink (Version: 1)
Something I've noticed recently is that most of the websites I've been asked to assess now seem to be "new, improved, and with an API". Often the API is based on SOAP, and it's been an interesting discussion on how best to scan these new Web Services based on WSDL for vulnerabilities.
The simple way is to run the developers test suite, usually coded up as a project file in SoapUI, through BURP. However, what folks are finding is that the proxy function within SoapUI simply doesn't work, especially for HTTPS. And the SoapUI solution to get around this is pretty convoluted. The solutions that folks have generally come up with have also in some cases been complex, and most of them include the step "change the SoapUI test for this case from HTTPS to HTTP" (counting on BURP to flip it back to HTTPS). (http://ardsec.blogspot.ca/2012/08/soapui-to-burp-fuzz-away.html and http://gerionsecurity.com/2013/03/soapui-with-burp/ for instance lay out two ways to take this path).
These solutions against the grain for me, mostly because I'm lazy. If I need to update all of the test cases in an API, that's generally somewhere between 1-3 mods per API call, and when the developer comes out with the next version (as they are wont to do), I have to do all of that all over again. And if I miss one, that'll be the one that would have given me SQL injection or something else equally good.
So how do I get around this?
Simple. I use the "Invisible Proxy" feature within Burp (any other product would call this "transparent" instead of "invisible" proxy). Let's do this step by step:
You'll need two hosts - I use two VMs. Mainly because my mantra is that you really need a good reason to rn anything physical. Install SoapUI on one, and Burp on the other. I'm going to assume that these are both Windows boxes, but this works just as well with Linux of course
1/ Out of the box, run all the tests within the SoapUI project, as received from the developers
2/ Now flip out to a command prompt and dump your DNS cache, so you know which hosts are being called in the API (they're not always the hosts you think they are). In Windows, this is:
or, since you just want the hostnames and IPs (in short, the actual DNS records), run:
ipconfig /displaydns | find "Record"
Many Linux hosts don't do DNS Caching, so you might need to run tcpdump and capture unique dns queries instead (or extract the DNS records used by the SOAP tests from your local DNS Server logs, but that's not as reliable)
3/ Next, on the SoapUI machine edit the local hosts file (c:\windows\system32\drivers\etc\hosts, or /etc/hosts) and add a host entry for each of the API targets. Instead of the real IP of the target, use the IP of the Burp machine, so that the Test Suite is directed at Burp.
4/ Over to Burp to the Burp machine, fire up Burp, and enable Transparent Proxy. Be sure to enable it for the address you are targeting as proxy, or enable it for everything. Also be very sure that you enable it for each port in use. I've noticed developers lately have started using not just tcp/80 and 443, but have started getting "cute" with the https ports, often using 4443, 8443, 8843 and so on. That pcap file created in step 2 might come in really handy, or you can just look at the various tests in the Test Suite to get all of these ports. You'll need a proxy set up for each tcp port in use.
For instance, setting up port 443 will look like:
When you are done, your proxy Options screen should look like this ā?? ā??Invisibleā? indicates a port that is proxying transparently (note that your screen will vary depending on ports in use)
5/ Back to your SoapUI machine, re-run your API tests - they'll all show nicely in the Burp Target pane!
6/ Still in Burp, everything is now set up to use Scanner, Repeater, Intruder or any of the other Burp functions. For instance, in Burp Scanner, the SOAP services above ended up with the issues listed below:
And yes, SQL injection was verified and worked, so did XML injection!
Interestingly, there is a security tab in SoapUI, where you can do some basic security tests - mostly looking for basic SQL Injection and XML Injection. Iā??m still playing with this ā?? so far Iā??ve been running both, and Burp is coming out ahead. However the SoapUI app is showing XSS vulnerabilties that Burp does not. Look for a second story on this after I've had some time to work it through.
Of course, the tools will only get you so far. Once you have a list of possible vulnerabilities, you still need to manually verify each one. And also of course, once you have the API all mapped out, playing with it manually (or with Repeater / Attacker and so on in Burp) will often net you your best findings.
What will you typically see? Developers are getting the idea that XSS and SQL injection are bad things, so in well run dev shops I'm seeing this easy stuff crop up less and less. However, every time I look at an API, I find this good stuff all over again. SQL injection in the API is just too much fun ! XML injection is also very common (of course) - you'll find that if you put this in your report as a finding, you'll have to add a page on what exactly that is, and how it impacts the security of the application, and in turn how it impacts the organization.
So, in short, APIs seem to be offering up the new ā??low hanging fruitā?. If you've found something cool in a SOAP API, please let us know in our comment form. Or better yet, if you've found some other way to simplify proxying SoapUI through Burp or otherwise evaluating SOAP interfaces, please also let us know!
SoapUI plus Burp - it's like chocolate, but with more chocolate!