Hackers Actively Exploiting Widely-Used Social Share Plugin for WordPress

wordpress plugin hacking

Hackers have been found exploiting a pair of critical security vulnerabilities in one of the popular social media sharing plugins to take control over WordPress websites that are still running a vulnerable version of the plugin.

The vulnerable plugin in question is Social Warfare which is a popular and widely deployed WordPress plugin with more than 900,000 downloads. It is used to add social share buttons to a WordPress website or blog.

Late last month, maintainers of Social Warfare for WordPress released an updated version 3.5.3 of their plugin to patch two security vulnerabilities—stored cross-site scripting (XSS) and remote code execution (RCE)—both tracked by a single identifier, i.e., CVE-2019-9978.

Hackers can exploit these vulnerabilities to run arbitrary PHP code and take complete control over websites and servers without authentication, and then use the compromised sites to perform digital coin mining or host malicious exploit code.

However, the same day when Social Warfare released the patched version of its plugin, an unnamed security researcher published a full disclosure and a proof-of-concept for the stored Cross-Site Scripting (XSS) vulnerability.

hacking wordpress website

Soon after the full disclosure and PoC release, attackers started attempting to exploit the vulnerability, but fortunately, it was only limited to the injected JavaScript redirect activity, with researchers finding no in-the-wild attempts to exploit the RCE vulnerability.

Now, Palo Alto Network Unit 42 researchers found several exploits taking advantage of these vulnerabilities in the wild, including an exploit for the RCE vulnerability which allows the attacker to control the affected website and an exploit for the XSS vulnerability which redirects victims to an ads site.

Though both flaws originated because of improper input handling, using a wrong, insufficient function eventually made it possible for remote attackers to exploit them without requiring any authentication.

“The root cause of each of these two vulnerabilities is the same: the misuse of the is_admin() function in WordPress,” the researchers say in a blog post. “Is_admin only checks if the requested page is part of admin interface and won’t prevent any unauthorized visit.”

At the time of writing, more than 37,000 WordPress websites out of 42,000 active sites, including education, finance, and news sites (some Alexa’s top ranking websites), are still using an outdated, vulnerable version of the Social Warfare plugin, leaving hundreds of millions of their visitors at the risk of hacking through various other vectors.

Since it is likely the attackers will continue to exploit the vulnerabilities to target WordPress users, website administrators are highly recommended to update the Social Warfare plugin to 3.5.3 or newer version as soon as possible.

Let’s block ads! (Why?)

Link to original source

Source Code for CARBANAK Banking Malware Found On VirusTotal

carbanak source code

Security researchers have discovered the full source code of the Carbanak malware—yes, this time it’s for real.

Carbanak—sometimes referred as FIN7, Anunak or Cobalt—is one of the most full-featured, dangerous malware that belongs to an APT-style cybercriminal group involved in several attacks against banks, financial institutions, hospitals, and restaurants.

In July last year, there was a rumor that the source code of Carbanak was leaked to the public, but researchers at Kaspersky Lab later confirmed that the leaked code was not the Carbanak Trojan.

Now cybersecurity researchers from FireEye revealed that they found Carbanak’s source code, builders, and some previously unseen plugins in two RAR archives [1, 2] that were uploaded on the VirusTotal malware scanning engine two years ago from a Russian IP address.

“CARBANAK source code was 20MB comprising 755 files, with 39 binaries and 100,000 lines of code,” researchers say. “Our goal was to find threat intelligence we missed in our previous analyses.”

FireEye researchers have plans to release a 4-part series of articles detailing CARBANAK features and analysis based upon its source code and reverse engineering.

carbanak source code

First uncovered in 2014 by Kaspersky Lab, Carbanak is one of the most successful malware attacks in the world launched by a highly organized group that continually evolved its tactics to carry out cybercrime while avoiding detection by potential targets and the authorities.

