Show Notes: linuxactionnews.com/246

The post Linux Action News 246 first appeared on Jupiter Broadcasting.

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Show Notes:

Akamai’s quarterly State of the Internet report: The Krebs Attack

• “Internet infrastructure giant Akamai last week released a special State of the Internet report. Normally, the quarterly accounting of noteworthy changes in distributed denial-of-service (DDoS) attacks doesn’t delve into attacks on specific customers. But this latest Akamai report makes an exception in describing in great detail the record-sized attack against KrebsOnSecurity.com in September, the largest such assault it has ever mitigated.”
• Akamai: “The same data we’ve shared here was made available to Krebs for his own reporting and we received permission to name him and his site in this report.”
• “Akamai said the attack on Sept. 20 was launched by just 24,000 systems infected with Mirai, mostly hacked Internet of Things (IoT) devices such as digital video recorders and security cameras.”
• “The first quarter of 2016 marked a high point in the number of attacks peaking at more than 100 Gbps,” Akamai stated in its report. “This trend was matched in Q3 2016, with another 19 mega attacks. It’s interesting that while the overall number of attacks fell by 8% quarter over quarter, the number of large attacks, as well as the size of the biggest attacks, grew significantly.”
• “The magnitude of the attacks seen during the final week were significantly larger than the majority of attacks Akamai sees on a regular basis,” Akamai reports. “In fact, while the attack on September 20 was the largest attack ever mitigated by Akamai, the attack on September 22 would have qualified for the record at any other time, peaking at 555 Gbps.”
• Krebs has also made a .csv of the data available: “An observant reader can probably correlate clumps of attacks to specific stories covered by Krebs. Reporting on the dark side of cybersecurity draws attention from people and organizations who are not afraid of using DDoS attacks to silence their detractors.” In case any trenchant observant readers wish to attempt that, I’ve published a spreadsheet here (in .CSV format) which lists the date, duration, size and type of attack used in DDoS campaigns against KrebsOnSecurity.com over the past four years.”
• Some comments about the “mega” attacks on Kreb’s site:
• “We haven’t seen GRE really play a major role in attacks until now. It’s basically a UDP flood with a layer-7 component targeting GRE infrastructure. While it’s not new, it’s certainly rare.”
• “Overall, Columbia was the top source of attack traffic. This is surprising, because Columbia has not been a major source of attack traffic in the past. While Columbia only accounted for approximately 5% of the traffic in the Mirai-based attacks, it accounted for nearly 15% of all source IPs in the last four attacks. A country that was suspiciously missing from both top 10 lists was the u.s. With regards to Mirai, this may be due to a comparative lack of vulnerable and compromised systems, rather than a conscious decision not to use systems in the u.s.”
• “There are a few distinctive programming characteristics we initially discovered in our lab, and later confirmed when the source code was published, which have helped identify Mirai-based traffic. At the end of the day what Mirai really brings to the table is a reasonably well written and extensible code base. It’s unknown as to what Mirai may bring in the foreseeable future but it is clear that it has paved the way for other malicious actors to create variants that improve on its foundation.”
• The full report can be downloaded here
• Some other data from the report:
• “Last quarter we reported a 276% increase in NTP attacks compared with Q2 of 2015. This quarter, we analyzed NTP trends over two years and have noticed shrinking capabilities for NTP reflection.” — It is good to finally see NTP falling off the attack charts as it gets patched up
• “Web application attack metrics around the European Football Cup Championship Game and the Summer Games, as analyzed in the Web Application Attack Spotlight, show us that while malicious actors take advantage of high-profile events, there’s also a lull that indicates they might like to watch them.” (see page 26)
• Application Layer DDoS attacks (GET/HEAD/POST/PUT etc) account for only 1.66% of DDoS attacks. Most attacks are aimed at the infrastructure layer (IP and TCP/UDP)
• “Repeat DDoS Attacks by Target / After a slight downturn in Q2 2016, the average number of DDoS attacks increased to an average of 30 attacks per target, as shown in Figure 2-13. This statistic reflects that once an organization has been attacked, there is a high probability of additional attacks.”
• SQL Injection (49%) and Local File Inclusion (40%) make up the greatest share of attacks against web applications

Is your server (N)jinxed ?

