Wrap-up: Hack-Lab 2017#2

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements. This hack-lab took place in our office in Bern.

 

Topics

The following topics, tools and technology has been discussed during this Hack-Lab:

  1. Threat Modeling and Security Concept session
  2. CMS Assessment
  3. JWT4B development
  4. GnuRadio door bell analysis
  5. Windows Share Enumeration Tool
  6. Exploit.courses testing and training

Wrap-Up

Topic #1 -Threat Modeling and Security Concept session

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his knowledge about threat modeling and security concept creation and analysis with colleagues.

Information Security fundamentals:

  • Security Foundations – CIA
  • Security Design Principles
  • Threat Modeling and Standards

Security Concepts:

  • Ownership and Data Classification
  • Architecture and Network Topology
  • Web Security Controls
  • Operational Security

Topic #2 – CMS Assessment

Using different available security and hardening scanners, we try to asses the security of three CMS: Drupal, Joomla, WordPress.

The goal is to find new vulnerabilities and possible test cases. We refresh and update our Compass Knowledge and improve our tool-set for CMS security assessments.

Technology:

  • Drupal
  • WordPress
  • Joomla
  • Web Scanners written in Python

Topic #3 – JWT4B development

We create a Burp plugin which helps the analyst testing apps which uses JSON Web Tokens (jwt.io).

The first step, which we performed in the previous hacklab, was to create a basic prototype, which enables Burp to visualize the tokens. During this hacklab we increased the functionality, implemented signature checking and interception functionalities.

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which enables him to modify the JWT token comfortably:

Technology:

  • Java
  • JJWT (library)
  • JWT

Topic #4 – GnuRadio door bell analysis

We analyzed a wireless door bell with the help of GnuRadio and HackRF One. We captured the ASK modulated signal, and stored it as digital bitstream in a file. Afterwards we could successfully replay the stored bitstream, making the door bell ring. The next step will include to further analyze the bitstream. 

Technology:

  • GNU Radio
  • HackRF One SDR
  • Kali Linux

Topic #5 – Windows Share Enumeration tool development

If a pentest is performed in a large environment, it is possible that hundreds of accessible Windows shares are available in the network. The goal is to create a tool, which supports us during our penetration tests. Our tool should display the following information for every share in the network:

  • IP Address
  • Hostname
  • Share Name
  • 20 top level files and directories
  • ACLs for the top level files and directories

We managed to implement this tool by combining  Linux Samba tools (smbclient, smbcalcs) in an advanced shellscript.

Technology:

  • Windows, filesharing, network share
  • ACL, Permissions
  • masscan
  • samba / smbclient / smbcacls
  • Linux, Shell, Scripting

Topic #6 – Exploit.courses testing and training

Dobin Rutishauser teaches the “Exploiting & Defense” part of the Application- and Software-Security module at the Bern University of Applied Sciences (Berner Fachhochschule). For this assignment he created a website which provides writeups and challenges to be solved by the students. It also hosts dedicated per-user Linux container, accessible via JavaScript terminal. The Hack-Lab was used to check the website for usability problems, resistance against local DoS attacks, security problems and also basic functionality checks. We also performed a review of some of the writeups, where the team members solved several of the challenges. This includes the ARM buffer overflow challenge, and an extended version of the shellcode development challenge.

The team could identify several small bugs, some small mistakes in the writeups, and gave valuable usability improvement feedback.

Technology:

  • qemu, LXC / LXD
  • x86, x64 and ARM
  • gdb, readelf and python
  • AngularJS and go

Hacking-Lab @ CodeMash 2017

What is CodeMash?

CodeMash is a conference for software developers and IT security professionals. It takes place every year in Sandusky, Ohio, in the U.S.

The event consists of two parts: two days of training sessions (called “PreCompiler”), followed by two days of conference with sessions. It attracts about 3’000 visitors and takes place in the Kalahari resort, which hosts, besides a huge conference center, the largest indoor water park in the U.S.

What the heck did Hacking-Lab do there?

Hacking-Lab was asked to run a Capture-The-Flag tournament at the conference. Ivano and myself took this chance and decided to visit the conference as a sponsor.

Booth

We had a sponsor booth during the conference part. Many people showed up, and we had a lot of interesting discussions! We also gave a lot of “swag” (stickers, USB chargers, etc.).

Capture-The-Flag Tournament

As mentioned above, we were running the official Capture-The-Flag (CTF) tournament of the conference. Even though it was running in parallel with all the interesting sessions at the conference, 100 participants signed up and did a great job! There was quite a neck-and-neck race between the top three, jslagle, CodingWithSpike and fire.eagle!

Win-a-shirt Challenge

Besides the CTF, we also ran a “Win-a-shirt” challenge. It was necessary to solve a small puzzle (simple cipher written in JavaScript), in order to grab a Hacking-Lab t-shirt at our booth. 110 conference visitors did so, and are happy owners of a cool t-shirt now!

    

Training Session

In the “PreCompiler” part, we had a successful, four-hour training sessions. 80 showed up and took the chance to learn about Hacking-Lab. We assisted them in getting ready for the CTF, and they could solve some “Step-By-Step” challenges in Hacking-Lab.

Talk and Sessions

I gave a sponsor talk with the title “Capture-The-Flag Done Right: Attack/Defense System”. I explained our attack/defense system (which we used at the European Cyber Security Challenge), and made some live-demos. Besides that, we also had an “after dark” session, and a couple of “open space” sessions, where we supported CTF players.

       

Conclusion

The CodeMash conference is simply amazing! We were really impressed. Great atmosphere, friendly people, and well organized. The location is great, too. Hacking-Lab will be definitely back next year! There are already plans to run a second competition next year, in addition to the CTF. It should be more like a scavenger hunt, with puzzles and riddles. Perhaps, pretty much like our Hacky Easter events.

