PHISHING ATTACKS ON TELECOMMUNICATION CUSTOMERS RESULTING IN ACCOUNT TAKEOVERS CONTINUE

PHISHING ATTACKS ON TELECOMMUNICATION CUSTOMERS RESULTING IN ACCOUNT TAKEOVERS CONTINUE

Phishing attacks targeting various telecommunication companies’ customers continue. Individuals receive automated telephone calls that claim to be from the victim’s telecommunication carrier. The IC3 released an advisory about this scam in May 2013. Since then, the attacks have increased and recently, victims have reported receiving SMS texts with a similar phishing message encouraging them to go to web sites to claim their reward. Victims are directed to a phishing site to receive a credit, discount or prize ranging from $100 to $2,500. The monetary amounts being offered are increasing to make the scam more enticing. A fraudulent web site example would be www.My(insertphone company name)900.com. Other fraudulent web sites may contain words such as, MyBonus, ILove, ILike, Reward, Promo, or similar words, along with a telephone company’s name.

The phishing site is a replica of one of the telecommunication carrier’s sites and requests the victim’s log-in credentials and the last four digits of their Social Security number. Once access is gained, the subject makes changes to the customer’s account and may place orders for mobile phones.

The IC3 urges the public to be cautious of unsolicited telephone calls, e-mails and text messages, especially those promising some type of compensation for supplying account information. If you receive such an offer, verify it with the business associated with your account before supplying any information. Use the phone numbers that appear on your account statement to contact the business.

If you have fallen victim to this scam, immediately notify your telecommunication carrier and file a complaint with the IC3, http://www.ic3.gov.

Wildcard DNS, Content Poisoning, XSS and Certificate Pinning

Hi everyone, this time I'm going o talk about an interesting vulnerability that I reported to Google and Facebook a couple of months ago. I had some spare time last October and I started testing for vulnerabilities on a few companies with established bug bounty programs. Google awarded me with $5000,00 and Facebook payed me $500,00 for reporting the bugs.

I know you may be more interested on highly sophisticated exploits that allow arbitrary file upload to the Internet, with custom payloads that may lead to unexpected behavior like closing Security Lists. Hopefully this class of bugs is already patched by Fyodor and Attrition is offering an efficient exploit mitigation technique.

The title may be a little confusing, but I'm going to show that it's possible to combine all these techniques to exploit vulnerable systems.

Content Poisoning and Wildcard DNS

Host header poisoning occurs when the application doesn't validate full URL's generated from the HTTP Host header, including the domain name. Recently, the Django Framework fixed a few vulnerabilities related to that and James Kettle made an interesting post discussing lots of attack scenarios using host header attacks.

While testing this issue, I found a different kind of Host header attack that abuses the possibility to browse wildcard domains. Let's have a quick look at the Wikipedia entry on Hostnames:

"The Internet standards (Request for Comments) for protocols mandate that component hostname labels may contain only the ASCII letters 'a' through 'z' (in a case-insensitive manner), the digits '0' through '9', and the hyphen ('-'). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hostname labels to start with digits. No other symbols, punctuation characters, or white space are permitted."

The fun part here is that the network stack from Windows, Linux and Mac OS X consider domains like -www.plus.google.com, www-.plus.google.com and www.-.plus.google.com valid. It's interesting to note that Android won't resolve these domains for some reason.

Take, for example, the following URL: https://www.example.com.-.www.sites.google.com. If we compose an e-mail and paste it on the body, GMail will split them and the received message will have two “clickable” parts (https://www.example.com and sites.google.com).

Most e-mail based notification use the very same host you are browsing in order to compose the notification messages: you see where this is going, right?

Facebook has a wildcard DNS entry at zero.facebook.com. In order to exploit the flaw, we have to browse the service using a poisoned URL and perform actions that may need e-mail confirmation, checking whether Facebook mails the crafted URL to the user.

The only vulnerable endpoint that I found affected by this issue was the registration e-mail confirmation. You may be asking, how could one exploit this to attack a legitimate user?

