Kategorie

We've had a number of articles covering the interesting news out of Intel's 2019 Open-Source Technology Summit (OSTS) held at Skamania Lodge in Stevenson, Washington. Here's a look back at the news out of the open-source event as well as some other smaller bits of information shared during the event.

(credit: US Navy)

This post has been updated to add comments Linksys made online, which says company researchers couldn't reproduce the information disclosure exploit on routers that installed a patch released in 2014. Representatives of Belkin, the company that acquired Linksys in 2013, didn't respond to the request for comment that Ars sent on Monday. Ars saw the statement only after this article went live.

More than 20,000 Linksys wireless routers are regularly leaking full historic records of every device that has ever connected to them, including devices' unique identifiers, names, and the operating systems they use. The data can be used by snoops or hackers in either targeted or opportunistic attacks.

(credit: Troy Mursch)

Independent researcher Troy Mursch said the leak is the result of a flaw in almost three dozen models of Linksys routers. It took about 25 minutes for the Binary Edge search engine of Internet-connected devices to find 21,401 vulnerable devices on Friday. A scan earlier in the week found 25,617. They were leaking a total of 756,565 unique MAC addresses. Exploiting the flaw requires only a few lines of code that harvest every MAC address, device name, and operating system that has ever connected to each of them.

Read 9 remaining paragraphs | Comments

Note: We have updated this story to reflect new information after Stack Overflow changed its original announcement and shared more details on the security incident. Stack Overflow, one of the largest question and answer site for programmers, revealed today that unknown hackers managed to exploit a bug in its development tier and then almost a week after they gained unauthorized access to its

A cross-site scripting flaw in a popular WordPress plugin enables an unauthenticated attacker to insert JavaScript payloads into impacted websites.

The German software company behind TeamViewer, one of the most popular software in the world that allows users to access and share their desktops remotely, was reportedly compromised in 2016, the German newspaper Der Spiegel revealed today. TeamViewer is popular remote-support software that allows you to securely share your desktop or take full control of other's PC over the Internet from

Posted by Kurt Thomas and Angelika Moscicki
Every day, we protect users from hundreds of thousands of account hijacking attempts. Most attacks stem from automated bots with access to third-party password breaches, but we also see phishing and targeted attacks. Earlier this year, we suggested how just five simple steps like adding a recovery phone number can help keep you safe, but we wanted to prove it in practice.
We teamed up with researchers from New York University and the University of California, San Diego to find out just how effective basic account hygiene is at preventing hijacking. The year-long study, on wide-scale attacks and targeted attacks, was presented on Wednesday at a gathering of experts, policy makers, and users called The Web Conference.
Our research shows that simply adding a recovery phone number to your Google Account can block up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks that occurred during our investigation.


Google’s automatic, proactive hijacking protection
We provide an automatic, proactive layer of security to better protect all our users against account hijacking. Here’s how it works: if we detect a suspicious sign-in attempt (say, from a new location or device), we’ll ask for additional proof that it’s really you. This proof might be confirming you have access to a trusted phone or answering a question where only you know the correct response.
If you’ve signed into your phone or set up a recovery phone number, we can provide a similar level of protection to 2-Step Verification via device-based challenges. We found that an SMS code sent to a recovery phone number helped block 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks. On-device prompts, a more secure replacement for SMS, helped prevent 100% of automated bots, 99% of bulk phishing attacks and 90% of targeted attacks.


Both device- and knowledge-based challenges help thwart automated bots, while device-based challenges help thwart phishing and even targeted attacks.
If you don’t have a recovery phone number established, then we might fall back on the weaker knowledge-based challenges, like recalling your last sign-in location. This is an effective defense against bots, but protection rates for phishing can drop to as low as 10%. The same vulnerability exists for targeted attacks. That’s because phishing pages and targeted attackers can trick you into revealing any additional identifying information we might ask for.
Given the security benefits of challenges, one might ask why we don’t require them for all sign-ins. The answer is that challenges introduce additional friction and increase the risk of account lockout. In an experiment, 38% of users did not have access to their phone when challenged. Another 34% of users could not recall their secondary email address.
If you lose access to your phone, or can’t solve a challenge, you can always return to a trusted device you previously logged in from to gain access to your account.


