Breaking

Linq Injection – From Attacking Filters to Code Execution

Some of you (especially the .Net guys) might have heard of the query language Linq (Language Integrated Query) 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) presented 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….

Continue reading “Linq Injection – From Attacking Filters to Code Execution”

Continue reading
Breaking

DameWare Vulnerability

In course of a recent research project, I had a look at SolarWinds DameWare, which is a commercial Remote Access Software product running on Windows Server. I identified a remote file download vulnerability in the download function for the client software that can be exploited remotely and unauthenticated and that allows to download arbitrary files from the server that is running the software.

Continue reading “DameWare Vulnerability”

Continue reading
Breaking

Classic Web Vulns Found in Google Search Appliance 7.4

Google Search AppliancesHi all,

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.

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. Continue reading “Classic Web Vulns Found in Google Search Appliance 7.4”

Continue reading
Misc

Another Perspective in Vulnerability Disclosure

As you know we (as in ERNW) are quite involved when it comes to vulnerability disclosure and we’ve tried to contribute to a discussion at several occasions, such as Reflections on Vulnerability Disclosure and ERNW Newsletter 50 Vulnerability Disclosure Reflections Case Study.

In this post I want to add (yet) another perspective, motivated by a disclosure procedure which just happened recently. Continue reading “Another Perspective in Vulnerability Disclosure”

Continue reading
Breaking

Xen XSA 155: Double fetches in paravirtualized devices

As part of my research on the security of paravirtualized devices, I reported a number of vulnerabilities to the Xen security team, which were patched today. All of them are double fetch vulnerabilities affecting the different backend components used for paravirtualized devices. While the severity and impact of these bugs varies heavily and is dependent on a lot of external factors, I would recommend patching them as soon as possible. In the rest of this blog post I’ll give a short teaser about my research with full details coming out in the first quarter of 2016 .

Continue reading “Xen XSA 155: Double fetches in paravirtualized devices”

Continue reading
Misc

Sending Mixed Signals – What Can Happen in the Course of Vulnerability Disclosure

Update:

Given there’s quite some speculation and, as we think, misinformation going around we think it’s helpful to add/clarify the following information:

  • we fully comply with the injunction and we have no intentions to violate it. we do not plan to publish any technical information besides the report (agreed upon with FireEye themselves) and the slides (based on the former) anyway. No 3rd parties except for the ones involved (FireEye, lawyers) have received any additional technical information from our side, let alone an earlier version of the report.
  • the injunction covers accompanying details mostly within the architecture space, but not the core vulnerabilities themselves. Those are not part of the injunction.
  • we stand by the timeline as provided below. In particular, the following two points:
    – FireEye received a draft version of the report which had the objectionable material (as identified by the cease and desist letter) fully removed on August 11th.
    – according to the cease and desist letter FireEye’s lawyer sent us, they were informed – from our side – about the planned talk at 44CON on Jul 23rd.
  • there’s an injunction, but not a lawsuit. I used the term “sue” after consulting Merriam-Webster which states: “sue: to seek justice or right from (a person) by legal process”, but this might have been misinterpreted by some readers. As stated, there’s a pending injunction, but not a lawsuit.

Please note that we won’t share legal documents with 3rd parties or publish them as we consider this inappropriate.
Please note further that, during the whole process, our goal was to perform a responsible disclosure procedure with its inherent objectives (namely vulnerability remediation by vendor and education of various stakeholders involved, see also here or here). We consider this disclosure process as concluded. We don’t see a need to add technical details from our side as we feel that the objectives of responsible disclosure are met (not least as patches are released since quite some time and both vendor & finder have released reports).

===

We’ve just released an ERNW Newsletter titled “Playing With Fire: Attacking the FireEye MPS” which describes several (meanwhile patched) vulnerabilities in FireEye‘s “Malware Protection System” (webMPS) version 7.5.1. Right now Felix gives a talk at 44CON in London on the topic, including some demos. He will release the slides after the talk => to catch the respective announcement you might follow him on Twitter (which is probably a good idea anyway if you’re interested in vulnerability research).

Continue reading “Sending Mixed Signals – What Can Happen in the Course of Vulnerability Disclosure”

Continue reading
Misc

Reflections on Vulnerability Disclosure

In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want to delve into an abstract & general discussion of vulnerability disclosure (for those interested here’s some discussion in the context of Google’s Project Zero, this is the well-known CERT/CC approach, this a paper from WEIS 2006 laying out some variants, and finally some statement by Bruce Schneier back in 2007). Instead I will lay out which approach we followed in the past (and why we did so) and which developments make us consider it necessary to re-think our way of handling. The post is not meant to provide definitive answers; it was also written not least to provide clarity for ourselves (“write down a problem in order to better penetrate it”) and, maybe, to serve as a starting point for a discussion which will help the community (and us) to find a position on some of the inherent challenges.

Continue reading “Reflections on Vulnerability Disclosure”

Continue reading
Breaking

Revisiting Xen’s x86 Emulation: Xen XSA 123

In my last blog post, I gave an overview about recent vulnerabilities discovered in the x86 emulation layer of Xen. While both of the discussed vulnerabilities only allow for guest privilege escalation, the complexity of the involved code seemed to indicate that even more interesting bugs could be discovered. So I spent some time searching for memory corruption issues and discovered a very interesting bug that resulted in XSA 123 . This post gives an overview about the root cause of the bug and a short description of exploitation challenges. A follow-up post will describe possible exploitation strategies in more detail.

Continue reading “Revisiting Xen’s x86 Emulation: Xen XSA 123”

Continue reading
Breaking

The Dangers of x86 Emulation: Xen XSA 110 and 105

Xen Logo

Developing a secure and feature rich hypervisor is no easy task. Recently, the open source Xen hypervisor was affected by two interesting vulnerabilities involving its x86 emulation code: XSA 110 and XSA 105. Both bugs show that the attack surface of hypervisors is often larger than expected. XSA 105 was originally reported by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the emulation routines of several critical system instructions including LGDT and LIDT. The vulnerable code can be reached from unprivileged user code running inside hardware virtual machine (HVM) guests and can be used to escalate guest privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns insufficient checks when emulating long jumps, calls or returns.

Continue reading “The Dangers of x86 Emulation: Xen XSA 110 and 105”

Continue reading