{"id":1770,"date":"2017-06-08T17:40:03","date_gmt":"2017-06-08T15:40:03","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=1770"},"modified":"2023-08-06T21:50:48","modified_gmt":"2023-08-06T19:50:48","slug":"our-moments-of-aha","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2017\/06\/08\/our-moments-of-aha\/","title":{"rendered":"Our moments of AHA"},"content":{"rendered":"

\"Lightbulb<\/a><\/p>\n

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

How hacking team got hacked – you would think they got it right<\/strong><\/h2>\n

By Conrad Zeller<\/p>\n

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

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<\/a>.<\/p>\n

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 \u201creal\u201d 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.<\/p>\n

But on the other side the hacker who is known as \u201cPhineas Phisher\u201d, 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.<\/p>\n

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.<\/p>\n

ChromeOS Security – you would really think so<\/strong><\/h2>\n

By Benjamin Binder<\/p>\n

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

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.<\/p>\n

The attack itself uses a buffer overflow to trick dlmalloc<\/a> 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.<\/p>\n

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.<\/p>\n

There is an upside to this story however. All bugs and problems have been thoroughly fixed<\/a> and the HTTP-proxy has been purged<\/a> from ChromeOS completely.<\/p>\n

HTTP 2.0 – Can you believe it has been 16 years?<\/strong><\/h2>\n

By David Savast\u00fcrk<\/p>\n

Further we discussed the HTTP 2.0 protocol<\/a> 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\u2019s 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.<\/p>\n

However, HTTP 2.0 proposes enough solutions<\/a> 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 \u2013 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.<\/p>\n

The best thing is that HTTP 2.0 is fully backward compatible. So go for it!<\/p>\n

BBR \/ F10 – Wer nicht fragt bleibt dumm<\/strong><\/h2>\n

By Marc Schelling<\/p>\n

To quote a well-known saying: \u201eSometimes you do not see the wood for the trees\u201d. When reading the papers about BBR<\/a> and F10<\/a> 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: \u201cWhy did they wrote their paper in such a complicated way? It could be written much easier\u201d.<\/p>\n

But that were very narrow-minded thoughts. The solution was the product of the hard work they did.<\/p>\n

At the beginning, they had to<\/p>\n