Digging into “hack for hire” attacks
Where most bots and phishing attacks are blocked by our automatic protections, targeted attacks are more pernicious. As part of our ongoing efforts to monitor hijacking threats, we have been investigating emerging “hack for hire” criminal groups that purport to break into a single account for a fee on the order of $750 USD. These attackers often rely on spear phishing emails that impersonate family members, colleagues, government officials, or even Google. If the target doesn’t fall for the first spear phishing attempt, follow-on attacks persist for upwards of a month.


Example man-in-the-middle phishing attack that checks for password validity in real-time. Afterwards, the page prompts victims to disclose SMS authentication codes to access the victim’s account.
We estimate just one in a million users face this level of risk. Attackers don’t target random individuals though. While the research shows that our automatic protections can help delay, and even prevent as many as 66% of the targeted attacks that we studied, we still recommend that high-risk users enroll in our Advanced Protection Program. In fact, zero users that exclusively use security keys fell victim to targeted phishing during our investigation.



Take a moment to help keep your account secure
Just like buckling a seat belt, take a moment to follow our five tips to help keep your account secure. As our research shows, one of the easiest things you can do to protect your Google Account is to set up a recovery phone number. For high-risk users—like journalists, activists, business leaders, and political campaign teams—our Advanced Protection Program provides the highest level of security. You can also help protect your non-Google accounts from third-party password breaches by installing the Password Checkup Chrome extension.

The decision to pay a ransom in the case of a ransomware attack can be a complex one for businesses.

The importance of reading the network tealeaves of a company’s network traffic to head off an attack.

