Too many domain names with non-Latin letters are still shut out of the global Internet economy.

ompanies that do business online are missing out on billions in annual sales thanks to a bug that is keeping their systems incompatible with Internet domain names made of non-Latin characters. Fixing it could also bring another 17 million people who speak Russian, Chinese, Arabic, Vietnamese, and Indian languages online.


Those are the conclusions of a new study by an industry-led group sponsored by the International Corporation for Assigned Names and Numbers (ICANN), the organization responsible for maintaining the list of valid Internet domain names. The objective of the so-called Universal Acceptance Steering Group, which includes representatives from a number of Internet companies including Microsoft and GoDaddy, is to encourage software developers and service providers to update how their systems validate the string of characters to the right of the dot in a domain name or e-mail address—also called the top-level domain.

The bug wasn’t an obvious problem until 2011, when ICANN decided to dramatically expand the range of what can appear to the right of the dot (see “ICANN’s Boondoggle”). Between 2012 and 2016, the number of top-level domains ballooned from 12 to over 1,200. That includes 100 “internationalized” domains that feature a non-Latin script or Latin-alphabet characters with diacritics, like an umlaut (¨), or ligatures, like the German Eszett (ß). Some 2.6 million internationalized domain names have been registered under the new top-level domains, largely concentrated in the Russian and Chinese languages, according to the new study.


Many Web applications or e-mail clients recognize top-level domains as valid only if they are composed of characters that can be encoded using American Standard Code for Information Interchange, or ASCII.  The problem is most pronounced with e-mail addresses, which are required credentials for accessing online bank accounts and social media pages in addition to sending messages. In 2016, the group tested e-mail addresses with non-Latin characters to the right of the dot and found acceptance rates of less than 20 percent.

The bug fix, which entails changing the fundamental rules that validate domains so that they accept Unicode, a different standard for encoding text that works for many more languages, is relatively straightforward, says Ram Mohan, the steering group’s chair. The new research suggests that the potential economic benefits of making the fix outweigh the costs. Too many businesses, including e-commerce firms, e-mail services, and banks, simply aren’t yet aware that their systems don’t accept these new domains, says Mohan.


Things are improving, though. In 2014, Google updated Gmail to accept and display internationalized domain names without having to rely on an inconvenient workaround that translated the characters into ASCII. Microsoft is in the process of updating its e-mail systems, which include Outlook clients and its cloud-based service, to accept internationalized domain names and e-mail addresses.

It’s not just about the bottom line, says Mark Svancarek, a program manager for customer and partner experience at Microsoft, and a vice chair of the Universal Acceptance Steering Group. To let millions of people be held back from the Internet because “the character set is gibberish to them” is antithetical to his company’s mission, he says.

Acceptance of non-ASCII domains is likely to spur Internet adoption, since a large portion of the next billion people projected to connect to the Internet predominantly speak and write only in their local languages, says Mohan. Providing accessibility to these people will depend in many ways on the basic assumptions governing the core functions of the Internet, he says. “The problem here is that in some ways this is lazy programming, and because it’s lazy programming, it’s easy to replace it with better programming.” 

Source: This article was published technologyreview.com By Mike Orcutt

Categorized in Internet Privacy

The vulnerability exists within Microsoft's own antimalware protection engine, but thankfully there's already a fix.

Apple may now be the richest company, but it's Microsoft's operating system that still loads on most of our desktops and laptops around the world. So when a major security bug is discovered it's important it gets fixed quickly. And Google researchers recently discovered a really serious one in Windows Defender of all places.

The bug was discovered by Google Project Zero vulnerability researchers Tavis Ormandy and Natalie Silvanovich. As the tweet by Ormandy below notes, this is the "worst Windows remote code exec" bug discovered as far as he can remember.



 Tavis Ormandy

 @tavisoI think @natashenka and I just discovered the worst Windows remote code exec in recent memory. This is crazy bad. Report on the way. 


The vulnerability allows remote code execution if the Microsoft Malware Protection Engine "scans a specially crafted file." If successful, the attacker is then able to run whatever code they like on the breached system as well as using it to start infecting other Windows machines.

