Oracle PeopleSoft Enterprise SCM eBill Payment CVE-2017-3571 Remote Security Vulnerability
Oracle PeopleSoft Enterprise PeopleTools CVE-2017-3520 Remote Security Vulnerability
Oracle FLEXCUBE Enterprise Limits and Collateral Management Remote Security Vulnerability
Oracle E-Business Suite CVE-2017-3557 Remote Security Vulnerability
Oracle MySQL Server CVE-2017-3453 Remote Security Vulnerability
Oracle Solaris CVE-2017-3622 Local Security Vulnerability
Oracle WebCenter Sites CVE-2017-3541 Remote Security Vulnerability
Oracle WebCenter Sites CVE-2017-3602 Remote Security Vulnerability
Oracle Primavera Products CVE-2017-3579 Remote Security Vulnerability
Oracle PeopleSoft Enterprise PeopleTools CVE-2017-3519 Remote Security Vulnerability

Enlarge (credit: Seth Anderson)

Mirai, the botnet that threatened the Internet as we knew it last year with record-setting denial-of-service attacks, is facing an existential threat of its own: A competing botnet known as Hajime has infected at least 10,000 home routers, network-connected cameras, and other so-called Internet of Things devices.

Hajime uses a decentralized peer-to-peer network to issue commands and updates to infected devices. This design makes it more resistant to takedowns by ISPs and Internet backbone providers. Hajime uses the same list of user name and password combinations Mirai uses, with the addition of two more. It also takes steps to conceal its running processes and files, a feature that makes detecting infected systems more difficult. Most interesting of all: Hajime appears to be the brainchild of a grayhat hacker, as evidenced by a cryptographically signed message it displays every 10 minutes or so on terminals. The message reads:

Just a white hat, securing some systems.

Important messages will be signed like this!

Hajime Author.

Contact CLOSED

Stay sharp!

Another sign Hajime is a vigilante-style project intended to disrupt Mirai and similar IoT botnets: It blocks access to four ports known to be vectors used to attack many IoT device. Hajime also lacks distributed denial-of-service capabilities or any other attacking code except for the propagation code that allows one infected device to seek out and infect other vulnerable devices.

Read 3 remaining paragraphs | Comments

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Oracle E-Business Suite CVE-2017-3393 Remote Security Vulnerability
Oracle WebCenter Sites CVE-2017-3542 Remote Security Vulnerability
Oracle FLEXCUBE Universal Banking CVE-2017-3534 Remote Security Vulnerability
Oracle Java SE CVE-2017-3514 Remote Security Vulnerability
Oracle Transportation Manager CVE-2017-3530 Remote Security Vulnerability
Oracle Enterprise Manager Base Platform CVE-2017-3518 Remote Security Vulnerability
Cybozu Office CVE-2016-4869 Information Disclosure Vulnerability

Enlarge (credit: Piotrus)

Joel Abel Garcia, a 35-year-old from the Bronx, New York, became the third member of an alleged ring of automated teller machine "skimmers" to plead guilty today in the US District of New Jersey to the charge of conspiracy to commit bank fraud. Another member of the group—Victor Hanganu, a Romanian citizen living in Bayside, New York—pleaded guilty to the same charge on April 10. Eleven others have been charged in the conspiracy, which targeted PNC and Bank of America ATMs in New Jersey from March 2015 until June of 2016. Another Romanian, Radu Marin, pleaded guilty on March 29.

"According to admissions made in connection with the pleas, Garcia, Hanganu, and others sought to defraud financial institutions and their customers by illegally obtaining customer account information, including account numbers and personal identification numbers," a Department of Justice spokesperson said in a statement made on behalf of federal prosecutors in New Jersey. Garcia was found to be personally responsible for $132,805 in withdrawals using forged ATM cards out of a total of $428,581 over the 15-month period.

