Earlier this year I was asked to perform anOWASP ASVS (Application Security Verification Standard)with a colleague on a client's deployment of the web-based file-sharing softwarePydio. After getting my feet wet looking at the codebase, my interest was piqued in the platform and decided to independently research the software for vulnerabilities.

The following vulnerability disclosure is a detailed account of my findings. Four areas of weakness were identified: multiple XSS flaws, a credentialed SSRF flaw, multiple methods to discover the remote version of the software, and a credentialed Remote Code Execution flaw. After discussion with the Pydio developers, two of the flaws were fixed in the8.2.1 release. The remaining issues were not addressed due to the reasons discussed in the disclosure. A workaround is included for one of these issues, providing additional protections for those who may require it.

Update October 2018: The vendor has released Pydio 8.2.2, which includes an official fix for the credentialed Remote Code Execution flaw. The disclosure has been updated to reflect the new release.

Earlier this week I had the privilege of providing insight for aBleeping Computer articleabout the impending time-bomb that is world-writable Amazon S3 buckets. While S3 security is not a new topic, what gets the most attention are world-readable S3 buckets containing sensitive & confidential data. In fact,FedEx was in the news last weekfor leaking sensitive passport data via S3. However, the S3 insecurity topic this week is renewed interest in world-writable buckets.

A quick aside for folks new to the topic: S3 is a product provided through Amazon Web Services that allows anyone to create cloud-based file storage. These so called 'buckets' are basically virtual internet accessible hard drives. Unfortunately, they are often misconfigured and allow misuse by attackers looking to steal or manipulate data.

What likely got conversation going again this week was asecurity researcher who began placing warning messagesin exposed writable S3 buckets with the filename POC.txt. The file itself was not malicious, but warned the account owners that they are at risk to malicious attackers.

What might that risk be? Security expert Kevin Beaumontspeculated in a tweetthat these exposed files may be stolen and/or encrypted by attackers looking to extort companies for ransom. Others speculated that these open buckets are ripe targets to host cryptojacking scripts -- thelatest way attackers seek to monetize data breaches. (PS - If you want to understand the prevalence of cryptojacking, read the statistics published daily byBad Packets Report.)

Summary: A method is detailed - dubbed CSS Exfil - which can be used to steal targeted data using Cascading Style Sheets (CSS) as an attack vector. Due to the modern web's heavy reliance on CSS, a wide variety of data is potentially at risk, including: usernames, passwords, and sensitive data such as date of birth, social security numbers, and credit card numbers. The technique can also be used to de-anonymize users on dark nets like Tor. Defense methods are discussed for both website operators as well as web users, and a pair of browser extensions are offered which guard against this class of attack.

Want to check if you are vulnerable?

Want to protect yourself?

Install the Chrome or Firefox plugin.

Introducing CSS Exfil

Several months ago I began tinkering with Chrome's XSS auditor looking for bypasses. One remote injection method which reliably got through Chrome's filter was CSS injection. By utilizing injected CSS, an attacker essentially has complete control over the look-and-feel of a page. I also discovered an attacker can leverage CSS to steal form data. By utilizing CSS alone, browser protections like NoScript can't block the egress of data (although NoScript's XSS auditor is more effective than Chrome at blocking some of the injection Proof of Concept attacks detailed below).

While CSS injection is not a new vulnerability, using CSS as the sole attack vector to reliably exfiltrate data - to my knowledge - has never been presented. I am also not aware of any effective method previously documented to guard end users against such attack - other than to block CSS, which is not a practical solution.

My son loves building and Lego bricks are some of his favorite toys. He's also the son of a ham radio operator and is absolutely fascinated with radio antennas. For Christmas I built him a model radio tower complete with red pulsing lights and a Lego base.

Want to know an easy way to get hacked? Leave your sensitive data exposed publicly to the world.

It seems like not a week goes by without another story of a company or government leaking sensitive data on public AWS S3 buckets. S3 is a service that allows anyone to create cloud file storage, and by default is web accessible. Amazon recently made an update to their administration console to indicate if a 'bucket' is public, but there are a lot of historical/misconfigured buckets out there set as public when they should not be.

