Show Notes:

Get TechSNAP on your Android:

• Callisto – Android App
• Jupiter Broadcasting – Android App by ShaneQful

Browser Affiliate Extension:

• Jupiter Broadcasting Affiliate Extensions for Chrome and Firefox

Amazon S3 buckets unknowingly exposed?

• Security researcher Digininja was watching an old Hak5 episode about Amazon S3 and decided to give the free trial from Amazon a try
• All S3 buckets are accessed as: bucketname.s3-region.amazonaws.com
• An S3 bucket can be marked as Public or Private
• If you access the root of a Public bucket, you are given a list of the files inside that bucket
• Public S3 buckets can contain files that are marked as either Public, or Private
• Attempting to access a file marked private without an access key will return a HTTP 403 error
• While experimenting, he found that if you try to access a bucket that is assigned to a different region, amazon gives you a helpful redirect message
• Based on this, Digininja decided to try a wordlist against the Amazon S3 subdomain, and see what he could find in other peoples’ buckets
• Digininja was surprised to find that many buckets were marked public, rather than private
• While scraping through the results, he found a number of documents that should have been marked private but were not, including a Ministry of Defence training requisition form (containing personal information including SSN), a spreadsheet containing the accounts of a company, and many personal photos and videos
• It seems a lot of people are unknowingly making the contents of the S3 buckets public
• A number of people also appear to be trying to use S3 as a CDN, using it to host the images for their website (S3 is not a CDN, it can be rather slow, Amazon has a separate service to serve the contents of S3 via a CDN, called CloudFront)
• Researcher’s Blog Post
• Researcher’s Findings Post

---

The narrowly avoided Great KDE Disaster of 2013

• On March 22nd, the server that hosts git.kde.org was shut down for security updates, when it restarted there was evidence of file system corruption
• The original cause of the problem was not determined
• The real problem came, when the anongit mirrors of the 1500 KDE repositories mirrored the corrupt data, and there were no uncorrupt mirrors left
• The problem stems from the fact that in the replication strategy, git.kde.org was always considered to be correct
• The system they had in placed relied on the ability to sync an anongit mirror back upstream if there was a problem with the master
• It seems that git –mirror just copies data from the master, without the usual verification and safety measures that happen in git clone
• Luckily, KDE was in the process of replacing the projects.kde.org server, and it happened to have a mirror of the git repo from before the corruption, and they were able to restore git.kde.org from that
• The article goes on to discuss a number of the steps they are taking to make their system more robust in the future
• Update with more information to responses to common comments
• The update addresses the sysops 101 adage “mirrors are not backups”
• It talks about the problems they have with traditional backup systems
• tar: how do you take a tar archive of a live system? keeping .tar files going back 30+ days would take too much space (or cost to much to use S3 etc)
• rsync: same problem with a live system and rsync creates a mirror, which is not a backup
• Any answer? ZFS
• ZFS RAID Z, and ZFS snapshots are STILL not a backup
• But a ZFS snapshot can allow you to take a tar archive of a consistent version of the repo (no files will change with the tar is being made, since snapshots are read only
• Or better yet, you could store the actual ZFS snapshots (via ZFS send), so that you are basically getting ‘incremental’ backups, only the changed blocks are stored in each snapshot (requires that you keep and initial full snapshot and all incremental snapshots since then). Managing this can be difficult
• Backup software such as Bacula, running off the snapshots, would be the best solution

---

The root of the Java problem

• According to research by Websense, 93.77% of all installs of Java that were surveyed are vulnerable to at least one known exploit
• 75% of devices run a version that is at least 6 months old, 50% more than 2 years old
• 79% of devices are using some version of Java 6, which has now reached its End-Of-Live

---

Feedback:

• How can I go about telling my university that it has a vulnerability?

• pfSense question

• Getting started with KDE on FreeBSD?

• Nginx best-practice user setup

• Dump of username attempts for SSH login

• How I feel, as a Linux user, when Allan mentions ZFS.

---

Round Up:

• Apple finally enabled Two-Factor authentication for My Apple ID
• Mastercard hits PayPal and other Intermediaries with new higher per-transaction fee this June, because they do not disclose what you bought
• DHS to start scanning more internet traffic, moving from just Defense Contractors to ‘Infrastructure’ including banks and some transportation companies
• FBI’s top priority in 2013? Real-time spying on Gmail, Dropbox and Skype
• Server Room Cabling Hell: 15 of the Worst Server Wiring Jobs Ever!
• Paypal To Drop VMware From 80,000 Servers and Replace It With OpenStack
• “Perfect storm” pushes Bitcoin to $1b Market Cap Closer Toward the $100 per-coin mark
• Canadian Supreme Court rules that police need a warrent to read your text messages
• Egyptian navy arrests 3 attempting to sabotage undersea internet cable

---

The post Time to Git ZFS | TechSNAP 103 first appeared on Jupiter Broadcasting.

]]>