• A flaw in the way Debian (and Ubuntu) package nginx, can allow your server to be compromised.
• The flaw allows an attacker who has managed to gain control of a web application, like wordpress, to escalate privileges from the www-data user to root.
• “Nginx web server packaging on Debian-based distributions such as Debian or Ubuntu was found to create log directories with insecure permissions which can be exploited by malicious local attackers to escalate their privileges from nginx/web user (www-data) to root.”
• “The vulnerability could be easily exploited by attackers who have managed to compromise a web application hosted on Nginx server and gained access to www-data account as it would allow them to escalate their privileges further to root access and fully compromise the system.”
• The attack flow works as follows:
  • Compromise a web application
  • Run the exploit as the www-data user
  • Compile your privilege escalation shared library /tmp/privesclib.c
  • Install your own low-priv shell (maybe /bin/bash, or an exploit) as /tmp/nginxrootsh
  • Take advantage of the permissions mistake where /var/log/nginx is writable by the www-data user, and replace error.log with a symlink to /etc/ld.so.preload
  • Wait for nginx to be restarted or rehashed by logrotate
  • When nginx is restarted or rehashed, it creates the /etc/ld.so.preload file
  • Add the /tmp/privesclib.so created earlier to /etc/ld.so.preload
  • Run sudo, which will now load /tmp/privesclib.so before other libraries, running the code
  • sudo will not allow the www-data user to do any commands, but before sudo read its config file, it ran privesclib.so, which made /tmp/nginxrootsh setuid root for us
  • Run /tmp/nginxrootsh as any user, and you now have a shell as the root user
  • The now own the server
• Video Proof of Concept
• Fixes:
• Debian: Fixed in Nginx 1.6.2-5+deb8u3
  • Ubuntu 14.04 LTS: 1.4.6-1ubuntu3.6
  • Ubuntu 16.04 LTS: 1.10.0-0ubuntu0.16.04.3
  • Ubuntu 16.10: 1.10.1-0ubuntu1.1
• Make sure your log directory is not writable by the www-data user

Hacking 27% of the web via WordPress Auto-update

• “At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related wordpress.org systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites.”
• “The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.”
• “The server api.wordpress.org has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.”
• “Compromising this server could allow an attacker to supply their own URL to download and install software to WordPress websites, automatically. This provides a way for an attacker to mass-compromise WordPress websites through the auto-update mechanism supplied by api.wordpress.org. This is all possible because WordPress itself provides no signature verification of the software being installed. It will trust any URL and any package that is supplied by api.wordpress.org.”
• “We describe the technical details of a serious security vulnerability that we uncovered earlier this year that could compromise api.wordpress.org. We reported this vulnerability to the WordPress team via HackerOne. They fixed the vulnerability within a few hours of acknowledging the report. They have also awarded Wordfence lead developer Matt Barry a bounty for discovering and reporting it.”
• “api.wordpress.org has a GitHub webhook that allows WordPress core developers to sync their code to the wordpress.org SVN repository. This allows them to use GitHub as their source code repository. Then, when they commit a change to GitHub it will reach out and hit a URL on api.wordpress.org which then triggers a process on api.wordpress.org that brings down the latest code that was just added to GitHub.”
• “The URL that GitHub contacts on api.wordpress.org is called a ‘webhook’ and is written in PHP. The PHP for this webhook is open source and can be found in this repository. We analyzed this code and found a vulnerability that could allow an attacker to execute their own code on api.wordpress.org and gain access to api.wordpress.org. This is called a remote code execution vulnerability or RCE.”
• “If we can bypass the webhook authentication mechanism, there is a POST parameter for the GitHub project URL that is passed unescaped to shell_exec which allows us to execute shell commands on api.wordpress.org. This allows us to compromise the server.”
• There is security built into the system. Github hashes the JSON data with a shared secret, and submits the hash with the data. The receiving side then hashes the JSON with its copy of the shared secret. If the two hashes match, the JSON must have been sent by someone who knows the shared secret (ideally only api.wordpress.com and github)
• There is a small catch
• “GitHub uses SHA1 to generate the hash and supplies the signature in a header: X-Hub-Signature: sha1={hash}. The webhook extracts both the algorithm, in this case ‘sha1’, and the hash to verify the signature. The vulnerability here lies in the fact the code will use the hash function supplied by the client, normally github. That means that, whether it’s GitHub or an attacker hitting the webhook, they get to specify which hashing algorithm is used to verify the message authenticity”
• “The challenge here is to somehow fool the webhook into thinking that we know the shared secret that GitHub knows. That means that we need to send a hash with our message that ‘checks out’. In other words it appears to be a hash of the message we’re sending and the secret value that only api.wordpress.org and GitHub know – the shared secret.”
• “As we pointed out above, the webhook lets us choose our own hashing algorithm. PHP provides a number of non-cryptographically secure hashing functions like crc32, fnv32 and adler32, which generate a 32bit hash vs the expected 160 bit hash generated by SHA1. These hashing functions are checksums which are designed to catch data transmission errors and be highly performant with large inputs. They are not designed to provide security.”
• So instead of having to brute force a 160 bit hash (1.46 with 48 zeros after it) you only have to brute force 32 bits (4 billion possibilities). But it gets even easier
• “Of these weak algorithms, the one that stood out the most was adler32, which is actually two 16 bit hashing functions with their outputs concatenated together. Not only are the total number of hashes limited, but there’s also significant non-uniformity in the hash space. This results in many hashes being the same even though they were supplied with different inputs. The distribution of possible checksum values are similar to rolling dice where 7 is the most likely outcome (the median value), and the probability of rolling any value in that range would work its way out from the median value (6 and 8 would have the next highest probability, and on it goes to 2 and 12).”
• “The proof of concept supplied in the report utilizes the non-uniformity by creating a profile of most common significant bytes in each 16 bit hash generated. Using this, we were able to reduce the amount of requests from 2^32 to approximately 100,000 to 400,000 based on our tests with randomly generated keys.”
• “This is a far more manageable number of guesses that we would need to send to the webhook on api.wordpress.org which could be made over the course of a few hours. Once the webhook allows the request, the attack executes a shell command on api.wordpress.org which gives us access to the underlying operating system and api.wordpress.org is compromised.”
• “From there an attacker could conceivably create their own update for all WordPress websites and distribute a backdoor and other malicious code to more than one quarter of the Web. They would also be able to disable subsequent auto-updates so that the WordPress team would lose the ability to deploy a fix to affected websites.”
• “We confidentially reported this vulnerability on September 2nd to Automattic and they pushed a fix to the code repository on September 7th. Presumably the same fix had been deployed to production before then.”
• “We still consider api.wordpress.org a single point of failure when distributing WordPress core, plugins and theme updates. We have made attempts to start a conversation with members of Automattic’s security team about improving the security posture of the automatic update system, but we have not yet received a response.”

