Once again we spent an entire semester rifling through papers trying to learn something from the great ideas and mistakes others did before us.
In this post we want to share with you our greatest moments of aha together with the papers that provoked them.

How hacking team got hacked – you would think they got it right

By Conrad Zeller

In this term, we looked at one of the most famous hacks in 2015 – the hack of the Hacking Team. Hacking Team (link to their homepage) is an Italian company that sells offensive intrusion and surveillance services to governments, law enforcement agencies and corporations.

Because they are only focused on money they sell their stuff to rogue states as well and help them to hack and spy journalists, activists and political opposition. For this reason, they got the attention of a hacker who set himself a goal to hack this company and he documented the entire procedure and published it on pastebin.

This was a great experience for me because you would think that an IT Security company would secure themselves as much as they can, but they didn’t. The published DIY guide describes accurately the steps of the hack and helps us to reproduce them. It was nice to see how a “real” hacker thinks and which tools he uses to achieve his goals. We could reproduce his steps and sometimes it was too funny to be real.

But on the other side the hacker who is known as “Phineas Phisher”, did some fancy stuff which only a professional hacker could do. For example, after two weeks of reverse engineering he developed an exploit for one of the routers used by the target company , which was the central element of his hack.

Another interesting part of this topic were the ethical aspects. It was wondrous how such companies which are regarded as legal are working and what their real doing is. It is a MUST read document not only the IT Security affine, but all.

ChromeOS Security – you would really think so

By Benjamin Binder

In the midst of October Daniel Stenberg posted an analysis of a root-exploit on ChromeOS, later completed by this post for Google Project Zero.
The message caught my eye, because it was the first root-exploit on ChromeOS that made the non-techie news.

The bug allowing the exploit was implemented over 13 years ago in the c-ares library. I’m still not sure if it is a good sign that it took that long to discover and exploit the vulnerability.

The attack itself uses a buffer overflow to trick dlmalloc into merging memory areas that should not have been put together. With some very elaborate memory magic the attacker then gains a shell. Because the code calling the c-ares function (the shill HTTP-proxy) is running as root, this saves the attacker some trouble and allows him to execute root commands and pawn the system.

The most astonishing thing about this attack is that it allowed an attacker to execute malicious code from a web-context as root user. This is the exact one thing the ChromeOS security system should have prevented since its main goal is to protect against opportunistic attacks from the internet. Looking at it in hindsight, running the shill HTTP-proxy as root and being very liberal on accepting broken HTTP wasn’t a very good idea in the first place. The bug in thee c-ares library should have at least been found by testing with fuzzied input.

There is an upside to this story however. All bugs and problems have been thoroughly fixed and the HTTP-proxy has been purged from ChromeOS completely.

HTTP 2.0 – Can you believe it has been 16 years?

By David Savastürk

Further we discussed the HTTP 2.0 protocol which should replace the well-known HTTP 1.1 protocol. Did you know that HTTP 1.1 is used for more than 16 years now? 16 years! This is a very long time and HTTP 1.1 still works, but does it do it’s job sufficiently? Well, after our discussion we definitely answered this question with a NO. Especially because of all the hacks of developers which are used to gain some short-time benefits but reduce the overall performance of HTTP 1.1.

However, HTTP 2.0 proposes enough solutions which address these and has a real potential to make the web faster. It has some cool feature like server-push where the server sends content to browsers which is required for the requested page – without a separate request from the browser. For example www.yourpage.de/index.html is requested which has included some CSS and Javascript code. The server will now deliver the requested page and the needed CSS/Javascript. This saves a lot of requests and makes your site even faster. This is only one cool feature, and there are many more.

The best thing is that HTTP 2.0 is fully backward compatible. So go for it!

BBR / F10 – Wer nicht fragt bleibt dumm

By Marc Schelling

To quote a well-known saying: „Sometimes you do not see the wood for the trees”. When reading the papers about BBR and F10 I thought the solutions to their targeting problems where very simple. I doubted that the authors really were the first ones finding this answer? Another question I was wondering about was: “Why did they wrote their paper in such a complicated way? It could be written much easier”.

