jueves, agosto 06, 2015

Man-in-the-Cloud Attacks




Popular cloud storage services such as Google Drive and Dropbox can be abused by hackers running Man-in-the-Cloud (MITC) attacks.

The recently issued Imperva’s Hacker Intelligence Initiative report on Man-in-the-Cloud (MITC) attacks details how threat actors abuse popular cloud storage services for illegal activities. The experts have analyzed a number of cloud storage services including Dropbox, Google Drive, Box, and Microsoft OneDrive.
The report shows how hackers exploit common file synchronization services for command and control (C&C) communications, remote access, data exfiltration and endpoint hacking by reconfiguring them.
The disconcerting consideration made the expert at Imperva is that attackers can gain access to file synchronization accounts without compromising victim’s credentials.
Let’s start with the fundamentals, synchronization services of cloud storage services work in a simple as effective way, when users add a file to the local repository on their device, the content of the repository is automatically synchronized with the central hub of the service provider.
To improve the user experience, the applications don’t require users to enter their account credentials each time the synchronization is performed, the service providers compensate with a transparent authentication mechanism that relies on a synchronization token.
The authentication token is usually stored in a file, a registry, or the Windows Credential Manager on the user’s device, but obviously something is not working as it should!
The experts explained that even if the tokens are encrypted on the local device, hackers can easily access and decrypt them to synchronize any device with the victim’s account.
The researchers have developed a tool to run Man-in-the-Cloud attacks through the manipulation of synchronization tokens, they explained that the tool can be delivered to the victim via phishing or drive-by download attacks.
Man-in-the-Cloud attacks are easy to run, in some cases attacks can maintain access to the compromised account installing a backdoor, the access will be granted even after victims change their password.
The expert noticed that in the case of Dropbox, the authentication tokens not change even if the password is changed, meanwhile Google Drive revokes all tokens and requires users to re-authenticate each device using account credentials following a password reset.
Man-in-the-Cloud attacks are particularly difficult to track because the malicious code is typically not left running on the targeted machine and data traffic to/from the cloud architecture normally doesn’t raise any suspicion.
According to Imperva, threat actors are already running Man-in-the-Cloud attack in the wild, last year expert at Blue Coat uncovered the Inception Operation and recently researchers at FireEye described the HAMMERTOSS attacks that involved the use of Twitter and GitHub for C&C communications, and cloud storage services for data exfiltration.
Let me suggest the reading the Imperva’s Hacker Intelligence Initiative report on Man-in-the-Cloud attacks.
Source: (Security Affairs – Man-in-the-Cloud, cloud)

lunes, julio 13, 2015

MacOSX Preview Exception after Microsoft Office 2011 uninstall

As many users out there I had the need to move my entire work to MacOSX over time. I've been a Mac Fan since early '90s with limited access to some of the best Apple's Hardware that we've seen.
Unfortunately that golden age is gone and we ended up with a good operating systems but with some security, privacy and operational issues as we move forward.
Last week I decided to remove my old Microsoft Office 2011 package from my laptop and as you can imagine is not that easy. There are several steps that go from remove Microsoft Office 2011 office folder from your app directory (easy part) to manually remove .plist and fonts directories from your library profile.
I've found this process extremely tedious but at the end after a few minutes I've accomplished my task, Office Suite has been completely removed from OS X.
After a few hours I received an email with a PDF file and I proceed to open it with the Mac OS X standard app "Preview" but as soon as I tried to do it I get an exception message with the following information:

"Application Specific Information:*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderSet initWithObjects:count:]: attempt to insert nil object from objects[0]'terminating with uncaught exception of type NSException"

I thought that was something related to that PDF file only, but after doing some research I realized that this was something even bigger than just a corrupted PDF file, Preview was not working at all.
I've went through a ton of different forums, even Apple support community recommended pointless steps to fix this issue but at the end I found that was an issue with my Fonts library caused by the uninstall process of Microsoft Office.
In order to fix this problem I tried to run the built-in health check tool from Font Book but was useless, so after make some research I came up with a workaround.

1) Download Microsoft Office 2011 .dmg image.
2) Install Pacifist Shareware application that opens Mac OS X .pkg package files, .dmg disk images, and .zip, .tar, .tar.gz, .tar.bz2, and .xar archives and allows you to extract individual files and folders out of them.
3) Open Pacifist, browse your Office 2011 .dmg file and open the image.
4) Look for the core components and within that section select the "All Fonts" package.
5) Click Install.

Once you have installed the fonts main package you should be able to open Preview again.

Just some additional comments, I've found that this particular exception may be caused not only for a wrong Office 2011 uninstall process but for some inconsistency with your fonts library or even a PDF corrupted file that stayed resident in memory. Please keep that in mind before proceeding with the remediation process and always have a snapshot from your time machine or a complete backup from your key files. 

martes, julio 07, 2015

Hacking Team used shockingly bad passwords



One of the biggest hacks of the year -- not just in scope and size, but impact -- is over. As reporters and interested parties sift through the debris of the attack that left Hacking Team crippled, a big question remains.
How was someone able to walk in and swipe what appears to be the company's entire cache of corporate data?
The company used weak passwords.
To recap: Hacking Team creates spyware and malware programs for law enforcement and intelligence agencies around the world, including the US. But data leaked from the company suggests its services were offered to oppressive regimes, likely in breach of sanctions. A day after the attack, the company confirmed it had been breached. On Tuesday, a person came forward claiming responsibility for the hack.
It didn't take long for those sifting through scores of the documents to discover how the hack might have happened. 
The root passwords for Hacking Team's servers were inexplicably weak for their purpose. One of the passwords was simply "P4ssword," which would've taken any advanced password cracker just minutes to crack.
Other passwords grabbed from Hacking Team founder Christian Pozzi included "wolverine" and "universo," and other variations of dictionary words like "Passw0rd".
In cybersecurity circles, it's generally accepted that humans are the weakest link in the chain. The most common slip-up is using a poor password that can be easily guessed by a dictionary or brute-force attack. 
As the company cleans up its systems and tries to rebuild, its malware samples are in the wild, making it significantly easier to counter ongoing or future surveillance. Hacking Team, for all intents and purposes, is ruined.
Or should we say, "ruin3d."
Source: ZDNET

martes, enero 27, 2015

Certificate Transparency

You might hear about "Certificate Transparency", but what is the main goal of this framework?
Just to set the bar, we know that certificates are issued by hundred of different CA across the globe to validate the identity of a company/person and to establish secure communication between two parties. Because there is not a centralised repository and service that can globally check whether these certificates truly belong to a company/person, we might find some spoof certificates issued by company xyz looking for to intercept user's communications and capture valuable information. We have seen this a lot within the last years and that's why we need some sort of new framework that help us to protect users and companies against this attack vector around certificates, and there is where "Certificate Transparency" shows up.
Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open to scrutiny by domain owners, CAs, and domain users. Specifically, Certificate Transparency has three main goals:
- Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
- Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
- Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.
Certificate Transparency satisfies these goals by creating an open framework for monitoring the TLS/SSL certificate system and auditing specific TLS/SSL certificates. This open framework consists of three main components, which are described below.
For further reference please visit: http://www.certificate-transparency.org