Archive
A Review of the Grizzly Steppe (Russian Hacking) Report
I, like many, have heard the stories that the Russians hacked into sensitive applications/servers in an effort to compromise the US elections. That is a bold statement and if true, may justify the actions recently taken by the Obama administration. So it was with keen interest that I rushed to read the findings from the Joint Analysis Report (JAR-16-20296) between DHS and the FBI to see what evidence they had to substantiate these claims.
The full report may be found here:
The report makes the following claims:
“This document provides technical details regarding the tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election…”
“Previous JARs have not attributed malicious cyber activity to specific countries or threat actors. However, public attribution of these activities to RIS is supported by technical indicators from the U.S. Intelligence Community, DHS, FBI, the private sector, and other entities.”
Based on this information the US felt like it had the smoking gun and definitive proof of the following:
- The Who – the Russians were behind the attack
- The Why – to affect the US elections in order to guide the outcome
With this information in hand, I continued reading to now learn about:
- The How – how the attacks were performed
- The Proof – the evidence to substantiate Who, Why, and How
The report describes the “How” in a two pronged attack as follows:
Hack #1 – Casting the Phish Net…
1. A general spearphishing attack was sent to more than 1,000 people which included (in addition to others) several people from the U.S. Government.
Note: The number “1,000” is very specific so it seems like the government has some knowledge of the recipients – but they stop short of specifying if that 1,000 was directed at a particular party or not. I would think that would be important to know if the purpose of the attack was to affect the US election.
2. The attack led to one person from a particular U.S. political party falling prey to the attack and opening an attachment containing malware. This led to a chain of events where the malware was able to:
- Establish persistence on a “political party system”
- “Escalate privileges”
- “Enumerate Active Directory accounts”
- “Exfiltrate email from several accounts through encrypted connections back through operational infrastructure”
Note: This all sounds really impressive, but what does it all mean? If you remove all the jargon (enumerate, exfiltrate, etc.) and put this in layman’s terms, it sounds like the following occurred:
- Someone installed malware on their PC when they opened a file that they shouldn’t have
- Somehow the malware was able to gain privileged access to Active Directory
- The malware was able to perform a search against Active Directory
- The results of the search returned several email accounts
With this information on mind, there are a few things I am curious about.
First, the malware is only able to impersonate the user on the operating system on which it was installed. I’m not sure how a “normal user” can have escalated privileges in Active Directory unless that user is an administrator with escalated privileges (which brings up a whole different conversation about administrators knowing better). So I am curious how the malware was able to “escalate privileges” on its own.
Second, if the user (hence the malware) was not an administrator and they were able to perform an unauthorized search against Active Directory, then that indicates that Active Directory authorization and/or limitations were not configured properly. It has been my experience that Active Directory is (by default) pretty well locked down. Is it possible that the default settings were “relaxed” a bit and therefore may have opened up a hole?
Finally, would I really need “escalated privileges” just to troll email accounts? Couldn’t I simply scan the Outlook address book to obtain this information? It seems like the approach described in the report would take a lot of effort to code and would have a limited chance of success. Wouldn’t the malware have to land on an administrator’s computer for this approach to work?
3. Either way, the end result was that APT29 was able to get a list of email addresses from Active Directory.
Fast forward almost a year later (summer 2015 to spring 2016) and this takes us to the second part of our story.
Hack #2 – Hooking the Phish…
1. In the second hack, a targeted spearphishing attack was launched against the same political party that was compromised in the first attack.
Note: It should be noted that while the first attach was general (casting a net if you will), the second attack was targeted at a certain set of people using specific information to more easily trick those people. While the report doesn’t specifically say this, it is assumed that the attack targeted those email addresses that were obtained from the first attack.
Does this indicate that the political party in question was targeted because the end goal was to affect the election? If so, then this attack was planned almost a year in advance when we really didn’t have a clear picture as to who the candidates would be from either party. Were the Russians hedging their bets in case a certain party (or a certain candidate) was found to be leading? It seems more plausible that the second attack was launched more against a certain set of users more as a target of opportunity than anything else.
2. This spearphishing attack tricked multiple people into “changing their passwords through a fake webmail domain hosted by APT28”.
3. Upon initial login, APT28 was able to obtain the “real” credentials of users associated with the political party in question.
4. With these credentials in hand, APT28 was able to log into the real email server and access content (emails, attachments, etc.). The report goes on to say that this information was subsequently “leaked to the press and publicly disclosed.”
Where’s the Smoking Gun?
While the report is somewhat interesting, it does not provide the “smoking gun” that was anticipated. The report does provide a list of 48 hacker names of which APT28 and APT29 are included. The title of the table is “Reported Russian Military and Civilian Intelligence Services (RIS)” but there is nothing more than that to introduce the table and tell us anything about the names contained in the table. Am I supposed to jump to the conclusion that because APT28 and APT29 are listed that this is definitive proof that:
- they are the ones behind these attacks
- no one else has attempted to use these names as their hacking alias
- they specifically targeted a particular political party
- their intent was to affect the US election
- and most importantly, they are “state sponsored”
The last item is one of the most important as the administration has chosen to take action against Russia (the state) as if they sanctioned the attacks. If that is true then the need for a smoking gun becomes infinitely more important and that information is simply not provided. Going back to a statement made early on in the report,
“Previous JARs have not attributed malicious cyber activity to specific countries or threat actors. However, public attribution of these activities to RIS is supported by technical indicators from the U.S. Intelligence Community, DHS, FBI, the private sector, and other entities.”
the government has made it clear that it is stepping outside of normal protocol by publicly naming the attacker in the JAR. But they don’t provide any information to back up their claim. Nor is there anything specifically that indicates that this had anything to do with an attempt to affect the outcome of the US election; in fact, the information presented may lead one to believe the contrary.
In general, the report lacks information and forces us to accept the government’s assertion of the Who (the Russians) and the Why (to affect the election) without providing the Proof. Maybe the government has more information that they are not sharing, but to ask me to simply trust without verifying is asking me to trust too much.
Single Sign-On Explained
So what is SSO and why do I care?
SSO is an acronym for “Single Sign-On”. There are various forms of single sign-on with the most common being Enterprise Single Sign-On (ESSO) and Web Single Sign-On (WSSO).
Each method utilizes different technologies to reduce the number of times a user has to enter their username/password in order to gain access to protected resources.
Note: There are various offshoots from WSSO implementations – most notably utilizing proxies or portal servers to act as a central point of authentication and authorization.
Enterprise Single Sign-On
In ESSO deployments, software typically resides on the user’s desktop; the desktop is most commonly Microsoft. The software detects when a user launches an application that contains the username and password fields. The software “grabs” a previously saved username/password from either a local file or remote storage (i.e. a special entry in Active Directory), enters these values into the username and password fields on behalf of the application, and submits the form on behalf of the user. This process is followed for every new application that is launched that contains a username and password field. It can be used for fat clients (i.e. Microsoft Outlook), thin clients (i.e. Citrix), or Web-based applications (i.e. Web Forms) and in most cases the applications themselves are not even aware that the organization has implemented an ESSO solution. There are definite advantages to implementing an ESSO solution in terms of flexibility. The drawback to ESSO solutions, however, is that software needs to be distributed, installed, and maintained on each desktop where applications are launched. Additionally, because the software resides on the desktop, there is no central location in which to determine if the user is allowed access to the application (authorization or AuthZ). As such, each application must maintain its own set of security policies.
The following diagram provides an overview of the steps performed in ESSO environments.
A user launches an application on their desktop. An agent running in the background detects a login screen from a previously defined template. If this is the first time the user has attempted to access this application, they are prompted to provide their credentials. Once a successful login has been performed, the credentials are stored in a credentials database. This database can be a locally encrypted database or a remote server (such as Active Directory). Subsequent login attempts do not prompt the user for their credentials. Instead, the data is simply retrieved from the credentials database and submitted on behalf of the user.
Container-Based Single Sign-On
Session information (such as authenticated credentials) can be shared between Web applications deployed to the same application server. This is single sign-on in its most basic and limited fashion as it can only be used across applications in the same container.
The following diagram provides a high level overview of the steps performed in container-based single sign-on environments.
A user accesses a Web application through a standard Web browser. They are prompted for their credentials which can be basic (such as username and password) or can utilize other forms of authentication (such as multi-factor, X.509 certificates, or biometric). Once the user has authenticated to the application server, they are able to access other applications installed in the same J2EE container without having to re-authenticate (that is, if the other applications have been configured to permit this).
Traditional Web Single Sign-On
In contrast, WSSO deployments only apply to the Web environment and Web-based applications. They do not work with fat clients or thin clients. Software is not installed on the user’s desktop, but instead resides centrally within the Web container or J2EE container of the Web application being protected. The software is often times called a “policy agent” and its purpose is to manage both authentication and authorization tasks.
The following diagram provides a high level overview of traditional Web Single Sign-On.
A user first attempts to access a Web resource (such as ADP) through a Web browser. They are not authenticated to the domain so they are directed to the central authentication server where they provide their credentials. Once validated, they receive a cookie indicating that they are authenticated to the domain. They are then redirected back to the original Web resource where they present the cookie. The Web resource consults the authentication server to determine if the cookie is valid and that the session is still active. They also determine if this user is allowed access to the Web resource. If so, they are granted access. If the user were to attempt to access another Web resource in the same domain (i.e. Oracle eBusiness Suite), they would present the cookie as proof that they are authenticated to the domain. The Web resource consults the authentication server to determine the validity of the cookie, session, and access rights. This process continues for any server in the domain that is protected by WSSO.
Portal or Proxy-Based Single Sign-On
Portal and proxy-based single sign-on solutions are similar to Standard Web Single Sign-On except that all traffic is directed through the central server.
Portal Based Single Sign-On
Target-based policy agents can be avoided by using Portal Servers such as LifeRay or SharePoint. In such cases the policy agent is installed in the Portal Server. In turn, the Portal Server acts as a proxy for the target applications and may use technologies such as SAML or auto-form submission. Portal Servers may be customized to dynamically provide access to target systems based on various factors. This includes the user’s role or group, originating IP address, time of day, etc. Portal-based single sign-on (PSSO) serves as the foundation for most vendors who are providing cloud-based WSSO products. When implementing PSSO solutions, direct access to target systems is still permitted. This allows users to bypass the Portal but in so doing, they need to remember their application specific credentials. You can disallow direct access by creating container-specific rules that only allow traffic from the Portal to the application.
Single Sign-On Involving Proxy Servers
Proxy servers are similar to PSSO implementations in that they provide a central point of access. They differ, however, in that they do not provide a graphical user interface. Instead, users are directed to the proxy through various methods (i.e. DNS, load balancers, Portal Servers, etc.). Policy agents are installed in the proxy environment (which may be an appliance) and users are granted or denied access to target resources based on whether they have the appropriate credentials and permission for the target resource.
The following diagram provides a high level overview of centralized single sign-on using Portal or Proxy Servers.
Federation
Federation is designed to enable Single Sign-On and Single Logout between trusted partners across a heterogeneous environment (i.e. different domains). Companies that wish to offer services to their customers or employees enter into a federated agreement with trusted partners who in turn provide the services themselves. Federation enables this partnership by defining a set of open protocols that are used between partners to communicate identity information within a Circle of Trust. Protocols include SAML, Liberty ID-FF, and WS-Federation.
Implementation of federated environments requires coordination between each of its members. Companies have roles to play as some entities act as identity providers (IDP – where users authenticate and credentials are verified) and service providers (SP – where the content and/or service originate). Similar to standard Web Single Sign-On, an unauthenticated user attempting to access content on a SP is redirected to an appropriate IDP where their identity is verified. Once the user has successfully authenticated, the IDP creates an XML document called an assertion in which it asserts certain information about the user. The assertion can contain any information that the IDP wishes to share with the SP, but is typically limited to the context of the authentication. Assertions are presented to SPs but are not taken at face value. The manner in which assertions are validated vary between the type of federation being employed and may range from dereferencing artifacts (which are similar to cookies) or by verifying digital signatures associated with an IDP’s signed assertion.
The interaction between the entities involved in a federated environment (user, SP and IDP) is similar to the Web Single Sign-On environment except that authentication is permitted across different domains.
A major difference between federated and WSSO environments involves the type of information generated by the authenticating entity to vouch for the user and how it is determined that that vouch is valid and had not been altered in any way.
The following table provides a feature comparison between Web SSO and Enterprise SSO.
| Features | WSSO / PSSO / Proxy | ESSO |
| Applications Supported: | Web Only | Web Applications and Fat Clients |
| “Agent” Location: | Target System | User Desktop |
| Technologies: | SAML, Form Submission, Cookies | Form Submission |
| Internal Users? | Yes | Yes (through portal) |
| External Users? | Yes | No |
| Central Authentication? | Yes | No |
| Central Authorization? | Yes | No |
| Central Session Logoff? | Yes | No |
| Global Account Deactivation? | Yes (through password change) | No |
 |  |  |  |  |
Easy Identity 