According to Engadget, the vulnerability is present on Windows 7, 8.1, RT and Windows 10, meaning just about everyone running Windows is vulnerable.

So you won't be surprised to hear that Microsoft marked the bug as Critical and already has a fix available to close the security hole. It should be applied to your system automatically over the next few days, or you can manually trigger a Windows Update to install the patch now.


Source : This article was published pcmag.com By MATTHEW HUMPHRIES

Categorized in Search Engine

A bug in Word apparently targeted by scammers trying to steal banking logins will be patched, Microsoft has said.

The previously undetected, or "zero-day", vulnerability had been reported over the weekend.

Then, on 10 April, cybersecurity firm Proofpoint announced it had discovered an email campaign targeting the bug that aimed to distributed Dridex malware.

Dridex is designed to infect a victim's computer and snoop on banking logins.

In 2015, it was cited as the means by which cyber-attackers stole more than £20m from British bank accounts.

The flaw discovered in many versions of Microsoft Word for Windows could allow malicious software, including Dridex, to be installed, according to cybersecurity researchers.


Microsoft did not confirm whether Mac versions of Word were also affected.

A scam email campaign was found to be distributing Microsoft Word RTF [Rich Text Format] documents to recipients that contained Dridex.

'Fully exploited'

"During our testing (for example on Office 2010) the vulnerable system was fully exploited," wrote Proofpoint researchers in a blog.

"We plan to address this through an update on Tuesday April 11, and customers who have updates enabled will be protected automatically," said a Microsoft spokesman.

"Meanwhile we encourage customers to practise safe computing habits online, including exercising caution before opening unknown files and not downloading content from untrusted sources to avoid this type of issue."

Proofpoint also urged Microsoft Word users to install the security updates quickly.


"Because of the widespread effectiveness and rapid weaponisation of this exploit, it is critical that users and organisations apply the patch as soon as it becomes available," the firm said.

Source : bbc.com

Categorized in News & Politics

Cloudflare, which operates a widely used web content delivery network, announced a security bug on February 23 that caused sensitive data to leak from its customers’ websites.  The exact number of websites potentially affected is unknown but some estimates place the total in excess of 5 million. The Google security researcher who discovered the bug – nicknaming it “Cloudbleed” after the 2014 Heartbleed bug – reported it to Cloudflare on February 18, 2017.  Cloudflare disabled the compromised software and stopped the leak later the same day.

The leaked data reportedly included passwords, private messages, encryption keys, session cookies that would let an attacker log into an account without a password, IP addresses and other data.  Leaked data was exposed to search engine crawlers, which began to automatically cache the data, thus complicating remediation.


As of this writing there have been no publicized reports that leaked data has been exploited and Cloudflare has published analysis concluding that the vast majority of its customers probably were not affected.  However, operators of millions of websites and their users are left to wonder whether they were affected and what they should do next.

Below is a summary of what we know now and our thoughts on next steps.

What is Cloudflare?

Cloudflare makes a web content delivery product used by 6 million customers to enhance website performance and security.  When you visit a website in Cloudflare’s network, your request for the site is automatically routed to Cloudflare, which uses routing techniques and its own copy of the site’s static content to load the site faster than it would conventionally.

Cloudflare also offers features designed to enhance the security of web content, such as rewriting unencrypted http content to encrypted https, using “server-side exclude” technology to ensure data is seen only by its intended audience, and obfuscating email addresses.

What does the Cloudbleed bug do?

The bug was found in a parser used to power three security features – https rewrites, server-side excludes, and email obfuscation.  To execute these features, Cloudflare saves website content and data to memory for parsing.  The bug caused this data to leak – at random – into code of web pages in the Cloudflare network such that when you visited a web page, that page would include leaked data from an entirely different Cloudflare-supported website.

What type of information was leaked?

The Google researcher who discovered the bug gave this report:

I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.

Cloudflare’s CTO initially reported that end-user passwords, authentication cookies, OAuth tokens used to log into multiple website accounts, and encryption keys were at risk of exposure.  In its most recent blog post, Cloudflare reports that it has not yet found any instances of passwords, credit cards or health records among leaked data but that leakage of this and other sensitive data cannot be ruled out.  In addition, Cloudflare has emphasized that leakage occurred randomly and leaks would include a mixed bag of both potentially sensitive data and useless non-sensitive “noise”.

