Here's something to keep in mind when sharing files and storage with others: the mistakes of others can put you at risk.
There's not a lot of detail in this report, but it mentions cases where ransomware has spread through shared cloud storage (think iCloud, Dropbox, or Google Drive). If your friend or family member becomes infected, and you sync to the same shared account, you might unknowingly infect your device.
Ransomware is the current scourge of the Internet. Ransomware is malware that encrypts your personal data such as irreplaceable photos, documents, and financial records, making them unusable. It then charges a ransom fee to decrypt the files so you can use them again. The only fully reliable protection against this threat is a current and complete backup of your important data, stored somewhere out of the reach of the malware. Without such a backup, your only choices may be to pay the ransom or sacrifice the data forever.
While I have not personally experienced ransomware spreading in this manner, I did have an "oh crap" moment once when a child deleted music from a shared drive. I had set up a sizable library of (legally-owned!) music that they could download to their devices, and taught them how to use a mobile SMB client to browse the server; alas I was not clear enough in showing them the difference between "local device" and "shared server." When they wanted to remove music from their devices to make room for something new, one of them accidentally deleted some content from my server.
The point is, when sharing things with others, think of how their mistakes can put you at risk. In the music share scenario that I mentioned, I quickly learned to set the share so that my kids could only download music from it, but not change anything on the share itself. Only I could modify the contents of the share, and only from a PC that I controlled.
Similarly, you may consider whether sharing data in a read-only form is appropriate for your needs.
Monday, February 29, 2016
Tuesday, February 23, 2016
Apple Versus FBI - What does it really mean?
I have avoided weighing in on the FBI versus Apple fray thus far. While I have an opinion, there are people smarter than me, that are closer to the facts of the matter, and whose perspectives I hold in high regard. With that said, friends and family are turning to me as "the expert in their circle," to help them understand what is going on.
The time Thousand Foot Krutch taught me a cyber lesson
The end is where we begin
I'm a monster if that means I'm misunderstood
Cuz its alive and I can't hide it
The energy is rising
and I'm a traitor if that means I've turned on myself
"The End is Where We Begin," by Thousand Foot Krutch
I'm a monster if that means I'm misunderstood
Cuz its alive and I can't hide it
The energy is rising
and I'm a traitor if that means I've turned on myself
"The End is Where We Begin," by Thousand Foot Krutch
Thursday, February 18, 2016
glibc buffer overflow in DNS resolution (CVE-2015-754)
There is a serious bug in a commonly-used software library that can lead to a Linux computer being completely taken over by a malicious attacker. However, most consumers are not affected. Android is not vulnerable; the most common implementation for home routers and IoT devices is not vulnerable; and Apple iOS is unconfirmed as of this writing. Businesses and home users running full-fledged Linux distributions should patch quickly.
There are some functions that are so frequently used, it doesn't make sense for each software developer to write their own code. Reading files, downloading web pages, drawing a red circle on the screen, and looking up Internet addresses are a few examples. Instead of every developer writing their own way to handle these operations, they are written once and stored in a library for reuse by anyone.
GNU C Library, aka glibc, is such a library of commonly-used functions for software written in the C language to run in Linux. Its "getaddrinfo()" function is used by the client side DNS resolver, a service that translates human-friendly websites names into computer-friendly network addresses.
This function has a flaw: when making a DNS request, it allocates 2048 bytes of memory for the answer, but does not check that the answer it receives fits in that buffer. A malicious DNS server or a man-in-the-middle attacker could provide a DNS answer that is larger than 2048 bytes, overflowing the buffer and potentially allowing the attacker to execute malicious commands.
Here's the rub: glibc isn't just one program: it's a library used by untold numbers of programs. Depending on the developer's choices it may be embedded in the compiled program, or the program may make use of the library installed on the operating system. In the latter case, patches are available for many Linux distributions to fix the bug. In the former case however, the software developer must patch the library themselves and recompile the software.
The saving grace is, most consumers may not be affected. Most home routers, Blu-ray players, media streaming devices, and other Internet of Things devices are built on Linux - but often a tiny distribution such as BusyBox designed for embedded operating systems. These distributions use alternatives to glibc that may not be affected. Specifically, the uClibc library popular in embedded devices was fixed in 2010. Android is not affected as it uses the non-vulnerable Bionic library. iOS uses yet another library (BSD running libc rather than glibc); as of this writing I have not found confirmation that iOS is or is not vulnerable.
Links:
iptables -I FORWARD -p udp --dport 53 -j DROP
iptables -I FORWARD -p udp --sport 53 -j DROP
iptables -I FORWARD -p tcp --dport 53 -j DROP
iptables -I FORWARD -p tcp --sport 53 -j DROP
iptables -I FORWARD -d 208.67.220.123 -p udp --dport 53 -j ACCEPT
iptables -I FORWARD -d 208.67.222.123 -p udp --dport 53 -j ACCEPT
iptables -I FORWARD -s 208.67.220.123 -p udp --sport 53 -j ACCEPT
iptables -I FORWARD -s 208.67.222.123 -p udp --sport 53 -j ACCEPT
There are some functions that are so frequently used, it doesn't make sense for each software developer to write their own code. Reading files, downloading web pages, drawing a red circle on the screen, and looking up Internet addresses are a few examples. Instead of every developer writing their own way to handle these operations, they are written once and stored in a library for reuse by anyone.
GNU C Library, aka glibc, is such a library of commonly-used functions for software written in the C language to run in Linux. Its "getaddrinfo()" function is used by the client side DNS resolver, a service that translates human-friendly websites names into computer-friendly network addresses.
This function has a flaw: when making a DNS request, it allocates 2048 bytes of memory for the answer, but does not check that the answer it receives fits in that buffer. A malicious DNS server or a man-in-the-middle attacker could provide a DNS answer that is larger than 2048 bytes, overflowing the buffer and potentially allowing the attacker to execute malicious commands.
Here's the rub: glibc isn't just one program: it's a library used by untold numbers of programs. Depending on the developer's choices it may be embedded in the compiled program, or the program may make use of the library installed on the operating system. In the latter case, patches are available for many Linux distributions to fix the bug. In the former case however, the software developer must patch the library themselves and recompile the software.
The saving grace is, most consumers may not be affected. Most home routers, Blu-ray players, media streaming devices, and other Internet of Things devices are built on Linux - but often a tiny distribution such as BusyBox designed for embedded operating systems. These distributions use alternatives to glibc that may not be affected. Specifically, the uClibc library popular in embedded devices was fixed in 2010. Android is not affected as it uses the non-vulnerable Bionic library. iOS uses yet another library (BSD running libc rather than glibc); as of this writing I have not found confirmation that iOS is or is not vulnerable.
Links:
- Google Project Zero (initial discovery)
- Proof of Concept exploit
- ARS Technica coverage
- Threatpost coverage
- Darknet coverage
- glibc patch details
- Ubuntu security notice and patches
- RedHat Linux advisory and patch details
- Debian security advisory
- Amazon Linux (AWS) security advisory
- SUSE Linux security advisory
- uClibc patch details (from 2010)
Update: since the vulnerability exists when maliciously large DNS answers are provided by an attacker, one way to prevent exploit is to block those malicious DNS answers. There are several ways to do this, but perhaps the simplest is to limit DNS to a known provider, and block anything else.
I prefer OpenDNS' Family Shield product - it lets me block known malicious content as well as other categories I don't want myself of my family exposed to (pornography, nudity, sexuality, and "tasteless" content (which OpenDNS describes as sites that contain torture, mutilation, horror, or the grotesque, as well as pro-suicide and pro-anorexia content).
OpenDNS has publicly stated that their DNS software does not use the vulnerable glibc library, and that they have validity checks that prevent them from passing malicious DNS responses from a third party back to you.
OpenDNS has publicly stated that their DNS software does not use the vulnerable glibc library, and that they have validity checks that prevent them from passing malicious DNS responses from a third party back to you.
The following iptables rules will allow DNS traffic to and from the OpenDNS server, while blocking anything else using TCP or UDP 53 (the network port corresponding to DNS requests and answers).
iptables -I FORWARD -p udp --dport 53 -j DROP
iptables -I FORWARD -p udp --sport 53 -j DROP
iptables -I FORWARD -p tcp --dport 53 -j DROP
iptables -I FORWARD -p tcp --sport 53 -j DROP
iptables -I FORWARD -d 208.67.220.123 -p udp --dport 53 -j ACCEPT
iptables -I FORWARD -d 208.67.222.123 -p udp --dport 53 -j ACCEPT
iptables -I FORWARD -s 208.67.220.123 -p udp --sport 53 -j ACCEPT
iptables -I FORWARD -s 208.67.222.123 -p udp --sport 53 -j ACCEPT
Sunday, February 7, 2016
Poor UX leads to poorly secured SoHo routers
I typically do not disclose vulnerabilities when I know the vendor is working on a solution. In this case however, there is a very easy and reliable workaround available: enable the firewall in addition to disabling web access from the WAN.
Asus makes consumer wireless routers - so-called "SoHo" or Small Office / Home Office devices. The intended purchasers are homeowners and small businesses that don't want to invest in commercial-grade equipment or the professional IT staff to manage it, but still want higher-end features and reasonable security.
Alas Asus goofed in their design, making it easy for owners to think they have properly secured their router and yet still be vulnerable to an Internet attacker. In fact, over 135,000 Asus wireless routers can be logged into from the Internet - over 15,000 of which the owners took the time to secure properly (or so they thought).
Monday, February 1, 2016
A reflective week
Photo Credit: (NASA/Bill Ingalls) |
Like many aerospace enthusiasts in my generation, my mind this week has turned to the skies.
I remember the fateful morning 30 years ago last week, in my elementary school classroom along with perhaps every other student in the county, watching the shuttle launch that was to carry a teacher into space. Some images sear themselves into your minds' eye. For me, the Challenger exploding over the skies of Florida the morning of January 28, 1986 is one of those images.
13 years ago this morning, shortly before 6am Pacific Time, I awoke to what sounded like a sonic boom. Growing up an hour from a major Air force base in the '80s, it was a familiar sound, but a sound rare enough in recent years to wake me.
Later that morning I learned of the Space Shuttle Columbia disaster. At the time that I awoke, the shuttle would have been around 200,000 high over Central California, and roughly 150 miles south of my home at the time. Images later that morning of the shuttle disintegrating over Texas are seared into my mind.
Later that morning I learned of the Space Shuttle Columbia disaster. At the time that I awoke, the shuttle would have been around 200,000 high over Central California, and roughly 150 miles south of my home at the time. Images later that morning of the shuttle disintegrating over Texas are seared into my mind.
I'll never know if I heard Columbia making it's final re-entry to Earth. At 200,000 feet and 150 miles distant, it seems a stretch, though not impossible. Regardless, like the Challenger disaster 17 years earlier, as a lifelong aerospace nut February 1, 2003 is a morning forever frozen in my mind.