<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Timo Schmid on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/authors/timo-schmid/</link>
    <description>Recent content in Timo Schmid on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 26 Oct 2017 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/authors/timo-schmid/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Interacting with the BlueCoat Filesystem</title>
      <link>https://insinuator.net/2017/10/interacting-with-the-bluecoat-filesystem/</link>
      <pubDate>Thu, 26 Oct 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/10/interacting-with-the-bluecoat-filesystem/</guid>
      <description>&lt;p&gt;the last &lt;a href=&#34;https://insinuator.net/2017/10/reading-the-bluecoat-filesystem/&#34;&gt;post&lt;/a&gt; was about a fuse filesystem which provides a read-only access to the proprietary bluecoat filesystem. After some further investigations based on the possibilities this offered us, I started to implement a tool which allows to modify parts of the filesystem.&lt;/p&gt;&#xA;&lt;h2 id=&#34;protection-mechanisms&#34;&gt;Protection Mechanisms&lt;/h2&gt;&#xA;&lt;p&gt;Since last time, the discovered filesystem structures still had unknown fields. Some of those fields could be reconstructed and their purpose in the whole construct. The format of the &lt;code&gt;Partition&lt;/code&gt;-Header for example could now be described as&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reading the BlueCoat FileSystem</title>
      <link>https://insinuator.net/2017/10/reading-the-bluecoat-filesystem/</link>
      <pubDate>Thu, 05 Oct 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/10/reading-the-bluecoat-filesystem/</guid>
      <description>&lt;p&gt;You may remember our &lt;a href=&#34;https://insinuator.net/2016/12/research-diary-blue-coat/&#34;&gt;last post&lt;/a&gt; regarding the SGOS system and the proprietary file system. Since then, we got access to a newer version of the system (6.6.4.2). Still not the most current one (which seems to be 6.7.1.1) nor of the 6.6.x branch (which seems to be 6.6.5.1) though. As this system version also used the same proprietary filesystem (although it initially booted from a FAT32 partition), I decided to take a deeper look into this.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Git Shell Bypass By Abusing Less (CVE-2017-8386)</title>
      <link>https://insinuator.net/2017/05/git-shell-bypass-by-abusing-less-cve-2017-8386/</link>
      <pubDate>Wed, 10 May 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/05/git-shell-bypass-by-abusing-less-cve-2017-8386/</guid>
      <description>&lt;p&gt;The &lt;em&gt;git-shell&lt;/em&gt; is a restricted shell maintained by the git developers and is meant to be used as the upstream peer in a git remote session over a ssh tunnel. The basic idea behind this shell is to restrict the allowed commands in a ssh session to the ones required by git which are as follows:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;em&gt;git-receive-pack&lt;/em&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Receives repository updates from the client.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&lt;em&gt;git-upload-pack&lt;/em&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Pushes repository updates to the client.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&lt;em&gt;git-upload-archive&lt;/em&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Pushes a repository archive to the client.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Besides those built-in commands, an administrator can also provide it’s own commands via shell scripts or other executable files. As those are typically completely custom, this post will concentrate on the built-in ones.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Research Diary: Blue Coat</title>
      <link>https://insinuator.net/2016/12/research-diary-blue-coat/</link>
      <pubDate>Mon, 05 Dec 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/12/research-diary-blue-coat/</guid>
      <description>&lt;p&gt;As a part of our research time here at ERNW, last week we had an interesting time looking at one of the widespread and commonly adopted proxy appliance by many organizations Blue Coat Secure Gateway.&lt;/p&gt;&#xA;&lt;h1 id=&#34;introduction&#34;&gt;Introduction&lt;/h1&gt;&#xA;&lt;p&gt;The Blue Coat proxy Secure Gateway (SG) has been already in the market since 2001 [1]. The main aim of introducing the appliance was to achieve the following goals [2]:&lt;br&gt;&#xA;• High performance optimization.&lt;br&gt;&#xA;• Increasing the security measurements, by introducing malware/spyware protections, web based filtering, virus scanning and more.&lt;br&gt;&#xA;• Flexible Access Control capabilities.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reverse Engineering With Radare2 – Part 3</title>
      <link>https://insinuator.net/2016/10/reverse-engineering-with-radare2-part-3/</link>
      <pubDate>Mon, 24 Oct 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/10/reverse-engineering-with-radare2-part-3/</guid>
      <description>&lt;p&gt;Sorry about the larger delay between the previous post and this one, but I was very busy the last weeks.&lt;br&gt;&#xA;(And the technology I wanted to show wasn’t completely implemented in radare2, which means that I had to implement it on my own 😉 ). In case you’re new to this series, you’ll find the previous posts &lt;a href=&#34;https://insinuator.net/tag/radare2/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;As you may already know, we’ll deal with the third challenge today. The purpose for this one is to introduce&lt;br&gt;&#xA;some constructs which are often used in real programs.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Linq Injection – From Attacking Filters to Code Execution</title>
      <link>https://insinuator.net/2016/10/linq-injection-from-attacking-filters-to-code-execution/</link>
      <pubDate>Mon, 17 Oct 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/10/linq-injection-from-attacking-filters-to-code-execution/</guid>
      <description>&lt;p&gt;Some of you (especially the .Net guys) might have heard of the query language Linq (&lt;em&gt;Language Integrated Query&lt;/em&gt;) used by Microsoft .Net applications and web sites. It’s used to access data from various sources like databases, files and internal lists. It can internally transform the accessed data in application objects and provides filter mechanisms similar to SQL. As it is used directly inside the application source code, it will be processed at compile time and not interpreted at runtime. While this provides a great type safety and almost no attack surface for injection attacks (except from possible handling problems in the different backends), it is extremely difficult to implement a dynamic filter system (e.g. for datatables which should allow users to select the column to filter on). That’s probably the reason why Scott Guthrie (Executive Vice President of the Cloud and Enterprise group in Microsoft, also one of the founders of the .Net project) &lt;a href=&#34;https://weblogs.asp.net/scottgu/dynamic-linq-part-1-using-the-linq-dynamic-query-library&#34;&gt;presented&lt;/a&gt; the System.Linq.Dynamic package as part of the VS-2008 samples in 2008. This library allows to build Linq queries at runtime and therefore simplify dynamic filters. But as you may know, dynamic interpretation of languages based on user input is most of the time not the best option….&lt;/p&gt;</description>
    </item>
    <item>
      <title>Diving into EMET</title>
      <link>https://insinuator.net/2016/09/diving-into-emet/</link>
      <pubDate>Mon, 26 Sep 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/09/diving-into-emet/</guid>
      <description>&lt;p&gt;Last week, we decided to take a look onto the EMET library provided by Microsoft. This library is intended to introduce several security features to applications which are not explicitly compiled to use them.&lt;/p&gt;&#xA;&lt;p&gt;It also adds an additional layer to protect against typical exploiting techniques by filtering library calls, preventing usage of dangerous functions/components and inserting mitigation technologies.&lt;/p&gt;&#xA;&lt;p&gt;As EMET is already a target for many researchers, we currently only started to get an overview of it’s structure and how the different components are interacting with each other. Today we would like to share some of our results with you.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reverse Engineering With Radare2 – Part 2</title>
      <link>https://insinuator.net/2016/08/reverse-engineering-with-radare2-part-2/</link>
      <pubDate>Mon, 29 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/reverse-engineering-with-radare2-part-2/</guid>
      <description>&lt;p&gt;Welcome back to the radare2 reversing tutorials. If you’ve missed the previous parts, you can find them &lt;a href=&#34;https://www.insinuator.net/?p=6233&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;https://www.insinuator.net/2016/08/reverse-engineering-with-radare2-part-1/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Last time we’ve used the rabin2 application to view the  strings found inside the challenge01 binary to find password candidates. Based on the results we looked into the assembly to find the correct password. In this post, we’ll go through the next challenge and try out some of the features provided by radare2.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reverse Engineering With Radare2 – Part 1</title>
      <link>https://insinuator.net/2016/08/reverse-engineering-with-radare2-part-1/</link>
      <pubDate>Fri, 19 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/reverse-engineering-with-radare2-part-1/</guid>
      <description>&lt;p&gt;Welcome back to the radare2 reversing tutorials. If you’ve missed the intro, you can find it &lt;a href=&#34;https://www.insinuator.net/?p=6233&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The last time you got the challenge01 binary and your goal was to find the password for the login. Let’s see how the application looks like:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ ./challenge01&#xA;##################################&#xA;#          Challenge 1           #&#xA;#                                #&#xA;#      (c) 2016 Timo Schmid      #&#xA;##################################&#xA;Enter Password: test&#xA;Wrong!&lt;/code&gt;&lt;/pre&gt;&#xA;&lt;p&gt;The first and simplest step would be to look for strings inside the binary. We could do this either by using the unix utility &lt;em&gt;strings&lt;/em&gt; or the binary analyzing binary from radare &lt;em&gt;rabin2:&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reverse Engineering With Radare2 – Intro</title>
      <link>https://insinuator.net/2016/08/reverse-engineering-with-radare2-intro/</link>
      <pubDate>Wed, 03 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/reverse-engineering-with-radare2-intro/</guid>
      <description>&lt;p&gt;As some of you may know, there is a “new” reverse engineering toolkit out there which tries to compete with IDA Pro in terms of reverse engineering. I’m talking about &lt;a href=&#34;http://radare.org/r/index.html&#34;&gt;radare2&lt;/a&gt;, a framework for reversing, patching, debugging and exploiting.&lt;/p&gt;&#xA;&lt;p&gt;It has large scripting capabilities, runs on all major plattforms (Android, GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku, FirefoxOS and even on your pebble smartwatch 😉 ) and is free.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Pentesting Webservices with Net.TCP Binding</title>
      <link>https://insinuator.net/2016/08/pentesting-webservices-with-net.tcp-binding/</link>
      <pubDate>Mon, 01 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/pentesting-webservices-with-net.tcp-binding/</guid>
      <description>&lt;p&gt;Hi all,&lt;/p&gt;&#xA;&lt;p&gt;Most of you that are  pentesters  may have already tested plenty of webservices using SOAP (&lt;em&gt;Simple Object Access Protocol&lt;/em&gt;)* *for communication. Typically, such SOAP messages are transferred over HTTP (&lt;em&gt;Hypertext Transfer Protocol&lt;/em&gt;) and are encapsulated in XML (&lt;em&gt;Extensible Markup Language&lt;/em&gt;). Microsoft has developed different representations of this protocols to reduce the network load. As these representations/protocols aren’t really covered by typical tools out there, this post will show you some of them, and a proxy which can be used to simplify the testing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Classic Web Vulns Found in Google Search Appliance 7.4</title>
      <link>https://insinuator.net/2016/03/classic-web-vulns-found-in-google-search-appliance-7.4/</link>
      <pubDate>Wed, 23 Mar 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/03/classic-web-vulns-found-in-google-search-appliance-7.4/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://www.google.com/intx/en/work/search/products/gsa.html&#34;&gt;&lt;img src=&#34;https://www.insinuator.net/wp-content/uploads/2016/03/servers-300x156.png&#34; alt=&#34;Google Search Appliances&#34;&gt;&lt;/a&gt;Hi all,&lt;/p&gt;&#xA;&lt;p&gt;I’ve recently found some sort of classic web vulnerabilities in the Google Search Appliance (GSA) and as they are now fixed [0][1][2], I’d like to share them with you.&lt;/p&gt;&#xA;&lt;p&gt;First of all, some infrastructure details about the GSA itself. The GSA is used by companies to apply the Google search algorithms to their internal documents without publishing them to cloud providers. To accomplish this task, the GSA provides multiple interfaces including a search interface, an administrative interface and multiple interfaces to index the organization’s data.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Social Coding – Simple Things to Keep in Mind (updated)</title>
      <link>https://insinuator.net/2015/10/social-coding-simple-things-to-keep-in-mind-updated/</link>
      <pubDate>Mon, 26 Oct 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/10/social-coding-simple-things-to-keep-in-mind-updated/</guid>
      <description>&lt;p&gt;The current trend of social coding finally arrived at ERNW! From now on, you will find our public released tools and scripts commonly on &lt;a href=&#34;https://github.com/ernw&#34;&gt;https://github.com/ernw&lt;/a&gt;. Therefore I would like to share some thoughts/guidelines which you have to keep in mind if you want to be a social coder:&lt;/p&gt;&#xA;&lt;p&gt;Github and other repository hosts are great if you want to share opensource tools with the community, as they will find a common platform with defined workflows to extend/fix the work to get better software for everyone. What some should note is that (especially in terms of decentralized version control systems (DVCSs) like git, bazaar or mercurial) public really means public. Back in earlier days, if you shared your code with others you probably created a source code package of a defined version of your code. They will get the files you published, nothing more (and nothing less). Beginning with websites like sourceforge, a broader range of public VCSs came up (mostly driven by CVS or SVN). At this time, others were able to view your commit history (if you granted access to them) and all your mistakes you’ve done before your published code state (for example accidentally committed sensitive data). Those mistakes can still happen today. The difference with the DVCS used nowadays is that most of the time you have lesser control of your commit history (in the same way if someone had copied your history commit by commit in SVN, but then you may had noticed it because of the high network traffic). With DVCS, everyone gets a full copy (clone) of your repository even on a simple “checkout” (as called in SVN). This means he/she is able to search your history locally and has all the time he/she needs to do it. Even if you delete your repository (or modify the history), the original state is shared over all who have cloned it beforehand (thats one reason why DMCA takedowns are not that powerful/useful against git repositories).  Most of the public hosting platforms even included a search over all repositories (which is really useful if you want to find some tool or try to find the reason why a local tool doesn’t work).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Python For Hackers</title>
      <link>https://insinuator.net/2015/09/python-for-hackers/</link>
      <pubDate>Tue, 29 Sep 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/09/python-for-hackers/</guid>
      <description>&lt;p&gt;Python has reached a defacto standard in exploit development lifecycles and most of the proof of concept tools you’ll find out there are written in Python (besides the metasploit framework, which is written in Ruby). Python allows to write scripts handling with remote services, fiddling with binary data and interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a fast and easy way. The huge standard library with it’s “battery included” principle removes some of the dependency hell known from other frameworks/languages. I want to share some of my python coding experiences with you, and maybe this could give some helpful tips for your future work, to make the world a bit safer 🙂 (PS: most of the examples are written in Python 3.x or compatible to both Python branches).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some Security Impacts of HTML5 CORS or How to use a Browser as a Proxy</title>
      <link>https://insinuator.net/2013/08/some-security-impacts-of-html5-cors-or-how-to-use-a-browser-as-a-proxy/</link>
      <pubDate>Mon, 26 Aug 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/08/some-security-impacts-of-html5-cors-or-how-to-use-a-browser-as-a-proxy/</guid>
      <description>&lt;p&gt;With HTML 5 the current web development moves from server side generated content and layout to client side generated. Most of the so called &lt;em&gt;HTML5 powered&lt;/em&gt; websites use JavaScript and CSS for generating beautiful looking and responsive user experiences. This ultimately leads to the point were developers want to include or request third-party resources. &lt;em&gt;Un&lt;/em&gt;fortunately all current browsers prevent scripts to request external resources through a security feature called the &lt;em&gt;Same-Origin-Policy&lt;/em&gt;. This policy specifies that client side code could only request resources from the domain being executed from. This means that a script from example.com can not load a resource from google.com via AJAX(XHR/XmlHttpRequest).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Python Library for De- and Encoding of WCF-Binary streams</title>
      <link>https://insinuator.net/2011/12/python-library-for-de-and-encoding-of-wcf-binary-streams/</link>
      <pubDate>Fri, 23 Dec 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/12/python-library-for-de-and-encoding-of-wcf-binary-streams/</guid>
      <description>&lt;p&gt;In a .NET environment WCF services can use the proprietary WCF binary XML protocol described &lt;a href=&#34;https://blogs.msdn.com/b/drnick/archive/2009/09/11/binary-encoding-part-4.aspx&#34;&gt;here&lt;/a&gt;. Microsoft uses this protocol to save some time parsing the transmitted XML data. If you have to (pen-) test such services, it would be nice to read (and modify) the communication between (for example) clients and servers. One possibility is &lt;a href=&#34;http://www.fiddler2.com&#34;&gt;Fiddler&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Fiddler’s strengths include its extensibility and its WCF binary plugins. Sadly, these plugins can only decode and display the binary content as XML text.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Use Python for Burp plugins with pyBurp</title>
      <link>https://insinuator.net/2011/12/use-python-for-burp-plugins-with-pyburp/</link>
      <pubDate>Fri, 23 Dec 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/12/use-python-for-burp-plugins-with-pyburp/</guid>
      <description>&lt;p&gt;One of our favorite tools for conducting penetration tests (especially, but not only, web application tests) is Portswiggers’s &lt;a href=&#34;http://portswigger.net/burp/&#34; title=&#34;Burp Suite&#34;&gt;Burp Suite.&lt;/a&gt; Burp allows to extend its features by writing own plugins. But because Burp is written in Java, it only supports Java classes as plugins. Additionally, Burp only allows to use one plugin at the same time which has to be loaded on start-up.&lt;/p&gt;&#xA;&lt;p&gt;Now we have written a Burp-Python proxy (called &lt;strong&gt;pyBurp&lt;/strong&gt;) which adds some features to the plugin system:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