Suppose I want to attack the Facebook account from goodguy@example.com. I can create or associate a "duplicate" account using the "+" sign by browsing Facebook with these injected URL's. If I navigate to Facebook using an URL like https://www.example.com.-.zero.facebook.com, all I have to do is create the duplicate account goodguy+DUPLICATE@example.com. Most e-mail services like GMail and Hotmail don't consider what you type after the "+" and forward it to the original account.

In this case, all e-mails that Facebook sent to confirm that association had the poisoned links.

This can also be used to poison password reset emails, but Facebook forms were not affected. They quickly fixed that by hard coding the proper URL to their e-mail confirmation system. It's also possible (but not recommended) to fix these issues by sending notifications with relative links instead of complete URL's ("please click here" instead of "please click on the specified url: www.example.com.-.zero.facebook.com").

XSS and Wildcard DNS

While searching for these issues on Google I quickly found wildcard domains like:

- https://w00t.drive.google.com
- https://w00t.script.google.com
- https://w00t.sites.google.com

In case you're wondering how to quickly find these wildcard domains, you can download and lookup for them on the scans.io datasets. You can find these references on the Reverse DNS records or by searching for SSL certificates issued to wildcard domains, like *.sites.google.com.

During my initial tests, I was unable to craft URL's using .-. inside the drive.google.com domain (got 500 error messages) and all I could do was creating URL’s like this: https://www.example.com-----www.drive.google.com.

When you browse Google Drive using this URL, upload a File to a Folder and try to Zip/Download it asking for an e-mail confirmation (“Email when ready”), the e-mail confirmation message will be like this:

The "ready for downloading" link would point to https://www.example.com-----www.drive.google.com/export-result?archiveId=REDACTED. So far no big deal, I was still unable to poison the links... And phishing yourself is not that useful =)

I kept testing different URL's until I found a weird behavior on Google DNS Servers. When typing URL's containing a domain you control followed by a certain number of "-" and the wildcard domain from Google, the resolved IP would be the one from the URL you control.

My highly sophisticated Fuzzer in action

For some reason, there was a glitch on their DNS servers, more specifically in the regexp that stripped "--" from the domain prefixes. I'm not sure why they performed these checks but that may have something to do with Internationalized Domain Names.

XKCD's take on the bug

Some Google domains affected by this issue (October 2013):

- docs.google.com
- docs.sandbox.google.com
- drive.google.com
- drive.sandbox.google.com
- glass.ext.google.com
- prom-qa.sandbox.google.com
- prom-test.sandbox.google.com
- sandbox.google.com
- script.google.com
- script.sandbox.google.com
- sites.google.com
- sites.sandbox.google.com

Now that I can impersonate a Google's domain, it's possible abuse the Same Origin policy and issue requests on behalf of a logged user. lcamtuf already told us about HTTP cookies, or how not to design protocols. What happens if we control www.example.com and the logged user from drive.google.com visits the crafted URL http://www.example.com---.drive.google.com?

Request goes to legitimate site:

Requests goes to the user-controlled site, in this case my own server running nginx:

This leverages to a XSS-like attack: you have now bypassed the same origin and you can steal cookies and run scripts on the context of the site, for example.

Certificate Pinning and Wildcard DNS

So far so good, but what if we were performing the same tests on Google Chrome, which enforces Certificate Pinning for their domains? I didn't notice at first, but I accidentally found an issue on Chrome too: it was failing to perform the proper HSTS checks for these non-RFC compliant domains.

Other parts of the network stack were processing and fetching results from these "invalid" DNS names, but TransportSecurityState was rejecting them and therefore HSTS policies didn't apply. They simply removed the sanity checks to make TransportSecurityState more promiscuous in what it process.

