GCCC certification achieved

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)

Be a good netizen: enable SPF to prevent email spoofing for your domain

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)

GIAC GCCC index and studying

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)

Microsoft MIM PAM Portal and PAM REST API cross-site vulnerability

2019-02-07 18:11:00

 

If the screenshot above looks familiar to you, you need to pay attention. (Image source)

 

XSS attack on Microsoft's PAM Portal

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.

 

Attack vectors

One viable attack vector would be:

1. Attacker has access to a valid Active Directory account (either stolen or their own account).
2. Attacker requests access to a role that requires approval from a privileged administrator.
3. As justification, attacker enters Javascript or similar programming that includes shellcode.
4. Privileged administrator visits the "Approvals" tab and the shellcode is run on their computer, using their privileges.
5. The attacker has now gained access to the privileged administrator's computer with their credentials.

 

Root Cause for the cross-site scripting: MIM PAM REST API

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.

 

Resolution by Microsoft

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.

 

Mitigation

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.

 

Sources

1. O'Reilly Microsoft Identity Manager
2. TLK Tech Identity Thoughts
3. Microsoft docs
4. Sample PAM Portal
5. Microsoft TechNet forums
6. Microsoft TechNet forums (2)
7. Microsoft TechNet forums (3)
8. Just IDM

kilala.nl tags: work, sysadmin,

View or add comments (curr. 0)

Surprise! Invoke-WebRequest runs Javascript

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?

---

Update and correction

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)

Homebrew CMS security improvements

2019-02-02 21:07:00

Did you know that Mozilla offer a great resource called Observatory? This tool scans your website and provides you focused instructions on how to improve the basic security of your site. It'll help you prevent the most common causes for XSS, CSRF and more! With about an hour's work, I've taken my site from an F score to A+ :)

Now, it's been ages since I've first started work on this website of mine. Can't properly recall when I first started, but it's been at least tens years since version 1.0. I will readily admit that I'm an utter, utter hack: self-taught, borrowing code left and right, just trying to get things work. Along the way I've picked up security lessons, mostly on how to prevent SQLi and XSS. And now, thanks to Observatory I've learned more! 

Mozilla's web security guidelines document has been a great help! Until this week I'd never heard of HSTS or CSP, so I've taken time to improve my site's security posture. This included properly sourcing my own Javascript and diking out a lot of the JS I'd been sourcing externally (reCaptcha, Google Analytics, etc), just because they were dead weight to me. I had heard about SRI before through Troy Hunt's excellent article about Javascript supply chain security.

Anywho. It's been a learning experience! This little blog of mine ain't pretty, nor very exciting, but it's my little home and it makes a nice testbed to practice coding.

Some useful resources that helped me along:

• SHA256 calculator, because pasting JS into a box and clicking a button is easier ;)
• The whole CSP standard explained.
• Google's documentation and tips on adopting CSP. Includes simple things like migrating from href:javascript to in-line JS with hashes/nonces.
• StackOverflow explanation of CSP nonces.
• More of Troy Hunt's writing on CSP.
• Document on implementing SRI.

kilala.nl tags: website,

View or add comments (curr. 0)