Europolu a americkému ministerstvu spravedlnosti se podařilo ve spolupráci s orgány dalších šesti zemí kompletně rozbít síť kyberzločinců, která stála za malwarem GozNym. Ten ukradl v minulých letech z bankovních účtů lidí a podniků po celém světě přes 100 milionů dolarů (2,3 miliardy ...

From a zero day flaw in WhatsApp, to Patch Tuesday fixes, Threatpost breaks down the top vulnerabilities of this week.

Google had egg on its face this week after it had to recall some of its Titan hardware security keys for being insecure.

Six alleged members of "The Community" were indicted, along with three phone service employees who allegedly helped target subscribers.

Arrests in Europe and the US appear to have ended the cybercrime careers of the gang behind the GozNym banking malware.

A tool from the White House invites those who suspect political bias in social media censorship to "share their story with President Trump."

Cryptocurrency rumor mongers are likely to be dancing today as Amazon has successfully filed a patent for a Bitcoin-styled Proof-of-Work system. But dont get ahead of yourself, it doesn't look like the Seattle-based ecommerce giant will be accepting Bitcoin for payments.

The bloom is on mobile, whether it be the enterprise, employees or the cybercriminals plotting new ways to slip past a corporate defenses in a post-parameter world.

Image credit: PexelsWhen January updates for Windows got released, the public was alarmed by news of critical vulnerability CVE-2019-0547 in DHCP clients. A high CVSS score and the fact that Microsoft did not release an Exploitability Index assessment right away, which made it more difficult for users to decide whether they needed to update their systems immediately, stirred up the heat. Some publications even speculated that the absence of the Exploitability Index pointed to the appearance of a usable exploit in the near future.

Solutions such as MaxPatrol can identify which computers on a network are vulnerable to certain attacks. Other solutions detect such attacks. For these solutions to work, both the rules for identifying vulnerabilities in products and the rules for detecting attacks on those products need to be described. This, in turn, will be possible if for each separate vulnerability we figure out the vector, method, and conditions of exploitation. In other words, all the details and nuances related to exploitation. This requires a much more in-depth and full understanding compared to what can usually be found in descriptions on vendors' sites or in CVE, for example:

The reason for the vulnerability is that the operating system incorrectly handles objects in memory.
So, to update our products with rules for detecting attacks targeting the newly discovered vulnerability in DHCP and rules for identifying affected devices, we needed to dive into all the details. With binary vulnerabilities, one can often get to the faults lying at their root by using patch-diff, which compares and identifies the changes to the binary code of an app, a library, or an operating system's kernel made by a specific patch or update fixing the error. But Step 1 is always reconnaissance.

Note: To go directly to the vulnerability description, without reading the DHCP concepts it's based on, you can skip the first several pages and go straight to the section titled "DecodeDomainSearchListData function".

ReconnaissanceGo to a search engine and go through everything currently known about the vulnerability. This time there's not much detail, and most of it is information recycled from the original publication on the MSRC site. This situation is typical for errors found by Microsoft during an internal audit.

From the publication, we find that we are dealing with a memory corruption vulnerability contained in both client and server systems running on Windows 10 version 1803 and that it manifests when an attacker sends specially crafted responses to the DHCP client. A couple days after, the page will also contain Exploitation Index ratings:


As we can see, MSRC gave a rating of 2 — Exploitation Less Likely. This means the error is very likely either non-exploitable, or exploiting it is so difficult that it would require too much effort. Admittedly, Microsoft does not have a habit of lowballing such scores. This is partly due to reputational risks, as well as the relative independence of the response center within the company. So let's assume that if exploitation is indicated as unlikely, that is probably true. We could finish the analysis then and there. But it's always a good idea to double-check and at least see what exactly the vulnerability was. While vulnerabilities may be diverse, they also tend to reoccur and pop up in other places.

On the same site we download the patch (security update) provided as an .msu archive, unpack it, and look for the files most likely to be related to client-side processing of DHCP responses. Lately this has become more difficult. Updates are now provided not as separate packages fixing specific errors, but as a single package containing all monthly fixes. This increases the number of unrelated changes that we must wade through to find what truly interests us.

In the plethora of files, our search turns up several libraries matching the filter, and we compare these with their versions on an unpatched system. The dhcpcore.dll library looks the most promising of all. Meanwhile BinDiff shows minimal changes:


In fact, more or less significant changes are made only to one function — DecodeDomainSearchListData. If you are well familiar with the DHCP protocol and its rarely used functions, you already have an idea of what list is handled by that function. If not, we move to Step 2: reviewing the protocol.

DHCP and its optionsDHCP (RFC 2131 | wiki) is an extensible protocol whose extensibility is implemented by means of the options field. Each option is described by a unique tag (number, identifier), size of the data contained in the option, and the data itself. This practice is typical for network protocols, and one of these options "implanted" in the protocol is Domain Search Option, which is described in RFC 3397. It allows a DHCP server to set standard domain name endings on clients. Those will be used as DNS suffixes for connections set up in this way.

For example, let's say that on our client we have set the following name endings:

.microsoft.com .wikipedia.org


Then, in any attempt to determine address by domain name, these endings will be plugged in to DNS requests one by one, until a match is found. For instance, if the user types ru in the browser address bar, DNS requests will be formed first for ru.microsoft.com and then for ru.wikipedia.org:


In fact, modern browsers are too smart, so they react to names similar to FQDN by redirecting to a search engine. So we will later provide the output of less "thoughtful" utilities:



The reader might think this is the essence of the vulnerability. In itself, the ability to alter DNS suffixes using a DHCP server, when any device on the network can be identified as such, is a threat to clients requesting any network parameters using DHCP. But that's not all. As evident from the RFC, this is considered quite legitimate and documented behavior. A DHCP server is, in effect, a trusted component able to impact devices that connect to it.

Domain Search optionThe Domain Search Option number is 0x77 (119). As with all other options, it is coded by a single-byte tag with option number. And like most options, the tag is followed by a single-byte size of the data following the size. A DHCP message can contain more than one copy of the option. In this case, data from all such sections is concatenated in the same order as in the message.


In the example taken from RFC 3397 the data is divided into three sections of 9 bytes each. As seen from the picture, subdomain names in the full domain name are coded with a single-byte name length, followed by the name itself. The full domain name code ends in a null byte (null size of the subdomain name).

Also, the option uses the simplest data compression method: reparse points. Instead of the domain name size, the field might contain 0xc0. Then the next byte will establish the offset relative to the start of the data of the option used to search for the end of the domain name.
So, in our example, we have a coded list of two domain suffixes:

.eng.apple.com
.marketing.apple.com

DecodeDomainSearchListData functionThe DHCP option with number 0x77 (119) allows the server to set DNS suffixes on clients. But not on computers with Windows operating systems. Microsoft systems have traditionally ignored this option, so historically endings of DNS names were applied using group policies, when necessary. But things changed recently, when the new release of Windows 10 version 1803 introduced handling for Domain Search Option. As follows from the function name in dhcpcore.dll that was changed, it is the added handler itself that contains the error.

Now let's get to work. Comb the code a little, and here's what we find. The DecodeDomainSearchListData procedure, as one might guess, decodes data from the Domain Search Option of the message received from the server. As input, it takes a data array packed as described earlier, and it outputs a null-terminated string containing a list of domain name endings separated by commas. For instance, the function will transform the data from the above example into the following string:

eng.apple.com,marketing.apple.com

DecodeDomainSearchListData is called from the UpdateDomainSearchOption procedure, which writes the returned list to the "DhcpDomainSearchList" parameter of the registry key:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{INTERFACE_GUID}\

which stores the main parameters for the specific network interface.


The DecodeDomainSearchListData function makes two passes. On the first pass, it performs all actions except making an entry to the output buffer. So the first pass is for calculating the size of memory needed to hold the returned data. On the second pass, memory is allocated for that data and the allocated memory is filled. The function is not too big—about 250 instructions—and its main job is to handle each of the three possible variants of the character in the incoming stream: 1) 0x00, 2) 0xc0, or 3) all other values. The fix for the error related to DHCP boils down to adding a check of the size of the resulting buffer at the start of the second pass. If the size is zero, memory is not allocated for the buffer, and the function completes execution and returns an error:


