2019-03-24 14:12:00
Earlier this week I had a need to use Citrix Receiver on MacOS, to connect to a remote desktop environment. That's a pretty normal use-case :) Unfortunately it kept throwing me an error: "Cannot create connection file CitrixID".
Looking around the web it seems that plenty of people run into this issue, with plenty of hokey "fixes" going around. None of them got to the root of the issue. But here you are: the root cause!
When installing Citrix Receiver, the installation script uses your admin-rights to run a few commands using the actual root-account. Kind of yucky, but not very abnormal. The problem is that the scripts also creates configuration directories in your personal homedirectory. For example in "/Users/tess/Library/Application Support/Citrix Receiver". As you can see from the screenshot above, these directories and files are assigned root ownership, meaning that your normal user account cannot access or overwrite these files.
The solution consists of either A) changing the ownership to your account and group, or B) just hard-removing these directories and re-creating them. Option A is neater and either requires use of the Terminal (sudo chown -R tess:tess "/Users/tess/Library/Application Support/Citrix Receiver"), or you can try with with the Info-view of the directory and changing the permissions from there.
kilala.nl tags: work,
View or add comments (curr. 0)
2019-03-12 20:02:00
The past week I've gotten my start in an Ansible course and a book, starting my work towards RedHat's EX407 Ansible exam. I've been wanting to get a start in Ansible, after learning a lot about Puppet a few years back. And if I manage to pass EX407 it'll renew my previous RedHat certs, which is great.
Anywho! The online course has its own lab environment, but I'm also applying all that I learn to my homelab. So far Ansible managed the NTP settings, local breakglass accounts and some systems hardening. Next stop was to ensure that my internal PKI's certificates get added to the trust stores of my Linux hosts. I've done this before on RedHat derivatives (CentOS, Fedora, etc), but hadn't done the trick on Debian-alikes (Ubuntu, Kali, etc) yet.
First stop, this great blog post by Confirm IT Solutions. They've provided an example Ansible playbook for doing exactly what I want to do. :) I've taken their example and I'm now refactoring it into an Ansible role, which will also work for Kali (which unfortunately has unwieldy ansible_os_family and ansible_distribution values).
To summarize the differences between the two distributions:
RedHat expects:
Debian expects:
kilala.nl tags: work, sysadmin,
View or add comments (curr. 1)
2019-03-01 22:36:00
Continuing where I left off a few weeks ago, I've redone the network design for my homelab. When we last looked at the network, it was all flat with all VMs tucked in a single subnet behind a pfSense router. Because I want to work towards implementing the CSC in my lab, I've moved everything about quite a lot.
kilala.nl tags: work, studies,
View or add comments (curr. 0)
2019-02-28 14:39:00
It's been two weeks since finishing my index of the SEC566 course materials. This morning, I took the GCCC certification exam and passed with a 93% score! Yay!
On to the next big thing: RedHat's EX407 Ansible exam :)
kilala.nl tags: study,
View or add comments (curr. 2)
2019-02-25 09:57:00
Continuing with security improvements all site and domain admins can apply: everybody that runs their own domain can and should implement SPF: Sender Policy Framework.
What it does, is explicitly tell the whole Internet which email servers are allowed to send email on behalf of your domain(s). Like many similar advertisements, this is achieved through DNS records. You can handcraft one, but if things get a bit too complicated, you can also use the handy-dandy SPF Wizard.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2019-02-18 20:29:00
Ooofff!! I've spent the past three weeks building my personal index for the SANS SEC566 course books. It was quite a slog because the books are monotonous (twenty chapters with the exact same layout and structure), but I've made it through! 29 pages with 2030 keywords.
The index was built using the tried and true method made famous by Hacks4Pancakes and other InfoSec veterans.
Right after finishing the index I took my first practice exam and scored a 90%. That's a good start!
kilala.nl tags: work, studies,
View or add comments (curr. 2)
2019-02-07 18:11:00
If the screenshot above looks familiar to you, you need to pay attention. (Image source)
Microsoft's MIM is a widely used identity management platform for corporate environments. Many MIM tutorials, guides and books (including Microsoft's own site) [1][2][3] refer to Microsoft's sample PAM portal [4] to demonstrate how a request handling frontend could work. In this context, PAM stands for: "Privileged Access Management". While some of these sources make it clear that this is merely a demonstration, I can say without a doubt that there are companies that put this sample PAM portal to use in production environments. [5][6][7][8] Let me restate: there are enterprises putting the sample PAM Portal into production!
In short, the PAM portal allows an authenticated user to activate MIM "roles", which in turn will add groups to their account on-demand. By activating a role, MIM interacts with Active Directory and adds the groups configured for the role, to the end user's account. Unfortunately the sample PAM portal is not suited for production and I suspect that it has had little scrutiny with regards to the OWASP Top 10 vulnerabilities.
The cross-site scripting vulnerability that I ran into concerns the "Justification" field shown in the screenshot below. (Image source)
When activating a role, the end-user is presented with a popup asking for details of the request. The field labeled "justification" allows free entry of any text. It is not sanitized and the length appears to be limited to 400 characters. Through testing I have proven the ability to enter values such as:
<script>alert("Hello there, this is a popup.");</script>
<script>alert(document.cookie);</script>
These Javascript snippets are entered into the backend database without sanitation or conversion. The aforementioned 400 characters limit is easily enough for instructions to download and run shell code.
If we look at "Roles.js" on the Github page we see the following, where the form contents are loaded directly into a variable, without sanitation.
$("form#createRequestForm").submit(function(e){
var roleId = $("#roleIdInput").attr("value");
var justification = $("#justificationInput").val();
... ...
$.when(createPamRequest(justification,roleId,reqTTL,reqTime))
... ...
The "createPamRequest" function is defined in "pamRestApi.js", where yet again the input is not sanitized.
function createPamRequest(reqJustification, reqRoleId, reqTTL, reqTime) {
var requestJson = { Justification: reqJustification, RoleId: reqRoleId, RequestedTTL: reqTTL, RequestedTime : reqTime };
return $.ajax({
url: BuildPamRestApiUrl('pamrequests'),
type: 'POST',
data: requestJson,
xhrFields: {
withCredentials: true
}
})
}
The XSS comes into play when browsing to the "Requests" (History) or the "Approvals" tabs of the sample PAM portal. These pages respectively show the user's own history of (de)activation and other user's requests that are pending approval. After entering the code snippets above, visiting the "History" tab results in two popups: one with the short message and another one blank, as there are no cookie contents.
One viable attack vector would be:
The aforementioned sample PAM portal is a collection of Javascript bundles and functions, thrown together with some CSS and HTML. It has no database of its own, nor any data of its own. All of the contents are gathered from the MIM (Microsoft Identity Manager) database, through the MIM JSON REST API.
Based on the previously discussed vulnerability we can conclude that the MIM JSON REST API does not perform input validation or sanitation! At the very least not on the "Justification" field. The Javascript code I entered into the form was passed directly through the JSON API into the MIM database and was later pulled back from it (for the "Requests" and "Approvals" pages).
I have also verified this by delving directly into the database using SQL Management Studio. The relevant field in the database literally contains the user's input. There is no transcoding, no sanitation, etc.
I reported these issues to Microsoft through their responsible disclosure program in December, right before the holidays. After investigating the matter internally, they have provided a fix to the sample PAM Portal. The January 2019 revision of the code is no longer suceptible to an XSS attack.
Microsoft's resolution consists of hardening the coding of the PAM Portal itself: no data retrieve from the database will be interpreted as HTML. Instead it is hard-interpreted as plain text. Refer to the Github pull request chat for details.
They have NOT adjusted the MIM PAM REST API, which will continue to accept and store any user input offered. This means that accessing the API through Invoke-WebRequest is still susceptible to an XSS attack, because I-WR will happily run any Javascript code found. I showed this with examples earlier this week.
Anyone using the Microsoft MIM PAM Portal in their network should upgrade to the latest version of the project as soon as possible.
Also, if you are using the Powershell command Invoke-WebRequest to access the MIM PAM REST API, you should always adding the flag -UseBasicParsing.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2019-02-04 13:45:00
Well! It's been an interesting month, between work and a few vulnerabilities that I'd reported to a vendor. And now there's this little surprise!
Imagine that you're using Powershell's Invoke-WebRequest command in your management scripts, to access an API or to pull in some data. It happens, right? Nothing out of the ordinary! While I was pentesting one particular API, I decided to poke at it manually using Invoke-WebRequest, only to be met with a surprising bonus! The Javascript code I'd sent to the API for an XSS-attack was returned as part of the reply by the API. Lo and behold! My I-WR ran the Javascript locally!
Screenshot 1 shows the server-side of my proof-of-concept: Python running a SimpleHTTPServer, serving up "testpage.html" from my laptop's MacOS.
In the image above you'll also see the Unix/Linux/MacOS version of curl, which simply pulls down the whole HTML file without parsing it.
Now, the image below shows what happens when you pull in the same page through Invoke-WebRequest in Powershell:
Fun times!
This means that every time you run a curl or Invoke-WebRequest on Windows, you'd better be darn sure about the pages you're calling! This Javascript alert is benign enough, but we all know the dangers of cross-site scripting attacks or just plain malevolent Javascript! Annoyingly, I have not yet found a way to disable JS-parsing in these commands. Looks like it can't be done.
What's worse: these commands are often included in scripts that are run using service accounts or by accounts with administrative privileges! That runs afoul of Critical Security Control #5: controlled use of administrative privileges! (More info here @Rapid7). Basically, you're running a whole web browser in your scripting and tooling!
So be careful out there folks! Think before you run scripts! Check before you call to URLs you're not familiar with! Trust, but verify!
EDIT: I've sent an email to Microsoft's security team, see what they think about all this. I mean, I'm sure it's a well-known and documented fact, but personally I'd feel a lot safer if I had the option to disable scripting (like JS) in Invoke-WebRequest.
EDIT: It looks like the only way to disable Javascript in Invoke-WebRequest, is to disable it in the Internet Explorer browser. Guess that makes sense, because doesn't I-WR use the IE engines?
After discussing the matter with the security team of Microsoft, I have come to understand that I have misunderstood the documentation provided for Invoke-WebRequest. It turns out that you can easily protect yourself from this particular problem by always adding the flag -UseBasicParsing.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 3)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.