Where did leaked data go?

Leaked data could be stored in the browser caches of users who unwittingly downloaded leaked data, was cached by search engines like Google, Bing and Yahoo, and may have been saved by other bots that roam the Internet.  While Cloudflare worked with search engines to remove 770 cached instances of leaked data from 161 different domains before announcing the bug and was unable to find leaked data on sites like Pastebin, researchers subsequently reported that leaked sensitive data is still discoverable in search engines.

When did the leak become active?

As early as Sept. 22, 2016, when the https rewrite feature was first enabled.

The period of greatest exposure was between February 13, 2017 (when the email obfuscation feature was migrated to the compromised parser) and February 18, 2017 (when the compromised features were disabled).

How many Cloudflare customers were affected?

Cloudflare has not provided an official estimate but its latest blog post reports that it found data of approximately 150 Cloudflare customers among the more than 80,000 cached pages that have been purged by the search engines.  The post provides some useful analysis of the probability of a leak based on a website’s level of traffic.  For example, a site that made 250-500 million requests to the Cloudflare network per month is expected to have leaked 25-56 times.  Cloudflare estimates that the 99% of its customers sending fewer than 10 million requests per month probably had no leak at all.  The post also reports that a maximum of 6,457 websites could have triggered the bug.  However, because the websites that triggered the bug pulled information from other websites in Cloudflare’s network, the number of affected Cloudflare customers is unknown and could be much higher.


Has any data been exploited?

Cloudlfare reports that it has found no evidence of the bug being exploited before it was patched.

What is the risk to individuals?

The risk to specific individuals is difficult to evaluate at this stage.  The good news is that Cloudflare acted quickly to remediate the bug and purge known instances of leaked data from search engine caches—all before any reported instances of the bug being discovered or exploited by malicious actors.  In addition, the random distribution of leaked data across the Internet may limit the kind of accumulation of data in one place that would make it easier for a malicious actor to exploit it at scale.  Finally, according to Cloudflare’s analysis, the risk of a leak appears to be low for 99% of its customers.

The bad news is that some of the leaked data – including passwords, encryption keys, authentication tokens and conversations – is clearly sensitive and potentially exploitable to the extent it is still discoverable in search engine caches or elsewhere.

What should companies do now?

Like the Heartbleed bug before it, Cloudbleed is the latest internet security bug to expose a wide swath of the Internet to potential data leaks while in most cases leaving no way to conclusively confirm whether or not a particular company’s or individual’s data was leaked or exploited.  While Cloudbleed may pose low risk to most websites according to Cloudflare, its customers should take this news seriously given the sensitivity of the data exposed and the media attention that the bug has attracted.  Following some basic incident response best practices can help companies mitigate risk and assure customers and partners that appropriate steps are being taken.

  • Evaluate the impact. Companies that use Cloudflare should evaluate the impact to their own websites and any potentially sensitive data that those sites process, while continuing to follow new developments.  A careful reading of Cloudflare’s initial and follow-up posts, as well as the post by the Google security researcher who discovered the bug, followed by inquiries with Cloudflare, are a good start.
  • Take mitigating action. Because the Cloudbleed bug has been patched, efforts should focus on mitigating risk to potentially impacted individuals.  Cloudflare has recommended that concerned customers invalidate and reissue persistent secrets, such as long lived session identifiers, tokens or keys (the company says that customer SSL keys were not exposed and do not need to be rotated).  Other options include:
    • Informing customers about Cloudbleed and its potential impact.
    • Recommending that customers change passwords and use two-factor authentication to protect accounts
    • Forcing a change of administrator credentials for potentially impacted sites
    • Forcing a change of customer passwords
    • Requiring customers to log back into websites without changing passwords (if not already required by invalidating session identifiers)

