Saturday, March 25, 2017

Cyber Updates - 25/03

Hey all,
Here are this week's cyber updates:

(1) For those of you who haven’t noticed, last week WikiLeaks has disclosed several exploits allegedly used by the CIA. A thorough analysis of the exploits has revealed a vulnerability (CVE-2017-3881) in Cisco devices, allowing remote unauthenticated users to execute code on numerous Cisco devices.
While the vulnerability exists in the Cluster Management Protocol, Cisco devices in their default configuration are also vulnerable (even if no cluster configuration was set).
According to Cisco, the vulnerability exists due to the combination of two factors:
The failure to restrict the use of CMP-specific Telnet options only to internal, local communications between cluster members and instead accept and process such options over any Telnet connection to an affected device, and
The incorrect processing of malformed CMP-specific Telnet options.
To date, Cisco has yet to issue a patch, thus causing numerous Cisco devices (listening on the Telnet protocol) to remain vulnerable.
Organizations that use Cisco devices are urgently requested to block Telnet access to all Cisco devices.

Here are all the details:

(2) A hacking group, known as the “Turkish Crime Family”, have claimed to hack numerous iCloud accounts. The group has threatened Apple that they will wipe more than 200 million accounts if their ransom demand is not paid by April 7th. 
Apple has claimed that there was no evidence of their system being hacked, but couldn’t rule out that 3rd party websites were hacked and that users have reused their passwords for their Apple ID.

In any case, it is advised to change your Apple ID password as a precaution.

Here are all the details:

(3) Google Chrome has begun distrusting Symantec Extended Validation certificates after the company was caught improperly issuing EV certificates.
The EV status of Symantec CA will no longer be recognized by the Chrome browser for at least a year, until Symantec fixes its certificate issuance processes so that it can be trusted again.
Whether Google wants to make the internet safer, or wants to push clients into using their own CA, clients would definitely think twice in the near future before issuing an EV certificate from Symantec.

Here are all the details:

Stay tuned for more updates,

Dan Gurfinkel
Head of Offensive Security & Response Unit

Monday, March 20, 2017

Monday tech: Bypassing Google ReCaptcha 2.0

Hi everyone
Last week I talked about cracking regular CAPTCHAs, but the world is moving on to a more user friendly mechanisms, so this week I want to discuss Google ReCAPTCHA 2.0 bypassing.

2 and a half years ago at December 2014, Google made a (yet another) revolution, this time in the world of CAPTCHA. Till then, everyone used the deformed-letters CAPTCHAs classic method as pretty much the only common way to tell humans and bots apart. This (as well as audio-CAPTCHAs) was the only common way. Google used it in ReCAPTCHA version 1.0.

But Google knows a lot about us, our identity and surf habits, and they decided to use this information in order to create a No-CAPTCHA ReCAPTCHA risk analysis engine, which calculates multiple factors such as user behavior attributes, location, threshold, identity attributes (for signed-in Google accounts), browsing history and others, in order to decide whether to let the user continue without solving any challenge, or to show a visual or audio challenge. This ultimately uses cookies for both logged in and unauthenticated users.
This engine is risk based and therefor bots and bypass it with some degree of success. Bots can also bypass poor classic CAPTCHAs using OCR (optical character recognition), but the big question was: is Google’s ReCAPTCHA 2.0 is less secured?
As soon as Google published the new mechanism, hackers and researchers started testing it and finding multiple ways to bypass it.
For example:

This research uses both multiple tools including valid cookie creation, deep learning, reverse image search. Deep learning and artificial intelligence for solving reCAPTCHA 2.0 are algorithms that automatically identify an image’s content. There are multiple services that allows you to do it, one even ironically include Google’s own services in the Google reverse image search technique: You take the ReCAPTCHA 2.0 image and send it to Google in order to get keywords describing the image, titles from pages containing the image, higher resolution images and translation of non-English pages to English.
Recently a new similar technique was published, that uses Google voice recognition engine in order to bypass the audio CAPTCHA of ReCAPTCHA 2.0:

So the bottom line: Is ReCAPTCHA 2.0 more human friendly? Definitely. But is it more secured than regular CAPTCHA? Depending on the exact implantation, but if you compare it to ReCAPTCHA 1.0 - probably not.
But as in many cases, you need to find the balance between usability and security, and since the regular malformed characters CAPTCHAs are not usable, ReCAPTCHA 2.0 is a reasonable solution we can safely recommend. The future of bot-humans separation is rapidly moving to risk-based algorithms, and Google and also Facebook lead the way.

Google keeps learning from the new bypassing techniques that are published from time to time, and they keep improving their algorithms.
But even if Google will solve the latest ReCAPTCHA bypassing techniques, people will still want to bypass CAPTCHAs and ReCAPTCHA 2.0 specifically, and still offer payment to bypass it.
In if there is a demand, someone will fill in this demand.
Here is a ReCAPTCHA bypass service that offers 1000 CAPTCHAs bypass for as little as 1.2-3$, that has no patch. Why? Because the CAPTCHAs are actually solved by humans.
And there’s no solution for humans-based solving services.

Have a great week

Gil Cohen

Saturday, March 18, 2017

Cyber Updates - 18/03

Hey all,
Here are this week's cyber updates:

(1) Check Point has discovered a bug in the web versions of Whatsapp and Telegram. In particular, both applications do not properly parse images, allowing malicious HTML code to be executed within the Whatsapp/Telegram domain. This allows the attacker to steal the user’s data from the local storage, hence allowing the attacker to authenticate themselves on behalf of their victim.
Both Whatsapp and Telegram have announced they did not see an account being compromised by this exploit. However, since both apps use end-to-end encryption, these companies have no way of guaranteeing it nor can they block it on the server side.

(2) The next time you buy a phone, don’t expect it to be malware-free. Android phones (brands such as Galaxy or Nexus) have been found to be distributed with pre-loaded malware. While you would expect these phones to be bought without a malware, somewhere in the supply chain a spyware has been added to the firmware.
The spyware allows the attacker to install further malicious apps on the device, dial premium numbers and delete the user’s data.

(3) Microsoft has finally patched the notorious SMBv3 vulnerability. For those of you who don’t remember, two months ago a vulnerability in SMBv3 has been discovered that can possible permit remote code execution. A PoC code for denial of service was made available and exploited in the while.
For nearly 2 months Windows-based systems were not patched (as Microsoft has not solved this issue on their February “Patch Tuesday” updates).
Organizations are urged to update their Windows operating systems as soon as possible.

Stay tuned for more updates,

Dan Gurfinkel
Head of Offensive Security & Response Unit

Thursday, March 16, 2017

Cosmec made it to the IT TOP STARS Index!

At a conference held last week, TOP STARS IT index, a customer satisfaction index of IT services was launched for the first time in Israel. 
According to the production, this is the most comprehensive study conducted for the first time amongst hundreds of CIOs, IT managers and professionals, working in a variety of large and medium size organizations in Israel. The study was conducted by the accounting and business consultancy firm BDO with the participation of senior CIOs.
Together with two other companies, Cosmec came in first in the customer satisfaction category in providing information security services in Israel for year 2016!

Enat Malca
Marketing Manager |

Monday, March 13, 2017

Monday tech: Testing and bypassing CAPTCHAs

Hello everyone
My name is Gil Cohen, and I'm the CTO of Comsec.
For more than a year now, I publish internal technical emails to Comsec's consultants once every week.

Now I'm strarting a new tradition and start to publish these posts in Comsec's blogs. 
This week's first post will talk about breaking and testing CAPTCHAs.
We all know the annoying CAPTCHAs that are intended to stop automated scripts from overloading web interfaces.
As Pentesters, you need to check whether a CAPTCHA was implemented correctly or not. From my experience, I’ve written a CAPTCHA checking methodology of 8 different ways to bypass CAPTCHA. You need to do the steps in the order they are written as the first steps are easier to test and faster to bypass the CAPTCHA with.