The hacker group started its activities almost six years ago by launching a series of malware attacks using Anunak and Carbanak to compromise banks and ATM networks worldwide, and thereby stealing over a billion euros from more than 100 banks across the globe.

To compromise banks, hackers sent malicious spear-phishing emails to hundreds of employees at different banks, which infected computers with Carbanak malware if opened, allowing attackers to transfer money from affected banks to fake accounts or ATMs monitored by them.

According to the European authorities, the criminal group later developed a sophisticated heist-ready banking trojan called Cobalt, based on the Cobalt-Strike penetration testing software, which was in use until 2016.

The group was first exposed in 2015 as financially-motivated cybercriminals, and three suspects—Dmytro Fedorov, 44, Fedir Hladyr, 33, and Andrii Kopakov, 30—all from Ukraine were arrested last year in Europe between January and June.

All the three suspects, one of which (Kopakov) is believed to be the alleged leader of the organised criminal group, were indicted and charged with a total of 26 felony counts in August 2018.

Let’s block ads! (Why?)

Link to original source

Facebook Collected Contacts from 1.5 Million Email Accounts Without Users' Permission

facebook email database

Not a week goes without a new Facebook blunder.

Remember the most recent revelation of Facebook being caught asking users new to the social network platform for their email account passwords to verify their identity?

At the time, it was suspected that Facebook might be using access to users’ email accounts to unauthorizedly and secretly gather a copy of their saved contacts.

Now it turns out that the collection of email contacts was true, Facebook finally admits.

In a statement released on Wednesday, Facebook said the social media company “unintentionally” uploaded email contacts from up to 1.5 million new users on its servers, without their consent or knowledge, since May 2016.

In other words, nearly 1.5 million users had shared passwords for their email accounts with Facebook as part of its dubious verification process.

A Facebook spokesperson shared information with Business Insider that the company was using harvested data to “build Facebook’s web of social connections and recommend friends to add.”

The social media giant said the company had stopped this email verification process a month ago and has assured its users that it has not shared those contacts with anyone and that it has already started deleting them.

“Last month we stopped offering email password verification as an option for people verifying their account when signing up for Facebook for the first time,” Facebook says.

“We estimate that up to 1.5 million people’s email contacts may have been uploaded. These contacts were not shared with anyone and we’re deleting them. We’ve fixed the underlying issue and are notifying people whose contacts were imported. People can also review and manage the contacts they share with Facebook in their settings.”

This recently reported incident is the latest in a long list of privacy-related issues and controversies the tech giant is dealing with.

Just last month, Facebook was caught storing passwords of hundreds of millions of users in plaintext within its internal servers, which were accessible to some of its employees.

In October last year, Facebook also announced its worst-ever security breach that allowed hackers to successfully steal secret access tokens and access personal information from 29 million Facebook accounts.

The recent revelation once again underlines the failure of Facebook to protect its users’ information while generating billions of dollars in revenue from the same information.

Let’s block ads! (Why?)

Link to original source

Over 100 Million JustDial Users' Personal Data Found Exposed On the Internet

justdial data breach hacking

An unprotected database belonging to JustDial, India’s largest local search service, is leaking personally identifiable information of its every customer in real-time who accessed the service via its website, mobile app, or even by calling on its fancy “88888 88888” customer care number, The Hacker News has learned and independently verified.

Founded over two decades ago, JustDial (JD) is the oldest and leading local search engine in India that allows users to find relevant nearby providers and vendors of various products and services quickly while helping businesses listed in JD to market their offerings.

Rajshekhar Rajaharia, an independent security researcher, yesterday contacted The Hacker News and shared details of how an unprotected, publicly accessible API endpoint of JustDial’s database can be accessed by anyone to view profile information of over 100 million users associated with their mobile numbers.

The leaked data includes JustDial users’ name, email, mobile number, address, gender, date of birth, photo, occupation, company name they are working with—basically whatever profile related information a customer ever provided to the company.

Though the unprotected APIs exist since at least mid-2015, it’s not clear if anyone has misused it to gather personal information on JustDial users.

