Archive for the ‘computer security’ Category

10 Questions to Ask Yourself Before Snapping and Posting that Photo

July 18th, 2017

Let’s face it. Photos do the talking for most of us today. Everyone is snapping, chatting, posting, and engrossed in choosing the perfect photo filter. But what if, while steeped in capturing our lives in images, we were being rude, insensitive, or even breaking the law?

With so many posts, there’s bound to be some unhappy people. For instance, Miami Heat owner Ranaan Katz sued Google over a photo posted of him, and Beyonce’s publicist demanded Getty Images remove those famously unflattering Superbowl performance photos. In fact, in some states, posting “distressing” or embarrassing images of others without a “legitimate purpose,” is punishable by law.

Most people care about putting their best photos forward online. A 2014 study released by The Renfrew Center Foundation reveals that most people edit their pictures before putting them on social media in an attempt to present their  ‘best selves’ over their ‘real selves.’ So it stands to reason that perhaps in all our posting, we’re not always landing on the right side of polite.

While a lawsuit likely isn’t in your future, there are some written and unwritten rules to posting that will help keep you and your family out of hot water in digital social circles. Some of these rules here are the law, others, well just plain polite.

10 Questions to Ask Before Snapping that Photo

  1. Does this facility allow A) personal photography B) use of a selfie stick?  Be sure to look for a sign or posting regarding selfie sticks, photo opportunities, image copyrights, and safety tips when taking photos in high-traffic areas such as national parks, museums, sporting events, academic events.
  2. Am I creating a danger to myself or someone else by taking a photo here? Questionable locations might include zoos, theme parks, boats, crowded public areas such as malls, subways, streets, airports, or while driving a car. (Unfortunately, people die each year unnecessarily while taking risky photos.)
  3. Am I blocking someone’s view or impeding traffic flow by stopping to take this picture? We’ve all been there be it a theme park, concert, public event, ceremony, or celebration. We wait. And wait. Until they get the shot. And, sometimes it not only inconveniences others, but it can also cause an accident if getting the perfect photo trumps safety.
  4. Do I run the risk of offending someone’s religious views by taking a photo here? Often, cathedrals, religious landmarks, sacred burial spaces, and religious communities such as the Amish, forbid or frown on photos.
  5. Even though I can’t see a threat, is there a potential danger in taking a photo here? Think about snapping a photo in potential danger zones such as zoos, national parks, severe weather conditions, ships, subway, or moving bus.
  6. Did I get the permission to post from the people in my photo? How many times have you taken for granted that your friend or family member wants his or her photo posted? It never hurts — and may even save a relationship — to ask before posting.
  7. Is it in poor taste to take a photo here? Some states forbid taking and posting distressing photos or photos in bad taste such as an accident scene, a funeral, or individuals caught in compromising situations.
  8. Is this photo embarrassing to another person in any way? At one time posting unflattering photos of shoppers in Wal-Mart helped fuel the internet’s hunger for memes. At the end of the day, it’s all cyberbullying. Think before posting photos of parties, people in public restrooms, beaches, and in ways that make them look ridiculous. Unfortunately, recent reports of kids sabotaging and rating our their peers with inappropriate photos are becoming a thing.
  9. Is this photo of me too intimate? Just because you can doesn’t mean you should. Consider your clothing, facial expression, inference, and caption before posting a provocative photo.
  10. Am I overdoing it on the photos? How many are too many selfies to post in a week? If you are uncertain about your posting habits, ask a good friend to be honest with you.

ToniTwitterHS

 

 

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her on Twitter @IntelSec_Family. (Disclosures).

The post 10 Questions to Ask Yourself Before Snapping and Posting that Photo appeared first on McAfee Blogs.

Posted in computer security, cyberbullying, Family Safety, protecting kids online, social networking | Comments (0)

Analyzing a Patch of a Virtual Machine Escape on VMware

July 17th, 2017

A virtual machine is a completely isolated guest operating system installation within a normal host operating system. Virtual machine escape is the process of breaking out of a virtual machine and interacting with the host operating system, which can lead to infections and malware execution. VMware escapes demonstrated at the most recent PwnFest, organized by Power of Community in Seoul, South Korea, grabbed our attention as VMware was publicly pwned for the first time. The McAfee IPS Vulnerability Research Team decided to look deeper into the issue to better understand the vulnerability.

VMware responded well by very quickly pushing a fix for these exploits and releasing a security advisory. As we often do for security issues in closed-source software, we looked into the advisory. It includes this:

“The drag-and-drop (DnD) function in VMware Workstation and Fusion has an out-of-bounds memory access vulnerability. This may allow a guest to execute code on the operating system that runs Workstation or Fusion. On Workstation Pro and Fusion, the issue cannot be exploited if both the drag-and-drop function and the copy-and-paste (C&P) function are disabled.”

The vulnerability resides in the drag-and-drop and copy-and-paste functions. Both use the VMware remote procedure call (RPC) mechanism. VMware’s RPC has been a very popular attack surface for guest-to-host escapes.

Before we go deeper into the patch for VMSA-2016-0019 (CVE-2016-7461) we must have a basic idea of how VMware Workstation handles guest-to-host or host-to-guest copy-and-paste operations.

The following diagram shows the VMware drag-and-drop copy-and-paste (DnDCP) model by class hierarchy. (Source: Open VM Tools source code.)

 

To seamlessly perform a guest-to-host or host-to-guest copy-and-paste operation, VMware tools need to be installed on the guest operating system. VMware tools handle the guest-to-host or host-to-guest communication. In our investigation, we used Windows guest and Windows host. In Windows guest, the main tools process is vmtoolsd.exe.

One way guest and host communicate with each other is by RPC. VMware has an RPC interface called Backdoor.

Guest RPC mechanism

Let’s take a close look at how a guest and host OS communicate with each other over RPC. To understand the guest RPC mechanism, we referred to the open-source component of VMware tools, open-vm-tools, which primarily use the following functions for guest RPC calls:

Theoretically, anything using RpcChannel_Send() or RpcOut_send() can be sent with the command-line tool rpctools.exe, which ships with VMWare Workstation.

RpcOut_Send() invokes Message_Send(), which calls the function Backdoor().

The Backdoor function is responsible for sending the message through the VMware special I/O port.

 

Usually we see the following set of instructions while invoking Backdoor from guest to host.

 

In the VMware tools installation, the function resides in vmtools.dll. Here we see Backdoor() calling the function sub_10050190.

Digging into this, we find this function executes the privilege instruction “in.”

Let’s return to the vulnerability. We are mainly interested in DnDCP RPC message(s) because the vulnerability lies in DnDCP RPC, per the advisory. The VM Tools source code reveals the DnDCP RPC message structure for us.

 

From the source code, we see the first member of the structure is the RPC command. When we break into vmtools!RpcOut_send(x,x,x,) of the vmtoolsd.exe process in guest, we see the same thing.

Bool RpcOut_send(RpcOut *out, char const *request, size_t reqLen,char const **reply, size_t *repLen);

In RpcOut_Send(), the second argument is the request-RPC packet. If we dump the packet from the guest OS vm-tools process, in the data packet we first see the RPC command (as in the DnDCPMsgHrV4 structure) and we also see a copy-and-paste request packet for our test file debasish.txt on the guest desktop.

RPC packet handling in guest

Let’s look at how the host operating system handles the RPC request. On the host, each running virtual machine has a separate process, vmware-vmx.exe.

When a guest RPC is issued by the guest, code inside vmware-vmx.exe searches the guest RPC handler table for a handler corresponding the request.

If we search the raw string in vmware-vmx.exe disassembled in IDA Pro, we find almost all the handlers.

 

From this, we know vmware-vmx.exe is the main component in the host, responsible for handling the vulnerable component, the copy-and-paste RPC. We next performed a binary “diffing” of the patched and unpatched binaries. The patch was shipped through VMware Workstation Version 12.5.2, so we ran the binary diffing between the vmware-vmx.exe of Version 12.5.2 and 12.5.1.

We can see a few functions in vmware-vmx.exe that were modified by the patch.

One interesting modified function is vmware_vmx!sub_140621520.

 

This function grabbed our attention because it has a call to memcpy(), which is a perfect situation for triggering an out-of-bounds condition.

After running some debugging and reverse engineering, we confirmed the function vmware_vmx!sub_140621520 handles RPC packets, and we were able to control one argument of the modified function from the guest operating system. The argument is a pointer to a structure, giving us control of the content of the passed structure.

The following screenshot demonstrates the statement. The window at left is the guest virtual machine and the window at right is windbg attached with the vmware_vmx.exe process.

In this screen, we have modified an RPC packet in the main vm-tools process vmtoolsd.exe (RpcOut_send) at runtime, and the modified packet is received by the function vmware_vmx!sub_140621520 in the vmware-vmx.exe process.

Now, let’s look at the decompiled source code of our patched function to identify which fixes were added to kill the bug.

To send a valid RPC packet we referred to the source code of VM Tools, which defines the RPC packet structure. The following screen shows the definition of an RPC packet header; we can see the size is exactly 0x38.

 

