Top Three Continuous Monitoring Challenges in Meeting NIST Requirements

May 10th, 2012

I recently caught up with Rick Doten, VP Cyber Security at DMI.  (For those of you who might not be familiar with Rick, he is a leading IT security expert with prior leadership posts at Gartner, Lockheed Martin and Verizon – more about Rick’s work is at the end of this post…).

While Rick is a great believer in continuous monitoring, he touched upon three types that are simply not yielding desired results.  To help solve this, Rick urges both the U.S. Federal and defense communities to take a ‘back to basics’ risk-based approach, and ask the right questions to get meaningful and actionable insights. Given the topic matter and expert insight, I thought Rick would make an excellent guest blogger, and he kindly agreed to share this post with us.

The National Institute of Standards and Technology (NIST) has recommended regular additions to the Federal Information Security Management Act (FISMA) Act of 2002 to address the ever-growing number of IT security challenges faced by government agencies. However, budget and resource restrictions, as well as confusion regarding timelines and guideline interpretations make an existing challenge all the more difficult to manage. It shouldn’t be this hard.

 

The 1st challenge: politics, and two schools of thought on continuous monitoring

We are turning a corner in our interpretation of continuous monitoring.  Before the fall of 2011 many of my customers had already started to accelerate monitoring efforts from once every three years to  breaking the controls into thirds and test 1/3 of the controls each year. Originally, when  NIST 800-137 was issued, many thought this would satisfy the requirement, figuring yearly would be “continuous.” Then came the “oh-my-God moment” when DHS recently clarified that they really meant “near real time”.  Everyone sees the benefit – if one is compliant with 800-137 in accordance with the OMB, it avoids the certification and accreditation burden of FISMA reporting which is check-box, snapshot-in-time, paper-based, manual and expensive. 

Another school of thought or approach are the agencies that follow the SANS Institute’s Consensus Audit Guidelines (CAG) to fulfill continuous monitoring requirements.  (There are 20 different security controls listed, by the way.) The Department of State (DoS) is considered the poster child where they have been sharing their experience with everyone who would listen over the last few years.  DoS implemented CAG controls 1, 2, 5, 9 and 12 in a near real time way – but – they aren’t considered compliant by 800-137 guidelines.  Overall one can map between the 15 technical controls and 5 more procedural-like controls in the CAG to the 11 Information domains of NIST SP 800-137– with the exception of CAG number 9 related security skills and training, which is absent from 800-37.   Interestingly, most of the large systems integrators, in anticipation, have been developing their solutions around the CAG and not the 800-37 domains.  So, it will be interesting to see how this plays out.

Net, net … this needs to come to a head as it will be nirvana when government programs can harmonize on these approaches and get there with 800-137 and eliminate the burden of FISMA paper based reporting. 

 

The 2nd challenge: technical and organizational

First of all, the technology is the easy part.  In my interactions with government agencies both civilian and defense I see that they all have the technology – you name it, hardware and technologies such as IPS, IDS, forensics, DLP, asset management – the key challenge is of actually leveraging the potential of these tools, integrating them into a process, and coordination among the different organizations responsible for keeping the organization’s infrastructure running and secure.  In an agency, one group runs the desktops, another the network, another monitors security devices, another responds to threats; each use different tools, each is usually a different contact and contractor, and they are not well integrated, or in some cases, in-fighting is encouraged because it’s thought it makes contractors work harder to keep their work.  But for continuous monitoring to really work (i.e. get holistic security awareness) we need to get past the turf wars and work together. But then, who will they listen to? The network team? The asset team? (etc.). Who has overarching responsibility to organize these groups to a single goal?  It comes down to establishing a culture of teamwork, and process that is both scalable and actionable.

 

The 3rd challenge: complexity, data and false sense of security

This continues from the 2nd challenge.  Many agencies are getting a false sense of security because they fulfill NIST 800-53 technical controls and went on a technology buying spree to point to the industry leading technology for each control area.  What’s more is that as the threat environment keeps changing we add more defenses and burden our infrastructure even more.  But in reality, this added complexity in a way has increased actual risk. The challenge is getting all the pieces to work together and having a process to make sense of it. Security and information event management (SIEM) addresses this to a certain extent but just another technology to solve a point problem; one of too much data to analyze.