Feedback:

• Network Test

• SLOW FreeNAS FIXED

• Obligatory ZFS question / feature request

• ZFS replication for backup

Round Up:

• cURL Author: People email me asking for support with their Car’s infotainment system
• Another malicious link that can cause any iOS device to freeze & require a hard reset
• Walmart testing using the blockchain to track food recalls
• Attacking the Washington, D.C. Internet Voting System
• Uber Portal Leaked Names, Phone Numbers, Email Addresses, Unique Identifiers
• Mapping Malware Attack Methodology to Controls
• CocaCola moves most of their data to the cloud, but won’t store its secret formula in the cloud.
• Kaspersky OS: Antivirus Firm Launches Its Own “Hackproof” OS, Based On Microkernel
• Oracle acquires DNS provider Dyn
• Exploit Code Released for NTP Vulnerability
• Vulnerability in InPage publishing software used in attacks against banks

The post Turkey.deb | TechSNAP 294 first appeared on Jupiter Broadcasting.

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Show Notes:

Krebs hit with record breaking DDoS attack

• “On Tuesday evening, KrebsOnSecurity.com was the target of an extremely large and unusual distributed denial-of-service (DDoS) attack designed to knock the site offline. The attack did not succeed thanks to the hard work of the engineers at Akamai/Prolexic, the company that protects my site from such digital sieges. But according to Akamai, it was nearly double the size of the largest attack they’d seen previously, and was among the biggest assaults the Internet has ever witnessed.”
• “The attack began around 8 p.m. ET on Sept. 20, and initial reports put it at approximately 665 Gigabits of traffic per second. Additional analysis on the attack traffic suggests the assault was closer to 620 Gbps in size, but in any case this is many orders of magnitude more traffic than is typically needed to knock most sites offline.”
• “Martin McKeay, Akamai’s senior security advocate, said the largest attack the company had seen previously clocked in earlier this year at 363 Gbps. But he said there was a major difference between last night’s DDoS and the previous record holder: The 363 Gpbs attack is thought to have been generated by a botnet of compromised systems using well-known techniques allowing them to “amplify” a relatively small attack into a much larger one.”
• Almost all of the previous large scale DDoS attacks were the result of ‘reflection’ and ‘amplification’ attacks
• That is, exploiting DNS, NTP, and other protocols to allow the attackers to send a small amount of data, while spoofing their IP address to that of the victim, and cause the reflection server to send a larger amount of data.
• Basically, have your bots send spoofed packets of a few bytes, and the reflector send as much as 15 times the amount of data to the victim. This attack harms both the victim and the reflector.
• Thanks to the hard work of many sysadmins, most DNS and NTP servers are much more locked down now, and reflection attacks are less common, although there are still some protocols vulnerable to amplification that are not as easy to fix
• “In contrast, the huge assault this week on my site appears to have been launched almost exclusively by a very large botnet of hacked devices. According to Akamai, none of the attack methods employed in Tuesday night’s assault on KrebsOnSecurity relied on amplification or reflection. Rather, many were garbage Web attack methods that require a legitimate connection between the attacking host and the target, including SYN, GET and POST floods.”
• “There are some indications that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords.”
• “I’ll address some of the challenges of minimizing the threat from large-scale DDoS attacks in a future post. But for now it seems likely that we can expect such monster attacks to soon become the new norm.”
• “Many readers have been asking whether this attack was in retaliation for my recent series on the takedown of the DDoS-for-hire service vDOS, which coincided with the arrests of two young men named in my original report as founders of the service.”
• “I can’t say for sure, but it seems likely related: Some of the POST request attacks that came in last night as part of this 620 Gbps attack included the string “freeapplej4ck,” a reference to the nickname used by one of the vDOS co-owners.”