The fields binarySize and payloadSize are actually the variables v6 and v5 in our decompiled code. We can control the values of these two fields to cause an out-of-bounds access. To send an arbitrary RPC packet from guest to host, we developed a standalone tool that can send an RPC from guest to host via the function Backdoor. After thorough reverse engineering, we found that using the vulnerable function we can achieve an out-of-bounds read/write in the vmware-vmx.exe process.

Out-of-bounds read

As we know, the payloadSize is in our control. If we send a packet with a large payloadSize without a payload buffer, when the program reaches memcpy() it will read some memory out of bounds.

The preceding screen shows the code will copy 0x500-length contents from 0x36E4D96 to 0x378A0D0. However, our data ends only with 0x4C in 0x36E4DB7. The data after 0x36E4DB7 will cause an out-of-bounds read.

Out-of-bounds write

If the RPC message contains multiple packets, we will get into the function sub_1406215F0.

 

To create an out-of-bounds write in the preceding function we have to send more than one RPC packet in one session; then vmware-vmx will create a new buffer to combine the payloads of all packets. After some thorough reverse engineering trials, we conclude that RPC packets with the following characteristics can be sent from guest to host to achieve an out-of-bounds write.

First, we send a drag-and-drop RPC packet with these characteristics:

  • packet->binarySize is 0x10000.
  • packet->payloadOffset is 0x0.
  • packet->payloadSize is 0x500.

With these options, all preceding check conditions are satisfied.

  • packetSize is certainly larger than DND_CP_MSG_HEADERSIZE_V4.
  • packet->payloadSize is less than 0xFF64.
  • packet->binarySize is less than 0x400000.
  • packet->payloadOffset + packet->payloadSize < packet->binarySize.

The procedure will create a new buffer and copy all our packet payloads to it.

Then, we send another packet with the same session ID, in which

  • packet->binarySize is 0x10100.
  • packet->payloadOffset is 0x500.
  • packet->payloadSize is 0xFC00.

These options also satisfy the sanity checks.

  • packetSize is certainly larger than DND_CP_MSG_HEADERSIZE_V4.
  • packet->payloadSize is less than 0xFF64.
  • packet->binarySize is less than 0x400000.
  • packet->payloadOffset + packet->payloadSize < packet->binarySize.

Because this packet has the same session ID as the first packet, and the new buffer is already allocated, the code continues to copy payloads to the current buffer—because 0x500 + 0xFC00 = 0x10100, not 0x10000. This leads to an out-of-bounds write to memory of 0x100 bytes.

The preceding screenshot shows the memory state of the vmware-vmx.exe process before the out-of-bounds write happens.

The preceding screenshot shows the memory state of the vmware-vmx.exe process after the out-of-bounds write, where 0x40E3070 is the memory after the new buffer ends (0x10000). After we sent the second packet, we successfully overwrote 0x100 bytes of memory at 0x40E3070.

 

This post gives a brief overview of the RPC mechanism in VMware Workstation and how the RPC attack surface can be exploited to escape from the guest to the host operating system. In a series of posts, we will discuss each step of this exploitation in detail and demonstrate how these exploits can be chained together to achieve a complete VMware guest-to-host escape.

RPC is not the only vector to attack VMware. In future posts, we will discuss other virtual machine attack surfaces, techniques, and exploits.

 

The authors would like to thank Bing Sun for his valuable assistance throughout this analysis.

The post Analyzing a Patch of a Virtual Machine Escape on VMware appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, virtual machine, Vulnerability | Comments (0)

Why You Need to Watch Out When Using Public Wi-Fi

May 12th, 2017

If you’re like most people, you like to stay connected whether you are traveling or just on the go. That’s why it can be tempting to connect to free, public Wi-Fi networks, but you should know that these networks could open you up to some serious risks.

Public Wi-Fi networks often lack a security measure called encryption, which scrambles the information sent from your computer or device to the router so strangers cannot read it. Without this security measure in place, the information you send over these networks can potentially be intercepted by cybercrooks.

This information could include your banking and social media passwords, as well as your identity information. A nosy cybercriminal could also potentially snoop on you by watching which websites you visit, and what you type into web forms.

In fact, it is so easy to steal your information over unsecured networks cybercrooks sometimes setup malicious Wi-Fi hotspots in high-traffic areas, like airports, with the intention of grabbing users’ information.

That’s why if you have to connect when you’re away, you should only use secure and well-advertised Wi-Fi networks. You can usually tell if they use encryption because they require a password to join.

If you have to do something sensitive online, like check your bank account balance or make a purchase, try to stick to webpages that start with “HTTPS” rather than just “HTTP”. The “S” stands for secure, and indicates that the site uses encryption to protect your data. You can also look for a green lock icon at the beginning of the browser address, which indicates that the website connection is secure.