The right approach will vary for each company based on its own business, the operational costs of making these changes, the sensitivity of the data it handles and the probability of data leakage based on the volume of traffic it sends through Cloudflare.  Companies should perform their own risk assessments in determining the appropriate mitigating steps, weighing both the probability that leaked data could be exploited and the potential impact to the company and individuals if it is.  It is a good idea to document this analysis as part of your incident response process (discussed below).


  • Search for your data. Although Cloudflare took steps to purge leaked data from search engine caches, there have been reports on social media that leaked data remained discoverable after Cloudlfare’s purge.  Thus, potentially affected companies should make a reasonable effort to discover whether their own data is still searchable as part of their incident response efforts.  Whether these searches are performed with the assistance of security incident response vendors or in-house, it is advisable to document the methodology used for the search, why it is believed to be sound and the results of the searches.
  • Develop a communications strategy. Cloudbleed has attracted significant media attention and it is only a matter of time before companies are asked whether they are affected.  Proactively communicating your company’s response to Cloudbleed and efforts to investigate can help alleviate concerns and demonstrate that your company takes security seriously.  This message can be relayed through support emails, customer notices or talking points tailored to customers or other external parties who may inquire.  However, like any external communication relating to an information security incident, these messages should be carefully crafted with the assistance of legal counsel and other relevant internal stakeholders before distribution.
  • Consider security incident notice obligations. Companies should consult legal counsel to assess whether even potential leakage of data triggers breach notification obligations under legal or contractual obligations. While most legal breach notification requirements would not be triggered by unconfirmed potential data leakage, the question is worth closer examination if health data or other particularly sensitive data is at issue or if the company is subject to stringent contractual security incident notification requirements.
  • Initiate an incident under your incident response plan. Companies are increasingly required by law, contractual obligations or internal policy to follow a security incident response plan that addresses how to detect, respond to and mitigate security incidents affecting sensitive data.  If you have an incident response plan and handle sensitive data with potential exposure to Cloudbleed, this is a great reason to formally initiate in incident and respond according to your plan.  Doing this, and documenting the effort, can help you ensure a sound response and demonstrate that you responded responsibly in the event auditors, customers or governmental investigators inquire.  You will also learn something about how well your incident response plan works and what can be done to improve it.

Author : David Navetta & Boris Segalis

Source : http://www.dataprotectionreport.com/2017/03/cloudbleed-bug-impacts-large-swath-of-the-internet/

Categorized in Internet Privacy

Thanks to Google and Tavis Ormandy, your personal information is secure. If you are a frequent user of Uber, Ok Cupid or FitBit, then know that your passwords, messages or the content of your emails might not be personal anymore. Someone out there might be going through your emails or reading your messages as you read this.

Tavis Ormandy is a security researcher who works with Google’s Project Zero. He discovered a bug on cloudFare’s software that has been persistently sending personal information since September 2016. It proliferated this month beginning February 13-18 before discovery. The bad part is that personal information and other details are part of search engine results. This confirms fears of personal data indexing.



CloudFare is a security company that provides content distribution services to millions of sites. Amongst these sites are the riding sharing service Uber and the dating site Ok Cupid.

CloudFare is invisible to most users. It plays a crucial role and acts as a funnel where retailers, bankers and insurance companies can route their services securely. Once CloudFare was notified, they took steps to rectify the problem quickly, according to their Co-Founder Mathew Prince. Even though there are no solid indications of data exploitation, it is nevertheless worrisome. Shockwaves can be felt all across the software security world. In a blog post, they said that this data leak was because they were somehow upgrading their code. Running their new and old codes concurrently might have caused the leak. Only a small subset of their websites were compromised.


Once CloudFare was notified, they took steps to rectify the problem quickly, according to their Co-Founder Mathew Prince. Even though there are no solid indications of data exploitation, it is nevertheless worrisome. Shockwaves can be felt all across the software security world. In a blog post, they said that this data leak was because they were somehow upgrading their code. Running their new and old codes concurrently might have caused the leak. Only a small subset of their websites were compromised.



It is good that this bug was discovered early. CloudFare is a back end and security service provider for most websites. It’s technically invisible for simple internet users, but plays a critical role. Their codes usually crawl through websites picking out HTML errors. With this flaw, it means that when CloudFare code discovers errors, it doesn’t ping back CloudFare monitoring. It instead allows other website utilizing CloudFare services to access these websites and possibly retrieve personal data. This data is readable.