Justdial is Leaking Personal Details Of All Customers

After verifying the leaky endpoint, The Hacker News also wanted to verify if the API is fetching results directly from the production server or from a backup database that might not have information belonging to recently signed-up users.

justdial data breach hacking

To find this, I provided Rajshekhar a new phone number that was never before registered with Justdial server, which he confirmed was not listed in the database at that time.

Instead of installing and using the JD app or its website, I then simply called the customer care number and shared a random name and personal details with the executive to learn a few good restaurants in my city.

Immediately after completing the call, Rajshekhar sent me the profile details I shared with the JD executive associated with the same phone number that was previously not found in the database, indicating that the unprotected API is fething real-time information of users.

Although the unprotected API is connected to the primary JD database, Rajshekhar revealed that it’s an old API endpoint which is not currently being used by the company but left forgotten on the server.

Rajshekhar told The Hacker News that he discovered this unprotected end-point while pentesting the latest APIs in use, which are apparently protected and using authentication measures.

Besides this, Rajshekhar also found a few other old unprotected APIs, one of which could allow anyone to trigger OPT request for any registered phone number, which might not be a serious security issue, but could be used for spamming users and costing the company.

Rajshekhar also claimed that he tried to contact the company to responsibly disclose his findings, but unfortunately failed to find any direct way to contact the company and report the incident.

The Hacker News has also dropped an email to a few email addresses, linked to the company, we found on the Internet, providing the details of the incident. We will update this report when we hear back. Stay Tuned.

Let’s block ads! (Why?)

Link to original source

Apache Tomcat Patches Important Remote Code Execution Flaw

apache tomcat server security

The Apache Software Foundation (ASF) has released new versions of its Tomcat application server to address an important security vulnerability that could allow a remote attacker to execute malicious code and take control of an affected server.

Developed by ASF, Apache Tomcat is an open source web server and servlet system, which uses several Java EE specifications such as Java Servlet, JavaServer Pages (JSP), Expression Language, and WebSocket to provide a “pure Java” HTTP web server environment for Java concept to run in.

The remote code execution vulnerability (CVE-2019-0232) resides in the Common Gateway Interface (CGI) Servlet when running on Windows with enableCmdLineArguments enabled and occurs due to a bug in the way the Java Runtime Environment (JRE) passes command line arguments to Windows.

Since the CGI Servlet is disabled by default and its option enableCmdLineArguments is disabled by default in Tomcat 9.0.x, the remote code execution vulnerability has been rated as important and not critical.

In response to this vulnerability, the CGI Servlet enableCmdLineArguments option will now be disabled by default in all versions of Apache Tomcat.

Affected Tomcat Versions

  • Apache Tomcat 9.0.0.M1 to 9.0.17
  • Apache Tomcat 8.5.0 to 8.5.39
  • Apache Tomcat 7.0.0 to 7.0.93

Unaffected Tomcat Versions

  • Apache Tomcat 9.0.18 and later
  • Apache Tomcat 8.5.40 and later
  • Apache Tomcat 7.0.94 and later

Successful exploitation of this vulnerability could allow a remote attacker to execute an arbitrary command on a targeted Windows server running an affected version of Apache Tomcat, resulting in a full compromise.

The vulnerability was reported to the Apache Tomcat security team by a security researcher (not named by the Apache Software Foundation) on 3rd March 2019 and was made public on 10 April 2019 after the ASF released the updated versions.

This Apache vulnerability has been addressed with the release of Tomcat version 9.0.19 (though the issue was fixed in Apache Tomcat 9.0.18, the release vote for the 9.0.18 release did not pass), version 8.5.40 and version 7.0.93.

So, administrators are strongly recommended to apply the software updates as soon as possible. If you are unable to apply the patches immediately, you should ensure the CGI Servlet initialisation parameter’s default enableCmdLineArguments value is set to false.

Let’s block ads! (Why?)

Link to original source