Here are the 8 steps of CAPTCHA hacking:

  1. Client side CAPTHCA value: The first test is to check whether poor CAPTCHA implementation transmit the correct CAPTCHA value to the client side.
    I’ve seen several examples of CAPTCHA picture names that contained the answers, CAPTCHA validation that is being executed at the client side in JavaScript, and other funny client-related cases.

  2. Correctness flag (in the client side and the session): This searches for poor implementation where CAPTCHA correction flag (a Boolean indicating that the user guessed the CAPTCHA correctly or not) is transferred to the client either in the URL (something like, in the cookie or anywhere else. In addition there are buggy implementations of CAPTCHA that actually doesn’t initialize the correctness flags between guesses. You guess a CAPTCHA once, the session in the server side marks your session as a valid one and never checks any additional CAPTCHA value. Rare but can happen.
  3. CAPTCHA reuse: In this step you search for CAPTCHA implementation that fails to correctly initialize the correctness flag. Let’s say you have a contact-us page, that has a CAPTCHA in it, that is being loaded in a different HTTP request (for a picture - A very common practice), and this other request initialize all of the server side variables.
    So you might be able to correctly guess one CAPTCHA value, intercept and drop any other CAPTCHA creation request, and just reuse the correct first value again and again and again.
    The bug is that the correctness flag should be set to “CAPTCHA was not guessed correctly” upon CAPTCHA validation, not (only) upon CAPTCHA creation.
    When the contact-us form is submitted, the server should validate it and immediately flag the current session is non-CAPTCHA valid, no matter what the result is.
    If this is not done right after the validation and is only done in the CAPTCHA creation request, you can reuse values.
  4. CAPTCHA Replay: This step is very similar to the previous one, except the technical part where you don’t reuse a CAPTCHA value and send an additional request from the application’s GUI, you replay a valid request and send an identical copy of it again and again. Why do you need both steps? Because sometimes client values can change and affect this behavior – for example ViewState can be changed between requests. In rare cases you’ll see that CAPTCHA reuse is not working but replay is, so you have to test both.
  5. NULL\Empty CAPTCHA values: This nice step searches for poor implementation of unexpected missing input. Let’s say you have a parameter of the CAPTCHA value that is sent from the client to the server, and you have a client Javascript code that validates that the user inserts a value.
    What happens if the CAPTCHA value is empty? (You intercept it and drop the value) And what happens if you remove the CAPTCHA parameter name and value altogether? Can you bypass the CAPTCHA mechanism this way?
    In this step you have to first intercept and drop any CAPTCHA creation request (see CAPTCHA reuse), and then send an empty or non-existing value to check the behavior.
    There can be cases of NULL equals NULL (CAPTCHA was never created and was never sent to the server) which is true, or the case that allowed me to bypass all of the CAPTCHAs of the Israeli government websites, where there was a Boolean CAPTCHA correctness flag that was mistakenly initialized to true value, and when no CAPTCHA value was sent, the validation was never executed and the variable remained with the initial true value that allowed CAPTCHA bypass.
  6. CAPTCHA Repository: In this step you check whether CAPTCHAs are generated dynamically and randomly, or is there a repository of CAPTCHAs. If there is a repository, you can know the value by other characteristics of the image – for example a value of a certain Pixel or the HASH value of the binary data of the picture. I once found a repository in a gaming company’s system.
  7. CAPTCHA Reading: In this step you exploit accessibility features to bypass the CAPTCHA. If for example you have  feature that reads CAPTCHA value, you can test whether characters are being read in an identical form or not. In this example you can see that the values 0, 8, 2, 5 and 5 was being read, and that the 2 fives are identical, meaning you can guess the Correct value by inspecting the audio flow.
  8. CAPTCHA Optical Character Recognition: The last step that you try if all other step fails, is to pass the CAPTHCA image to an optical characters recognition algorithm. If the CAPTCHA image is not complicated enough, you can try to extract the value from it.
In the next post I’ll discuss Google’s ReCAPTCHA 2.0.

Have a great week :)