We are on a hamster wheel. We add more technology to bolster security defenses, more complexity and more data. People are hoarding more and more data to be relevant, but data is only relevant if it is actionable. So now we have a big data problem and folks are trying to apply business intelligence and analytics personnel to mine the data. As humans we like the data chase. The challenge is adding analytics as technology moves us away from the problem we were trying to solve in the first place.  Which encourages us to pull in even more data.  When will it stop? I have customers managing terabytes and petabytes of network log and event data. When we get to exabytes, what new tools will we need to buy to manage the data?  At some point it will not be manageable.

We need to get back to a set of risk questions that give actionable guidance.  What are we trying to protect in the first place? How can we prioritize? Most organizations are slowly realizing that their technology defenses won’t prevent a bank robber from getting in but what they are looking for is a way to prevent them from getting out and keeping them away from critical assets and infrastructure. 

Again, I am a huge supporter of continuous monitoring guidelines and they answer ‘what is happening now’ and how to prioritize responses, and move us away from yearly check box, snapshots of our systems.   But in order to make continuous monitoring work we need to solve the people and process problem: how are we going to implement this and work among the different teams to be successful. Further, we need to tune it to protect that which is identified as the most important assets to the organization.  And understand what is critical to protect about those assets: confidentiality, integrity, availability–the fundamentals.  We need to implement continuous monitoring with an enterprise risk-based approach, and not just as another point solution to meet compliance.

 

-  Seema Sheth-Voss, Director of Solutions Marketing, CORE Security

To comment on this post, please CLICK HERE.

 

About Rick…

Rick Doten has over 23 years of experience in the IT industry, the last 16 of which focus specifically on cyber security, including Ethical Hacking, forensics and incident response projects, and performing risk assessments to improving security and privacy programs for almost all commercial industries, the US federal Government, and international companies.  Rick’s experience comes from his wide industry knowledge and special expertise in risk management, cyber intelligence, insider threat, application security, and trusted computing. 

Before joining DMI, Rick was briefly a Consultant at Gartner, where he helped customers with their Risk Management programs.  Prior to Gartner, Rick was Chief Scientist at the Lockheed Martin Center for Cyber Security Innovation (CCSI); Rick worked with Lockheed business units to define their customers’ cyber security needs and to identify security solutions. While there, he perform due diligence for potential tech company acquisitions and investments, developed a training program for cyber threat intelligence, and a cyber security training program tailored for Lockheed executives.   Previous to that, Rick was Managing Principal for Verizon Business’s East Coast Professional Security Services practice.  There he managed dozens of Ethical Hackers, and Risk Assessment staff.  Rick also managed the Verizon Cyber Incident Response team.  In a previous Verizon role as Trusted Security Advisor, he supported the sales team as a subject matter expert and met with many Fortune 100 executives to discuss security trends.  Earlier in Rick’s security career, he was an “Ethical Hacker” at Global Integrity division of SAIC and ultimately became the team manager. While there, his work included web application, network, security technology assessments, and a cell phone fraud investigation in South America. 

 

Posted in Assessing defenses, Best Practices, Compliance, controls validation, Data breach legislation, FISMA, Government policy, NIST, Regulation, Security Intelligence, Security measurement, Uncategorized, Vulnerability assessment | No Comments » | Posted by: at 4:47 pm

The Big Trick Behind Exploit MS12-034

May 10th, 2012

My name is Nicolas Economou and I am a senior member on the Exploit Writing Team here at CORE Labs - specializing in Windows kernel exploitation -  where we work tirelessly to discover vulnerabilities within countless technologies so we can provide our customers with new tools to test and assess their networks.

In this post, I’m going to share a deeply technical explanation regarding the challenging work involved in exploiting a Windows-based vulnerability I discovered (CVE-2012-0181) and how it was exploited within Windows 2003, Windows Vista and Windows 2008. Although this is a first-time publication of these findings, you might be interested to know that the attack vector was the same used by the infamous Stuxnet worm to exploit a bug (MS10-073 and CVE-2010-2743).

(NOTE: The results of this research are included in a CORE Labs Advisory published earlier this week entitled: “Windows Kernel ReadLayoutFile Heap Overflow: CORE-2011-1123″.)

KeyboardLayout functions