The issue is certainly not isolated to S3. I was recently evaluating a piece of software for a client and noticed that sensitive data was being exposed though cache files which were publicly accessible / unauthenticated in an open directory on their web server, if you knew where to look. Lucky for them there was no evidence that this data had been accessed, but it made me curious to evaluate the extent of publicly accessible open directories on the web.

Let's Encrypt announced this week they will begin issuing wildcard SSL certificates starting January 2018, a feature many have been hoping would be added to the service for years. While many will be rejoicing, it may get a little harder locating scammers and phishers.

While the vast majority of Let's Encrypt issued certificates are for legitimate domains, the service has become a sort of best practice for phishing campaigns. Why? SSL brings the illusion of trust to a URL. This has been compounded with most browsers indicating a site is "secure" in the URL bar, by merely serving a site up via https. Combine this with the fact that Let's Encrypt is a completely free service, and you have a breeding ground for scammers.

One reliable method security researchers use to enumerate domain names (determine all sub-domains of a domain name) is to monitor SSL certificate issuance. TheCertificate Transparency projectmakes this easy.

The KRACK vulnerability publicly announced yesterday dropped like a bombshell, because the decade and a half old WPA2 protocol was not only thought to be secure, but the attack presented seems so obvious in retrospect. There is a lot of online coverage and one of the best summaries was written by security expert Bruce Schneier.

I am skeptical that devices will be patched in a timely manner. Vendors had a head start to get patches ready before the public announcement, and while this is a rare time I will commend Microsoft, who patched the flaw ahead of public release, many vendors were left sitting on their hands.

The Android ecosystem is particularly vulnerable to KRACK, due to the so-called null key issue. Google won't have an official patch available for a couple weeks (although the LineageOS team has it fixed), but my guess is the large majority of Android devices in the wild will never see that patch applied to their phone.

Likewise, I don't have high hopes that my home FiOS router will be patched, considering that it's up-to-date with a firmware version over a year old. Something tells me KRACK isn't the only issue that may be lurking within the device.

I never trusted that router anyway.

KRACK underscores an important lesson. You can't trust your network. As soon as a packet leaves your computer or smartphone, assume always that it's being sniffed and manipulated. If not by your ISP, then by some compromised router deep on the internet, or perhaps now a couple hundred feet away from you by that wardriver cruising your neighborhood or corporate parking lot.

This discovery is similar to the Google Docs phishing attack earlier this year. While this isn't necessarily a direct flaw within iOS, the attack vector is subtle and I bet would fool many people. In fact, I would be surprised if this wasn't previously used in the wild for a targeted spear phishing campaign. (Edit: It appears that this flaw was uncovered back in 2015!)

When I saw Felix's proof of concept, the first thing I thought is that this can also be leveraged in a web browser; no app or Apple App Store approval needed. I spent about 30 - 45 minutes and was able to create a pretty close replica of the iOS login dialog using pure HTML/CSS, and for the modal popup effect a few lines of javascript. Since this was just a proof of concept I didn't want to belabor the work, but I bet with an additional hour it could be made be look pixel perfect. Javascript and CSS3 effects could handle the transitions to make it appear like it's part of the native the native iOS UI.

In light of the recent data breach at Equifax I'm composing some thoughts in two posts. Thefirst postdiscusses the weaknesses in employing partial security solutions. This second post discusses why organizations must employ offensive security to stay ahead.

Offensive securityis a school of thought, where a proactive approach is taken to computer security. When people typically think of security, the first thing that comes to mind are traditional/defensive approaches: e.g. patching systems, strong passwords, employing firewalls, etc. While defensive measures are essential, an offensive security approach focuses on penetration testing and thinking like an attacker, with a goal of finding weaknesses in your own organization's systems and software.

In light of the recent data breaches at Equifax I'm composing some thoughts in two posts. This first post details how organizations often miss the mark securing data due to partial security solutions.

As soon as news of the Equifax breaches hit the wire people were asking: How did this happen? All public accounts point to a vulnerability in the software packageApache Struts, that went unpatched in Equifax's systems for months. (Note that Apache Structs is different from the widely used Apache web server, although that distinction is meaningless for the purposes of this post).