The shot heard round the world

• In this followup post, Krebs discusses “The Democratization of Censorship”
• You no longer need to be a nation state to censor someone, you just need a big enough botnet
• “Allow me to explain how I arrived at this unsettling conclusion. As many of you know, my site was taken offline for the better part of this week. The outage came in the wake of a historically large distributed denial-of-service (DDoS) attack which hurled so much junk traffic at Krebsonsecurity.com that my DDoS protection provider Akamai chose to unmoor my site from its protective harbor.”
• “Let me be clear: I do not fault Akamai for their decision. I was a pro bono customer from the start, and Akamai and its sister company Prolexic have stood by me through countless attacks over the past four years. It just so happened that this last siege was nearly twice the size of the next-largest attack they had ever seen before. Once it became evident that the assault was beginning to cause problems for the company’s paying customers, they explained that the choice to let my site go was a business decision, pure and simple.”
• This poses a huge problem. The bad guys now know the magic number, 650 gbps, at which point even the most expensive DDoS protection service will boot you off and shutdown your site.
• “Nevertheless, Akamai rather abruptly informed me I had until 6 p.m. that very same day — roughly two hours later — to make arrangements for migrating off their network. My main concern at the time was making sure my hosting provider wasn’t going to bear the brunt of the attack when the shields fell. To ensure that absolutely would not happen, I asked Akamai to redirect my site to 127.0.0.1 — effectively relegating all traffic destined for KrebsOnSecurity.com into a giant black hole.”
• “Today, I am happy to report that the site is back up — this time under Project Shield, a free program run by Google to help protect journalists from online censorship. And make no mistake, DDoS attacks — particularly those the size of the assault that hit my site this week — are uniquely effective weapons for stomping on free speech, for reasons I’ll explore in this post.”
• This raises another question, what happens when the bad guys perform an attack large enough to disrupt Google?
• This was the topic of the closing keynote at EuroBSDCon last weekend, sadly no video recordings are available.
• “Why do I speak of DDoS attacks as a form of censorship? Quite simply because the economics of mitigating large-scale DDoS attacks do not bode well for protecting the individual user, to say nothing of independent journalists.”
• “In an interview with The Boston Globe, Akamai executives said the attack — if sustained — likely would have cost the company millions of dollars. In the hours and days following my site going offline, I spoke with multiple DDoS mitigation firms. One offered to host KrebsOnSecurity for two weeks at no charge, but after that they said the same kind of protection I had under Akamai would cost between $150,000 and $200,000 per year.”
• “Earlier this month, noted cryptologist and security blogger Bruce Schneier penned an unusually alarmist column titled, “Someone Is Learning How to Take Down the Internet.” Citing unnamed sources, Schneier warned that there was strong evidence indicating that nation-state actors were actively and aggressively probing the Internet for weak spots that could allow them to bring the entire Web to a virtual standstill.”
• “Someone is extensively testing the core defensive capabilities of the companies that provide critical Internet services,” Schneier wrote. “Who would do this? It doesn’t seem like something an activist, criminal, or researcher would do. Profiling core infrastructure is common practice in espionage and intelligence gathering. It’s not normal for companies to do that.”
• “Furthermore, the size and scale of these probes — and especially their persistence — points to state actors. It feels like a nation’s military cyber command trying to calibrate its weaponry in the case of cyberwar. It reminds me of the US’s Cold War program of flying high-altitude planes over the Soviet Union to force their air-defense systems to turn on, to map their capabilities.”
• “What exactly was it that generated the record-smashing DDoS of 620 Gbps against my site this week? Was it a space-based weapon of mass disruption built and tested by a rogue nation-state, or an arch villain like SPECTRE from the James Bond series of novels and films? If only the enemy here was that black-and-white.”
• “No, as I reported in the last blog post before my site was unplugged, the enemy in this case was far less sexy. There is every indication that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — mainly routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords. Most of these devices are available for sale on retail store shelves for less than $100, or — in the case of routers — are shipped by ISPs to their customers.”
• “Some readers on Twitter have asked why the attackers would have “burned” so many compromised systems with such an overwhelming force against my little site. After all, they reasoned, the attackers showed their hand in this assault, exposing the Internet addresses of a huge number of compromised devices that might otherwise be used for actual money-making cybercriminal activities, such as hosting malware or relaying spam. Surely, network providers would take that list of hacked devices and begin blocking them from launching attacks going forward, the thinking goes.”
• While we’d like to think that the hacked devices will be secured, the reality is that they probably won’t be. Even if there was a firmware update, how often do people firmware update their IP Cameras? Their DVRs?
• The cable companies might be able to help by pushing firmware updates, and they have some incentive to do so, as the attacks use up their bandwidth
• In the end, even if ISPs notified their customers that they were part of the attack, how is a regular person supposed to determine which of the IoT devices was used as part of the attack?
• If you don’t know how to use a protocol analyzer, and the attack is not ongoing right now, how do you tell if it was your DVR, your SmartTV, your Thermostat, or your refrigerator that was attacking Krebs?
• And if we thought that 650 gbps was enough to make almost any site neel to an attacker, OVH.net reports a botnet of 150,000 CCTV/Camera/DVR units, each with 1 – 30 mbps of upload capacity, attacking their network with a peak of 1.1 terabits (1100gbps) of traffic, but they estimate the capacity of the botnet at over 1.5 terabits
• “I don’t know what it will take to wake the larger Internet community out of its slumber to address this growing threat to free speech and ecommerce. My guess is it will take an attack that endangers human lives, shuts down critical national infrastructure systems, or disrupts national elections.”
• “The sad truth these days is that it’s a lot easier to censor the digital media on the Internet than it is to censor printed books and newspapers in the physical world. On the Internet, anyone with an axe to grind and the willingness to learn a bit about the technology can become an instant, self-appointed global censor.”
• The possible solutions presented at EuroBSDCon were even scarier. Breaking the Internet up along national borders, and only allowing traffic to pass between countries on regulated major services like Facebook and Google.
• Additional Coverage: Forbes
• Additional Coverage: Ars Technica