The “LoadKeyboardLayout” function allows a program to load non-default “keyboard layouts”. We’ve addressed this in prior CORE Labs advisories including CVE-2010-2743.

The syntax for this function:

HKL WINAPI LoadKeyboardLayout(__in  LPCTSTR pwszKLID,__in  UINT Flags

Here, the string ‘pwszKLID’ holds the identity of the keyboard to be loaded (e.g., the English layout is ’00000409′) and the parameter ‘Flags’ specifies how the input locale identifier is going to be loaded.

The ‘LoadKeyboardLayout function’, located in ‘USER32.DLL’, is only the highest-level interface to load a new keyboard layout. However, the function is actually a wrapper for the wind32k system call (syscall for short) ‘NtUserLoadKeyboardLayoutEx’. Accessing this syscall is straight-forward, and in Windows 2003 can be done with the following code:

Depending of the OS version, the system call accepts seven or eight  parameters, whereas ‘LoadKeyboardLayout’ accepts only two. Of these additional parameters, there are three that play a role in this vulnerability:

  1. a handle of an opened keyboard layout file
  2. an index into the file
  3. flags

When the syscall is wrapped by ‘LoadKeyboardLayout’, these parameters are set before entering into kernel mode. In particular, the handle to a “keyboard layout file” is set when the ‘pwszKLID’ parameter passed to ‘LoadKeyboardLayout’ is converted to string with the name of a keyboard layout file (generally ‘kbdXX.dll’), and then this file is opened. The index argument is an offset into the keyboard layout DLL passed as a handle.

One can ask what would happen if the ‘NtUserLoadKeyboardLayoutEx’ function (the syscall) is called by us instead of calling it through ‘LoadKeyboardLayout’? We could then pass the handle we want and the index value we want… but does this have any security implications?

NtUserLoadKeyboardLayoutEx – parameters

In general, the keyboard layout files are DLLs that export only one function (‘KbdLayerDescriptor’) and which are located in the “windows\system32″ directory. On the other hand, index is a pointer relative to the DLL’s base and it is used to refresh a pointer table (‘LayerDescriptor’) located in the kernel’s .DATA section.

Windows XP and the other OSs

After the release of XP, Microsoft introduced some changes in how the syscall operates.

-  The file location parameter (handle) isn’t checked (e.g., this means we can pass a file of our design, and in particular, a rootkit).

-  The index into the file isn’t checked (e.g., this means we can pass an index out of the range used by the file mapped in kernel memory where it is easier to write attacker-generated code).

The rest of the OSes:

-  The file location parameter (handle) is checked (i.e., it must be located in “windows\system32″).

-  The index into the file is checked (i.e., it must be in the bound of the kernel memory mapped at the .DATA section).

Hence, exploitation for XP becomes easier. Next, we’ll  explain how to treat the latter cases.  Namely: how can we take advantage of this syscall in the cases of non-XP operating systems with the above restrictions?

The Bug

The bug is located in the ‘ReadLayoutFile’ function, which is part of the ‘win32k.sys’ kernel module. This function has a custom-built PE loader. When the index parameter is used by the PE loader, the bounds are checked as follows:

-  ‘base_addr’ is the kernel memory address where the .DATA section was copied.

-  index is the relative offset, starting from the ‘base_addr’, where the keyboard layout descriptor is located.

-  ‘limit_addr’ is the kernel memory address where the .DATA section ends.

-  ‘LayerDescriptor’ is a table consumed by the PE loader with 12 or 13 pointers to the different functions in the DLL. These pointers must be refreshed using ‘base_addr’.

Now, what happens if ‘base_addr + index’ is set with 1, 2 or 3 less than the ‘limit_addr’? (Using a bigger value may cause other checks to fail, so it is not advised.) For example:

If this pointer is in the bounds of the keyboard layout, the “PE loader” continues with the same process, until the table is refreshed (12 or 13 pointers). If this pointer is out of the bounds, the function ‘ReadLayoutFile’ deallocates the keyboard layout and returns ERROR.

Since we control index, the range checked is insufficient, so the bug could be used to overwrite one, two or three bytes out of the memory allocated by windows. This kind of bug is called  an off-by-one bug, or more generically: memory corruption.

A little bit of theory first

This picture depicts a snapshot of the paged memory pool in the Windows kernel heap:

Figure 1

Each of the pages in the paged pool represents a memory block. Each block holds 4096 bytes (4 kB). When writing into the paged memory tool (e.g., “mallocs” executed by the Windows kernel itself), one necessarily takes the whole block into memory.

The paged (memory) pool is a memory resource that the OS uses to store data: “The kernel’s pool manager operates similarly to the C-runtime and Windows heap managers that execute within user-mode processes.  Because the minimum virtual memory allocation size is a multiple of the system page size (4KB on x86 and x64), these subsidiary memory managers carve up larger allocations into smaller ones so that memory isn’t wasted.” When low in (virtual) memory, the system can thus write these pages to disk (physical) and free some space.

Let’s say we did use the ‘NtUserLoadKeyboardLayoutEx’ syscall; so that the .DATA section (of the keyboard layout) was allocated as one of the chunks depicted in Figure 1 (here the keyboard layout was mapped in a kernel memory address represented by a painted square):

Figure 2

Each memory chunk is depicted as a rectangle. The first eight bytes of each chunk contain a header that we represent by line separators:

Figure 3

In turn, the chunk header has the following structure:

Figure 4

The first half of the chunk header consists in two pointers:

  • The field previous, holds an “unsigned short” variable (16 bits). To obtain the chunk header previous to itself, one needs to multiply this number times 8.
  • The field next, holds an “unsigned short” variable (16 bits). To obtain the chunk header after itself, one needs to multiply this number times 8.

We note that actually only 9 bits are used to represent the chunk size, the remaining 7 bits are used as an index which determines the block which they belong to.

Exploitation

After describing the setting we are ready to get into the most complex and interesting part: the exploitation. This will take a few steps and I’ll describe solving the several challenges  as they appeared to me.

Step 1: HEAP Corruption – Part 1

As you may recall, using ‘NtUserLoadKeyboardLayoutEx’ we may overwrite 1, 2 or 3 bytes at the end of the chunk. Recall that at the end of each chunk, there follows a new chunk, that this chunk starts with a header, and that the first two bytes in this header are used to locate the previous chunk.

For example, if we managed to overwrite the header of the chunk after the keyboard layout file, then the previous field of this chunk’s header should point to the keyboard layout allocation:

Figure 5

Here, the red arrow represents what the bug allows us to overwrite.

Step 2: HEAP Corruption – Part 2

Let’s analyze what is the impact of overwriting the first byte of the next chunk header. Consider, for example, that we are using a keyboard layout file of 0×178 bytes in size (so the associated chunk containing the file plus the header is 0×180 bytes in size)

Figure 6

Since 0×180 (384 decimal) divide by 8 is 0×30, there follows that the previous field should hold the value 0×30 (or 48 decimal). Suppose that we overwrote the first byte with another value, say 0×10, then, the previous field header would point to some place within the keyboard layout chunk:

Figure 7

Obviously this is an unexpected behavior. According to this assumption, a new chunk would start at -0×80 with its own header:

Figure 8

Step 3: “Exploiting” the HEAP

If we overwrite the previous field on the next chunk header, two very different things can happen depending on what chunk is deallocated next (memory will be freed sometime after the chunk is used):

  1. If the keyboard layout chunk is deallocated (calling ‘ExFreePoolWithTag’ function), the Windows kernel produces a blue screen of death (BSoD) because the check that compares the size of the keyboard layout chunk, computed from the next field header in the keyboard layout chunk, with the value of the previous field header in the next chunk will fail and thus produce the blue screen.
  2. If the next chunk (one of the alloc chunks in Figure 8 ) is deallocated, a very interesting effect takes place: The ‘ExFreePoolWithTag’ function reads the previous field (that we have already overwritten) and obtains the chunk header of our choice. This effect is known as heap coalesce.

Figure 9

When the chunk is deallocated, the memory looks like this:

So, if we controlled the memory area content where the fake header is read, we could control the value of these 2 pointers (A and B).

The Big Problem

We can break the exploitation problem in the following three sub-problems.

First: When deallocation happens, we need to avoid the keyboard layout chunk so that the next chunk is deallocated. The former situation would lead to a BSoD and end our hope for getting the exploit to work. So we need to somehow provoke for the next chunk to be deallocated.

Second: After doing the off-by-one, we do not know the value of the first byte in the NEXT chunk header. We need to estimate this value so that we know where it will point.

Third: We don’t control the (keyboard layout) DLL content, so where will we write our payload?

The implication of this is that we can’t create a fake chunk header pointing into the DLL area, because this file is not writable. Hence, exploitation will have to go through some other means. On the other hand, we might be able to find, somewhere in the .DATA area, data consistent with a chunk header followed by two pointers and then have the byte used to overwrite the next chunk header to point to this (fake) chunk header.

Solving problems 2 and 3

Assume for now that we have solved problem 1; we’ll figure it out next. Then, problem 2 has a neat and interesting solution, which goes as follows. We know that the highest byte of the refreshed pointer is the first byte that we used to overwrite the next chunk header. We also know that the address is pointing somewhere in the kernel, and therefore this value must be bigger than 0×80000000. Hence, we can deduce that the highest byte will hold a value between 0×80 and 0xff.

For the heap coalesce, it is sufficient to control the memory area before the keyboard layout file and build the fake chunk header and the two pointers within that memory area. Assuming we can control allocations before the keyboard layout, we face the following situation:

Figure 10

To solve problem 3 note that we needn’t overwrite the DLL content, because if it is sufficient to find a DLL with a .DATA section located less than 0×400 bytes away. This is because the minimum byte value used to overwrite the next chunk is 0×80 (128 decimal), and 0×80 times 8 is 0×400 (1024 decimal). So that when the ‘ExFreePoolWithTag’ function finds the fake chunk header, it would be out of the keyboard layout chunk.

The Big Trick

Problem 1 is much more difficult because there isn’t a way to avoid the deallotation of the KEYBOARD LAYOUT CHUNK. The solution is achieved using a neat surgically-crafted heap spray technique. Say that the KEYBOARD LAYOUT is allocated exactly at the end of the memory page like this:

Figure 11

If this happens, the overwritten next chunk header is allocated in the next memory page (next 4 kB).

Figure 12

In this case, the keyboard layout chunk will be inevitably deallocated, but Windows will not do the sanity check since it is not needed.

In this way we can avoid the BSoD as ‘ExFreePoolWithTag’ function deallocates the (fake/corrupted) next chunk. Since the next chunk header starts exactly at the beginning of the next memory page, the previous field value should be 0.

Even though the chunk is located at the start of the page, the ‘ExFreePoolWithTag’ function will use the previous field to find a previous chunk header. So, this innocent-looking check allows us to use a fake chunk header and point to the previous memory page, the page where the keyboard layout was allocated.

This is illustrated by Figure 13:

Figure 13

As a result, we can use POINTER 1 and POINTER 2 to overwrite a memory address with a specific value. Once a specific memory address was written, there are many ways to take control of the Windows kernel, for example, by overwriting the Service Description Table (SDT) table. That may be known by many, and for the rest, it is a story for some other time.

Final Notes

I used this same technique to write the local exploit for MS11-077 (CVE-2011-2003) and the local exploit for the bug used by MS11-087 (the infamous Duqu bug, with CVE-2011-3402).

It is worth noting that this technique will not work in Windows 7 because some additional checks will make the heap coalesce technique fail.

 

- Nicolas Economou, Senior Exploit Writer, CORE Labs

To comment on this post, please CLICK HERE.

 

 

Posted in Assessing defenses, Brute force attacks, CoreLabs, Ethical hacking, Exploits, Penetration testing, Source code analysis, Uncategorized, Vulnerability advisories | No Comments » | Posted by: at 3:22 pm

Down to the CORE: April 2012 IMPACT Report

May 10th, 2012

It was an exciting month getting ready for the release of CORE Impact Pro v12.3 – including a lot of phone calls with customers to review how their feature requests were being implemented into Impact –  and lots of fun planning with internal builds of the new version.

We were also busy working with some vendors having responsibly disclosed vulnerabilities discovered by CORE Security Consulting Services and CORE Labs within SAP (see associated blog) and Microsoft products. We worked closely with these vendors to help them release mitigation patches and guidelines to their customers.

But with all of that going on we didn’t stop producing exploits for Impact. In April we released ten exploits or updates to exploits for client-side and remote. The most interesting exploit was Microsoft Windows MSCOMCTL Exploit (MS12-027), released April 17th. The vulnerability was announced and patched by Microsoft on April 10th.

 

Updates for April 2012 (excluding maintenance updates):

Remote Code Execution

  • LotusCMS router PHP Command Injection Exploit
  • Novell ZENworks Configuration Management Preboot Service Opcode 0x4c Buffer Overflow Exploit
  • Miniserv Perl Format String Exploit (Update)
  • Netmechanica NetDecision HTTP Server Buffer Overflow Exploit
  • SolarWinds Storage Manager Server SQL Injection Authentication Bypass Exploit

Client Side

  • NetOp Remote Control Client Buffer Overflow Exploit
  • Microsoft Office Excel RTD Data Record Processing Stack Overwrite Exploit MS11-021 (Update)
  • Adobe Reader Font SING Table Buffer Overflow Exploit (Update)
  • Atlassian FishEye Struts 2 ExceptionDelegator Remote Code Execution Exploit
  • Microsoft Windows MSCOMCTL Exploit (MS12-027)

 

- Alex Horan, Senior Product Manager

To comment on this post, please CLICK HERE.

Posted in Client side testing, CORE IMPACT Pro, CoreLabs, Disclosure, Exploits, Microsoft, Penetration testing, Uncategorized, Vulnerability assessment, Vulnerability research | No Comments » | Posted by: at 12:16 pm

CORE Labs Discovery of Six Vulnerabilities within SAP Netweaver

May 9th, 2012

As a security researcher and member of the CORE Security Consulting Services team, and close partner with CORE Labs here in Buenos Aires, I need to perform security analysis of complex enterprise IT environments with software installations from any number of vendors. These environments’ technologies are often both poorly documented and maintained. Our job here at CORE is to make sure  our customers and other security professionals have a better understanding about hidden risks within their IT systems through vulnerability assessments and testing.

Evaluating the security levels of these systems is challenging, as was the case with SAP NetWeaver Applications Servers, a service that communicates with SAP’s GUI applications using the Diag (Dynamic Information and Action Gateway) network protocol. This SAP service’s complexity stems from the fact that the protocol is proprietary, documentation is not available to those who are not customers and there are no tools available to comprehensively evaluate an SAP installation.

Considering this, I focused on SAP’s protocol. I tested manually, performed remote fuzzing sessions, played around with its network packets and crashed the services in several ways. All of this enabled me to create an exploit toolset that led me to discover six vulnerabilities related to the SAP Diag network protocol  that can:

-          Establish a connection to the SAP Application Server’s Dispatcher service

-          Query the application server

-          Perform man-in-the-middle (MiTM) attacks

-          Emulate a valid user by logging into SAP providing valid credentials

-          Perform denial-of-service attacks

 

As a result of this work, I partnered with my fellow security researchers at CORE Labs where we shared details through our process of responsible disclosure to security professionals at SAP and today we issued a security advisory with technical details and a patch.  This was timed with SAP’s issuance of an advisory covering these vulnerabilities. (to access the SAP advisory, visit their Community Network website and register)

 

Technical Details Regarding the Six Vulnerabilities within SAP Netweaver Application Servers

DiagTraceHex Denial of Service: Developer Traces are used within a SAP installation to diagnose problems. These can be configured at different levels of detail, from 0 (no traces) to 3 (full trace plus additional information). When Developer Traces are configured at levels 2 or 3 for the “Dialog processor” component, the SAP Netweaver Application Server’s work processes makes a full hex dump of all Diag requests and responses. I found that a vulnerability is triggered by sending a Diag packet containing an item, e.g., the Diag XML Blob, with a wrong length field value. The application server will try to dump the packet’s content and end up dumping the server’s memory; this raises an exception, crashing the dialog work process.

DiagTraceAtoms and DiagTraceStreamI Denial of Service: These two vulnerabilities also require that the work process handling the request is configured to trace “Dialog processor” events at levels 2 or 3. In both cases, an unauthenticated user can cause a denial-of-service by sending specially-crafted packets of type DYNT ATOM and RCUI CONNECT_DATA.

Diaginput and DiagiEventSource Denial of Service: These are the other two denial-of-service vulnerabilities Diaginput and DiagiEventSource. An unauthenticated user can send malformed messages of type VARINFO MAINAREA_PIXELSIZE or UI_EVENT_SOURCE and the dialog work process will end up crashing and leaving the Diag service unavailable, thus provoking the denial-of-service.

DiagTraceR3Info Remote Code Execution:  The sixth crash we performed with the DiagTraceR3Info looked more promising as this vulnerability could possibly allow an attacker to take over the server. By investigating the crash in more detail, I found that the problem was a stack-based overflow that was produced when the server handled messages containing ST_R3INFO CODEPAGE items. Exploitation of this bug was very straightforward using some well-known Unicode exploitation techniques. This bug also need work process’ developer traces to be configured at levels 2 or 3 for the “Dialog processor” component.

 

What is the Business Risk?

It is worth noting that all of these vulnerabilities were accessable with no authentication required. The dispatcher service is commonly accessible only from internal networks, thus enabling an internal attacker to exploit the vulnerabilities. What this means is that any attacker with connectivity to a vulnerable SAP Dispatcher service could potentially compromise the entire SAP installation. The potential impact includes financial fraud, siphoning of critical business information and sabotage of every SAP Netweaver Dialog instance – rendering the service unavailable to legitimate users.

Even though some of the bugs require the Developer Traces to be set to levels higher than the standard (which isn’t really common in production environments) it’s worth mentioning that a regular user with permissions for executing Screen Traces (i.e., transaction ST20), work process management (i.e., transactions SM04/SM50) or profile management (i.e., transaction RZ10/RZ20) authorizations could enable traces on server’s work processes and then launch the exploit for these vulnerabilities.

Access to turn on developer traces on production environments are mostly given only to BASIS administrators, but sometimes granted to regular users for troubleshooting or to developers in non-production environments. It’s also worth mentioning that SAP’s default users SAP* and DDIC has this capability. Therefore, it is suggested that  SAP administrators follow standard guidance about default SAP users and passwords.

 

How you can Mitigate Risk

SAP has released fixes for these vulnerabilities. You can find the details in SAP Note 1687910 (requires authentication; to access the SAP advisory, visit their Community Network website and register). Apart from the remediation we outline in our advisory, we suggest you employ these countermeasures or workarounds that will help mitigate risk:

- Restrict network access to Dispatcher service’s ports. Access to TCP ports 32NN (NN is SAP’s instance number) should be allowed only to required users.

- Disable Developer Traces for the Dialog Processing component. This can be performed using transaction SM50 and/or through “rdisp/TRACE*” profile parameters.

- Restrict access to transactions that can be used to enable Developer Traces. Some examples of these transactions are ST20 (screen traces) and SM04/SM50 (work processes management) through authorization object S_ADMI_FCD, and transactions RZ10/RZ20 (profile maintenance) using the authorization object S_RZL_ADM.

- Encourage the use of SAP GUI for HTML client instead of the SAP GUI application. Ensure that you also enable HTTPS/SSL.

 

 

- Martin Gallo, Security Researcher, CORE Security Consulting Services

To comment on this post, please CLICK HERE.

 

Posted in Assessing defenses, Attacks, Conducting Tests, controls validation, CoreLabs, Disclosure, Exploits, Research, Risk management, Security Intelligence, Uncategorized, Vulnerability assessment, Vulnerability research | No Comments » | Posted by: at 11:01 am

Test the Weakest Link and Phish Your Users

May 7th, 2012

I’ve been advocating for the use of email born phishing tests against the user population within companies for over six years now, and I have to admit the fight is a complex one. Most of the network and security analysts I talk to about this agree with me and want to leverage this type of testing. But internally at their organizations, HR or some other policy group is worried about the legal or emotional Impact of ‘targeting’ users in an organization and reports floating around about the fact that a user within a certain group clicked a link which eventually lead to critical system or account compromise.

Erick Doyle recently wrote an article in TechWeek Europe discussing whether pen testing will ever include social engineering as standard practice. He explicitly asks the question “Is social pen testing ethical?” While he doesn’t seem to answer that question, my answer is “yes”. Social pen testing by itself has no ethics to it and as a practice it is needed, where the question of ethics comes in is how you treat the results. If you send out a company-wide email publically naming and shaming those users who clicked the link you probably will increase security awareness, but not create a feelings in your user population that they are a branch of the security team.

 

For those organizations that are unsure about performing social pen testing, CORE Impact Pro v12.3 (announced today) provides two capabilities of measurement to help them determine the risk their users pose:

1)      “How well do our users’ machines defend themselves?”

