Darknet - The Darkside

Don`t Learn to HACK - Hack to LEARN. That`s our motto and we stick to it, we are all about Ethical Hacking, Penetration Testing & Computer Security. We share and comment on interesting infosec related news, tools and more. Follow us on Twitter, Facebook or RSS for the latest updates.

02 October 2014 | 2,650 views

OpenVPN Vulnerable To Shellshock Exploit

Check Your Web Security with Acunetix

So last week the big news was about the cross platform exploit in BASH that we covered in our article – Everything You NEED To Know About Shellshock Bug In BASH.

As mentioned in the comments, a certain combination of circumstances and configuration options can leave OpenVPN vulnerable to Shellshock.

OpenVPN Vulnerable To Shellshock Exploit

This could be a pretty serious issue as I’m sure there are thousands of OpenVPN servers sitting around fairly idle, that are unlikely to be updated and around about to get pwned. If the OpenVPN is using system level pre-auth with the auth-user-pass-verify option – they will be in trouble.

The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg. Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says.

Shellshock affected the crucial and ubiquitous *nix component Bash up to and including version 4.3. Mullvad chief technology officer Stromberg described the flaw in a forum post overnight, adding that he disclosed the vulnerability to OpenVPN sometime last week.

“OpenVPN servers are vulnerable to Shellshock under certain configurations,” Stromberg said. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client.

“One option used for username+password authentication is auth-user-pass-verify. If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username. This attack vector is pre-auth.”

There’s a whole list of Shellshock PoCs here on Github including the one for OpenVPN – Shellshocker PoCs. The exploit walkthrough is available here, including the OpenVPN config and log output – OpenVPN ShellShock PoC.

I’m honestly not sure how much impact this will actually have in the wild as to know that we’d have to know how common it is for OpenVPN systems to auth in this manner.

A proof of concept for the exploit has surfaced online. Those using OpenVPN can dodge Shellshock by preventing Bash from running scripts. OpenVPN’s Gert Doering told Threat Post OpenVPN was vulnerable only on systems where /bin/sh points to /bin/bash, or when scripts running bash as an interpreter were called explicitly.