Firefox preparing to block Certificate Authority for violating rules

• “The organization that develops Firefox has recommended the browser block digital credentials issued by a China-based certificate authority for 12 months after discovering it cut corners that undermine the entire transport layer security system that encrypts and authenticates websites.”
• “The browser-trusted WoSign authority intentionally back-dated certificates it has issued over the past nine months to avoid an industry-mandated ban on the use of the SHA-1 hashing algorithm, Mozilla officials charged in a report published Monday. SHA-1-based signatures were barred at the beginning of the year because of industry consensus they are unacceptably susceptible to cryptographic collision attacks that can create counterfeit credentials. To satisfy customers who experienced difficulty retiring the old hashing function, WoSign continued to use it anyway and concealed the use by dating certificates prior to the first of this year, Mozilla officials said. They also accused WoSign of improperly concealing its acquisition of Israeli certificate authority StartCom, which was used to issue at least one of the improperly issued certificates.”
• “Taking into account all the issues listed above, Mozilla’s CA team has lost confidence in the ability of WoSign/StartCom to faithfully and competently discharge the functions of a CA,” Monday’s report stated. “Therefore we propose that, starting on a date to be determined in the near future, Mozilla products will no longer trust newly issued certificates issued by either of these two CA brands.”
• So, existing certificates will continue to work, to avoid impact on those who paid for certificates, but Mozilla will not trust any newly issued certificates
• “WoSign’s practices came under scrutiny after an IT administrator for the University of Central Florida used the service to obtain a certificate for med.ucf.edu. He soon discovered that he mistakenly got one for www.ucf.edu. To verify that the error wasn’t isolated, the admin then used his control over the github subdomains schrauger.github.com and schrauger.github.io to get certificates for github.com, github.io, and www.github.io. When the admin finally succeeded in alerting WoSign to the improperly issued Github certificates, WoSign still didn’t catch the improperly issued www.ucf.edu certificate and allowed it to remain valid for more than a year. For reasons that aren’t clear, Mozilla’s final report makes no explicit mention the certificates involving the Github or UCF domains, which were documented here in August.”
• Some other issues highlighted in the Mozilla report:
  • “WoSign has an “issue first, validate later” process where it is acceptable to detect mis-issued certificates during validation the next working day and revoke them at that point. (Issue N)”
  • “If the experience with their website ownership validation mechanism is anything to go by, It seems doubtful that WoSign keep appropriately detailed and unalterable logs of their issuances. (Issue L)”
  • “The level of understanding of the certificate system by their engineers, and the level of quality control and testing exercised over changes to their systems, leaves a great deal to be desired. It does not seem they have the appropriate cultural practices to develop secure and robust software. (Issue V, Issue L)”
  • “For reasons which still remain unclear, WoSign appeared determined to hide the fact that they had purchased StartCom, actively misleading Mozilla and the public about the situation. (Issue R)”
  • “WoSign’s auditors, Ernst & Young (Hong Kong), have failed to detect multiple issues they should have detected. (Issue J, Issue X)”