New user-less client side testing capabilities are designed to test a sample Windows desktop machine and answer the question ‘What, if any, client side attacks would compromise this image?’ Most organizations have standard desktop images, which are refreshed on a regular basis. This testing capability allows you to run every client side exploit against the image and will return a list of those attacks that succeed despite any endpoint security systems deployed on that image.

2)       “How likely is it that my users would fall for a client side attack?”

I know, phishing has been available for many releases: Impact Pro’s phishing capabilities allow you to send an email to many employees with a passive link (no attacks sent). IMPACT Pro will also record the number of people who both clicked the link (and how, if you so wish) and potentially exposed their machines to attack as a result.

The magic really happens when you think about what the results from addressing these two questions allow you to know: you will know both specific & literal numbers for how many attacks could compromise a user’s machine, despite the protections on those machines. You will also know how many of your users would click a link on an email they were not expecting to receive, and risk exposing their machine to attack. If both numbers are high you know there is some serious work to be done, but you also have the evidence to show the powers that be to get the time and resources allocated to doing this work. If only one number is high you know where to best focus your resources to bring the risk your users pose to a level the organization is comfortable with.

Of course, user-less client side is not the only thing we added in v12.3 – as with every release of the product we expanded on the depth of the features we already have.

 

Network Testing Reports