If you are on your mobile phone, you can skip the Wi-Fi network altogether and connect using the cellular network. It is somewhat more secure, since it’s harder for cybercrooks to sniff out your individual data from others on the network.

If you travel a lot, consider investing in a Virtual Private Network (VPN), which is a piece of software that allows you to create a secure connection to another network over the Internet. Anyone potentially trying to snoop on you will only see that you are connected to the VPN, and not what you are doing.

Of course, the most important thing is to remember that using public Wi-Fi is always risky, and requires some extra steps to protect your data.

Here are some more tips to help keep you safe:

  • Think twice before connecting to any public Wi-Fi network, especially if it does not require a password to join.
  • Avoid using free, public computers. Cybercriminals sometimes place compromised computers in legitimate Wi-Fi hotspots with the intention of spreading malware or stealing your data.
  • Try to save sensitive transactions, like banking and online shopping, for your secure home or work networks.
  • If you do use a public network, stick to sites that begin with “HTTPS” so you know they are secure. The HTTPS Everywhere browser extension can direct you to encrypted pages when available. Also, look for the green lock icon in the browser’s address bar.
  • When using your laptop, make sure to turn off “sharing” of your folders and devices so no one else on the network can access them. A quick web search can tell you how to do this on your operating system.
  • Use comprehensive security software and keep it up-to-date. If your software includes a firewall, make sure to enable it.

Looking for more mobile security tips and trends? Be sure to follow @McAfee Home on Twitter, and like us on Facebook.

The post Why You Need to Watch Out When Using Public Wi-Fi appeared first on McAfee Blogs.

Posted in computer security, Consumer Threat Notices, internet security, wi-fi | Comments (0)

Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service

May 9th, 2017