• Mozilla Report
• Mozilla Wiki: WoSign issues
• WoSign incident report

Feedback:

• Backups

• A Little Salty

• Salt SSH

• FreeNAS

• FreeNAS(found a bug), and ZFS stripe with 4-SSD use case question

• Content Filtering HTTPS on pfSense with no proxy

• NFS vs Samba

Round Up:

• macOS Sierra Addresses Dropbox Security Concerns by Explicitly Asking for Accessibility User Permission
• How to crash systemd in one tweet
• How the Seattle Police Secretly—and Illegally—Purchased a Tool for Tracking Your Social Media Posts
• Hacking Tesla cars, locally and remotely
• A Pokemon Go guide infected thousands of phones
• New 2.5 and 5 gbps ethernet standards approved. Allows 2.5 gbps over standard cat 5e cables, and 5gbps over cat6
• Apple Logs Your iMessage Contacts — and May Share Them With Police
• Money Mules now using Bitcoin ATMs
• Firefox is eating your SSD – here is how to fix it
• Disassembly of Super Mario Bros.
• Heads up: CentOS 5 goes end-of-life in 6 months
• What happens when you don’t test your backups
• Russia Bans Pornhub, YouPorn – Tells Citizens To Meet Someone In Real Life

The post Botnet of Things | TechSNAP 286 first appeared on Jupiter Broadcasting.

Is it time to replace openSSL? We’ll follow up on the Heartbleed story, discuss how attackers got read access to Google’s production servers and then it’s a great batch of your questions and our answers.

All that and much much more…

On this week’s TechSNAP!

Thanks to:

— Show Notes: —

Heartbleed followup

• The developer who introduced the heartbeat feature, that lead to the heartbleed flaw, claims it was an honest mistake and denies the involvement of any intelligence agencies or other mischief
• An investigation and some insider info has allowed the construction of a more much accurate timeline of the events leading up to heartbleed and the breakdown of responsible disclosure
• 2014-03-21 (or earlier): Neel Mehta of Google Security discovers Heartbleed vulnerability
• 2014-03-21: Bodo Moeller and Adam Langley of Google commit a patch for the flaw (based on timestamp of the patch sent to OpenSSL and Redhat)
• 2014-03-31 (or earlier): CloudFlare is notified about the flaw under a non-disclosure agreement
• 2014-04-01: Google notifies OpenSSL of the flaw. OpenSSL was going to release a patch that week, but changed the planned release to April 9th to allow more coordination
• 2014-04-02: Researchers at Codenomicon find the same bug
• 2014-04-03: Codenomicon notifies NCSC-FI
• 2014-04-04: Akamai finds out about the bug from an undisclosed source and patches their servers
• 2014-04-04: Rumors begin about a flaw in OpenSSL, but no details are available
• 2014-04-05: Codenomicon purchases the heartbleed.com domain, OpenSSL team commits the Google patch to their private git repo
• 2014-04-06: NCSC-FI (CERT-FI) requests that CERT/CC (Computer Emergency Response Team Coordination Center) allocate a CVE for the bug, no details given. Mark Cox of OpenSSL notifies Redhat about the issue and asks them to coordinate with the other operating systems since Mark is on holiday. RedHat security engineer sends the email to the private distributions list with no details, distros that agree to the embargo (no notification until April 9th) are given the details. These distros include SuSE (Monday, April 7 at 01:15), Debian (01:16), FreeBSD (01:49) and AltLinux (03:00). Other operating systems, Ubuntu (asked at 04:30), Gentoo (07:14) and Chromium (09:15), request details during the night, but by time the RedHat engineer gets up in the morning, the flaw has become public
• 2014-04-07 (or earlier): Facebook is notified and patches their servers
• 2014-04-07: NCSC-FI notifies OpenSSL that Codenomicon has discovered a flaw. OpenSSL team decides that \”the coincidence of the two finds of the same issue at the same time increases the risk while this issue remained unpatched. OpenSSL therefore released updated packages [later] that day.\”
• 2014-04-09: Facebook and Microsoft donate $US15,000 to Neel Mehta via the Internet Bug Bounty program for finding the OpenSSL bug. Mehta gives the funds to the Freedom of the Press Foundation
• In summary, those who knew about the issue before it was public: Google (March 21 or prior), CloudFlare (March 31 or prior), OpenSSL (April 1), Codenomicon (April 2), National Cyber Security Centre Finland (April 3), Akamai (April 4 or earlier) and Facebook (no date given)
• Those who had a few hours of advanced warning: SuSE, Debian, FreeBSD and AltLinux
• There is also a timeline from the perspective of the OpenSSL team
• Researchers at Lawrence Berkeley National Laboratory find No evidence that heartbleed was exploited before it became public
• Meanwhile, researchers at the University of Michigan setup a honeypot and monitored who tried to heartbleed it. Of the 41 groups that attacked the honeypot, the majority of those groups — 59 percent — were in China.
• What is worse than heartbleed? Bugs in heartbleed detection scripts
• Akamai claimed to be protected from heartbleed by their own patches
• They were proven wrong
• Akamai updated their blog post explaining the fault
• Akamai was forced to rekey all of their customers’ SSL certificates

