Many organisations “lock-down” their desktop environments to reduce the impact that malicious staff members and compromised accounts can have on the overall domain security. Many desktop restrictions can slow down an attacker but it’s often possible to “break-out” of the restricted environment. Both assessing and securing these desktop environments can be tricky, so I’ll run you through how I assess them here, highlight some of the tricks and the methodology that I use with the intention that both breakers and defenders can get a better look at their options.
Same Origin Policy (SOP) is a key security mechanism within the browser that I’ve written about previously. In short, it prevents applications at different origins from interacting with each other. An origin is defined as the domain name, application protocol, and port number.
Same-Origin Policy is a protection mechanism built in to web browsers to prevent malicious web sites from interacting with web sites we visit. I’ve already written a full explanation of the mechanism here, but the TL;DR is that it allows web origins to make requests to other origins but prevents them from reading the response.
Sometimes, however, we may have a business need to allow two origins that we control to interact with each other. One method to allow communication is HTML5 postMessage which I’ve talked about already, another is Cross Origin Resource Sharing (CORS) and I’ll talk about the security implications of CORS here!
When talking to companies about the effects of hacking and data breaches I often talk to companies about the effect on stock prices and the potential for brand damage – but, does a security breach really cause a noticeable effect on share prices? Incidentally I was recently working on a script to pull historical stock data for companies at specific dates. So I figured I’d test drive the new script and pull some historic data for companies immediately following a breach, to show the ultra-short term affect on their share price. So I offer my raw data here without analysis and allow you to draw your own conclusions. It’s pretty interesting to see the initial drops in stock and the patterns that affect all companies and all breaches regardless of how well it is handled.
Group Policy Preferences (GPP) was an addition to Group Policy to extend its capabilities to, among other things, allow an administrator to configure: local administrator accounts (including their name and password), services or schedule tasks (including credentials to run as), and mount network drives when a user logs in (including connecting with alternative credentials). GPP are distributed just like normal group policy, meaning that an XML file is stored in the SYSLVOL share of the domain controllers and when a user logs in their system queries the share and pulls down the policy.
This essentially means that a share exists on the domain controller which any domain user can access which contains other user account credentials, possible including a local administrator password which is reused across the network. This can mean that privilege escalation from a domain user to domain administrator becomes incredibly easy, as I’ve described before.