“What you want to do from OpenVPN’s point of view is to ensure that you’re not using a 2.2.x version anymore, and that you just do not run your scripts using bash (#!/bin/bash) but use a shell that is better suited to script usage, like ash/dash,” Doering told the publication. “Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert.”

Vendors have released solid and borked patches for the Shellshock bug over the last week since the flaw was revealed. The patching prompted Blighty’s privacy watchdog to urge organisations patch their Bash instances

Apple has issued a patch for the smaller subset of affected users, while F5 has moved to stop holes in its line of BIG-IP products including the ARX, Enterprise Manager and BIG-IQ systems, but not FirePass or LineRate proxy systems. Stromberg in April identified the susceptibility of OpenVPN to the HeartBleed vulnerability.

The OpenVPN systems will only be vulnerable if /bin/sh points to /bin/bash and if they don’t use an alternative (more suitable) shell like ash/dash (which is the default shell in Debian systems).

There are also other vectors being exposed like QNAP NAS devices (which was one of my worries), anything Linux based with BASH that is unlikely to get updated is at fairly high risk:

Shellshock Attacks Hit Major NAS Kit; IoT Next?

Shellshock – the bug that just keeps on giving.

Source: The Register



29 September 2014 | 3,676 views

masscan – The Fastest TCP Port Scanner

masscan is the fastest TCP port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second.

It produces results similar to nmap, the most famous port scanner. Internally, it operates more like scanrand, unicornscan, and ZMap, using asynchronous transmission. The major difference is that it’s faster than these other scanners. In addition, it’s more flexible, allowing arbitrary address ranges and port ranges.

masscan - The Fastest TCP Port Scanner

NOTE: masscan uses a custom TCP/IP stack. Anything other than simple port scans will cause conflict with the local TCP/IP stack. This means you need to either use the -S option to use a separate IP address, or configure your operating system to firewall the ports that masscan uses.

PF_RING – Beyond 2 million packets/second

To get beyond 2 million packets/second, you need an Intel 10-gbps Ethernet adapter and a special driver known as “PF_RING DNA” from http://www.ntop.org/products/pf_ring/. Masscan doesn’t need to be rebuilt in order to use PF_RING. To use PF_RING, you need to build the following components:

  • libpfring.so (installed in /usr/lib/libpfring.so)
  • pf_ring.ko (their kernel driver)
  • ixgbe.ko (their version of the Intel 10-gbps Ethernet driver)

You don’t need to build their version of libpcap.so.

When masscan detects that an adapter is named something like dna0 instead of something like eth0, it’ll automatically switch to PF_RING mode.

Usage

Usage is similar to nmap. To scan a network segment for some ports:

This will:

  • scan the 10.x.x.x subnet, all 16 million addresses
  • scans port 80 and the range 8000 to 8100, or 102 addresses total
  • print output to that can be redirected to a file

To see the complete list of options, use the –echo feature. This dumps the current configuration and exits. This output can be used as input back into the program:

Banner checking

Masscan can do more than just detect whether ports are open. It can also complete the TCP connection and interaction with the application at that port in order to grab simple “banner” information.

The problem with this is that masscan contains its own TCP/IP stack separate from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before masscan can grab the banner.

The easiest way to prevent this is to assign masscan a separate IP address. This would look like the following:

The address you choose has to be on the local subnet and not otherwise be used by another system.

In some cases, such as WiFi, this isn’t possible. In those cases, you can firewall the port that masscan uses. This prevents the local TCP/IP stack from seeing the packet, but masscan still sees it since it bypasses the local stack. For Linux, this would look like:

On Mac OS X and BSD, it might look like this:

Windows doesn’t respond with RST packets, so neither of these techniques are necessary. However, masscan is still desigend to work best using its own IP address, so you should run that way when possible, even when its not strictly necessary.

The same thing is needed for other checks, such as the –heartbleed check, which is just a form of banner checking.

You can download masscan here:

1.0.3.zip

Or read more here.


26 September 2014 | 3,849 views

Everything You NEED To Know About Shellshock Bug In BASH

Shellshock (CVE-2014-6271) the bug in BASH is causing havoc on the Internet this week, as far as I’m concerned it’s a bit overstated – seriously how many people are still using cgi scripts? None I hope. I do suspect though a lot of shared hosts might get owned by this as most commercial control panel software installs a /cgi-bin/ and sometimes a script by default.

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

Shellshock Bug In BASH

We’ve been so focused on buffer overflows and memory stack bugs during the past decade, we’re currently getting owned by bugs from the 90s – which once again shows the need for proper code auditing on Open Source projects (and donations/budget allocations for such activities).

The other risk profile I see exposed here is devices like routers/proxy boxes and so on that use some type of trimmed down regular Linux with BASH. I’ve seen some comments from the embedded community that this shouldn’t be an issue for them as they tend to use BusyBox which is not vulnerable.

To test for the vulnerability on your *nix systems just issue the following command as any user (doesn’t have to be root):

If you see this:

It’s vulnerable, if it’s fixed or not vulnerable you should see this:

As far as the risk, I definitely don’t think it’s a 10/10 risk vulnerability, although there already 2 worms in the wild exploiting this bug to build botnets. I don’t think any reasonably well secured server will fall foul to this though, even without BASH updated it shouldn’t be an issue.

But if you do find a vulnerable system with a cgi script, it’s trival to exploit and get a reverse shell with code such as this:

I pretty much exclusitely use nginx so I don’t have the issues many will have, if you use Apache and have mod_cgi enabled – you may well be in trouble. Look out for servers with FTP/Telnet/Apache with something like Masscan and sort them out as your primary/production systems are pretty safe without any updates/changes.

Some views/updates from others:

The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash.

The Register

It can be exploited by attackers looking to override or bypass environment restrictions to execute shell commands, i.e. unauthorized, malicious code.

The flaw is deemed critical for many reasons. For one, the number of affected devices is huge: think about all the web servers (including Apache ones) and embedded devices (routers, etc.) running on Linux, Mac computers… The number could very well be in the hundreds of millions.

Secondly, the US-CERT and NIST gave it the maximum score (10.0) for both impact and exploitability. Exploitation of the flaw can lead to unauthorized disclosure of information, unauthorized system access and modification, and disruption of service, and the exploitation process is extremely short and simple: it takes just a few lines of code.

Helpnet Security

According to several security firms, attackers are already probing systems for the weakness, and that at least two computer worms are actively exploiting the flaw to install malware. Jamie Blasco, labs director at AlienVault, has been running a honeypot on the vulnerability since yesterday to emulate a vulnerable system.

“With the honeypot, we found several machines trying to exploit the Bash vulnerability,” Blasco said. “The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system. This malware turns the systems into bots that connect to a C&C server where the attackers can send commands, and we have seen the main purpose of the bots is to perform distributed denial of service attacks.”

Krebs on Security

Today’s bash bug is as big a deal as Heartbleed. That’s for many reasons.

The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.

The second reason is that while the known systems (like your web-server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable. These systems are rarely things like webservers, but are more often things like Internet-enabled cameras.

Robert Graham

If you are running Mac OS X it’s not so trivial to fix, even if you run Homebrew, updating that will only update Homebrew BASH and not system BASH which still leaves you vulnerable if you have any public web services. If you don’t run any public web services from your Mac (like most people) you don’t have much to worry about. Some reading:

How to patch Bash on OSX in wake of “shellshock”?
How to patch your vulnerable OS X to latest bash issue (for advanced users)

If you running Ubuntu on your production systems (like me) the update/patch is trivial:

If you only want to upgrade BASH and not mess with your packages then just do:

The reboot might not strictly be necessary, but honestly I prefer to be safe than sorry.

So what’s the downlow? Are a lot of huge websites going to get owned and is half the Internet going to go dark? No. Are a lot of old devices/servers/unloved pieces of equipment/shared hosting servers going to get owned and turned into members of Botnets? Yes most likely.

Is this going to effect the average consumer? No not really, does it effect the average company? Probably yes it will, but not at the core of your production systems which should be fairly immune to this vulnerability.

But it’s fairly easy to patch, so why not – if you can do it without disrupting your business too much – just patch.

We’ll have to wait a couple of weeks to see where this really goes, and see if it’s really as disruptive as Heartbleed was.


24 September 2014 | 1,356 views

drozer – The Leading Security Testing Framework For Android

drozer (formerly Mercury) is the leading security testing framework for Android. drozer allows you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS.

drozer - Android Security Testing Framework

drozer provides tools to help you use, share and understand public Android exploits. It helps you to deploy a drozer Agent to a device through exploitation or social engineering. Using weasel (MWR’s advanced exploitation payload) drozer is able to maximise the permissions available to it by installing a full agent, injecting a limited agent into a running process, or connecting a reverse shell to act as a Remote Access Tool (RAT).

drozer helps to reduce the time taken for Android security assessments by automating the tedious and time-consuming. In a way you could think of drozer as Metasploit for Android devices.

  • Discover and interact with the attack surface exposed by Android apps.
  • Execute dynamic Java-code on a device, to avoid the need to compile and install small test scripts.

Features

  • Discover Installed Packages
  • Send Intents to IPC Endpoints
  • Broadcast Intents
  • Access Databases from other Apps
  • Interact with Services in other Apps
  • Arbitrary Java Execution
  • Run an Interactive Shell
  • Access a device with Remote Exploits
  • Root Privilege Escalation
  • Command-line Interface
  • Use drozer with Physical Devices
  • Use drozer with Android Emulators

You can download drozer here:

Windows installerdrozer-installer-2.3.3.zip
Debian/Ubuntu (.deb)drozer_2.3.3.deb
Redhat/CentOS (.rpm)drozer-2.3.3-1.noarch.rpm

Or read more here.


23 September 2014 | 1,473 views

CloudFlare Introduces SSL Without Private Key

Handing over your private key to a cloud provider so they can terminate your SSL connections and you can work at scale has always been a fairly contentious issue, a necessary evil you may say.

As if your private key gets compromised, it’s a big deal and without it (previously) there’s no way a cloud provider or load balancing service could terminate your SSL connections and complete the secure handshake with a users browser.

CloudFlare Introduces SSL Without Private Key

Until now, CloudFlare presents a fairly intelligent solution – which has taken them 2 years to develop – but solves most problems with the current situation.

Content delivery network and web security provider CloudFlare has introduced a new feature that allows customers to take advantage of the company’s solutions without ever having to hand over their private SSL keys.

Private SSL keys are highly sensitive because they can be leveraged by a malicious actor to spoof an organization’s identity and intercept traffic. That is why, over the past two years, CloudFlare has been working on introducing keyless SSL.

The idea emerged after CloudFlare had a meeting in the fall of 2012 with representatives of a major bank, which at the time was targeted with distributed denial-of-service (DDoS) attacks by alleged Iranian hackers of the Izz ad-Din al-Qassam Cyber Fighters group.

“The bankers all acknowledged what they needed was a cloud-based solution that could scale to meet the challenges they faced. Unfortunately, since they needed to support encrypted connections, that meant the cloud-based solution needed to terminate SSL connections,” Matthew Prince, the CEO and co-founder of CloudFlare, wrote in a blog post.

Losing an SSL key is considered a critical security event which, as Prince describes it, could turn into a “nightmare,” and financial institutions can’t afford to take such risk. CloudFlare has been working since the 2012 meeting with the bank representatives on finding a practical way of helping organizations benefit from the cloud without the need to take possession of their SSL keys.

I honestly think the whole SSL certificate process is pretty broken, really it needs a major rework – but I’m not exactly sure what the solution is. At least what CloudFlare has come out with is a solution to one part of the problem.

It seems fairly obvious in some ways, run an agent inside the secure infrastructure of the client, have very limited access to the agent to access the key. But it’s always obvious when someone else thought of it, isn’t it?

One of CloudFlare’s engineers came up with a solution by the next day, but it took two years to perfect the solution and make it secure, fast and scalable.

“To make it work, we needed to hold connections open between CloudFlare’s network and agents running on our customers’ infrastructure. Moreover, we needed to share data about crytographic sessions setup for a visitor between all the machines that could serve that visitor,” Prince explained. “Making it work was one thing, making it fast was another. And, today, Keyless SSL clients are experiencing 3x+ faster SSL termination globally using the service than they were when they were relying only on on-premise solutions.”

On Friday, CloudFlare security engineer Nick Sullivan published a blog post providing technical details on how they’ve managed to achieve keyless SSL.

“We’ve seen how private keys can be stolen, and investing in techniques to limit their exposure makes the Internet a safer place. Our review of Keyless SSL indicates the keys themselves do not leave your infrastructure, and a secure channel with CloudFlare both protects the communication and reduces the attack surface for your key,” a spokesperson from NCC Group’s Cryptography Services group commented.

“One of the core principles of computer security is to limit access to cryptographic keys to as few parties as possible, ideally only the endpoints. Application such as PGP, Silent Circle, and now Keyless SSL implement this principle and are correspondingly more secure,” Jon Callas and Phil Zimmermann of encrypted communications firm Silent Circle said in a joint statement.

There’s a nice technical post with details of the implementation here: Keyless SSL: The Nitty Gritty Technical Details

It’s only just been launched, so it’s too early to see if anyone has figured out how to hack it yet. As obviously, if the agent can be discovered and is insecure – it can compromise the client infrastructure and the private key.

Source: SecurityWeek


20 September 2014 | 3,799 views

tinfoleak – Get Detailed Info About Any Twitter User

tinfoleak is basically an OSINT tool for Twitter, there’s not a lot of stuff like this around – the only one that comes to mind in fact is creepy – Geolocation Information Aggregator.

tinfoleak is a simple Python script that allow to obtain:

  • basic information about a Twitter user (name, picture, location, followers, etc.)
  • devices and operating systems used by the Twitter user
  • applications and social networks used by the Twitter user
  • place and geolocation coordinates to generate a tracking map of locations visited
  • show user tweets in Google Earth!
  • download all pics from a Twitter user
  • hashtags used by the Twitter user and when are used (date and time)
  • user mentions by the the Twitter user and when are occurred (date and time)
  • topics used by the Twitter user

tinfoleak

You can filter all the information by:

  • start date / time
  • end date / time
  • keywords

You can download tinfoleak here:

tinfoleak-1.2.tar.gz

Or you can read more here.


18 September 2014 | 727 views

Twitter Vulnerability Allows Deletion Of Payment Details

Twitter has been in the news a lot lately, firstly about their patent filing regarding the pro-active scanning on the web for malware and then the bug bounty going live – which is related to this story.

This is a pretty neat Twitter vulnerability that was discovered by someone taking part in the Twitter bug bounty program that we wrote about earlier this month.

Twitter Vulnerability

It’s not a massively dangerous vulnerability, in terms of the average Twitter user – but it could have been very disruptive to Twitter itself if undiscovered as a malicious user could have removed payment details from any account it could find the username/account ID for.

A researcher has uncovered a vulnerability on one of Twitter’s subdomains that could have been exploited to delete all the payment cards used by customers to pay for advertisements.

Companies and individuals that want to run ad campaigns on Twitter’s platform are required to add a payment card to their account. Egyptian security researcher Ahmed Aboul-Ela discovered multiple Insecure Direct Object Reference flaws that could have been leveraged by an attacker to delete the cards associated with Twitter Ads.

Aboul-Ela identified the first vulnerability after analyzing the POST request sent to the server when the “Delete this card” button is clicked. The request contained the parameters “account,” the ID of the Twitter account, and ” id,” a 6-digit number associated with the customer’s credit card. By changing the value of these parameters to one of a different account he owns, the researcher managed to delete the card.

While this method required the attacker to know the targeted user’s Twitter account ID, the second vulnerability found by the Egyptian expert is far easier to exploit.

It would be fairly trivial to write a brute force script to delete all cards from all accounts and effectively halt all Twitter advertising campaigns, which would save a lot of people money, and cost Twitter a lot of money.

But the vulnerability was disclosed responsibly and fixed two days after it being divulged to Twitter, the researcher received $2,800 for this vulnerability, which is a fairly respectable amount.

If users add invalid credit cards to their Twitter Ads accounts, they’re presented with two options: try to add the card again, or dismiss it. Dismissing a card is the same as deleting it, and the researcher soon realized that he could perform this action on valid cards already added to accounts. After analyzing the POST request, Aboul-Ela found that unlike the previous attack method, this one only required the attacker to know the 6-digit ID associated with the card.

“Imagine a blackhat hacker that could write a simple Python code and use a simple for loop on 6 numbers he could delete all credit cards from all Twitter accounts which will result in halting all the Twitter ads campaigns and incur big financial loss for Twitter,” the researcher explained in a blog post.

Aboul-Ela said Twitter addressed the vulnerabilities within two days after being notified. The company rewarded him with a $2,800 bounty.

Twitter has been running a bug bounty program on the HackerOne platform for the past three months, but at the beginning of September, the company decided to start handing out monetary rewards for researchers who contribute to making the service more secure. The minimum reward is $140, but a maximum limit has not been set. The bounty paid by Twitter to Aboul-Ela is the largest so far.

It’s good to see some interesting stuff coming out of the Twitter bug bounty program and I hope to see more, especially things like this which are pretty clever edge case scenarios that developers really wouldn’t think of addressing.

More companies should be running more effective bug bountry programs and securing them against potentially devastating attacks like this.

Source: Security Week


16 September 2014 | 1,439 views

StegExpose – Steganalysis Tool For Detecting Steganography In Images

StegExpose is a steganalysis tool specialized in detecting steganography in lossless images such as PNG and BMP (LSB – least significant bit type). It has a command line interface and is designed to analyse images in bulk while providing reporting capabilities and customization which is comprehensible for non forensic experts.

Steganography is the art or practice of concealing a message, image, or file within another message, image, or file. The word steganography combines the Ancient Greek words steganos, meaning “covered, concealed, or protected”, and graphein meaning “writing”.

StegExpose rating algorithm is derived from an intelligent and thoroughly tested combination of pre-existing pixel based staganalysis methods including:

  • Sample Pairs by Dumitrescu (2003)
  • RS Analysis by Fridrich (2001)
  • Chi Square Attack by Westfeld (2000)
  • Primary Sets by Dumitrescu (2002)

In addition to detecting the presence of steganography, StegExpose also features the quantitative steganalysis (determining the length of the hidden message).

Detecting Steganography In Images

Usage

[directory] – directory containing images to be diagnosed

[speed]Optional. Can be set to ‘default’ or ‘fast’ (set to ‘default if left blank). default mode will try and run all detectors whereas fast mode will skip the expensive detectors in case cheap detectors are able to determine if a file is clean.

[threshold]Optional. The default value here is 0.2 (for both speed modes) and determines the the level at which files are considered to be hiding data or not. A floating point value between 0 and 1 can be used here to update the threshold. If keeping false positives at bay is of priority, set the threshold slightly higher ~0.25. If reducing false negatives is more important, set the threshold slightly lower ~0.15

[csv file]Optional. Name of the csv (comma separated value) file that is to be generated. that If left blank, the program will simply output to the console.

Performance

The accuracy and speed of StegExpose has been tested on an image pool of 15,200 lossless images, where 5,200 of them were stego images (images with hidden data) created with the tools OpenStego, OpenPuff, SilentEye and LSB-Steganography. Embedding rates range from 2.5% to 25.3% with an average of 13.8% (secret data / cover image).

You can download StegExpose here:

master.zip

Or read more here.


13 September 2014 | 2,461 views

Google DID NOT Leak 5 Million E-mail Account Passwords

So a big panic hit the Internet a couple of days ago when it was alleged that Google had leaked 5 Million e-mail account passwords – and these had been posted on a Russian Bitcoin forum.

I was a little sceptical, as Google tends to be pretty secure on that front and they had made no announcement regarding the incident. The news was published on a number of fairly high profile, legitimate news sources as though it was real (TIME, CBS, FastCompany, IBT, The Independent & many more).

Google Password Leak

Some may say the whole thing was just an elaborate e-mail farming excercise as many articles cited a domain IsLeaked.com which registered a mere 2 days before the huge password leak..by Russians.

Plenty of room for conspiracy theories here.

In some cases, those alleged breaches are not quite what they seem to be. Case in point is a report first posted to a Russian Bitcoin forum site that information on nearly 5 million Google account holders was breached this week.

Any alleged attack against Google is noteworthy, and 5 million accounts is also a significant number. That said, the bigger questions that always should be asked in any breach coverage center on what was stolen and whether there is any real impact.

As a professional, facts are my currency, and speculation is just a cheap narcotic. So when I initially saw the first Google account breach reports, I held off on writing until the facts were revealed.

The facts are that Google itself was not breached and 5 million users are not actually at risk.

In a blog post Sept. 10, Google claimed that less than 2 percent of the username/password credentials in the Russian breach list were actually valid.

To add further fuel to the fire, Google noted that its automated anti-hijacking systems would limit the risk on the 2 percent that might be affected. Additionally, Google is now telling those people in the 2 percent list that they are required to reset their passwords.

Google did release something later about this ‘compromise’ and stated that less than 2% of the leaked e-mail addresses were valid credentials and all those that might have been effected have had their passwords forcibly reset.

The Google announcement is here: Cleaning up after password dumps

They also stated categorically that the leaked account details were not due to a compromise of any Google systems.

So to recap, it wasn’t 5 million “real” passwords, and of those that might be real, there is little user risk. It also was not actually an attack directly against Google’s infrastructure either.

“It’s important to note that, in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems,” Google stated. “Often, these credentials are obtained through a combination of other sources.”

So what does that mean? Simply put, Google account information is also used on non-Google systems and also might be stored outside of Google’s control or influence. An attacker can get a user account by a breach of a third-party system or more likely via a phishing attack against a user.

In this case, Google has made it painfully obvious that the risk is low with this credentials breach. Aside from the fact that only 2 percent of the account information might be valid, Google’s efforts to protect its users and its systems from attacks are exemplary. Alerting users to the potential of a highjack and requiring a new password is an excellent best practice.

The use of other security tools and techniques to detect anomalous account behavior is also admirable. As I’ve written in the case of the Apple iCloud security incident, it is incumbent on Internet vendors and online services to proactively defend users against fraud, and that’s precisely what Google is doing.

So basically yah, this is a whole lot of non-news about something that didn’t really happen. Either way, keep your accounts safe and set up 2FA please.

But it does show once again, Google is up on the security of its userbase and it intends to keep everyone safe. Because they need your data, that’s how they make money.

Source: eWeek


11 September 2014 | 2,706 views

Lynis v1.6.0 Released For Download – Linux Security Auditing Tool

Lynis is an open source linux security auditing tool. The primary goal is to help users with auditing and hardening of Unix and Linux based systems. The software is very flexible and runs on almost every Unix based system (including Mac). Even the installation of the software itself is optional!

It’s a great tool for auditing *nix based systems and hardening them based on the recommendations, it works well on a variety of systems including Linux, AIX, FreeBSD, OpenBSD, Mac OS X & Solaris.

Lynis - Linux Security Auditing Tool

We’ve written about this tool a few times, when it first came out in 2008 – Lynis – Security & System Auditing Tool for UNIX/Linux and again in 2009 – Lynis 1.2.6 Released – UNIX System & Security Auditing Tool.

How it works

Lynis will perform hundreds of individual tests to determine the security state of the system. Many of these tests are also part of common security guidelines and standards. Examples include searching for installed software and determine possible configuration flaws. Lynis goes further and does also test individual software components, checks related configuration files and measures performance. After these tests, a scan report will be displayed with all discovered findings.

Typical use cases for Lynis:

  • Security auditing
  • Vulnerability scanning
  • System hardening

Why open source?

Open source software provides trust by having people look into the code. Adjustments are easily made, providing you with a flexible solution for your business. But can you trust systems and software with your data? Lynis provides you this confidence. It does so with extensive auditing of your systems. This way you can verify and stay in control of your security needs.

You can download Lynis v1.6.0 here:

lynis-1.6.0.tar.gz

Or read more here.