You can easily reproduce this on Chrome prior to v31: proxy Chrome through OWASP ZAP (accepting its certificate), visit URL’s like https://sites.google.com and Chrome will display a “heightened security” error message. If you type URL’s like https://www-.sites.google.com or https://www-.plus.google.com Chrome offers the option to “Proceed anyway”. If you're in Turkey right now you don't need to do nothing, the Turkish Telecom does all the MITM job for you.

It's worth mentioning that when you issue a wildcard certificate for your host, it will be valid for a single level only. Certificates issued to *.google.com should not be trusted when used on domains like abc.def.google.com.

The hardcoded list of domains and pinned certificates from Chrome can be found here:

- https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

During my analysis, I found that 55 out of 397 domains with Transport Security enabled had wildcard entries on their DNS. A nation sponsored attacker, with a valid and trusted CA could simply MITM your traffic and inject requests to these invalid domains, circumventing the HSTS policies and stealing session cookies, for example.

Google did not assign a CVE for that bug, but they fixed that within a couple of weeks. Chrome 32 and 33+ (the one that changed the SSL warning from red to yellow) are not affected by this issue.

In times of Goto fails, it was really interesting to follow the Chromium's tracker, their internal discussions, tests performed and so on. The commits fixing these issues can be found here.

Conclusion

Google and Facebook security teams were both great to deal with. The bug was quite fun as well because it was different from the traditional OWASP Top 10 issues.

And because the industry totally needs new Vulnerability terminologies, anyone willing to refer to these attacks shall name them Advanced Persistent Cross Site Wildcard Domain Header Poisoning (or simply APCSWDHP).

In case you're from NSA and want to use this technique to implant our DNS's, please use the codename CRAZY KOALA so we could better track them when the next Snowden leaks your documents

Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)

You may have heard of “Heartbleed,” a flaw in OpenSSL that could allow the theft of data normally protected by SSL/TLS encryption. We’ve assessed this vulnerability and applied patches to key Google services such as Search, Gmail, YouTube, Wallet, Play, Apps, App Engine, AdWords, DoubleClick, Maps, Maps Engine, Earth, Analytics and Tag Manager.  Google Chrome and Chrome OS are not affected. We are still working to patch some other Google services. We regularly and proactively look for vulnerabilities like this -- and encourage others to report them -- so that that we can fix software flaws before they are exploited. 

If you are a Google Cloud Platform or Google Search Appliance customer, or don’t use the latest version of Android, here is what you need to know:

Cloud SQL
We are currently patching Cloud SQL, with the patch rolling out to all instances today and tomorrow. In the meantime, users should use the IP whitelisting function to ensure that only known hosts can access their instances. Please find instructions here.

Google Compute Engine

Customers need to manually update OpenSSL on each running instance or should replace any existing images with versions including an updated OpenSSL. Once updated, each instance should be rebooted to ensure all running processes are using the updated SSL library. Please find instructions here.

Google Search Appliance (GSA)

Engineers have patched GSA and issued notices to customers. More information is available in the Google Enterprise Support Portal.

Android

All versions of Android are immune to CVE-2014-0160 (with the limited exception of Android 4.1.1; patching information for Android 4.1.1 is being distributed to Android partners).

We will continue working closely with the security research and open source communities, as doing so is one of the best ways we know to keep our users safe.

Apr 12: Updated to add Google AdWords, DoubleClick, Maps, Maps Engine and Earth to the list of Google services that were patched early, but inadvertently left out at the time of original posting.

Apr 14: In light of new research on extracting keys using the Heartbleed bug, we are recommending that Google Compute Engine (GCE) customers create new keys for any affected SSL services. Google Search Appliance (GSA) customers should also consider creating new keys after patching their GSA. Engineers are working on a patch for the GSA, and the Google Enterprise Support Portal will be updated with the patch as soon as it is available.

Also updated to add Google Analytics and Tag Manager to the list of Google services that were patched early, but inadvertently left out at the time of original posting.

Apr 16: Updated to include information about GSA patch.

Heartbleed Will Linger "For Many Months to Come"