CloudFare CTO reassured customers that the problem is being fixed with mitigation above industry standards in use. According to a post on their website, their technical teams were working hard to fix and clean up the bug. They have since reached out to major search engines and requested them to dispose off any cached data that might include leaked personal information.

So, if you are a subscriber of any of their services take a cautious approach and change your password.

Author : Dalmas Ngetich

Source : https://easterndaily.com/cloudfare-bug-leaking-personal-info/





Categorized in Internet Privacy

WhatsApp has a security bug that could allow encrypted messages to be intercepted from the popular messaging app that owner Facebook has said promises end-to-end encryption.


WhatsApp, acquired by Facebook in 2014, said last year that all communications such as text messages, videos and other files flowing the service would be encrypted. The app has become hugely popular, with more than 1 billion users.

About the time that WhatsApp announced its end-to-end encryption, cryptography and security researcher Tobias Boelter at the University of California-Berkeley contacted WhatsApp about a flaw he had found in the app. He found that undelivered messages — perhaps because the receiver of the message was offline or had changed their phone number — could be intercepted either by an attacker or WhatsApp itself, he says.


That's because WhatsApp makes new encryption keys for undelivered messages and those could be intercepted by a third party that is not WhatsApp. WhatsApp itself, since it is generating another version of the message, has it on its servers, too.

In an interview with The Guardian, Boelter said, "If WhatsApp is asked by a government agency to disclose its messaging records, it can effectively grant access due to the change in keys."

Boelter also did a presentation on the WhatsApp vulnerability earlier this year — a video is posted on Twitter— and wrote about the situation on his blog in May saying that "next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI."

He contacted Facebook and WhatsApp about the vulnerability in April 2016 and, in May, Facebook told him the company is not "actively working on changing" it.

A WhatsApp spokesperson told The Guardian that users can change their security settings so that they know when a contact's key or code is changed. "We know the most common reasons this happens are because someone has switched phones or reinstalled WhatsApp. This is because in many parts of the world, people frequently change devices and Sim cards. In these situations, we want to make sure people's messages are delivered, not lost in transit," the company told The Guardian.

Privacy advocates had been concerned with WhatsApp on another issue, too. In August 2016, WhatsApp said it would begin sharing data with Facebook, as a way to better serve users and fight spam. But the requirement that users opt-out of the feature led privacy groups including Electronic Privacy Information Center to file complaints with the Federal Trade Commission.

EPIC called the move an "unfair and deceptive trade practice." And European Union Commissioner Margrethe Vestager said Facebook "gave us incorrect or misleading information during the investigation into its acquisition of WhatsApp."

Author : Mike Snider

Source : http://www.cnbc.com/2017/01/13/whatsapp-has-bug-that-could-be-exploited.html

Categorized in Social

How did we ever make it through life before the advent of smartphones? There are so many important things we do with these handy little gadgets it's hard to imagine being without one. One great thing smartphones have done is expand the way we communicate with others.

Apps like FaceTime and Skype allow us to speak to someone anywhere in the world, face to face. The more traditional way, of course, is through text messaging. Now there is a nasty prank going around that could infect your phone and kill your messaging app forever.

What's happening is people are receiving prank messages on their iPhone that cause the iMessage app to crash. Without having the fix, it is not recoverable.


iMessage overload

Here is what's causing the app to crash. The victim receives a malicious link from someone through the iMessage app. Once the link is clicked on, the app gets bombarded with an overload of code, causing it to crash indefinitely.

Seriously, the iMessage app will never work again without the fix.

The malicious link is delivered through a vCard file. A vCard is a virtual business card that allows you to create and share contact information through instant messaging.

The size of a normal vCard file is around 300 lines of code. This malicious vCard, discovered by Vincedes3, has over 14,000 lines of code. A bug in Apple's iOS won't allow the iMessage app to move past this huge file.

The app freezes completely and rebooting the phone doesn't fix the problem. Every time you try and open the app, a blank screen appears.

