(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Yahoo CEO Marissa Mayer said she'll forgo her 2016 bonus and any stock award for this year after the company admitted it failed to properly investigate hack attacks that compromised more than a billion user accounts.

"When I learned in September 2016 that a large number of our user database files had been stolen, I worked with the team to disclose the incident to users, regulators, and government agencies," she wrote in a note published Monday on Tumblr. "However, I am the CEO of the company and since this incident happened during my tenure, I have agreed to forgo my annual bonus and my annual equity grant this year and have expressed my desire that my bonus be redistributed to our company’s hardworking employees, who contributed so much to Yahoo’s success in 2016."

Her note came as Yahoo for the first time said that outside investigators identified about 32 million accounts for which forged browser cookies were used or taken in 2015 and 2016. The investigators said some of the forgeries were connected to the same nation-sponsored attackers who compromised Yahoo in 2014. The cookies tied to the forgeries have since been invalidated. Yahoo also said that the 2014 attacks targeted 26 specific accounts by exploiting the company’s account management tool. The company went on to say unnamed senior executives failed to grasp the extent of the breach early enough.

Read 3 remaining paragraphs | Comments

 

Enlarge (credit: Palo Alto Networks)

It's a mystery that left researchers scratching their heads: 132 Android apps in the official Google Play market attempted to infect users with... Windows malware.

The apps, which were spawned by seven different developers, mostly contained carefully concealed HTML-based iframe tags that connected to two heavily obfuscated malicious domains. In one case, an app didn't use iframes but instead used Microsoft's Visual Basic language to inject an entire obfuscated Windows executable into the HTML. The apps were equipped with two capabilities. One was to load interstitial ads, and the other was to load the main app. The main apps loaded WebView components that were configured to allow loaded JavaScript code to access the app's native functionality.

That was a lot of work considering that the Windows-based malware was incapable of executing on an Android device. On top of that, the two malicious domains in the iframes—brenz.pl and chura.pl—were taken over by Polish security authorities in 2013. So what, precisely, was going on?

Read 3 remaining paragraphs | Comments

 

At a recent penetration test, one of typical tests that everyone runs these days are available TLS/SSL ciphers. There are many tools that can be used for this I personally prefer nmaps ssl-enum-ciphers script, which does a great job on ranking ciphers similarly to what SSL Labs do (but you can run it on any port and on internal sites as well). A lot of people use testssl.sh, which is very nice as well.
I was going through results of a scan and noticed something weird weak ciphers were reported for TCP port 389, which is LDAP. This actually caused me to think it is a false positive, but then having such a false positive with nmap was unusual so I decided to dig deeper (read: thing that SANS ISC Handlers love the most: look into packets).
Heres the output of the nmap script:

$ nmap -sT -Pn -p 389 10.0.161.5 --script ssl-enum-ciphers

Starting Nmap 7.40SVN ( https://nmap.org ) at 2017-03-01 21:06 CET
Nmap scan report for rhea.zoo.local (10.0.161.5)
Host is up (0.00036s latency).
PORT    STATE SERVICE
389/tcp open  ldap
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 1024) of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: C

As shown above its certainly TCP port 389 and yet we have ciphers properly detected. Initially I thought this must be some kind of STARTTLS, which allows one to take an existing insecure connection and upgrade it to a secure connection using SSL/TLS. STARTTLS is very common on SMTP but here were talking about LDAP.
After doing a network capture I went to analyze packets and, since we width:600px" />

We can see that a specific OID is being requested here: LDAP_START_TLS_OID (1.3.6.1.4.1.1466.20037). This request basically tells the LDAP server STARTTLS width:600px" />

After this the packet capture shows normal SSL/TLS continuation where Client Hello, Server Hello and all other required packets are exchanged.
The listing above shows also a lot of ciphers which are today not considered secure or best practice.

However, before blindly screaming SSLv3 and POODLE, it should be noted that exploitation of this vulnerability requires the attacker (besides performing a MitM attack) to be able to make the client send some arbitrary requests (so proper padding can be provoked), which might not be that easy or possible for protocols such as LDAP but Ill leave this for a future diary.

--
Bojan
INFIGO IS
@bojanz

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Libgd CVE-2016-6912 Security Bypass Vulnerability
 
Linux Kernel CVE-2016-9806 Local Denial of Service Vulnerability
 
Linux Kernel CVE-2017-2584 Denial of Service Vulnerability
 
Linux kernel 'ip_sockglue.c' Denial of Service Vulnerability
 
Linux Kernel 'kernel/ptrace.c' Local Privilege Escalation Vulnerability
 
QEMU 'hw/usb/hcd-xhci.c' Denial of Service Vulnerability
 
Siemens RUGGEDCOM NMS CVE-2017-2682 Cross Site Request Forgery Vulnerability
 
Siemens RUGGEDCOM NMS CVE-2017-2683 HTML Injection Vulnerability
 
MuPDF 'pdf-object.c' Use After Free Denial of Service Vulnerability
 
Artifex MuPDF CVE-2017-5991 Null Pointer Dereference Denial of Service Vulnerability
 
Joomla com_publication Component - 'sid' Parameter Sql Injection Vulnerability
 
Joomla com_news Component - 'id' Parameter Sql Injection Vulnerability
 
Joomla com_frontpage Component - 'Itemid' Parameter Sql Injection Vulnerability
 
Joomla com_filecabinet Component - 'id' Parameter Sql Injection Vulnerability
 
Joomla com_webgrouper Component - 'Itemid' Parameter Sql Injection Vulnerability
 
[SECURITY] [DSA 3798-1] tnef security update
 
Stored Cross-Site Scripting vulnerability in Contact Form WordPress Plugin
 
TYPO3 CMS Unspecified Multiple Cross Site Scripting Vulnerabilities
 
Red Hat CloudForms Management Engine CVE-2017-2632 Privilege Escalation Vulnerability
 
Joomla com_jdownloads Component - 'cid' Parameter Sql Injection Vulnerability
 
tnef Multiple Integer Overflow, Type Confusion and Out of Bounds Write Vulnerabilities
 
Cross-Site Request Forgery in WordPress Download Manager Plugin
 
Cross-Site Scripting in Magic Fields 1 WordPress Plugin
 
Cross-Site Request Forgery in Atahualpa WordPress Theme
 
Gwolle Guestbook mass action vulnerable for Cross-Site Request Forgery
 
Admin Custom Login WordPress plugin affected by persistent Cross-Site Scripting via Logo URL field
 
Admin Custom Login WordPress plugin custom login page affected by persistent Cross-Site Scripting
 
Cross-Site Request Forgery in File Manager WordPress plugin
 
Cross-Site Request Forgery in Global Content Blocks WordPress Plugin
 
Internet Storm Center Infocon Status