So the vulnerability shows itself only when the size of the target buffer is zero. And in the very beginning the function checks its inputs, whose size cannot be less than two bytes. Therefore, exploitation requires finding a non-empty domain suffix option formed in such a way that the size of the output buffer equals zero.

ExploitationThe first thing that comes to mind is using the reparse points to make sure that non-empty input data generates an empty string of output:



A server set up to respond with an option with such content will indeed cause an access violation on non-updated clients. Here is why. At every step, when the function parses part of the full domain name, it copies that part into the target buffer and appends a period. In this example from the RFC, the following data will be copied to the buffer in the following order:

1). eng.

2). eng.apple.

3). eng.apple.com.

Then, when the zero domain size is encountered in the input data, the function changes the previous character in the target buffer from a period to a comma:

4). eng.apple.com,

and keeps parsing:

5). eng.apple.com,marketing.

6). eng.apple.com,marketing.apple.

7). eng.apple.com,marketing.apple.com.

8). eng.apple.com,marketing.apple.com,

When input data ends, all that's left is replacing the last comma with a null character, and here's a string ready to be written to the registry:

9). eng.apple.com,marketing.apple.com

What happens when the attacker sends a buffer formed as described? From the example we can see the list it contains is made of a single element — an empty string. On the first pass, the function calculates the output data size. Since the data does not contain any non-zero domain name, the size is zero.