That sounds pretty damning, but I'm not going to speculate why a software package went unpatched. It should have been patched - and swiftly - but what if the flaw was a so-called 0-day exploit without a patch? Would Equifax still be held liable for such a massive breach? The answer should be a resounding yes!

For the last couple years, I have extensively usedLet's Encryptto provide SSL certificates for websites I administer. I'm clearly not alone, as Let's Encrypt recently announced they have issued over100 million SSL certificates.

I'm a huge fan of their service, as I've always felt the CA (Certificate Authority) industry was a bit of a scam -- charging an arm and a leg for encryption certificates, for no other reason other than self-signed certificates are flagged as being 'unsafe' in most web browsers. Encryption is encryption, and a self signed cert is just as good as any in this respect (weak/flawed encryption algorithms/protocols notwithstanding). Let's Encrypt allows anyone to generate a certificate at no cost and install into their website with relative ease, and their goal of encrypting the entire internet is one I strongly support.

Recently I started playing around with the ACME validation routine Let's Encrypt uses to verify domain ownership, suspecting that it may be abused to issue an SSL certificate to an attacker.

I didn't set a stopwatch to time myself, but I can tell you that I was able to slap this rig together on a breadboard and tune it up very quickly. There are no coils to wind (unless you want to); it tunes a wide range of crystal frequencies, and it outputs an easy 500mW AM signal. I had three crystals on hand, and was able to load up frequencies 6925 kHz, 14322 kHz and 28266 kHz without problem.

A few months ago I came across the project on Adafuit Retro Gaming with Raspberry Pi, and thought it would make the perfect gift for my brother-in-law. I finally got around to building it with a few tweaks of my own.

A few months ago I came across an interesting project, an Arduino Word Clock. If you aren't familiar with the term, it's basically a clock that tells you the time as a sentence instead of with digits. So instead of 10:30pm, it would say, it is half past ten. The reported time accuracy is within 5 minutes, which is good enough for a general clock / interesting piece of art. I decided to build one as a Christmas present for my dad.

Although I read a few different designs on the web, I decided to take my own path and design my own. I encourage you to do the same; sometimes it's easier to do things the way you want to do them and look to others for inspiration, than follow instructions to the last detail.

The general steps are: 1) Create the clock face, 2) Wire the lights, 3) Build the driver for the lights, 4) Add the clock, and 5) Final assembly.

If you are interested in radio and hobby electronics be sure to check out my new website makeRF.com!

Amateur radio and hobby electronics are two of my favorite hobbies, and am always looking to interest others in the art. I launched makeRF as a platform for my own self-directed learning, and to share my builds and experiments for others to try out. I aim to present topics in an accessible format so beginners can take a stab at the projects, but also include interesting detail for those with more expertise.

If you read my last post, you saw my schematic on how to build a musical Arduino doorbell.

After the doorbell was installed, I noticed that it rang by itself sometimes. Not often enough to be too annoying, but enough to think about correcting the issue at some point. I noticed it rang sometimes when a large appliance clicked on, like the dishwasher or central air, and even sometimes when getting a static shock on a light switch.

My annoyance level went through the roof when a large thunderstorm rolled though one afternoon. During the fifteen minutes of thunder crashing, the doorbell rang by itself six times!

Earlier this year my family and I had the good fortune to move to our first home. The home had everything we wanted, except a working doorbell.

The original doorbell button was there, complete with decades of corrosion and wires that were cut between the button and what looked to be some sort of buzzer. Initially, I planned to buy a new chime and button at Home Depot, hook up the wires, and be done with it. The chime selection, however, was sub-par.

Apparently the doorbell market is dominated by ding-dong and Westminster. Growing up, my father built a doorbell that played the first two measures of Pictures at an Exhibition. Maybe I was spoiled listening to this during my formative years, but if I wanted a doorbell that played music, I needed to build it myself.

For the last year and a half I have been paying Verizon anywhere between $100 - $160 a month for a phone line and static DSL line into an office that I no longer occupy. I'm sure this sounds incredibly stupid, but the main reason I've kept paying is because the static IP hosted the main Kiddix development server and remote support server. I finally decided that this was too much money to be paying each month just to host these servers, so they got a new home. But, what to do with the phone number? Even though I use my cell phone as my primary business line, it's always been nice to have a second more public line, so I decided to try and keep the number.