Critical Git bug allows malicious code execution on client machines

Developers who use the official Git client and related software are being urged to install a security update that kills a bug that could allow attackers to hijack end-user computers.

The critical vulnerability affects all Windows- and Mac-based versions of the official Git client and related software that interacts with Git repositories, according to an advisory published Thursday. The bug can be exploited to give remote code execution when the client software accesses booby-trapped Git repositories.

"An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine," Thursday's advisory warned. "Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem."

Read 1 remaining paragraphs | Comments

12 million home and business routers vulnerable to critical hijacking hack

More than 12 million routers in homes and small offices are vulnerable to attacks that allow hackers anywhere in the world to monitor user traffic and take administrative control over the devices, researchers said.

The vulnerability resides in "RomPager" software, embedded into the residential gateway devices, made by a company known as AllegroSoft. Versions of RomPager prior to 4.34 contain a critical bug that allows attackers to send simple HTTP cookie files that corrupt device memory and hand over administrative control. Attackers can use that control to read plaintext traffic traveling over the device and possibly take other actions, including changing sensitive DNS settings and monitoring or controling Web cams, computers, or other connected devices. Researchers from Check Point's malware and vulnerability group have dubbed the bug Misfortune Cookie, because it allows hackers to determine the "fortune" of an HTTP request by manipulating cookies. They wrote:

If your gateway device is vulnerable, then any device connected to your network—including computers, phones, tablets, printers, security cameras, refrigerators, toasters or any other networked device in your home or office network—may have increased risk of compromise. An attacker exploiting the Misfortune Cookie vulnerability can easily monitor your Internet connection, steal your credentials and personal or business data, attempt to infect your machines with malware, and over-crisp your toast.

Determining precisely what routers are vulnerable is a vexing undertaking. Devices frequently don't display identifying banners when unauthenticated users access them, and when such banners are presented, they often don't include information about the underlying software components. Beyond that, some device manufacturers manually patch the bug without upgrading the RomPager version, a practice that may generate false positives when automatically flagging all devices running versions prior to 4.34. To work around the challenges, Check Point researchers performed a comprehensive scan of Internet addresses that probed for vulnerable RomPager services. The results showed 12 million unique devices spanning 200 different models contained the bug. Manufacturers affected included D-Link, Edimax, Huawei, TP-Link, ZTE, and ZyXEL.

Read 4 remaining paragraphs | Comments

Wordfence and WPScan Acted Irresponsibly With WordPress Plugin Vulnerability

Several years ago we noted a pretty big problem when it came to the security of WordPress plugins; many plugins with known security vulnerabilities in their most recent version were still available in the wordpress.org Plugin Directory. That was a big failure as making sure that those vulnerabilities were fixed or the plugin was pulled until it was fixed was such a low hanging fruit towards better plugin security. For a while after that we were keeping a watch for unfixed vulnerabilities to make sure that wasn’t occurring, but after a while we were simply too busy with services unrelated to security of WordPress that we didn’t have time to do this anymore. Recently we again had time to focus on the security of WordPress plugins, as part of that we started working a new plugin, Plugin Vulnerabilities, which lets you know of security vulnerabilities that exist and existed in the plugins you have installed.

When we started working on the plugin we quickly found that the issue of plugins with known vulnerabilities in their most recent versions still being available in the wordpress.org Plugin Directory hasn’t gone away. In less than a month we have helped to get known vulnerabilities in seven plugins fixed by either contacting the developers of the plugins – who in many are not notified by the person who discovered the vulnerability – or letting the people running the Plugin Directory know that a vulnerability exists in the plugin. Some of them were rather serious, one that we mentioned before involved a backup plugin that permitted any logged in user to download backups made by the plugin. In that case within a day of us passing along the issue to the Plugin Directory people the issue was resolved, that was after almost a month had gone by since the developer had been notified of the issue and two weeks after it was made public.

While looking into another vulnerability we found something more troubling. On September 10 a claimed vulnerability was disclosed in the plugin Rich Counter. In late November when we took a look at it to verify that it was real before add it to our plugin, we found that as described the exploit didn’t work. To exploit the vulnerability it said you should change your web browser’s user agent to “Mozilla<script>alert(document.cookie)</script>”. For us it didn’t work that way, but it did work if you removed “Mozilla” from the start of the user agent. We were somewhat curious as to what had happened to cause a situation where a vulnerability was correctly identified but the explanation of the exploitation of it to not work. We thought it might be case where someone else had actually discovered the issue and someone else was trying to take credit for it. We didn’t find anything to explain the situation, but while doing that we found that several WordPress related security projects had mentioned the disclosure of the vulnerability. We are rather troubled that they were aware of the vulnerability but had not made sure it was fixed or the plugin was pulled from the directory. What made this worse was that within days of us alerting the developer to the issue a partial fix was made and after further message the issue appears to be fully fixed. It would have been quite easy for them to have done the same, but they didn’t leaving website vulnerable when they didn’t have to be, so we feel it is worth highlighting their irresponsible behavior.

First up is Wordfence, which sells a WordPress security service. They mentioned the vulnerability back on October 30 in a post about plugins with vulnerabilities they wanted  “to draw your attention to”, unfortunately they were more interested in drawing your attention to their website then actually drawing the attention of the developer to the issue who would have actually fixed the issue if they had contacted them as we did (or if the developer was unwilling at that time Wordfence should have then contacted the WordPress.org Plugin Directory about it).

The other place we found it mentioned was the in WPScan Vulnerability Database, a website that lists WordPress vulnerabilities,  in an entry added on October 18. Again this came from someone selling WordPress security services and the project is also sponsored by another security company Sucuri. You have to question why security companies would be in the business of providing wider notice of security vulnerabilities in WordPress plugins but not letting the developer, who could actually fix the issue, or the people at the Plugin Directory know about the issue if their interest was truly in security versus making you more vulnerable and then selling you their security services.

Scammers Sell Free Mobile Flash Player Using YouTube Feeds

Scammers love to sell “Flash Player” for Android to careless users who are easily deceived. Although a series of these scam apps were deleted from the official Android app store after our recent report, malicious apps such as Android/Fladstep have reappeared in the store. This time scammers are promoting their sales tools using the RSS feeds from the world’s most popular movie distribution site, YouTube, to impersonate legitimate apps.

fladstep-d-1

After being launched, the malicious app shows a playlist of video movies with titles related to Flash Player for Android devices.

fladstep-d-2

This playlist of movies is actually retrieved from YouTube, from its published RSS feeds. We can bet that these movies do not belong to the attacker.

fladstep-d-code-1

The playlist appears to start with advice about Flash Player. However, the scammer first replaces all the movie links with links to fraudulent sales websites, which require visitors to pay money for the fake Flash Player. (Adobe’s version is free.) We have seen these websites before.

fladstep-d-code-2

If a user selects “Yes” on the download site, a familiar, suspicious page appears. Finally the user is redirected to a PayPal page. Unlike the previously reported case in which the scammer offered the free Flash Player for €5, this time the scammer has doubled the price, to €10.

fladstep-d-4

Of course, you don’t need to pay for this bogus free version of Flash Player for Android; you should directly download and install it from Adobe. If it appears you have been tricked into buying a maliciously crafted version of Flash Player, you can simply close the app or browser if you see the preceding screen.

The post Scammers Sell Free Mobile Flash Player Using YouTube Feeds appeared first on McAfee.