How to reduce the threat from third-party includes

To achieve better-looking, more feature-rich and responsive applications, there is an ever-growing need to include resources from 3rd party domains into your web application. Common examples are JavaScript frameworks like jQuery or AngularJS, often distributed via a content delivery network (CDN), or even complete applications like Google Maps. But by including these resources, the security boundary of the web application is extended to include these 3rd party domains. If they get compromised, the delivered resources my be modified or backdoored, thus injecting malicious code into your website.

Fortunately, two browser-side mechanisms have been introduced to mitigate or limit the impact from externally-included resources: Subresource Integrity and sandboxing.

Subresource Integrity

Subresource Integrity (SRI) allows developers to pin down certain versions of scripts or stylesheets which are included from external domains. The goal is to ensure that the external script has not been modified inadvertently, or intentionally replaced or altered by an attacker. A cryptographic hash is used to ensure that the version included in the website has not been tampered with:

<script src="https://external.cdn.ch/example-framework.js" 
integrity="sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYX
ysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==" 
crossorigin="anonymous"></script>

As soon as the content of the external resource “example-framework.js” changes, the hash set on the consuming website does no longer match the script’s hash and the script will not be run by the browser. Note that Cross-Origin Resource Sharing (CORS) must be enabled on the Content Delivery Network’s side to be able to use the integrity attribute, or else the script will not load at all, even with a correct hash.

The SHA-512 hash to pin down external resources can be calculated as follows:

cat example-framework.js | openssl dgst -sha512 -binary | 
openssl base64 -A

While only the script and link tags support the integrity attribute by the time of writing, other tags will probably follow, enabling developers to also ensure the integrity of images or other content embedded from externally.

The crossorigin attribute defines whether or not the browser should send credentials when fetching the external resource. It defaults to anonymous if an invalid value is given. The values are defined as follows:

Keyword State Description
anonymous (or empty string) Anonymous Requests for the element will have their mode set to “cors” and their credentials mode set to “same-origin”. (i.e. CORS request and credentials for the external domain are not sent with the request)
use-credentials Use Credentials Requests for the element will have their mode set to “cors” and their credentials mode set to “include”. (i.e. CORS request and credentials for the external domain are sent with the request)
[crossorigin attribute not present] No CORS Requests for the element will have their mode set to “no-cors”. As a consequence, data cannot be read cross-origin.

Security considerations

SRI only makes sense if the website is secured with TLS. If an attacker is able to intercept and alter the website he can inject his own scripts and strip the hashes or generate them on-the-fly.

Since hashes like MD5 or SHA-1 are prone to collision attacks, they should be avoided for pinning external resources. SHA-384 or SHA-512 are considered secure.

Note that only Firefox, Chrome and Opera support SRI at the time of writing. This means that users of Internet Explorer or Edge do not benefit from the SRI protection. Therefore it is still preferable to host the resources on your own domain, than to depend on SRI.

While SRI can be used to ensure the integrity of external resources, it does not feature a report mechanism that tells the including party if a script has been modified and therefore does no longer run in the user’s browsers. A report-uri mechanism, as known from HSTS, HPKP or CSP, would need to be custom-developed.

Sandboxing

From a security standpoint, it is a bad idea to include external resources directly into the website, because this is giving them full access to the website’s Document Object Model (DOM). A resource could thus access and alter the whole content of the website. When confined in an iframe, access to the parent’s DOM is restricted. It is however still possible to open pop-up windows from within the iframe, display dialogs or perform other unwanted actions. With the HTML5 feature sandboxing, it is possible to further restrict the behavior of “iframed” content.

The following examples would embed content into an iframe, while disabling JavaScript, applying a unique origin to its content and preventing it from using the top-level browsing context:

<iframe src="//external.cdn.ch/example_resource.html" 
id="sandboxed_frame" sandbox="" height="500" width="700"></iframe>
<iframe src="//external.cdn.ch/example_resource.html" 
id="sandboxed_frame" sandbox height="500" width="700"></iframe>

An empty or missing “sandbox” value applies the sandbox as restrictively as possible. This would prevent any execution of JavaScript in the iframe. It is however possible to soften up the sandbox with various flags as shown in the following table, to allow dynamic and interactive content:

Directive Effect
allow-popups Enables iframe content to open pop-up windows.
allow-pointer-lock Enables iframe content to use the Pointer Lock API. The mouse movements can be tracked and the mouse pointer can be hidden.
allow-scripts Enables iframe content to run JavaScript (with the exception of code which must be enabled through further flags, e.g. window.open())
allow-popups-to-escape-sandbox Enables iframe content to create pop-up windows without sandbox restrictions. (Why would you want to do that?!?)
allow-modals Enables iframe content to display modal windows such as alert();, prompt(); or through showModal().
allow-top-navigation Enables iframe content to load content to the top-level browsing context, e.g. via href or target=”_top”.
allow-same-origin

Sandboxed iframe content resides in a custom origin, isolating it from the originating domain. It can therefore not perform requests or read data from its original origin. This directive allows the iframe content to run in the originating domain, thus removing those restrictions.

allow-forms Enables iframe content to submit forms.
allow-presentation Enables iframe content to start presentations.

As always, the sandboxing directive should be set as restrictively as possible. All major browsers support the sandbox feature. While the execution of JavaScript cannot be avoided for non-static content, sandboxing can nonetheless prove valuable to prevent those scripts from opening pop-up windows, dialogues or screen-filling content which could be abused to trick users into revealing their credentials.

Our next Web Application Security courses