No one would ever say that reporting is the most exciting part of a test, but few would disagree that it is very important. With that in mind we extended the capabilities of existing reports and added new reports as requested by our customers. Highlights include:

Wellness Report – as people test their networks regularly with IMPACT Pro the number of exploitable vulnerabilities naturally goes down..To help show that the level of effort for testing the system has not decreased this wellness report will detail the effort that went into testing each machine to determine its security posture.

Mitigation Report – ahhh sweet paper work, the point of finding vulnerabilities is to fix them, introduce compensating controls to mitigate them, or make a business decision to accept the risk they represent. The mitigation report provides a list of all issues found and creates the paper trail of remediation for your manager to sign off on. It can then be filed and produced for third party auditors.

Full Executive Report – while there is still an executive report for each vector tested, this one shows a combined summary of all the testing done in the workspace

Host Report – this one has undergone a makeover and now includes exposure information, which Mitre defines as access to information or capabilities that could be used as a stepping stone into a system or network. With v12.3, IMPACT Pro can check for exposures and the host report will detail them. The host report can also include a list of hosts by services or listening ports. It will also include the last screenshot taken on the machine.

 

Web Application Testing

By adding client certification to the existing authentication mechanisms supported by Impact Pro we are able to test a large portion of web applications automatically. These certificates can be imported from a file or accessed via the local machine store. We have also improved the sorting and categorizing of our predefined exploit search folders, to better related them to the OWASP Top Ten.