OpenSSL, the popular general-purpose cryptographic library that implements SSL/TLS protocols for web authentication, has recently suffered from several vulnerabilities. We have written about “CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL” and “SSL Death Alert (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers” among others. Today we examine the high-severity bug CVE-2017-3733, the Encrypt-Then-MAC renegotiation crash that can cause a denial of service.

Before SSL/TLS encrypts data, it runs the Handshake and ChangeCipherSpec protocols.

During the Handshake phase, the client and server decide which encryption algorithms to use. Once the negotiation is done, the client and the server send each other a ChangedCipherSpec message, after which the traffic is encrypted with the negotiated algorithms.

Encrypted data is sent in one of two ways along with the message authentication code (MAC) in SSL/TLS.

  1. MAC-then-encrypt: This method calculates the MAC of the plain text, concatenates it with the plain text, and runs the encryption algorithm over it.
  2. Encrypt-then-MAC: The cipher-text is generated by encrypting the plaintext and then appending a MAC of the encrypted plaintext.

If the ClientHello message does not contain an Encrypt-Then-Mac extension, then the default is MAC-then-encrypt mode. If ClientHello has an Encrypt-Then-Mac extension, the server will compute the MAC after encrypting the data.

If the client or server wish to change the algorithms used for encryption, they can renegotiate the Cipher_Suites that they have already agreed upon. This can occur any time during data transfer by initiating a new Handshake, which takes place over an existing SSL connection.

Triggering the vulnerability

OpenSSL offers this explanation:

“During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected.”

Say the client starts a TLS handshake with the server using the default MAC-then-encrypt mode. If the client later renegotiates with the Encrypt-then-MAC extension enabled and sends encrypted data in that mode before the ChangeCipherSpec message, the server will crash, causing a denial of service.

When the client triggers this vulnerability, the server crashes at the ssl3_get_record function, in the ssl3_record.c file:

The crash occurs at line no. 352, when checking to see if mac_size is less than EVP_MAX_MD_SIZE (64 bytes):

The if statement preceding the assertion checks whether the Encypt-then-MAC flag is set in the server. The macro in the if condition:

The flag TLS1_FLAGS_ECRYPT_THEN_MAC is already set when the ClientHello packet is sent with the Encrypt-then-MAC extension at the time of renegotiation. So the control will go inside the if condition. But because the ChangeCipherSpec message has not yet passed to the server, it does not know it must use Encrypt-then-MAC.

Putting a break point at line no. 352 and checking the mac_size variable shows us the value 0xffffffff, which is greater than EVP_MAX_MD_SIZE (64). Thus the assertion fails and the server crashes.

Let’s go to the code and find how the mac_size variable gets the value 0xffffffff. The EVP_MD_CTX_size function calculates the mac_size.

It returns -1 when the message digest value is null. 0xffffffff is the two’s complement of -1. This means “s->read_hash” returns null as the server tries to calculate the hash using the MAC-then-encrypt mode.

Users of McAfee products are protected from this attack by signature 0x45c09700. All administrators should update OpenSSL to the latest version.

 

Thanks to Hardik Shah for helping me with this post.

 

 

 

 

The post Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Vulnerability | Comments (0)

Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL

March 8th, 2017

OpenSSL is a popular open-source library for SSL and is used by various software and companies across the world. In January, OpenSSL released an update that fixed multiple vulnerabilities. One of them is CVE-2017-3731, which can cause a denial of service due to a crash. McAfee Labs analyzed this vulnerability to provide detection for customers. 

Figuring out the changes using patch diff

The patch modified a couple of files related to various cipher algorithms. For this report we will examine e_chacha20_poly1305.c. The following code shows the patch to this file, taken from https://git.openssl.org/?p=openssl.git;a=commitdiff;h=2198b3a55de681e1f3c23edb0586afe13f438051.

We can see that a simple step was added to check the value of variable length against the constant POLY1305_BLOCK_SIZE and just below that we see that this constant is subtracted from the variable “len.”

If we look at the declaration, POLY1305_BLOCK_SIZE is declared in the file poly1305.h as “#define POLY1305_BLOCK_SIZE 16.” The variable len is defined in e_chacha20_poly1305.c as “unsigned int len;”

So if the variable len is less than 16, it will cause an integer underflow, that is, the value of len will become very large. When used, this value can cause problems with the normal program flow because the value of len will be incorrect.

Digging further

We can see in the preceding image that this len value is assigned to “actx->tls_payload_length.” Then the function chacha20_poly1305_cipher is called. Inside this function actx->tls_payload_length is assigned to the variable “plen”:

Notice that variable plen will now have the very large value that we got from the previous len integer underflow. We can further see that the value of plen is passed to the function poly1305_Update:

Poly1305_Update will carry this large value as it calls the function Poly1305_blocks:

If we take a closer look at the function, we can see that the variable len contains a very large integer value, which is used as the counter in a “while” loop:

We can also see a call to the function U8TOU32, which reads the value of *inp (a pointer), and that the value of *inp is increased by POLY1305_BLOCK_SIZE for each iteration of the loop. Because the value of len is very large, eventually *inp will point to nonreadable memory. Attempting to read that will cause an access violation error—resulting in an OpenSSL crash.

Exploiting the vulnerability from the network

To exploit this vulnerability, a client needs to use the chacha20_poly1305 cipher suite (or another vulnerable cipher, as can be seen from patch diff) and send an encrypted handshake message in which the record length is less than 16 bytes (in the case of chacha20_poly1305 cipher). This will cause an integer underflow and OpenSSL will crash, as we see in the following images running OpenSSL and Gnu Debugger:

Conclusion

OpenSSL is very popular and thus can be a target for denial of service attacks. These types of vulnerabilities can impact many installations. We recommend that users update their OpenSSL installations to the latest version.

McAfee Network Security Platform customers are protected against this vulnerability through signature ID: 0x45c09400.

The post Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Vulnerability | Comments (0)

Pentesters Can Take Advantage of Weakness in SAML

March 4th, 2017

When penetration testers examine the security of applications, we employ a number of tools. We recently wrote about keeping track of browser options. Another protocol that we use to test is the Security Assertion Markup Language (SAML), a popular XML-based authentication information exchanger for implementing single sign-on (SSO) authentication.

The protocol works like this:

  • A user accesses the application URL (the service provider).
  • The application initiates the SSO request and redirects the user to the SSO URL (the identity provider) if already not logged in.
  • The user enters valid SSO account details and the identity provider generates SAML response code and sent it to the service provider.
  • The service provider (application) verifies the SAML response code and authenticates the user.

This protocol considered secure, with the following advantages:

  • Users need to authenticate only once online to access different services, reducing the chances for identity theft and phishing attacks. Because SAML response code controls authentication attempts, users account details never leave the identity provider firewall.
  • The unique user accounts are taken care of by the identity provider, so users do not need to remember additional authentications for each application. This even eliminates separate action for each service such as changing or forgotten passwords, etc.
  • An administrator has one console to control all users.

In spite of this generally secure structure, however, we have observed interesting privilege escalation issues through SAML response tampering.

Here is the scenario:

  1. To test authorization, we created two user roles.
  2. Normal user, aka testuser, with limited access.
  3. Administrator user, aka adminuser, with full access.
  4. We launched the application SSO login URL and used testuser to log in.
  5. We ran a man-in-the-middle login process using the Burp proxy server to examine the SSO login.
  6. After entering testuser’s valid id and password, we observed that an intermediary request was used to generate the SAML response and make the SSO.

SAML assertion message generated from a successful authentication.

  1. We intercepted the response for this request.
  2. We copied the Base64-encoded SAML response and decoded the value using decoders available online.
  3. While examining this decoded value, we saw that the value had a parameter “testuser.”
  4. We replaced this value with “adminuser” and again encoded the value with Base64.

Login ID in decoded SAML response.

  1. We placed this edited SAML response into the intercepted response in Step 5 and continued the traffic.
  2. The result was that testuser’s privilege had escalated to a higher level user and that we had effectively logged on as adminuser.

This is one useful attack scenario while pentesting with SAML. Other SAML-specific attacks can be found in the OWASP SAML cheat sheet.

We recommend that application service providers validate user authorization based on the complete original SAML assertion message instead of only on a single element such as the “saml NameID” in the preceding example.

The post Pentesters Can Take Advantage of Weakness in SAML appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security | Comments (0)

Pentesters Need to Keep Track of Browser Options

February 9th, 2017

Penetration testers searching for vulnerabilities always include cross-site scripting (XSS) attacks as one of their methods. Recently we observed an unusual XSS-related case that taught us something new.

During an XSS-related test, we inserted the “<script>alert(1)</script>” payload as a GET request’s parameter and executed this command in Internet Explorer 11. We expected to see our “malicious” alert but instead the browser returned “The webpage cannot be found,” making us think that our command had failed. We next ran the command on Firefox and saw a different response—a successful XSS execution with “alert box 1.”

Different browser responses for the same HTTP response code.

When we examined the request/response traffic in Burp’s proxy server, we saw “HTTP/1.1 400 Bad Request” with our inserted XSS payload in the response body. This suggested that the command should work at all times.

The actual page response in Burp.

Clearly there are differences in browser behavior for the same response HTTP code. After further investigation we found Internet Explorer’s advanced feature “Show friendly HTTP error messages”:

Internet options in IE.

When this feature is checked (the default), Internet Explorer shows its own friendly error message instead of the page response from web server.

In our XSS attempt, Internet Explorer ignored the web server’s bad request response (the injected XSS payload was even reflected in the response) and showed its own message. By looking only at this response, there is a strong chance that we could miss a serious issue during our testing.

We unchecked this option, restarted the browser, and ran the same malicious URL. This time we saw the successfully executed response with the alert box.

Successful XSS execution after disabling the “friendly error message” feature in IE.

There are some other specific browser settings/dependencies that need attention while pentesting:

Enable XSS filter (in IE): When this option is enabled, the browser recognizes a potential attack in its response (reflected script), and will automatically block script code from running. When this occurs, we see a message in the notification bar that the web page was modified to help protect your privacy and security. Disable this option in the security field while pentesting:

The XSS filter option in IE.

Developers also have the choice to set a custom XSS-protection response header to enable XSS filters in browsers. Read this page for more information.

Next time you are pentesting, take a look at these sorts of browser options. They may help you to greater success.

 

References:

http://www.liutilities.com/products/registrybooster/tweaklibrary/tweaks/11253/

https://support.isqsolutions.com/article.aspx?id=10161

 

The post Pentesters Need to Keep Track of Browser Options appeared first on McAfee Blogs.

Posted in computer security, email and web security, endpoint protection, McAfee Labs | Comments (0)

Analyzing CVE-2016-9311: NTPD Vulnerability Can Lead to Denial of Service

February 3rd, 2017

The network time protocol synchronizes time across various devices on a network. The network time protocol daemon (NTPD) is an open-source implementation of this protocol. In the last couple of months, a number of vulnerabilities have been reported in NTPD. One is CVE-2016-9311, which can cause a crash leading to a denial of service. We have analyzed this vulnerability and provided detection for our customers. In this post we take a detailed look at this vulnerability.

Finding the changes

Examining the patch, we found that the function “report_event” in ntp_control.c holds the fix for this vulnerability. The patch diff tool gives us the following screen (taken from http://bugs.ntp.org/attachment.cgi?id=1460&action=diff):

 

The left side of the preceding image shows the unpatched code, while right side has the patched code.

In the vulnerable version of code there is one assert statement:

INSIST(peer!=NULL)

INSIST is defined in ntp_assert.h. If peer==NULL, then the assertion will fail and NTPD will crash.

In the fixed version, we can see that the INSIST(peer!=NULL) statement is replaced by a simple “if” check:

if ((err & PEER_EVENT) && !peer)

return

This if statement checks whether the value of “peer” is null. If so, it will simply return and prevent a crash.

Analyzing the root cause

To trigger this vulnerability, program flow needs to reach the “report_event” function with a parameter such that the INSIST assertion check fails. (The variable “peer” should be null.)

When NTPD receives a packet, it goes to the function “receive” in ntp_proto.c. The “receive” function performs various checks on the received packet; one checks for valid or invalid crypto-negative acknowledgement (crypto-NAK) packets:

If NTPD receives an invalid NAK packet, it will call the vulnerable function “report_event.” In this vulnerable function, a check looks for the number of traps. If no traps are configured on NTPD, then the function will simply return and the vulnerable code path will not be taken.

This vulnerability can be exploited only if traps are enabled in NTPD. To check for invalid NAK packets, the function “valid_NAK” is present in ntp_proto.c:

As we see in the preceding image, the following conditions will mark a packet as an invalid NAK:

  • If mode is not MODE_SERVER and mode is not MODE_ACTIVE and mode is not MODE_PASSIVE.
  • If keyid is not 0.
  • If there is no peer or peer does not have a key.
  • If the origin does not match.

If the trap functionality is enabled on NTP, then sending an “invalid NAK” packet with no peer present will trigger this vulnerability. We can confirm this using a debugger on vulnerable version. The following screen shows NTPD crashing because of this assertion failure:

Conclusion

This vulnerability can be exploited only on NTPD installations with traps configured to cause a denial of service; traps are not enabled by default. Authorization is not required to exploit this vulnerability.

Apply the latest patches or use an up-to-date version of NTPD to guard against this vulnerability. Customers of McAfee Network Security Platform are protected from this vulnerability through signature ID 0x41b01100.

References

The post Analyzing CVE-2016-9311: NTPD Vulnerability Can Lead to Denial of Service appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Vulnerability | Comments (0)

A Billion Users Affected by Latest Yahoo Breach

December 15th, 2016

Yahoo Inc. just revealed its second major breach in a year. Its first disclosure, taking place in September, claimed that cybercriminals stole data on more than 500 million users. Its second disclosure, taking place on Wednesday, announced that cybercriminals stole data on more than a billion of the service’s users. The criminals, essentially, stole the details of almost every Yahoo account.

The stolen data includes names, email addresses, telephone numbers, dates of birth, hashed passwords (more on this in a moment) and encrypted and unencrypted security questions and answers. The cybercriminals did not compromise any clear-text (normal text, like what you’re reading now) passwords, banking information or payment card data, according to Yahoo. The company has not been able to identify how the data was stolen, though it does say it believes the intrusion began in August 2013.

And that’s not all. While Yahoo did take the precaution of hashing passwords—essentially jumbling passwords so much they become unrecognizable—the cybercriminals behind the attack can still bypass a password challenge, thanks to forged cookies. Cookies, in internet lingo, are a type of tracker stored on each user’s computer. This tracker contains information relevant to a particular website or service and the user it’s assigned to, allowing that user to enjoy easier access to services and more.

Cybercriminals, however, can use forged cookies to trick Yahoo’s service into thinking a user is accessing their account when it’s actually the criminal in question. Yahoo has invalidated these cookies and is in the process of notifying users affected by this technique. The forged cookies are a bigger problem than it immediately seems, since it suggests a hostile party had access to the company’s proprietary code—a major issue for any organization dependent on software for profit.

Regardless, there are steps you should immediately take if you ever find yourself involved in a massive data breach like this one:

  • First, change your password. The first order of business is logging into the affected account and changing your password. It should be a complex password, with capital and lower-case letters, numbers and symbols, and should contain at least eight characters. If you have trouble coming up with such passwords or, more likely, trouble remembering them, then consider investing in a password management solution like Intel Security True Key, which helps generate and store complex passwords for you.
  • Keep an eye out for suspicious activity. A post-breach environment is a prime time for hackers—particularly for phishing scammers. These crooks depend on tricking users into giving up information based off of appeals to authority and immediacy, often via email. Never click on or respond to any email asking for personal data or account login information. Don’t click on any links in an email purporting to be from a compromised service. Instead, type in the website’s web address on your own and reset your password from there.
  • Use comprehensive security. No one is capable of being on guard 24 hours a day, seven days a week. For that, you’ll need a comprehensive security solution capable of doing all the security monitoring for you. For that, there are a range of security solutions, like McAfee LiveSafe™, which stay up to date on the latest malware threats and protect your devices from the woes of dangerous websites and more.

And, of course, stay on top of the latest consumer and mobile security threats by following me and @IntelSec_Home on Twitter, and ‘Like’ us on Facebook.

gary

The post A Billion Users Affected by Latest Yahoo Breach appeared first on McAfee Blogs.

Posted in computer security, Consumer Threat Notices, cybersafety, email and web security | Comments (0)

Do You Need to Pull Up Your SOCs?

December 13th, 2016

This week’s McAfee Labs Threats Report: December 2016 revealed the results of a survey gauging the state of the security operations center (SOC). The following is an excerpt from this article.

A few years ago, dedicated SOCs seemed to be going the way of the dinosaur—the era of big rooms with big monitors and teams of analysts seemed ready to be replaced by distributed teams, outsourced, or disbanded entirely. If you were not in the Defense Department or on Wall Street, many thought, then you did not need a SOC. Then targeted attacks and insider threats moved from movie and government plots to an everyday reality for enterprises. According to an Intel Security survey, 68% of investigations in 2015 involved a specific entity, either as a targeted external attack or an insider threat.

Today, almost all commercial (1,000–5,000 employees) and enterprise (more than 5,000 employees) organizations run some type of SOC, and half of them have had one for more than a year, according to the latest research study from Intel Security. As the number of incidents continues to increase, security organizations appear to be maturing and using what they learn to educate and improve prevention in a virtuous cycle. For instance, survey respondents documented their expanding investments in SOCs and attributed an increase in investigations to an improved ability to detect attacks. Those who reported a decline in investigations of incidents attributed this improvement to better protection and processes, which mature organizations perform as the final stage of a security investigation.

These are some of the findings in a primary research study commissioned by Intel Security on the current state of security management environments and threat detection capabilities, as well as priority areas for future growth.

Almost nine out of 10 organizations in this study reported that they have an internal or external SOC, although commercial organizations are slightly less likely to have one (84%) compared with enterprises (91%). Smaller organizations in general are implementing SOCs a bit later than enterprises, as only 44% of commercial groups have had one for more than 12 months, whereas 56% of enterprise SOCs have been around for that long. Most SOCs (60%) are currently run internally, with 23% operating a mix of internal and external support, and 17% fully external. For the few that have not established a SOC, only 2% of enterprises have no plans to do so, versus 7% of commercial companies.

Of the 88% of organizations operating a SOC, the majority (56%) reported that they use a multifunction model combining SOC and network operations center (NOC) functionality. Organizations in the United Kingdom (64%) and Germany (63%) are even more likely to operate in this model. Dedicated SOCs are in use by 15% of companies and are more prevalent in the United States (21%). Virtual SOCs are the third model, also used by about 15% of respondents, followed by a distributed or co-managed SOC, at 11%. Only 2% reported operating a command SOC.

This distribution of SOC implementations has several implications. The majority operate at or past the midpoint of SOC maturity, progressing toward the goal of a proactive and optimized security operation. However, more than a quarter (26%) still operate in reactive mode, with ad-hoc approaches to security operations, threat hunting, and incident response. This can significantly extend detection and response times, leaving the business at greater risk of significant damage, as well as facing a higher cleanup cost.

Whether from an increase in attacks or better monitoring capabilities, most companies (67%) reported an increase in security incidents, with 51% saying they have increased a little, and 16% that they have increased a lot. This is analogous to findings from the key topic “Information theft: the who, how, and prevention of data leakage” in the McAfee Labs Threats Report: September 2016. That primary research study found that organizations which watched data more closely for leakage reported more data-loss incidents.

Only 7% overall indicate that incidents have decreased, and the remaining 25% say that they have remained stable over the past year. There was little variance reported by country, but incidents increased as organizations get smaller, possibly indicating that criminals have broadened their attack targets. Only 45% of the largest organizations (more than 20,000 employees) reported an increase, compared with 73% of the smallest (fewer than 5,000 employees).

The small group that reported a decrease in incidents overwhelmingly (96%) believe that this was due to better prevention and processes. Of those who said that incidents increased, the majority feel that it was due to a combination of improved detection capabilities (73%) and more attacks (57%).

Most organizations are overwhelmed by alerts, and 93% are unable to triage all relevant threats. On average, organizations are unable to sufficiently investigate 25% of their alerts, with no significant variation by country or company size. Almost one-quarter (22%) feel that they were lucky to escape with no business impact as a result of not investigating these alerts. The majority (53%) reported only minor impact, but 25% say they have suffered moderate or severe business impact as a result of uninvestigated alerts. The largest organizations, perhaps because of their better monitoring capabilities and stable incident levels, are more likely to report no business impact (33%).

 

To learn more about the SOC survey findings, visit www.mcafee.com for the full report.

The post Do You Need to Pull Up Your SOCs? appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Optimize Operations, Quarterly Threats Report, security management | Comments (0)