It’s been nearly two weeks since the Heartbleed bug was made public -- two weeks of massive coverage from news outlets across the globe as the security of online services used my much of the world was called into question. 
Now things are beginning to settle down. Most of the major players have announced that they’ve shored up the vulnerability that left them open to leaking sensitive data. The first arrest has been made in connection with Heartbleed, a 19-year-old London, Ont. man accused of the theft of 900 social insurance numbers from the Canada Revenue Agency’s Website, and users across the world have received a slew of “please reset your password” emails.

But there’s a long way to go, and it may be awhile before one of the biggest bugs in recent memory is truly “fixed.”
“I think things are going to be lingering for many months to come, just because that’s the nature of the way patches get implemented and holes get fixed,” said Marc Gaffan, co-founder of Incapsula. “I would imagine if we did a survey three or six months from today we’d find astonishing results in terms of how many organizations have not patched [the Heartbleed OpenSSL vulnerability].”
The big players have patched things up by now, but OpenSSL is widely used, the figure most often being quoted a massive two-thirds of web servers.
“As you start moving away from that nucleus, you get more and more organizations that are less up to date, less able, less willing to patch their systems,” Gaffan said, describing the way a typical vulnerability is addressed. Heartbleed is certainly major, but that isn’t going to change the nature of the way people react.
And we haven’t even touched on the billions of users, many who may not follow through on their end due to ignorance or laziness or simply because they just don’t care. That’s exactly what Justin Balthrop argued on Medium when discussing a huge problem that’s at the core of this Heartbleed mess -- passwords:

I have 268 passwords on 268 different websites. At least that’s what my password manager says. I actually stopped saving new passwords a while back, so the real number of passwords I should change now that Heartbleed has been revealed is even higher than that. How many of those passwords do you think I’m going to change? It took me 10 minutes just to find the change password form for my bank! What about the average computer user who uses the same password for every website and doesn’t understand the details of the exploit? How many passwords will they change?

Not very many.

A Look at Heartbleed's Popularity

We thought it would be interesting to use our HackSurfer data to conduct a little sociological experiment. Which of the two major cybersecurity moments of the past five months is garnering more discussion: the Heartbleed bug or the Target breach?


As you can see, they both took up a massive chunk of the discussion, but Heartbleed is even more “popular” than Target over it’s respective period. This may reflect how far reaching the vulnerability is, which is hardly surprising given the amount of posts and articles we’ve seen here at HackSurfer regarding the bug.
“I don’t think that this has been overplayed [in the media],” Gaffan said. “Given the ubiquitousness of OpenSSL plus the potential damage that this vulnerability can create, it does create a pretty big hole out there.”

Who Left the Curtains Open?

So what is Heartbleed?
It’s a small bug that’s been in existence for the past two years and affects many websites that collect personal and financial information. That little padlock icon you see along with “https” on most browsers is meant to assure users that everything is safe. Heartbleed discovered that’s not necessarily been the case. 
Michael Hamlin, an X-Force security architect with IBM, explained the problem with Heartbleed using the typical household analogy on a recent IBM podcast.
Imagine all of your usernames, passwords and other data is written on a big stack of paper sitting on your desk.
“They’re in your house. They’re locked up. They’re secure,” Hamlin said. “We think about SSL that way. We trust the servers' encrypting our sessions, and we provide our usernames and passwords. They’re encrypted. But if a burglar walks up and looks through the window and there's a stack of papers on the desk now, it can read the first page, whatever is exposed on the top page, and that's kind of how this vulnerability works. It was like not drawing the curtains shut. It left that chunk of memory open to anybody that requested it.”
Perhaps most importantly, they discovered that private encryption keys could be stolen through the vulnerability.
As Codenomicon, the security firm that discovered the flaw (Google engineer Neel Mehta discovered it independently as well), described, “These are the crown jewels, the encryption keys themselves. Leaked secret keys allow the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will.”

What Should I Do? What Will Hackers Do?