Those of you who like to use our Attack Graph to show a visual representation of how you have performed a multi-vector attack, and compromise of the environment, will be pleased to know that you can condense the web application portion of the attack graph to a single node representing the target web application. This makes for a clean and easy-to-read graph.

 

WiFi Testing

We listen to our customers and as a result we removed the restriction of only supporting a single AirpCap card. Now you can utilize multiple AirPcap cards and sniff on one channel while broadcasting packs on another. The introduction of a WiFi Man in The Middle (MiTM) attack wizard makes it quick and easy to create a fake access point (AP) and configure automatic MiTM attacks to take place as soon as clients connect to the AP and start passing traffic through it. This includes replacing images in HTTP traffic, injecting client side attacks into their traffic or manipulating forms to harvest the data being submitted. You can also configure DNS, SMB, POP3 and HTTP servers to act as endpoints.

 

I’m excited about the new capabilities we have added in this release as it shows our customers that we are adding more depth, and tangible results, to the features they already know and use. And to those of you who install and use v12.3, I would be thrilled to hear about your experiences with the new functionality!

 

 

- Alex Horan, Senior Product Manager

To comment on this post, please CLICK HERE.

 

 

Posted in Automated penetration testing, Client side testing, Conducting Tests, CORE IMPACT Pro, Ethical hacking, Penetration testing, Phishing, Uncategorized, Vulnerability assessment, Web App Penetration Testing, WiFi Penetration Testing | No Comments » | Posted by: at 3:33 pm

« Older Entries