• The Akamai post raises an interesting questions about EV-SSL certificates, and how much longer they might take to re-key

• Is the IETF to blame for allowing the heartbeat feature to be added to the standard in the first place?

• See BSD Now episode 033 for news on the OpenBSD fork of OpenSSL
• Why I quit writing Internet standards
• Statement by the CRA about 900 SIN numbers leaking due to heartbleed
• RCMP arrests 19 year old from London, Ontario for using heartbleed against the CRA
• CloudFlare launched a challenge to see if anyone could capture their private key
• two or more people were successful, and the certificate has since been revoked
• ACM Queue – PHK: Putting OpenSSL out of its misery
• PHK shares his experience making a living while working on open source in “Raking in the dough on Free and Open Source Software”
• Open source is a thankless job, we do it anyway
• Does the OpenSSL flaw alter the “open source is safer” equation?
• Coverity report finds open source software to be higher quality Coverity\’s analysis found an average defect density of .59 for open source C/C++ projects that leverage the Scan service, compared to an average defect density of .72 for proprietary C/C++ code
• 863 CIOs surveyed, 18% said their orgs are unaffected by Heartbleed because they use anti-virus

How we got read access to Google’s production servers

• A group of researchers decided to target Google
• Looking at the trends in the industry, flaws are most often found in:
• Old and deprecated software
• Unknown and hardly accessible software
• Proprietary software that only a few people have access to
• Alpha/Beta releases and otherwise new technologies
• So they did their homework
• They used the Google search engine, to search for software and companies that Google had acquired, antique systems, and products with very few users
• They found the Google Toolbar button gallery
• The product allows users to customize the toolbar by uploading XML that controls the style etc
• They quickly managed to perform an XXE attack
• They were then able to read files on Google’s production servers, including /etc/passwd, and some custom init scripts that Google uses to manage their cluster of servers
• They likely could have escalated the attack, and possibly accessed Google’s internal servers
• The team reporting the issue to Google, and was awarded a $10,000 bug bounty

Feedback:

• LastPass

• Automated bare-metal backups for a physical server?

• SLAs and Daylight Savings

• pfsense and logs

• Heartbleed

• Memory allocation in OpenSSL

Round Up:

• PSA: Fraudulent Crypto Kickstarter Campaign
• weev (AT&T iPad data incident) conviction vacated, the information was not protected by a password or other security mechanism, so accessing it was not “misuse”
• HAM Radio operators accidently tripping arc fault circuit interrupters, American Radio Relay League labs working with manufacturer on fix
• When Azure breaks: Lessons for every cloud programmer
• Obama: NSA Must Reveal Bugs Like Heartbleed, Unless They Help the NSA
• Canadian Government publishes guidelines for staying safe online
• Comcast PAC gave money to every senator examining Time Warner Cable merger | Ars Technica
• 7 Habits of highly successful UNIX admins
• Over $100K in Bitcoin Was Stolen in a Ridiculously Low-Tech Heist

The post Time to Kill openSSL | TechSNAP 158 first appeared on Jupiter Broadcasting.

It’s never been easier to break a D-Link Router, we’ll share the details about the built in backdoor.

Plus a huge batch of Java fixes land, a look at iMessage security, and much much more!