But that were very narrow-minded thoughts. The solution was the product of the hard work they did.

At the beginning, they had to

• see the problem,
• doubt that the current solution is optimal and
• have the courage to see an argument, that there cannot be a solution, as a hint instead of a dead end. For example, BBR: “Jeffrey M. Jaffe proved it was impossible to create a distributed algorithm that converged to this operating point.”

They had to

• rethink the problem to find a solution differing completely from the current one to bypass the dead end (For example: BBR: “This result changed the direction of research from finding a distributed algorithm that achieved Kleinrock’s optimal operating point to investigating different approaches to congestion control.” They tried again to find a distributed algorithm.)
• and find a simple way to implement their solution to minimize the overhead and keep the costs low. (For example, F10: only change the physical connections of the switches, using the same cables.)
• They had to be experts in their field to find the stumbling blocks, that appeared while implementing their solution. If the solution is error-free, but the results differ from the predicted results. They had to know all technologies used in the solutions environment, to find the parameter limiting their solution. (For example, BBR: “… discovered that 75 percent of BBR connections were limited by the kernel’s TCP receive buffer, …”)

This hard way had to be gone to get the simple solutions belying the complexity they solve. They teach us to question everything from time to time, because new requirements might need better solutions than the ones found in the past. While rethinking I realized that their complex papers point out their struggles on their way, that we can change our thinking instead of using a solution and stay stupid.

Object-oriented programming – write longer functions

By Korbinian Kuhn

One of my personal highlights this term was Brian Will’s video essay why Object-Oriented Programming is Bad. He points out typical problems and non-satisfying solutions in OOP with small examples, tries to prove the pros of procedural programming and talks about code aesthetics in general. I don’t think you have to share his opinion, but whether you’re programming object-oriented or procedural, his video may make you think about it.

Some of his key statements are:

• Encapsulation does not work at a fine-grained level of code!
• Rather minimize state instead of segregating it!
• Absence of structure is more structure than bad structure!
• Encapsulate (loosely) at the level of namespaces/packages/modules!
• Don’t be afraid of long functions!

Raft – Consensus and simplicity?

By Patrick Kleindienst

My first personal moment of “aha” creeped over me when we were discussing our first paper of the lecture, which was about the Raft consensus protocol. Before reading this paper, I’d already learned that Docker  makes use of the Raft protocol for managing its built-in Swarm Mode.

Diving deeper into Raft, I began to understand their intention behind preferring Raft over mainstream protocols like Paxos. I just realized: Hey, distributed consensus and simplicity does not necessarily have to be contradiction! This doesn’t mean that understanding Raft doesn’t presume any efforts, but together we managed to come to a collective comprehension and were finally able to see and explain the fundamental ideas and mechanisms of the Raft protocol.

Beyond Raft, I had another moment of “aha” when we discussed “Pivot Tracing” in one of our last meetings. That was because injecting code into an application (Java-based in the context of this paper) in order to gather diagnostic output for monitoring or troubleshooting was also the idea I pursued in my bachelor’s thesis. Since I’d not heard about Pivot Tracing at this time, reading this paper made me realize that the basic idea might be more meaningful than I thought it is during my thesis.

At least, what virtually shocked me was “How Hacking Team got hacked”. Before starting to read that, I expected to learn about some rocket science hacking practices when going into this. However,  in a terrifying way, recognizing how this hack has been conducted was really disillusioning. Unpatched embedded devices, unencrypted backups as well as NoSQL databases without any sort of authentication seem like an invitation for hackers to me.

What’s the point here is that this is not an individual case! Recently, lots of news popped up concerning MongoDB and Elasticsearch databases which could be accessed from the internet without difficulty. That confirms my opinion that taking care of frequent updates, authentication and authorization cannot be replaced with antivirus software and intrusion detection tools.

We want more….

If you have read a new paper that you think would enlighten others, feel free to post it in the comment section.

 Title image:

Author: Andrew Krasnoyarsk, https://pixabay.com/p-336193/?no_redirect