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.
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.
Posted: Feb 06, 2018
Keyword tags: CSS Exfilexploitweb security
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.
Posted: Dec 21, 2017
Keyword tags: electronicsmake555 timerlegoradioantenna
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.
Posted: Dec 12, 2017
Keyword tags: securityinfoseccybersecurityowaspremote vulnerabilitys3
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. The Certificate Transparency project makes this easy.
Posted: Nov 16, 2017
Keyword tags: infoseccybersecuritycertificate transparencylets encryptphishing
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.
Fortunately, you can protect yourself, with encryption.
Posted: Oct 18, 2017
Keyword tags: securityhackingkrackwpa2
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!)
Posted: Oct 10, 2017
Keyword tags: securityhackingphishing
In light of the recent data breach at Equifax I'm composing some thoughts in two posts. The first post discusses the weaknesses in employing partial security solutions. This second post discusses why organizations must employ offensive security to stay ahead.
Hot off the Equifax news, last week we heard about a breach of the SEC EDGAR reporting system, and announced yesterday, Deloitte's private communications. Organizations must start to think like would be attackers.
Offensive security is 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.
Posted: Sep 26, 2017
Keyword tags: securityhackinginfosecoffensivesecurity
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 package Apache 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!
Posted: Sep 21, 2017
Keyword tags: securityhackinginfosec
Posted: Aug 31, 2017
Keyword tags: securityhackingremote vulnerabilityssllets encrypt
Posted: Feb 25, 2016
Keyword tags: shortwavetransmitterqrpschematicAM transmitterelectronics500mW
Posted: Feb 13, 2014
Keyword tags: raspberry piarcademakeelectronics
Posted: Dec 24, 2013
Keyword tags: arduinoelectronicsclockRTCshift registers
Posted: Jun 17, 2013
Keyword tags: amateur radioelectronicsmakeDIYmakeRF
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!
So, what was happening, and how did I fix it?
Posted: May 22, 2013
Keyword tags: arduinocircuitselectronicsdoorbellschematicfilter
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.
Posted: Mar 27, 2013
Keyword tags: arduinocircuitselectronicsdoorbellschematiclm386
Posted: Jun 13, 2012
Keyword tags: google voiceland linenumber porting