Garcia admitted as part of the plea that "he installed 'skimming' devices on the ATMs" belonging to PNC and Bank of America at multiple locations in New Jersey, "including pinhole cameras that recorded password entries and card-reading devices capable of recording customer information encoded on magnetic strips," according to the statement.

Read 3 remaining paragraphs | Comments

flatCore-CMS CVE-2017-7877 Cross Site Request Forgery Vulnerability
Cybozu Office Multiple Security Vulnerabilities
WordPress WP Statistics CVE-2017-2136 HTML Injection Vulnerability
Cybozu Office CVE-2016-4868 Email Header Injection Vulnerability
FreeBSD CVE-2016-1886 Local Buffer Overflow Vulnerability
[ANNOUNCE] HPACK Bomb Attack vulnerability in ATS - CVE-2016-5396
MantisBT CVE-2017-7615 Security Bypass Vulnerability
SourceBans++ sourcebans-pp CVE-2017-7891 Cross Site Scripting Vulnerability
ASSETBASE CVE-2017-2134 Cross Site Scripting Vulnerability
HP Vertica Analytics Platform CVE-2017-5802 Remote Privilege Escalation Vulnerability
CVE-2017-7615 Mantis Bug Tracker v1.3.0 / 2.3.0 Pre-Auth Remote Password Reset
[CVE-2017-5661] Apache XML Graphics FOP information disclosure vulnerability

Enlarge (credit: Harrison Weber)

Smartphones know an awful lot about us. They know if we're in a car that's speeding, and they know when we're walking, running, or riding in a bus. They know how many calls we make and receive each day and the precise starting and ending time of each one. And of course, they know the personal identification numbers we use to unlock the devices or to log in to sites that are protected by two-factor authentication. Now, researchers have devised an attack that makes it possible for sneaky websites to surreptitiously collect much of that data, often with surprising accuracy.

The demonstrated keylogging attacks are most useful at guessing digits in four-digit PINs, with a 74-percent accuracy the first time it's entered and a 94-percent chance of success on the third try. The same technique could be used to infer other input, including the lock patterns many Android users rely on to lock their phones, although the accuracy rates would probably be different. The attacks require only that a user open a malicious webpage and enter the characters before closing it. The attack doesn't require the installation of any malicious apps.

Malicious webpages—or depending on the browser, legitimate sites serving malicious ads or malicious content through HTML-based iframe tags—can mount the attack by using standard JavaScript code that accesses motion and orientation sensors built into virtually all iOS and Android devices. To demonstrate how the attack would work, researchers from Newcastle University in the UK wrote attack code dubbed PINLogger.js. Without any warning or outward sign of what was happening, the JavaScript was able to accurately infer characters being entered into the devices.

Read 12 remaining paragraphs | Comments


Our reader Charlieforwarded us a somewhat interesting Apple phish. Apple is a big phishing target, and the phish itself wasnt all that special. It does a reasonable good jobemulating real Apple e-mails, but what is more interesting are the From width:300px" />

The From address was set to . For the uninitiated, this may look like a valid Apple domain. But instead, it is a subdomain of is of course not the valid source of the e-mail. But why did this e-mail make it past SPF filters? does define an SPF record:

v=spf1 ip4: ip4: ~all

The record contains a common error: In the end, the ~ ahead of all indicates a soft fail. In essence, this may short-out the SPF definition. There is also no DMARC record for this domain. The ~ is often added to prevent false positives, for example, if companies are afraid that they didnt capture all the mail servers sending e-mail on their behalf. While this may be a good idea initially, it should be removed later.

Next, the link leads to The domain is not associated with Apple. The web page is still up (but blacklisted), and provides a good copy of the genuine Apple login page. width:300px" />

Interesting about this domain: It was registered back in January. So the bad guy put some work into this to avoid some recently registered domain filters.

So lessons learned:

  • Make sure yourSPF record ends with -all not ~all (subtle but important)
  • When hunting for bad domains, details matter and the registration date may not be enough to find malicious domains.

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status