Comment Re:Not CUPS! (Score 1) 63
True, it is indeed cups-browsed bound to 0.0.0.0:631.
Submission + - When CUPS Runneth Over: The Threat of DDoS (akamai.com)
generic writes: Akamai researchers have confirmed a new attack vector using CUPS that could be leveraged to stage distributed denial-of-service (DDoS) attacks.
Research shows that, to begin the attack, the attacking system only needs to send a single packet to a vulnerable and exposed CUPS service with internet connectivity.
The Akamai Security Intelligence and Response Team (SIRT) found that more than 198,000 devices are vulnerable to this attack vector and are accessible on the public internet; roughly 34% of those could be used for DDoS abuse (58,000+).
Of the 58,000+ vulnerable devices, hundreds exhibited an “infinite loop” of requests.
The limited resources required to initiate a successful attack highlights the danger: It would take an attacker mere seconds to co-opt every vulnerable CUPS service currently exposed on the internet and cost the attacker less than a single US cent on modern hyperscaler platforms.
Research shows that, to begin the attack, the attacking system only needs to send a single packet to a vulnerable and exposed CUPS service with internet connectivity.
The Akamai Security Intelligence and Response Team (SIRT) found that more than 198,000 devices are vulnerable to this attack vector and are accessible on the public internet; roughly 34% of those could be used for DDoS abuse (58,000+).
Of the 58,000+ vulnerable devices, hundreds exhibited an “infinite loop” of requests.
The limited resources required to initiate a successful attack highlights the danger: It would take an attacker mere seconds to co-opt every vulnerable CUPS service currently exposed on the internet and cost the attacker less than a single US cent on modern hyperscaler platforms.
Submission + - Zero-day in popular jQuery plugin actively exploited for at least three years (zdnet.com)
generic writes: For at least three years, hackers have abused a zero-day in one of the most popular jQuery plugins to plant web shells and take over vulnerable web servers, ZDNet has learned.
The vulnerability impacts the jQuery File Upload plugin authored by prodigious German developer Sebastian Tschan, most commonly known as Blueimp.
The plugin is the second most starred jQuery project on GitHub, after the jQuery framework itself. It is immensely popular, has been forked over 7,800 times, and has been integrated into hundreds, if not thousands, of other projects, such as CMSs, CRMs, Intranet solutions, WordPress plugins, Drupal add-ons, Joomla components, and so on.
A vulnerability in this plugin would be devastating, as it could open gaping security holes in a lot of platforms installed in a lot of sensitive places.
This worse case scenario is exactly what happened. Earlier this year, Larry Cashdollar, a security researcher for Akamai's SIRT (Security Intelligence Response Team), has discovered a vulnerability in the plugin's source code that handles file uploads to PHP servers.
Cashdollar says that attackers can abuse this vulnerability to upload malicious files on servers, such as backdoors and web shells.
The Akamai researcher says the vulnerability has been exploited in the wild. "I've seen stuff as far back as 2016," the researcher told ZDNet in an interview.
The vulnerability was one of the worst kept secrets of the hacker scene and appears to have been actively exploited, even before 2016.
Cashdollar found several YouTube videos containing tutorials on how one could exploit the jQuery File Upload plugin vulnerability to take over servers. One of three YouTube videos Cashdollar shared with ZDNet is dated August 2015.
It is pretty clear from the videos that the vulnerability was widely known to hackers, even if it remained a mystery for the infosec community.
But steps are now being taken to address it. The vulnerability received the CVE-2018-9206 identifier earlier this month, a good starting point to get more people paying attention.
All jQuery File Upload versions before 9.22.1 are vulnerable. Since the vulnerability affected the code for handling file uploads for PHP apps, other server-side implementations should be considered safe.
Cashdollar reported the zero-day to Blueimp at the start of the month, who promptly looked into the report.
The developer's investigation identified the true source of the vulnerability not in the plugin's code, but in a change made in the Apache Web Server project dating back to 2010, which indirectly affected the plugin's expected behavior on Apache servers.
The actual issue dates back to November 23, 2010, just five days before Blueimp launched the first version of his plugin. On that day, the Apache Foundation released version 2.3.9 of the Apache HTTPD server.
This version wasn't anything out of the ordinary but it included one major change, at least in terms of security. Starting with this version, the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via .htaccess files. This setting was made for security reasons, was enabled by default, and remained so for all subsequent Apache HTTPD server releases.
Blueimp's jQuery File Upload plugin was coded to rely on a custom .htaccess file to impose security restrictions to its upload folder, without knowing that five days before, the Apache HTTPD team made a breaking change that undermined the plugin's basic design.
"The internet relies on many security controls every day in order to keep our systems, data, and transactions safe and secure," Cashdollar said in a report published today. "If one of these controls suddenly doesn't exist it may put security at risk unknowingly to the users and software developers relying on them."
Since notifying Blueimp about his discovery, Cashdollar has been spending his time investigating the reach of this vulnerability. The first thing he did was to look at all the GitHub forks that have sprouted from the original plugin.
"I did test 1000 out of the 7800 of the plugin's forks from GitHub, and they all were exploitable," Cashdollar told ZDNet. The code he's been using for these tests is available on GitHub, along with a proof-of-concept for the actual flaw.
At this article's publication, of all the projects derived from the original jQuery File Upload plugin, and which the researcher tested, only 36 were not vulnerable.
But there is still lots of work ahead, as many projects remain untested. The researcher has already notified US-CERT of this vulnerability and its possible impact. A next step, Cashdollar told ZDNet, is to reach out to GitHub for help in notifying all plugin fork project owners.
But looking into GitHub forks is only the first step. There are countless web applications where the plugin has been integrated. One example is Tajer, a WordPress plugin that Cashdollar identified as vulnerable. The plugin had very few downloads, and as of today, it has been taken off the official WordPress Plugins repository and is not available for download anymore.
Identifying all affected projects and stomping out this vulnerability will take years. As it's been proven many times in the past, vulnerabilities tend to linger for a long time, especially vulnerabilities in plugins that have been deeply ingrained in more complex projects, such as CRMs, CMSs, blogging platforms, or enterprise solutions.
The vulnerability impacts the jQuery File Upload plugin authored by prodigious German developer Sebastian Tschan, most commonly known as Blueimp.
The plugin is the second most starred jQuery project on GitHub, after the jQuery framework itself. It is immensely popular, has been forked over 7,800 times, and has been integrated into hundreds, if not thousands, of other projects, such as CMSs, CRMs, Intranet solutions, WordPress plugins, Drupal add-ons, Joomla components, and so on.
A vulnerability in this plugin would be devastating, as it could open gaping security holes in a lot of platforms installed in a lot of sensitive places.
This worse case scenario is exactly what happened. Earlier this year, Larry Cashdollar, a security researcher for Akamai's SIRT (Security Intelligence Response Team), has discovered a vulnerability in the plugin's source code that handles file uploads to PHP servers.
Cashdollar says that attackers can abuse this vulnerability to upload malicious files on servers, such as backdoors and web shells.
The Akamai researcher says the vulnerability has been exploited in the wild. "I've seen stuff as far back as 2016," the researcher told ZDNet in an interview.
The vulnerability was one of the worst kept secrets of the hacker scene and appears to have been actively exploited, even before 2016.
Cashdollar found several YouTube videos containing tutorials on how one could exploit the jQuery File Upload plugin vulnerability to take over servers. One of three YouTube videos Cashdollar shared with ZDNet is dated August 2015.
It is pretty clear from the videos that the vulnerability was widely known to hackers, even if it remained a mystery for the infosec community.
But steps are now being taken to address it. The vulnerability received the CVE-2018-9206 identifier earlier this month, a good starting point to get more people paying attention.
All jQuery File Upload versions before 9.22.1 are vulnerable. Since the vulnerability affected the code for handling file uploads for PHP apps, other server-side implementations should be considered safe.
Cashdollar reported the zero-day to Blueimp at the start of the month, who promptly looked into the report.
The developer's investigation identified the true source of the vulnerability not in the plugin's code, but in a change made in the Apache Web Server project dating back to 2010, which indirectly affected the plugin's expected behavior on Apache servers.
The actual issue dates back to November 23, 2010, just five days before Blueimp launched the first version of his plugin. On that day, the Apache Foundation released version 2.3.9 of the Apache HTTPD server.
This version wasn't anything out of the ordinary but it included one major change, at least in terms of security. Starting with this version, the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via
Blueimp's jQuery File Upload plugin was coded to rely on a custom
"The internet relies on many security controls every day in order to keep our systems, data, and transactions safe and secure," Cashdollar said in a report published today. "If one of these controls suddenly doesn't exist it may put security at risk unknowingly to the users and software developers relying on them."
Since notifying Blueimp about his discovery, Cashdollar has been spending his time investigating the reach of this vulnerability. The first thing he did was to look at all the GitHub forks that have sprouted from the original plugin.
"I did test 1000 out of the 7800 of the plugin's forks from GitHub, and they all were exploitable," Cashdollar told ZDNet. The code he's been using for these tests is available on GitHub, along with a proof-of-concept for the actual flaw.
At this article's publication, of all the projects derived from the original jQuery File Upload plugin, and which the researcher tested, only 36 were not vulnerable.
But there is still lots of work ahead, as many projects remain untested. The researcher has already notified US-CERT of this vulnerability and its possible impact. A next step, Cashdollar told ZDNet, is to reach out to GitHub for help in notifying all plugin fork project owners.
But looking into GitHub forks is only the first step. There are countless web applications where the plugin has been integrated. One example is Tajer, a WordPress plugin that Cashdollar identified as vulnerable. The plugin had very few downloads, and as of today, it has been taken off the official WordPress Plugins repository and is not available for download anymore.
Identifying all affected projects and stomping out this vulnerability will take years. As it's been proven many times in the past, vulnerabilities tend to linger for a long time, especially vulnerabilities in plugins that have been deeply ingrained in more complex projects, such as CRMs, CMSs, blogging platforms, or enterprise solutions.
Comment Re:A vague problem (Score 1) 47
Here is one http://www.openwall.com/lists/...
Comment Re:"But according to a number of researchers" (Score 1) 47
I see your point, I only care to assign CVE IDs to my discoveries because folks ask me for them. It gets annoying when I've found a vulnerability and someone is hounding me about the CVE ID so they can track it and mitre doesn't respond to my emails.
Comment Re:A vague problem (Score 1) 47
Mitre either isn't responding or flat out rejecting valid requests because they've changed the scope of what they will assign numbers too.
Comment Re:"But according to a number of researchers" (Score 1) 47
What makes for a crappy security researcher? because the software they've found a bug in isn't on mitre's short little list of CVE approved vendors?
Comment Raspberry pi and andriod os (Score 1) 99
I'd be interested in loading andriod on my second pi due in late august, I hope it is out by then. The raspbain distro is very snappy on the little Pi. I'm very happy with it.
Comment Why (Score -1, Troll) 456
cause it sux.
Comment Grey water? (Score 1) 230
Where I am from water from the toilet is black water. Grey water is water from shower/sink.
Comment screen shots.... (Score 1) 90
Comment Screenshots (Score 2) 136
Not by me.
Comment Kind of like a slinky (Score 1) 195
Falling down stairs.
Comment These are neat to look at. (Score 2) 100
Comment Eh why.. (Score 1) 171
did they put dudes in that video at all. Men in tights aren't a good thing from any angle.
Slashdot Top Deals
What this country needs is a good five cent microcomputer.