There are three main things a website owner should do, whether they’re tiny or a huge SAAS platform, said Gaffan:

1. Patch your infrastructure; make sure that you’ve implemented the fix to the Heartbleed vulnerability.
2. Reissue certificates with a new private key, just in case it was stolen when the vulnerability existed.
3. Websites that run with persistent cookies (if you’re constantly logged in to social media for example) leave users vulnerable if that cookie information is stolen; log out of all them and log back in; “Given that the vulnerability is now fixed with most of the bigger providers, that means that those credentials will be no longer snatchable.”

One problem: many smaller businesses still operate with the mentality that they’re a small target and therefore can operate without being on cybercriminals’ radar.
“What people don’t actually realize is that in this era of automation, smaller and smaller websites are being hacked today just because they’re out there on the internet,” Gaffan said. “There are scanners that are available already today that can tell you if a website is vulnerable to Heartbleed or not. If I’m a bad guy, what I would do is start scanning a couple of million websites each day and compiling a list of who I need to go after. Once I’d compiled that list, I’d build another automated tool that all it does is hit Heartbleed vulnerable servers and try to pull out usernames and passwords. That’s something that is going on all the time with other vulnerabilities.”
If you’re a user, how do you know the websites you’re visiting are safe? There’s several options. Use a tool just like criminals are: scanners. Many companies are offering the ability to check for Heartbleed (likeNorton, for example). There are dozens of apps springing up, and there’s even browser extensions that can make confirming a site is safe simple and easy.
Except, there’s one big problem with all of that. As The Guardian reported last week, researchers are claiming that most popular Heartbleed detection tools are flawed:

A deluge of tools then hit the internet promising to help people determine whether the web services they were using or hosting were affected. But 95% of the most popular ones are not reliable, according to London-based security consultancy and penetration testing firm Hut3.

“A lot of companies out there will be saying they've run the free web tool and they're fine, when they're not,” Hut3’s Edd Hardy told the Guardian. “There's absolute panic. We're getting calls late at night going 'can you test everything'.”

Unfortunately, that means you may have to make sure the tool you’re using to stay safe is providing safe and accurate results.

Andriod Stay Safe From Virus

How To Stay Safe From Andriod Virus:

• Make sure the Android system setting ‘Unknown sources’ is unchecked to prevent dropped or drive-by-download app installs
• Download a mobile security app like Lookout’s app that protects against malware as a first line of defense

Check out the full advertisement for the malware toolkit below:

• This week, researchers found Dendroid, a custom “Remote Access Toolkit” (RAT) for Android targeting customers from Western countries, and yes, it breached Google Play. A RAT is a type of malware that is used to remotely control the devices it is installed on. The toolkit is being sold for $300 to anyone who wants to automate the malware distribution process. The creator promises that the malware can take pictures using the phone’s camera, record audio and video, download existing pictures, record calls, send texts, and more.
  All Lookout users are protected from this threat.
  
  On top of all of these features, the toolkit comes with a business model that is highly reminiscent of Russian custom malware toolkits. The author is selling the toolkit online, demanding payment in currencies like Bitcoin, and provides a warranty promise that the malware will remain undetected. Want to evade detection and get into Google Play? This toolkit will help you do just that. While this type of complete toolkit based approach is common in the Russian underground, especially with banking trojans, this type of model is unusual to find in the U.S.
  What’s more, it looks as if Dendroid was designed with evading Play Store security in mind. Amongst its numerous features, Dendroid features some relatively simple — yet unusual — anti-emulation detection code that helps it evade detection by Bouncer, Google’s anti-malware screening system for the play store. Malware-detecting programs like Bouncer, use “emulation” in order to log and understand the behaviors of software so that it can look for risky behavior to remember and block that behavior in the future. However, by using “anti-emulation” code, malware writers can attempt to hide by not executing any bad code, which might alert the detection system.
  As Dendroid is a new threat, detections are very low right now. We only detected a single application infected with Dendroid and it has already been removed from the Play Store, however, the developer’s account is still open.
  This toolkit is different from the majority of custom Android malware solutions in other ways as well. Most of these solutions typically just offer a few pieces of code for the wannabee malware author to insert into an innocent target application. More sophisticated features, such as command and control of infected devices, is then left up to the operator to implement. Dendroid, on the other hand, offers a full command and control infrastructure with a control panel every bit as feature rich as some of the more sophisticated Russian botnets.
  Available for $300 in cryptocurrencies such as Bitcoin or Litecoin (and PayPal if the seller trusts you), Dendroid offers its customers a list of advanced spyware features and complete command and control backed up by its promise of a lifetime warranty.