This isn't the first time we've seen a malicious link crashing iPhones this year. We told you about this earlier, where a text with a malicious five-second video crashed your iPhone.

Fixing this crashing problem

This is a terrible prank for people to pull on anyone. If you receive a vCard message, it's probably a good idea to not click on it.

If somehow your iPhone does get hit with this problem, there could be a fix. The hacker that discovered this problem, Vincedes3, has created the solution.

What you need to do is click here on the Safari browser to open the link he's provided. Clicking on this link triggers a process that is supposed to fix the crash and return the iMessage app to its original working state.

Once the process is complete, you should receive a message that reads, "I have just saved your iPhone bro ;)" in the iMessage app.

The flaw affects most iPhones as well as all of the latest versions of iOS.

Author : Mark Jones

Source : http://www.komando.com/happening-now/385154/new-imessage-bug-can-crash-your-iphone-with-a-single-text

Categorized in Internet Privacy

Do you still have a Yahoo Mail account? The tech company made its way onto the scene in 1994 and became a popular search engine and email service. However, it's had a very rough year.

First we learned of a massive data breach that could have impacted billions of users. Then we found out Yahoo was allegedly complying with a government security agency's request to spy on all incoming emails. Now, there is more troubling news coming out about the tech giant.

Security researcher Jouko Pynnonen recently discovered a severe security vulnerability with Yahoo Mail. The flaw would allow an attacker to access the victim's email account.

This was a cross-site scripting (XSS) attack, similar to the one discovered by Pynnonen around the same time last year. Watch this video to see a brief detail of last year's discovery:

Why this flaw is so alarming

What's terrifying about this is the victim wouldn't even need to click on a malicious link to be affected. You only had to view an email sent by the scammer for your Yahoo Mail account to be compromised.


Yahoo filters HTML messages, which is supposed to keep malicious code from making its way into a user's inbox. However, Pynnonen discovered a vulnerability that kept the filters from catching all malicious code. It had to do with different types of attachments that could be added to emails.

The good news is once Pynnonen reported the flaw, Yahoo fixed it. The tech giant also paid him $10,000 for discovering the vulnerability through its Bug Bounty Program.

Even though these flaws have been patched, it's been a rough stretch for Yahoo. If all of these problems worry you, you might want to close your Yahoo accounts. Here are instructions on how to do that:

  • How to close your Yahoo account:
  • Go to the "Terminating your Yahoo account" page.
  • Read the information under "Before continuing, please consider the following information."
  • Confirm your password - if you forgot your password, you can recover it with the Yahoo Sign-in Helper.
  • Click Terminate this Account.

Remember, if you do close your Yahoo account, you will not be able to use services associated with it. So if you decide to keep your account, at the very least make sure you have a strong password. Here are three proven formulas for creating hack-proof passwords.

You can also enable two-step verification, set up a Yahoo Account Key, or use a password manager. It's always better to be safe than sorry!

Author:  Mark Jones

Source:  http://www.komando.com/

Categorized in Internet Privacy

There is a new bug in the Google search results that seems to be impacting web pages that contain YouTube embeds. Instead of showing the date of the page or article, which is published by the author, Google is showing the date of the video embed, pulled from the upload date.

There are tons and tons of reports of this since over the weekend. Google is indeed aware of it; in fact, Gary Illyes of Google said he’d send the bug to the appropriate team.

To illustrate the bug, do a search for [understanding google panda] and look for the result from www.thesempost.com. You will see Google dates it as December 30, 2014, but if you look at the page itself, it is dated January 11, 2016.


Here is a screen shot of the date on the story:


If you look at the snippet, this is the date on that:


Google has been aware of the issue for about two days, and there is no ETA for a fix. Some webmasters and site owners believe their rankings may be hurt by this bug, but that does seem unlikely.

Author:  Barry Schwartz

Source:  http://searchengineland.com

Categorized in News & Politics

airs logo

Association of Internet Research Specialists is the world's leading community for the Internet Research Specialist and provide a Unified Platform that delivers, Education, Training and Certification for Online Research.

Get Exclusive Research Tips in Your Inbox

Receive Great tips via email, enter your email to Subscribe.

Follow Us on Social Media