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


LeakedSource, a legally and ethically questionable website that sold access to a database of more than 3.1 billion compromised account passwords, has disappeared amid an unconfirmed report that its operator was raided by law enforcement officers.

"Leakedsource is down forever and won't be coming back," a person using the handle LTD wrote Thursday in an online forum. "Owner raided early this morning. Wasn't arrested, but all [solid state drives] got taken, and Leakedsource servers got subpoenaed and placed under federal investigation. If somehow he recovers from this and launches LS again, then I'll be wrong. But I am not wrong."

Attempts to reach LeakedSource operators for comment weren't successful.

Read 5 remaining paragraphs | Comments

JasPer 'jpc_t2dec.c' Remote Heap Buffer Overflow Vulnerability

The Facebook signature wall in question is much bigger than this one, by the way. (credit: Matteo Artizzu)

Facebook is enhancing its existing protection against account takeovers with cryptographically based security keys that can be used as a second factor of authentication, the social network is announcing today.

A handful of online services—including Google, Dropbox, GitHub, and Salesforce—already support security keys based on the open Universal 2nd Factor, or U2F, standard, created by the Fido Alliance. Now Facebook is offering them, too. The inexpensive devices, which plug into users' USB port, were recently shown to beat out smartphones and most other forms of two-factor verification in a two-year study of more than 50,000 Google employees. That assessment was based on the ease of using and deploying keys, the security they provided against phishing and other types of account-takeover attacks, and the lack of privacy trade-offs that accompany some other forms of two-factor authentication.

Just as attackers can use phishing techniques to trick people into divulging their passwords, attackers can also trick people into divulging the one-time passwords that form the basis of most two-factor authentication schemes. Security keys, by contrast, rely on a cryptographic secret baked into their silicon. This data can't be easily divulged. Security keys also can't suffer from dead zones that often prevent cellphones from receiving text messages. The keys are also not susceptible to the types of malware compromises that can hit smartphones.

Read 2 remaining paragraphs | Comments

JasPer 'jas_seq.c' Denial of Service Vulnerability
JasPer 'jp2_cod.c' Null Pointer Dereference Denial of Service Vulnerability
lcms2 CVE-2016-10165 Out-of-Bounds Read Denial of Service Vulnerability
Network Time Protocol CVE-2015-7705 Denial of Service Vulnerability
IETF IPv6 Protocol CVE-2016-10142 Denial of Service Vulnerability
Wireshark CVE-2017-5597 Denial of Service Vulnerability
Hawtio CVE-2017-2594 Directory Traversal Vulnerability
Google Chrome Multiple Security Vulnerabilities

Yesterday, I wrote a blog post[1] which explained how to interconnect a Cuckoo[2] sandbox and the MISP[3] sharing platform. MISP has a nice REST API that allows you to extract useful IOCs in different formats. One of them is the Suricata"> alert http $HOME_NET any - $EXTERNAL_NET any ( msg: MISP e3791 Outgoing HTTP Domain: khanji.ddns.net content: Host|3a| content:khanji.ddns.net pcre: /(^|[^A-Za-z0-9-])khanji\.ddns\.net[^A-Za-z0-9-\.]/Hi )

This is very tempting to automatically inject more and more IOCs into your IDS system to spot bad traffic. Also, a" />

MISP can receive your own IOCs from sandboxes, from remote connected MISP instances or from external public/private sources. Keep in mind that an IOC must always be delivered in a contact. A simple example is the use of public DNS servers: For anorganizationA, traffic to public DNS like Google or OpenDNS can be considered as suspicious. It could be legit to define them as IOCs. But in the organizationB, they use some public DNS services. If B integrates blindly all IOCs published by A, they will be facing a risk of false positive alerts! I already faced this issue with many customers. Classic bad IOCs are:

  • CRL services likecrl.verisign.com,sc.symcb.com
  • URL shorteners
  • Public DNS
  • Hashes of DLLs

To prevent this problem, my recommendation is to test your set of IDS rules based in shared IOCs before enabling them in production. This can be performed in three steps:

1. Get some network data. The simple solution is to use samples from yourfull packet capture solution[4], exportPCAP files generated during interestingtime periods like in the morning (8AM-10AM) when people arrive at the office, read their emails and visit their regular websites or at the lunchbreak."> # wget --header Authorization: xxxxxxxxxxx \--no-check-certificate \-O /tmp/misp.rules \"> # suricata -r /tmp/sample-08-10.pcap -S /tmp/misp.rules -l /tmp

Now, it"> # cat /tmp/fast.log | awk { print $3 } | sort -u | while read ALERT do X=`echo $ALERT | tr -d []` N=`grep $X fast.log|wc -l` echo $ALERT : $N done[1:2200025:1] : 320[1:2200067:1] : 224[1:2200075:1] : 9[1:2210007:1] : 38[1:2210008:1] : 38[1:2220006:1] : 1[1:2221007:1] : 1

Easy to spot a rule that generates a lot of hits! (Those three steps can be easily scripted for automatic reporting).


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

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

PEAR HTTP_Upload v1.0.0b3 Arbitrary File Upload
[SECURITY] [DSA 3771-1] firefox-esr security update
Google Forms WordPress Plugin unauthenticated PHP Object injection vulnerability
Cisco Security Advisory: Cisco TelePresence Multipoint Control Unit Remote Code Execution Vulnerability
Cisco Security Advisory: Cisco Expressway Series and TelePresence VCS Denial of Service Vulnerability
Cisco Security Advisory: Cisco Adaptive Security Appliance CX Context-Aware Security Denial of Service Vulnerability
ESA-2016-166: EMC Isilon OneFS Privilege Escalation Vulnerability
Internet Storm Center Infocon Status