On this week’s TechSNAP

Thanks to:

Reverse engineering a D-Link router

• Researchers found an authentication bypass backdoor in some D-Link routers
• Research was conducted on a D-Link DIR-100 revA
• The firmware is made by a company called Alpha Networks which was spun off from D-Link in 2003
• Other devices known to be vulnerable from D-Link:
  • DIR-100
  • DIR-120
  • DI-624S
  • DI-524UP
  • DI-604S
  • DI-604UP
  • DI-604+
  • TM-G5240
• Some devices from Planex appear to use the same firmware:
• BRL-04R
• BRL-04UR
• BRL-04CW
• If the router is accessed user a User-Agent string of: xmlset_roodkcableoj28840ybtide then the user bypasses the username/password requirement and has full access to the router
• If read backwards: edit by 04882 joel backdoor
• This backdoor also allows an attacker to perform remote code execution and could be used to infect a router with spyware
• D-Link promises to issue fixed firmware by the end of the month

Akamai finds most DDoS attacks come from Asia

• Threatpost reports on Akamai’s “State of the Internet report”
• Akamai is a global CDN that services many large websites including Microsoft Update
• “The Pacific rim region (especially China and Indonesia) accounted for just over 79 percent of all observed attacks” according to the firm’s studies
• The report also discussed the Syrian Electronic Army’s (SEA) and its attacks on media outlets, the exhaustion of IPv4 address space, and a rise in mobile data traffic
• The data does not quite match up with reports from other DDoS protection vendors
• The Prolexic report for Q1 2013 shows China as the source of 40.68% of all DDoS attacks, and Indonesia did not even register. USA: 21.88%, Germany: 10.59%
• The Prolexic report for Q2 2013 shows slightly different results, with China holding strong at 39.08% with Mexico coming in at a surprising second with 27.32% and Russian at 7.58%
• The wild differences are partly due to the fact that each company is measuring attacks against their clients, not the wider internet
• There is also the methodology for localizing the source of the attack to consider, GeoIP databases and the like are often inaccurate
• Each company may also have a different definition of a DDoS attack. Are bots crawling a website an attack? What about SQL injection attempts?

Oracle releases the October Critical Patch Update, with updates for Java

• This is the first time that the Oracle quarterly CPU (Critical Patch Update) has included updates for Java, usually Java is updated on a separate cycle
• “Of the 51 Java patches released, 50 allow for remote code execution and 20 were given the highest criticality rating by Oracle”
• All users should immediately upgrade to Java 7u45
• Java 6 is vulnerable to nearly a dozen critical vulnerabilities, but updates are only provided to Oracle customers with support contracts (Apple)
• Rapid7 (maintainers of Metasploit) recommend that if you must use Java: “run Java in the most restricted mode and only allow signed applets from white-listed sites”
• “Noted Java bug hunter Adam Gowdiak told Threatpost that the patches also harden interactions of LiveConnect code, a browser feature that allows applets to communicate with the javascript engine in the browser, and Java Rich Internet Applications”
• “Overall, there are 127 patches in the Oracle CPU that touch most of the Oracle product line. Aside from the Java vulnerabilities, the only other bug approaching the same level of criticality is in MySQL Enterprise Monitor, but it is not a remote execution bug.“

Feedback:

• Performance question about nginx and uWSGI

• Getting started as a Systems Administrator

• Are Dynamic IP\’s that much of an issue?

[asa]0133390098[/asa]

• Technical Book Recommendation: Systems Performance by Brendon Gregg

Round-Up:

• iMessage Privacy
• Surge 2013 Lightning Talk – Brendon Gregg – Benchmarking gone wrong 17:30
• More than 35,000 vBulletin forums hacked weeks after release of fix for vulnerability
• THC: SSL/TLS IN A POST-PRISM ERA
• SQLi Capture the Flag, with Prizes Story
• Surge 2013 Lightning Talk – Bryan Cantrill – Fun with tail 41:00
• Flaws found in Linux /dev/random pRNG
  • Insecurities in the Linux /dev/random | Hacker News
• FreeBSD now goes up to 11
• World\’s 3rd Largest Chinese Bitcoin exchange hit by 100Gbps DDoS attack
• Why internet pathing matters
• Skype under investigation in Luxembourg over link to NSA
• PR Newswire hacked on or before March 8th, related to Adobe hack “It’s unsettling to imagine the possible outcomes if the stolen data fell into the hands of any groups that are trying to affect political and economic stability”
• Further evidence that attacks against Adobe and others are related to ColdFusion exploits

The post SoDDing D-Link Backdoor | TechSNAP 132 first appeared on Jupiter Broadcasting.