On the second pass, a heap memory block is allocated for the data and the data is copied. But the parsing function immediately encounters the null character indicating the end of the domain name, so, as explained before, it changes the previous character from a period to a comma. And then we have a problem. The target buffer iterator is set to zero. There's no previous character. The previous character belongs to the header of the heap memory block. And this character will be changed to 0x2c, which is a comma.

However, this happens only on 32-bit systems. Using unsigned int to store the current position of the target buffer iterator causes changes in handing on x64 systems. Let's look more closely at the fragment of code responsible for writing the comma to the buffer:


One is subtracted from the current position using the 32-bit register eax, but when addressing the buffer, the code addresses the full 64-bit register rax. On the AMD64 architecture any operations with 32-bit registers zero out the high halfword of the register. This means that the rax register, which used to contain a zero, will after subtraction store 0xffffffff and not –1. Therefore on 64-bit systems the value 0x2c will be written at the address buf[0xffffffff], way outside of the memory allocated for the buffer.

These findings strongly correlate with the exploitability scoring by Microsoft, because to exploit this vulnerability, an attacker has to learn how to perform remote heap spraying on the DHCP client, as well as have sufficient control of heap memory distribution to make sure that preset values (namely, comma and period) are written to the prepared address and cause controllable adverse effects.

Otherwise, writing the data to an unchecked address will result in failure of the svchost.exe process with all the services it may host at the moment, and subsequent restart of those services by the operating system. That's a fact attackers may also use to their advantage if circumstances permit.
This is seemingly all we can say about the studied error. But we still feel it's not the end. As if we have not yet considered every option. There must be more than meets the eye...

CVE-2019-0726Most likely, that's the case. If we look closely at the type of data causing the error and compare that data with how exactly the error occurs, we can see that the list of domain names may be changed in such a way that the resulting buffer size will not be zero, yet there will still be an attempt to write it outside of the buffer. For that to happen, the first element of the list must be an empty string, and all others may contain nominal domain names. For example:


The option includes two elements. The first domain suffix is empty, it ends immediately in a null byte. The second suffix is .ru. The calculated size of the output string will be three bytes, allowing it to pass the check for empty target buffer introduced in the January update. At the same time, a zero at the very beginning of the data will force the function to write a comma as the previous character in the resulting string, but since the current position of the iterator in the string, as in the example before, is zero, it will write outside of the allocated buffer.

Now we need to confirm our theoretical results by a practical test. Let's simulate a case where the DHCP server responds to a client request with a message with the presented option, and we immediately find an exception when trying to write a comma at position 0xffffffff of the buffer allocated for the resulting string:


Here register r8 contains a pointer to incoming options, rdi contains the address of the allocated target buffer, and rax contains the position in that buffer where the character must be written. These are the results we got on a system with all updates installed (as of January 2019).

We wrote to Microsoft informing them of the problem, and guess what? They lost our message. Yes, this sometimes happens even to the best and most reputable vendors. No system is perfect, and in this case you need to find alternative ways of communication. A week later, having not received even an automated response, we made contact directly on Twitter. After several days of analysis we found that the details we sent had nothing to do with CVE-2019-0547 and actually formed a separate vulnerability, which will get a new CVE identifier. A month later, in March, a new patch was released, and the issue got a number: CVE-2019-0726.

This is how sometimes when trying to figure out a 1-day vulnerability, you may accidentally stumble upon a 0-day vulnerability, just by trusting your instincts.

Author: Mikhail Tsvetkov, Positive Technologies

The web skimming script was recently found stealing payment data on the websites of Forbes Magazine as well as seven others.

Apples devices are far better defended against malware and viruses than other platforms, but does this mean they don't need anti-virus software?

Developers of the privacy-focused Brave browser have raised concerns last week about possible user privacy issues in Client-Hints, a new internet standard currently pending approval by the Internet Engineering Task Force (IETF).