Information Security News
Who Didn't Win a Piece of This Army Infosec Deal?
Last Friday, the Army awarded 18 companies $7.2 billion worth of indefinite-delivery, indefinite-quantity contracts for “flexible, comprehensive, cost-effective services to support the Army's need for fully integrated intelligence, security ...
Browsers are generally designed to prevent a script from one site from being able to access content from another site. They do this by enforcing what is called the Same Origin Policy (SOP): scripts can only read or modify resources (such as the elements of a webpage) that come from the same origin as the script, where the origin is determined by the combination of scheme (which is to say, protocol, typically HTTP or HTTPS), domain, and port number.
The SOP should then prevent a script loaded from http://malware.bad/ from being able to access content at https://paypal.com/.
A vulnerability has been discovered byÂ JohnathanÂ LooneyÂ at the JuniperÂ SIRTÂ inÂ FreeBSDÂ (base forÂ JunosÂ and many other products) in the way thatÂ FreeBSDÂ processes certain TCP packets (https://www.freebsd.org/security/advisories/FreeBSD-SA-14:19.tcp.asc) Â If you send TCP SYN packets for anÂ existingÂ connection (i.e. the correct source IP, source port, destinationÂ IP,Â destinationÂ port combination) the operating system will tear down the connection. Â
The attack is similar to the "slipping in the TCP window" attack described back in 2004 by Paul Watson (http://packetstormsecurity.com/files/author/3245/),Â but using SYN packets instead of RST. Â One of the Handlers hasÂ successfullyÂ reproduced the attack in their lab. Â
For those of you that don't haveÂ FreeBSDÂ in your environment, you probably do. There areÂ a number of products thatÂ utiliseÂ FreeBSDÂ as their base operating system. A few that spring to mind are OSX, Bluecoats,Â CheckPoint,Â NetscalerÂ and moreÂ (A partial list is hereÂ http://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD).Â Â
Keep an eye out for updates from your vendors, Juniper's is here Â --> Â http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10638">=SIRT_1">M(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
by Sean Gallagher
Apple has put fixes in place to its iCloud cloud storage service that now prevent an attacker from mining data from an iOS device backup stored in the cloud by gaining access to the user’s password—at least if that user has turned on Apple’s new two-factor authentication.
As we reported last week, iCloud previously did not use two-factor authentication to help protect backup data or the Find My iPhone service. This meant that the accounts of victims of social engineering attacks or those who used passwords based on personal data could be harvested of their backup data—allowing the attacker to gain access to photos, call records, SMS records, e-mail, and other personal data. Apple had said that it was moving to provide additional protection through two-factor authentication in advance of the release of iOS 8.
We tried accessing one of the accounts attacked during our testing just prior to the Apple event last week using Elcomsoft Phone Password Breaker, a forensic tool that uses a reverse-engineered version of Apple’s iOS backup protocols to extract backup data from an iCloud account. The account now has two-factor authentication turned on, and the attempt failed—it yielded an unspecified HTTP error.
Pretty much ever since the new top level domain (TLD) ".biz" went online a couple years ago, and the only ones buying domains in this space were the scammers, we kinda knew what would happen when ICANN's latest folly and money-grab went live. It looks like a number of the "new" top level domains, like ".support", ".club", etc have now come online. And again, it seems like only the crooks are buying.
We are currently investigating a wave of phishing emails that try to lure the user to a copy of the Bank of America website. The main difference, of course, is that any login credentials entered do not end up with Bank of America, but rather with some crooks, who then help themselves to the savings.
Phishing emails per se are nothing new. But it appears that URLs like the one shown in the phishing email above have a higher success rate with users. I suspect this is due to the fact that the shown URL "looks different", but actually matches the linked URL, so the old common "wisdom" of hovering the mouse pointer over the link to look for links pointing to odd places .. won't help here.
But wait, there's more! Since the crooks in this case own the domain, and obviously trivially can pass the so-called "domain control validation" employed by some CA's, they actually managed to obtain a real, valid SSL certificate!
Quoting from the Certificate Authority's web site:
Comodo Free SSL is a fully functional Digital Certificate, recognized and trusted by 99.9% of browsers. Your visitors will see the golden padlock and won't see security warnings. What will you get:
They don't mention why they think any of this is a good idea.
Addition of SSL to the phish means that another "scam indicator" that we once taught our users is also no longer valid. When a user clicks on the link in the phishing email, the browser will actually show the "padlock" icon of a "secure site". See the screenshot below.
If you have seen other recent banking phishes that use new top level domains and/or valid SSL certificates, please let us know via the contact form, or the comments below!
Â(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Who Didn't Win a Piece of This Army Infosec Deal?
Last Friday, the Army awarded 18 companies $7.2 billion worth of indefinite-delivery, indefinite-quantity contracts for “flexible, comprehensive, cost effective services to support the Army's need for fully integrated intelligence, security ...