NASA radio waves News

The National Security Agency is using secret wireless technology that allows it to access and alter data on computers, even when they are not connected to the Internet, according to a New York Times report.

Since 2008, the agency has been increasingly using a "covert channel of radio waves" that can transmit from hardware installed in the computers, according to NSA documents and experts interviewed by the Times. Signals can then be sent to briefcase-size relay stations miles away, according to the report.

The NSA has also installed surveillance software on nearly 100,000 computers around the world, according to the Times. The newspaper said the Chinese Army was a frequent target of such technology but said there was no evidence that the agency used either technology inside the US.

Repeating earlier denials that its data collection activities are arbitrary or unconstrained, the NSA rejected any comparison to Chinese attackers who have been accused to planting similar software on computers belonging to US companies and government agencies.

"NSA's activities are focused and specifically deployed against -- and only against -- valid foreign intelligence targets in response to intelligence requirements," the NSA said in a statement. "In addition, we do not use foreign intelligence capabilities to steal the trade secrets of foreign companies on behalf of -- or give intelligence we collect to -- U.S. companies to enhance their international competitiveness or increase their bottom line."

The surveillance agency also asserted that a complex web of laws, regulations, and policies governed its use of such tools and that "continuous and selective publication" of the agency's techniques was "detrimental to the security of the United States and our allies."

Last month, a Der Spiegel report detailed how the agency's Office of Tailored Access Operations intercepts deliveries of electronic equipment to plant spyware to gain remote access to the systems once they are delivered and installed. According to that report, the NSA has planted backdoors to access computers, hard drives, routers, and other devices from companies such as Cisco, Dell, Western Digital, Seagate, Maxtor, Samsung, and Huawei.

The German news magazine also described a 50-page product catalog of tools and techniques used by a program called ANT, which stands for Advanced or Access Network Technology, to send and receive signals to devices.

President Obama is expected to announce on Friday the changes to the NSA he is expected to adopt based on recommendations from a presidential task force. The panel, which was appointed by President Obama in the wake of disclosures made this summer by former NSA contractor Edward Snowden, has reportedly proposed stricter standards for NSA data searches and that a third party be responsible for storing phone records collected by the agency.

EC-COUNCIL Website has been Hacked

Snowden’s Passport on the Site:

As of Saturday, February 22, 2014 at 8:00pm EST, it seems like the main website operated by EC-Council has been hacked.  On the site is an image of Edward Snowden’s passport and text stating, “owned by certified unethical software security professional -Eugene Belford”.

Edward Snowden, the man who turned whistle-blower against the National Security Agency (NSA) and revealed its global spying program, was trained by EC-Council as a Certified Ethical Hacker (CEH).

The hack maybe a DNS hijacking attack,  the information below kind of point that way:

Server:            75.75.75.75

Address:         75.75.75.75#53

Non-authoritative answer:

Name: eccouncil.org

Address: 93.174.95.82

As of Feb. 23, it seems as though EC-Council has not gained control of their website.  An update was posted on the EC-Council site stating:

“owned by certified unethical software security professional

Obligatory link: http://attrition.org/errata/charlatan/ec-council/ -Eugene Belford

P.S It seems like lots of you are missing the point here, I’m sitting on thousands of passports belonging to LE (and .mil) officials”