From our Delicious feed today:
#tags: hackers metasploit
#tags: hardware hacking opensource music programming
#tags: infosec opensource OpenBSD vpn infiltration
#tags: defense pdf windows
2010-12-14
Links: 2010-12-14
#tags: hackers metasploit
#tags: hardware hacking opensource music programming
#tags: infosec opensource OpenBSD vpn infiltration
#tags: defense pdf windows
2010-12-08
Links: 2010-12-08
From our Delicious feed today:
#tags: forensics linux infosec privacy
#tags: locks lockpicking physicalsecurity humor fail
#tags: locks security automotive lockpicking physicalsecurity
#tags: dos oldschool software
#tags: cartoon humor
2010-12-07
Links: 2010-12-07
From our Delicious feed today:
#tags: movie video
#tags: virtualization virtualbox software opensource
#tags: pci compliance
#tags: defense weapons
#tags: makerbot fabrication ccckc hackerspace video
#tags: science measurements mechanics electronics
#tags: science biology chemistry
#tags: music movie
#tags: movie review
#tags: adobe pdf drm fairuse
2010-12-05
Links: 2010-12-05
From our Delicious feed today:
#tags: irc mac osx software opensource
#tags: defense security infosec software tools freeware
#tags: socialengineering humor
#tags: humor
#tags: ne network security tools opensource dos networking hacking testing
#tags: piracy lawsuit electronics
#tags: privacy security internet opensource
#tags: microsoft tools freeware sysadmin
#tags: electronics soldering
#tags: politics wikileaks humor
Links: 2010-12-05
From our Delicious feed today:
#tags: irc mac osx software opensource
#tags: defense security infosec software tools freeware
#tags: socialengineering humor
#tags: humor
#tags: ne network security tools opensource dos networking hacking testing
#tags: piracy lawsuit electronics
#tags: privacy security internet opensource
#tags: microsoft tools freeware sysadmin
#tags: electronics soldering
#tags: politics wikileaks humor
2010-12-02
Automate posting links from Delicious to Blogger
As you can tell, I've been playing with a way to create real blog posts from Delicious, not just an RSS feed splice. The old feed splice was being done with Feedburner, and it usually worked pretty well, but it lacked the flexibility I wanted and furthermore, it wouldn't actually create a post here. It would only show up in the RSS feed.
Delicious has an "experimental" (as in, not maintained since 2008) "Blog Posting Tool" that simply refuses to work with Blogger, the platform we currently use. In fact, it's so arcane that I don't really know if anyone has ever really made it work on anything other than Wordpress.
I threw something together in PHP that uses the Simple HTML DOM library to parse the output of the Delicious API. One part of that library that broke pretty spectacularly at first was trying to grab the "tag" attribute of each element. Simple HTML DOM uses "tag" as a variable name all over the place, and it caused some major recursion. I used preg_replace to change the name of "tag" to something else to avoid this namespace collision.
It's written in PHP because I was originally planning on cooking up something web-based, but I went more lightweight instead. Who knows, maybe I'll re-write it later on. Perhaps perl, python, ruby or even newLISP would have been better for this. It's designed to be run manually from the command-line or (more specifically) a nightly cron job.
I just know that there aren't any easy-to-use solutions for posting Delicious links to Blogger, and a lot of people seem to want something like this. It's rough, has some vestigial debugging code left in it, and it's probably not easy enough for most folks. It does what I wanted it to do, though, and you'll probably be seeing a lot more frequent link posts because of it.
Source. Public Domain. Yadda yadda. Enjoy.
Links: 2010-12-02
From our Delicious feed today:
#tags: productivity work video leadership
#tags: gnome linux
#tags: robotics toys
#tags: linux virtualization sysadmin
2010-11-30
Links: 2010-11-29
2010-11-01
OpenBSD 4.8 is out!
It's still farming out to the FTP Mirror Sites but several of them already have the installation ISOs for the most popular platforms ready to download. The OpenBSD 4.8 walk-through for getting a secure OAMP web hosting environment set up seems to work just fine.
2010-10-18
OpenBSD 4.8 is almost here! Chroot Apache, MySQL and Suhosin Hardened PHP
I actually cheated a bit to make this article, if you can call busting my ass performing a "make package" for hundreds ports in OpenBSD-current and doing a bunch of Virtual Machine snapshot reversions "cheating." It was a major pain in the butt to do, but I won't have much free time when OpenBSD 4.8 actually ships, so here you have it.
My Chroot OAMP series of articles is pretty popular, especially since attacks against PHP web applications are on the rise and people are looking for ways to get a little extra security for their web hosting environments.
By default, OpenBSD ships with a specially patched and code-audited derivative of Apache web server. It has been engineered specifically to run in a chroot environment, which is to say that even if someone or something could make Apache run arbitrary code, it can only impact what's in the web directory. It can't readily harm or disrupt the rest of the system.
The version of PHP in OpenBSD's package repository has also been tweaked with the Suhosin Hardened-PHP patch, which can defend vulnerable PHP applications from certain kinds of malicious attacks.
A relatively current version of MySQL is also in the package repository. The configuration provided isn't too bad.
Getting the software installed is easy, but turning it into a functional and secure AMP environment can be a chore if you haven't done it before.
Preparation:
During the installation of OpenBSD, you are prompted to create a non-root user. This feature was introduced last year with OpenBSD 4.6, and is primarily to discourage the improper use of the root account. The user you create during installation will be automatically added to the wheel group, which grants permission to use the su command. I generally add the wheel group to sudo as well, by adding this line to /etc/sudoers (with the root user):
%wheel ALL=(ALL) SETENV: ALLIf you are currently logged in with your user-level account, you will need to log off and log in again in order to use sudo.Package management used to be one of the more annoying aspects of OpenBSD. In 2004, I even wrote my own scripts to wrangle the packages. They've gotten consistently better over the years, and with OpenBSD 4.8, they introduced yet another great feature: /etc/pkg.conf (manual page .) There are only a few options available for this file right now, but it allows you to set global options for the package tools instead of setting up and relying on the PKG_PATH environment variable. If you perform an FTP install, the installer should automatically add the FTP mirror you used to this file. If you installed from CD but would like to use an ftp mirror for pkg_add, you need to add an "installpath" line to /etc/pkg.conf, which may not exist yet.
installpath=ftp://ftp5.usa.openbsd.org/pub/OpenBSD/4.8/packages/i386Of course, you can pick whichever mirror you like. The OpenBSD project maintainers frown upon pointing direct downloads at the main ftp site. You can easily add local package repositories to this path.
Installing Packages
Installing php5-mysql and mysql-server will fetch all of the dependencies for OAMP. This process may take a while depending on your connection speed. There are several dependencies that will be installed, including php5-core and some perl modules.
sudo pkg_add php5-mysql mysql-serverNext, copy the PHP + MySQL sample files into placesudo cp /var/www/conf/modules.sample/php5.conf \Run the script to get the default MySQL database installed, start MySQL and set a MySQL root password./var/www/conf/modules/
sudo cp /var/www/conf/php5.sample/mysql.ini \/var/www/conf/php5/
At this point, both MySQL and PHP are installed and set up with a default configuration that will probably work fine for most applications.sudo /usr/local/bin/mysql_install_dbsudo /usr/local/share/mysql/mysql.server startsudo /usr/local/bin/mysqladmin \-u root password 'your-password'
Chroot Setup
In this version of OpenBSD, a chroot /tmp directory already exists with the proper permissions in /var/www, which simplifies setup of the chroot environment. All we're left to do is to reproduce the directory structure for the MySQL socket under /var/www.
sudo mkdir -p /var/www/var/run/mysql # -p creates subdirs as neededStart Apache and MySQL at bootSet apache to start on boot by editing /etc/rc.conf. Find the httpd_flags line in the file, change NO to "" -- literally, two double quotes as shown below.
sudo vi /etc/rc.conf
Then, make sure that MySQL starts at boot and that the real mysql.sock file gets hard linked into the new directory by editing /etc/rc.local. I also added a line to remove the old hard link before starting MySQL. The end of my /etc/rc.local looks like this:# use -u to disable chroot, see httpd(8)httpd_flags=""
rm /var/www/var/run/mysql/mysql.sockAfter getting all of the services set up to start automatically, I usually reboot to make sure everything starts up as expected.
/usr/local/share/mysql/mysql.server starr
sleep 5
ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
sudo rebootTesting
Once the system comes back online, the most basic test of Apache and PHP is to create a phpinfo script. This can be done with one line of shell-fu, which will launch "tee" with root permissions to write the phpinfo.php file.
echo "<?php phpinfo(); ?>" | sudo tee /var/www/htdocs/phpinfo.phpThen, navigate to http://your.openbsd.ip.address/phpinfo.php in your web browser. It should load a nice-looking document containing details about PHP's configuration. In particular, check for MySQL.
To wrap up, I performed the usual "5 minute install" of Wordpress 3.0.1 (current as of writing) to see what happens. The end result was a totally painless and fully functional setup that's ready to go.
The ultimate simple guide to Internet privacy
People are making a big fuss about privacy and how companies are invading it. Without further delay, here is my all-encompassing guide to Internet privacy.
- Think about what you're going to post.
- If you can concoct any situation in your mind where it would be bad for any one specific person to see it (e.g., your boss, your parents or even the person you're making fun of,) either now or for the foreseeable future, then do not post it on the Internet.
Your mother probably said something along the lines of "If you don't want it on the front page of the newspaper, then don't do it!" She was on to something, you know.
Also, if you're using someone else's bandwidth, server resources and infrastructure for free, then the service they provide to you is not their product. Their product is the data you willingly give them, which they're more than happy to monetize in any number of ways.
Also, if you're using someone else's bandwidth, server resources and infrastructure for free, then the service they provide to you is not their product. Their product is the data you willingly give them, which they're more than happy to monetize in any number of ways.
2010-10-15
Shibboleet!
In today's xckd, we see the magic passphrase "shibboleet."
I'd never heard of this word before, but when I saw mention of the 1990s, I figured it had to be a portmanteau of "shibboleth" and "leet" (or 1337 as it were), where leet is a shortened form of "elite" - a (now tongue-in-cheek) catchphrase for a hacker, programmer or engineer who is among the best of the best at a given skill.
The word shibboleth comes from a Hebrew word that was difficult for non-Hebrew-speakers to pronounce properly. At one point in history, Hebrews used this word to weed out Ephraimite impostors. This day and age, a shibboleth is any defining trait or practice that's inherent to a given culture, but particularly one that is used as a cultural indicator. We naturally use shibboleths frequently in the form of inside jokes, lexical idiosyncrasies and even our fashion.
That makes today's xkcd particularly meta.
2010-10-11
Nessus XML parsing with awk
At the office, I use Nessus for automated network scanning and patch auditing. With credentials and proper tuning of the scan policy, Nessus is a very powerful tool for more than skript kiddie network scanning. This leaves me with a whole bunch of data to wade through on a weekly basis.
Usually, I only concern myself with the high-severity issues for weekly reports, then as I have time, I dig deeper into the more trivial problems. Still, this required me to manually open the scan files, filter them by severity, and export the data. I got tired of that and made a quick and really dirty XML parser (.nessus files are XML) with shell and grep. It was horrendously slow.
Andy, a fellow KC2600-er helped me wrap my brain around some of the finer points of awk to make it more efficient. This is slightly modified from the one I use at work, which is part of a bigger script that does other things. I figure it's useful for others who use Nessus regularly. The script is here.
Basically, it stores the HostName tag when it encounters it, then iterates through the lines, storing them temporarily until it runs into a line indicating a high-severity plugin has been triggered (severity level 3), then it spits out the host name and the plugin that was triggered. I probably could write the whole thing in awk, but I wrapped it in a little bit of plain old shell script.
Output looks something like this:
Windows
----------------------------------------------------
x.x.x.19:MS10-062: Vulnerability in MPEG-4 Codec Could Allow Remote Code Execution (975558)
x.x.x.19:Adobe Reader <= 9.3.4 / 8.2.4 CoolType.dll SING Font 'uniqueName' Field Parsing Overflow (APSA10-02)
x.x.x.20:MS10-066: Vulnerability in Remote Procedure Call Could Allow Remote Code Execution (982802)
Mac
----------------------------------------------------
x.x.x.8:Mac OS X AFP Shared Folders Unauthenticated Access (Security Update 2010-006) (uncredentialed check)
Linux
----------------------------------------------------
x.x.x.40:PHP 5.2 < 5.2.14 Multiple Vulnerabilities
2010-10-07
It only happens once every 823 years!
- OR -
Shell Scripting for Pedantry's Sake.
Today's "That can't be true!" moment hit me when I started seeing this making the rounds (in various different paraphrased versions) on Teh Intarwebs:
"This month has 5 Fridays, 5 Saturdays and 5 sundays-Only happens every 823 years!"
Truth be known, I don't really care about how many weekends are in a month except for the fact that I get three paychecks this month. That happens about twice per year, and that's always welcome! Once in a while, though, I just can't help it. I have to disprove something. I figured the easiest way to disprove this particular claim would be to write a shell script that used the "cal" tool, found in every unix variant known to mankind.
For there to be 5 Fridays, Saturdays and Sundays in a single month, there is a basic requirement for a 31-day month that begins on a Friday, and only then will the 31st fall on a Sunday to complete 5 "whole weekends" in one month.
Initially, I was thinking of ways to see what months started on a Friday. That would get me close. It would give me months such as February 2013, which have only 28 days. Then it hit me: Look for any month with a 31st day that falls on Sunday. Using "cal," I can simply roll through the calendar year looking for a line that begins with "31" and guarantee that the month will satisfy the requirements of having five Fridays, Saturdays and Sundays.
So here we go!
#!/bin/sh
ye=2010
mo=1
while true
do
until [ $mo -gt 12 ]
do
cal=`cal $mo $ye | grep ^31`
if [ -z "$cal" ]
then
echo -n ""
else
echo
cal $mo $ye
fi
mo=`expr $mo + 1`
done
mo=1
ye=`expr $ye + 1`
done
Output:
January 2010
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
October 2010
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
July 2011
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
March 2013
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
August 2014
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
May 2015
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
I don't know. It looks like these things happen more than every 823 years. You can rest easy knowing that it will actually happen a total of 825 times in the next 823 years. Yep, I counted them.
One of the derivatives mentioned October specifically, though. Perhaps this only happens once every 823 Octobers?
Slightly modified, we make the script check Octobers...
#!/bin/sh
ye=2010
mo=10
while true
do
cal=`cal $mo $ye | grep ^31`
if [ -z "$cal" ]
then
echo -n ""
else
echo
cal $mo $ye
fi
ye=`expr $ye + 1`
done
Output:
October 2010
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
October 2021
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
October 2027
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
October 2032
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Nope. More than a decade at times, but not 823 years.
2010-09-22
Experiences from the red team.
My experiences from the red team:
Ax0n posted his experiences at CyberRaid 0 and I totally agree, leadership and coordination make a big difference. I am not an experienced penetration tester so my efforts were mostly for naught. The red team had some very talented people but we didn't coordinate our efforts until it was too late.
Shenanigans :
Before the game, unbeknownst to every one, a red teamer spread around a bunch of authentic looking USB keys with some uber proprietary security software. Complete down to the holographic tamper evident tape. He also placed a power strip which had a baby monitor built into it. The baby monitor was ineffective, it was on the 49Mhz band which is horrible for indoor reception. Because the blue team was separated from the game network this did not work either but any one running the dongle got hit with a Trojan horse / remote control app. The USB keys were confiscated by the FBI (literally).
Wasted time:
The scoring system was down, and DNS was not working so in effect the contest didn't start until after lunch. This was poor planning on the contest promoters. The network connection kept going down so that was even more wasted time. The bulk of the points were scored by a group who concentrated on the default password angle. Alot of people were using Metasploit and once the egress filtering kicked in that halted all progress on that front.
MOAR SHENANIGANS !
Ax0n pretty much confirmed my suspicions, (at least from his team) that most services were firewalled off in addition to egress filtering with the exception of services needed to score. This method of defense really hamstrung red teams efforts in that it prevented the scoring mechanism from working. That combined with shall we say, creative interpretation of the rules made it tough going on every one.
What were you expecting?
On day one and the tail end of day two, law enforcement came in looking for mac-addresses and IP addresses, and came up empty handed every single time. The first time we learned that a team caught some one hitting their web apps with a web app vulnerability scanner. They collected a mac address and an IP and turned it into the cops. The mac address was the Cisco switch (duh, routed network) and the IP address has been tossed long ago. The following attempts of catching the l33t hax0r also ended in utter failure. Mostly because Mac addresses are easily changed, especially on virtual machines. They were getting no where and really should have concentrated on doing their job.
After learning about the total ineffectiveness of the blues attempts of catching people most people just opened up on them, full blown Fasttrack scans ...etc
In the end ...
In the last hour we did what we should have done from the start, we talked. The networks were mostly patched and firewalled all to hell so really we were down to actions of last resort. One item of interest was looking for a machine with poorly configured IP forwarding and bounce crafted packets off of it to the scoring server. I think a large part of our lack of success was stepping on each others toes and poor communication.
What I took away from this event:
- Teamwork!
- Communication!
- Egress filtering hamstrung people using remote exploits.
- IDS's only work if you can use them.
- Law enforcement is worthless unless you have done the leg work and provide them with useful information.
- Be professional, being childish gets you nowhere.
- Beware of default logins and bad configurations.
2010-09-20
What I personally learned at CyberRAID
One last post from me on the inaugural CyberRAID event here in Kansas City.
Leadership
I'm not sure why I was chosen as team captain. Maybe it was because I knew more people on my team than everyone else, because I seemed more confident or because I was one of the first ones present. I wasn't nervous. I felt like I was as prepared as I was going to be. I had my plan, tools and more than half my life behind me that I've spent doing security work in some capacity or another. I thought I was ready to orchestrate a defense team, too, so I happily accepted the position of Captain at the start of the game when people told me "Go up to Dwight! Get our info!" It's not that I can't orchestrate a defense team, but I wasn't as ready as I had thought I'd be, and my plan fell apart pretty quickly.
My plan was to get people organized by what they're good at, and set them on a task. I kind of succeeded at that, but I did plenty of things wrong from the beginning. First, I was stressed but I haven't completely forgotten my manners. My requests probably sounded like a bossy demand followed by "please." Next, I didn't enforce these roles nor did I evaluate how it was going. Some roles changed without much communication. More than once, someone stepped on the toes of someone else who was already working on something. I'm thankful that there wasn't any apparent infighting on my team. Everyone remained rational.
I've lead teams on many projects in my career, but I have no formal management experience or training. I've been an IT worker in a crisis situation more times than I can count. I've never had to lead a crisis response, though. To manage people and work on technical things at the same time is a truly herculean task -- one that I feel I only barely stumbled through.
I learned a lot about myself and hardships faced by leaders in a crisis situation. I also gained a new perspective on IT workers. Among my team, I had some of the most brilliant and capable security minds I know of in the region. On the first day, we had grand ideas and the right mindset, but our implementation of them was slipshod at best. Our good communication skills were the only thing standing between what we had (which was still a good effort) and unabashed anarchy.
Things I learned about leadership and IT teams (and thus, what I need to work on myself):
#1: Technical leaders must lead first and foremost, and help second.
#2: Groups of geeks require a little bit of guidance to avoid replicating (or undoing) work.
#3: Good communication is vital, and its prerequisite is good rapport.
#4: Change management is an extension of good communication. Yeah, I went there.
On the technical side, there were so many things that I'd do different right from the start.
#5: Get visibility to the DMZ network and I'd immediately scan it from the outside while the firewall and system admins work to start locking down obvious things.
#6: Additional Virtual Machines on the DMZ. It would have been great to have a decent (and familiar) IDS on a Span Port. It might have also been fun to have a few honey pots sitting on the DMZ. Had I thought about this ahead of time, I could have totally made it happen. These are tools any one of us could have brought along for the ride in VMs.
#7: Egress filters from the start. There's no good reason not to. They make sense in the enterprise, and they make sense in the game.
Things I'm taking back to the office:
#7: Egress filters! I'm mentioning it twice. Blind SQL injection and RCE exploits are very popular, so crafty hackers and pen-testers often try to leverage these vulnerabilities to launch some process that can notify them that their exploit has worked. This might be popping an xp_cmdshell to launch ping with a special payload they can look for in return, or it may be something much more quotidian, such as a reverse_tcp or meterpreter call-back from metasploit. Again, egress filters make sense in the real world. To further this point, watch out for obscure tunneling through ICMP and DNS. Ideally the DNS server your DMZ uses should not allow recursion.
#8: We all know that despite our best efforts, a dedicated adversary will find a way in. For some reason, this exercise made it sink in a little better. It's been a while since I've worked somewhere that was breached on my watch. This further boosts my desire to learn more about modern post-breach activities both defensive (forensics, containment) and offensive (post-exploitation, pivoting). I have some serious reading and research to do!
Who else was at CyberRAID, CCDC, SANS ICE II or any other recent exercise like this? What did you get out of it?
2010-09-17
Cyber-RAID 0 - Blue Team Wrap-Up
First and foremost, I owe a huge thank you to all my team-mates. Blue Team 2 (which I was on) took home first place in the Defense category by a margin of 5% or so. Like I said yesterday, we had an all-star team with such an awesome range of talents. There's no way any one or two of us could have done as well on our own. We used everyone's skills, and we learned quite a bit from one another. I also learned a lot from watching the Red Team work.
The VMs on each team's network for this exercise:
10.10.9.11 - Secondary DNS Server - Red Hat Linux 7.3 (Valhalla)
- DNS had to remain open to the outside world. Marks would occur against your network if the scorebot system could not get your system to resolve the addresses it's supposed to be hosting.
- SSH: the scorebot user must be able to log in.
- DNS had to remain open to the outside world. This one was properly configured.
- OWA on port 80 had to remain open to the outside world.
- HTTP had to remain open to the outside world.
- SSH: the scorebot user must be able to log in.
- MySQL had to be open to the outside world, allowing the scorebot user to select from a special table.
- HTTP had to remain open to the outside world, and a flag file in the web root had to remain intact (subject to MD5 checksum)
- FTP had to be open to the outside world, allowing the scorebot user to retrieve a file.
- SSH: the scorebot user must be able to log in.
- SSH: the scorebot user must be able to log in.
- MySQL had to be open to the outside world, allowing the scorebot user to select from a special table.
- HTTP had to remain open to the outside world, and a flag file in the web root had to remain intact (subject to MD5 checksum)
- FTP had to be open to the outside world, allowing the scorebot user to retrieve a file.
- SSH: the scorebot user must be able to log in.
10.10.9.253 - Solera IDS and packet capture VM
- This wasn't a target, and didn't have anything the attackers could get their hooks into. It was provided to us, but none of us knew how to use it, nor did any of us have time to play with it. We instead relied on local logs and traditional packet captures from Wireshark and tcpdump.
Gotchas:
All the systems had many extra services running. There were default passwords on database, web-app and shell accounts. Anonymous FTP (with upload ability) was allowed on the two FTP servers.
This was a self-contained and isolated network, making traditional methods of patching impossible. What's more: in order to protect the Blue Team laptops, the VMWare server had dual interfaces. Blue Teams were only given enough infrastructure to connect to the management interface of the virtual environment. That means that Blue Team only got console access to the environment. The hosts themselves were natted to the hostile network through a Cisco ASA.
Day 1, with more detail:
Our first action was to snapshot all of the VMs. This would let us revert them in the case of complete ownage or if one of the red-teamers rm'd our boxes. Next, we figured out who was good at what kinds of things. This would come in handy later on. Next, we all started exploring the VMs through the VMWare consoles. There were eight VMs and eight people. You'd figure we could have each taken one of the VMs and started hardening or patching them. But no, everyone immediately opened 3, 4, or 5 VMs at once and started trampling on other peoples' sessions. I was just as guilty as everyone else.
I think most of us were more prepared for a totally Windows-centric environment. Several of us brought Windows Update patches on DVD. Our team started patching those right away, while two guys with firewall experience worked to restrict only incoming services we needed.
It was already too little, too late. Surbo from i-Hacked completely and totally pwn3d our exchange server early on in the game while my friend Eric was busy trying to figure out what in the hell was going on. At this point, scoring hadn't started yet, so the firewall guys shut down all incoming traffic.
Before lunch, the systems people started hardening and patching the boxes as best as we could without having Internet access. We all had reasonably good communication, and we all had some good ideas. Egress filtering came into mention before lunch. The firewall guys built up a good rule-set that would allow all scored incoming services to work properly once the "deny all" rule was pulled, while disallowing any connections out from the systems that weren't absolutely needed. All of this was to shut down any phone-home scripts.
After lunch, we opened up the firewall ruleset to the world and started watching the score board. A lot of time was spent yesterday troubleshooting the firewall and various services, making sure we had as few marks against us as possible.
BIND on our Red Hat Linux box (using a 2002-era version of that distro!) ended up being brutally misconfigured. It was also a horribly vulnerable version, but no red-teamers seemed to exploit it to properly pop a shell. Yesterday, no blue team could solve the issue.
Toward the end of the day, our Pointy-Haired Boss demanded that he wanted the company's computers to be able to access http, https, smtp, dns, mysql and postgresql outside the network. Firewall changes that we made broke all our incoming services for a while, due to using the wrong IP addresses in the DMZ rules.
We got these changes implemented, and then found that our PHB was using his personal laptop to connect out over those ports to verify that the changes were made. After that, scoring was complete for Day One.
Day 2
One of the game rules was that we couldn't explicitly block anything by IP address either inbound or outbound. First thing in the morning, we created a group for our DMZ servers then placed full egress filtering on them. At some point in the morning, the PHB verified he could still get out to the other networks from his laptop on our DMZ. He had no idea what we had done.
In normal IT shops, this is known as adhering to the letter of the law instead of the spirit of it. It's a type of insubordination that IT guys can use against management when they really think they know what's better for the company. I really don't like resorting to these kinds of tricks in the real world, but since it's a tool that IT guys have in the real world, it's a tool my team was willing to use. Later on in the day, the PHB came back around and asked us to prove to him that our DMZ servers could also get out. This was a much more blatant deception. Our firewall guy dropped the egress rule while one of our Linux guys feigned a bit of ignorance to stall the boss for 15 seconds or so while we pulled the shields down.
These were risky moves. If at any time we would have been found to be out of compliance with the boss's demands, it would have cost us an instant 5,000 marks against us. In the real world, moves like this could potentially cost you your job. Of course, in the real world, you can often talk the boss out of making bad decisions, and the boss would likely have to provide a good business reason to implement the features that were being asked of us.
Things were going more smoothly on day two. We hooked up a switch to the DMZ to give our personal laptops some visibility to the front-end of our network. This helped things immensely, and it's something I'd do immediately on the first day of an event like this in the future. I brought speakers, too, so that my team had some tunes. We rocked out to 808 State, Paul Van Dyk, Daft Punk, Juno Reactor, Steve Porter, Orbital, White Zombie and more. At a reasonable volume, of course.
With the exception of the badly configured BIND server, our team and Team 3 were holding steady on marks against us. We both started to identify some SQL injection and default usernames being exploited on our networks. Team 3 had gained on us a lot at the end of Day One, but we held a margin of about 200 points ahead of their team for the entirety of Day Two.
More demands rolled in. We had 30 minutes to open Exchange's SMTP to the world, and we had to add a new zone with MX, A and NS records to the active directory's DNS server. Our Windows admins aced it.
While that was going on, I was digging into BIND on the redhat box. I was the first blue-teamer to finally dig into the issue and fix it. Only one other team was able to resolve this issue, and it took them a while after I had fixed my team's. I'll spare you the details, but it was really, really misconfigured.
At this point, several attackers had some kind of hooks into a few of our systems, but they were having trouble scoring phone-homes. With all our tasks out of the way, we went into incident response mode, booting and cleaning up after red teamers.
One last PHB demand for the day: Set up VoIP trunks and extensions on our Asterisk server, and allow the protocols needed to talk between networks. We weren't going to actually communicate over it, but we needed to at least show that we could get into the interface and configure Asterisk with FreePBX. Since my machine was plugged into the external switch and since no one on my team (even me) had any Asterisk experience that would make them any better for the job, I went ahead and took the charge on that one. It required collaborating with my team-mates to grok the config files and tweak the databases so I could get logged in.
There was about half-an-hour of incident response left after that. About 10 minutes before scoring closed, the game organizers joked that he'd remove 10,000 marks from any team who could provide him with full packet captures of the entire exercise from Solera by the time scoring closed. I say he was joking, because that VM had only 2GB of hard drive space on it, so there's no way it could have stored it all. Even if it could have stored it, I doubt anyone could have exported all that data in 10 minutes.
All of the tasks required collaboration, and the entire exercise calls for a team of people with diverse skills.
Evil WiFi: Subversive Wireless & Self Defense (BSidesKC)
I'm used to talking among smaller groups of people around a table, but that was the extent of my public speaking experience until my presentation at B-Sides KC. Thanks for all who participated. It was a pleasure interacting with you today!
I think the presentation went pretty well. B-Sides seems like a great place for shy security nerds to practice their presentation and speaking skills. Predictably, I think I said "Um" quite a bit. I'll get better, I'm sure.
When my original Evil WiFi rig left a trail of dead newbs in its wake at DefCon last year, I decided I should probably refine it a little bit. A presentation was in the back of my mind. When I got laid off at the beginning of this year, I started playing with it in earnest again. I even drew up a quick outline that I was thinking of submitting to Black Hat and DefCon. I'm honestly still not 100% happy with the setup. I'd bet I could get most of this running on a single netbook, and use some of the newer features of Metasploit.
I wish we would have been able to record the talks. The audience added a lot of insight. I also had a big pile of notes to go with these slides. I deleted them, entirely on purpose, so I could wing it during the presentation. I know the material.
The ongoing theme of the talk was that wireless technology is helplessly broken for all but a few savvy users. Of course, most of the people who attended my presentation were savvy users themselves: hackers, penetration testers, sysadmins and mostly highly-technical folks that "get it" - I'm hoping they can take this back to their day jobs and use it wisely. Not all hope is lost if you need WiFi in the enterprise, though. You just have to know the threats and use your head.
I also demonstrated the effectiveness of my current Evil WiFi rig with its new captive portal functionality, and explained how the mechanics of the system work. It surprised me that the audience enjoyed watching me fumble my way around, but the demo seemed effective enough considering parts of it were somewhat staged for display purposes (browsing to my captive portal from localhost just to show how it looks and what firewall rules it adds) but once I enabled Karma, we started seeing a few folks get tangled up in in.
I didn't demonstrate Hamster & Ferret for a few reasons. Complete strangers using my access point, 18 U.S.C. § 1030 (and related codes) and the presence of FBI agents in the room had something to do with it.
2010-09-16
Cyber-RAID 0, Day One - Blue Team
Asmodian X is Red-Teaming, but here are some of my thoughts on Cyber-RAID 0 from the Blue Team side.
First: today was one of the most frustrating and stressful days of my entire IT career. That's saying something, considering that I'm officially off the clock, on vacation with a "four-day weekend." I'm burning vacation days to participate, and some good friends of mine with strong ties to the financial, law enforcement and education industries sponsored my attendance at this event. Being stressed out doesn't mean I'm not having fun, though. This is my first time in a game like this, so it's new and exciting to me.
Next, I have an all-star team working with me. We got to self-organize into groups, so I already knew some of the people on my team, and what they're capable of.
Blue Teams
The "Blue Team" is actually 4 teams with 8 members each. The goal of each blue team is to get as few marks against their network as possible. Each "network" is a VMWare server with 8 VMs. Each team gets a nearly identical setup, save for a few passwords being different. Marks are racked up based on the integrity of mandatory services. Your exchange server goes down? That's a certain number of marks against your team. An attacker deletes or modifies a certain file on your web server? More marks against you. These accumulate periodically until you restore the services to their intended state. I won't go into what all services are checked or what kinds of virtual machines we're running, since some of my red-team buddies might take advantage of the information. It's safe to say that there were many services running that didn't need to be.
By gathering enough data to implicate a specific attacker, each Blue Team can recover some of the marks against their network as well as getting the attacker "arrested" - sidelined for 30 minutes.
The Red "Team"
The Red Team is full of lone-gunmen who are free to collaborate if they wish, but they're much less structured than the Blue Teams are. Each Red Team member scores points for themself by getting phone-home scripts or binaries to run from the Blue Team network. Ideally, they exploit remote-code-execution vulnerabilities, pop a box to get a session or shell, or otherwise get the Blue Team's systems to contact the scoring server on their behalf. The goal of the Red Team attackers is to score as many points as possible. If they can persist their hold on a Blue Team network, they can continue to rack up points by running their phone-home processes repeatedly. Note: these scripts can't be run in an infinite loop effectively to rack up tens of thousands of points per minute.
The Pointy-Haired Boss
Toward the end of the day, our Virtual CEO decided to DEMAND that we change our firewall rulesets to open certain ports for outbound access to any remote server. As you can imagine, per the rules of the game, many of the blue teams had opted to implement egress filtering rules that would allow the services to be contacted from the outside, but to disallow any outgoing connections originating from our servers in order to foil any successful "phone home" attempts, even in the event of a complete system compromise. This demand was certain to throw a wrench into egress filtering rules, but the team I'm on dealt with it well enough. Tomorrow, more demands will be thrown at us, and the usual fare of IT issues will be simulated: password resets, account creation, etc.
Results
"We have met the enemy, and he is us!"
At the start of the game, each of the Blue Teams caused more problems for themselves than the attackers did: team-mates accidentally knocking out power to production systems, intentionally telling Red-Teamers to "Piss Off" by modifying an integrity-monitored web page, and failing to fully understand this network that was just dropped into our laps are only three examples of the sort of frustrating things I saw today, and pretty much every team had the same problems.
There's still a half-day ahead of us, but the last time I checked, our Blue Team team was in the lead (by virtue of having nearly a thousand fewer "marks" against us than our closest competitor) but I have a feeling we'll need to work hard to stay in the lead. The members of the Red Team seem to be having a very, very rough go of things as well. The top attacker, last I saw, had a mere dozen points. My guess is that the attackers are landing a few successful exploits, but are having difficulty with the way points are awarded.
We'll see how it turns out at 13:00 tomorrow afternoon. B-Sides runs all day tomorrow as well, but Cyber-RAID participants will miss out on the first half.
Evil Wifi - Captive Portal Edition
As part of my presentation for B-Sides KC later this week, I decided to revive my Evil Wifi project for a demonstration. I'll post my presentation slides and some talking points this weekend. Since my daily-use laptop is a MacBook running Mac OS X Snow Leopard, I put this together for OS X. I do understand that OS X isn't free, but it works, and well. It's also something fun (and perhaps evil) you can do with that new netbook after turning it into a hackintosh, as so many friends of mine have done lately.
Originally, my Evil Wifi setup was a stand-alone rig with a laptop and a wireless router. The router has a tempting SSID for freeloaders (such as "Guest") while also running KARMA, a set of wireless driver modifications that will rope in any wireless devices that are broadcasting the names of their preferred networks in hopes of finding one to connect to. The router would hand out my laptop's IP as the DNS and default route.
The laptop was running Hamster and Ferret, a suite of sidejacking tools from Errata Security. These tools allow an attacker to gather and re-use session IDs from other network users. Additionally, it was running Metasploit for two reasons: a fake DNS server that resolves all domain names to itself, and a fake HTTP server with a specially-crafted page designed to facilitate the capture of many popular session cookies, which Hamster and Ferret would see and store.
Captive Portals are those wireless hotspots that require you to pay, enter a password, or acknowledge a terms-of-service agreement before continuing. No one could get out to the Internet through Evil Wifi. I intentionally designed the landing page to look like a captive portal that required a password. Most users would find themselves somewhat puzzled, then move on to a different network. Some people have asked if I could have configured the laptop to allow outbound traffic, and others (Like John Sawyer of Dark Reading) actually figured out how to do it. I thought about it last year, via Internet Connection Sharing, but I'd have lost the ability of Metasploit to gather a bunch of potentially valuable session IDs quickly.
I've been thinking of way to combine the best of both worlds, and I think I've nailed it.
To continue, you'll need a configuration much like the original Evil Wifi, but with a few tweaks. Here's how I did it using Mac OS X. Keep in mind that Linux works fine and also has Internet Connection Sharing, but you'll have to tweak some of the steps, and come up with equivalent iptables rule sets.
Laptop:
- MacBook, OS X Snow Leopard
- Metasploit Framework (Using build 10314 right now)
- Apachefriends XAMPP
- Errata Security Hamster & Ferret
- Older Fonera Fon2100 or Open-Mesh Mini-Router
- Jasager
I configured en0 (my ethernet port) for a static IP of 192.168.1.2, netmask 255.255.255.0.
My first experiment with OS X's built-in Internet sharing showed that it starts a program called natd and inserts a rule to the ipfw firewall to divert traffic through natd on port 8668. Avid BSD users are probably familiar with all of this. It's exactly how I configured my first FreeBSD home router back in the 90s. Since Internet Sharing also does a bunch of other stuff that I don't want it to do (starting a caching name server, adding a virtual IP address, and some other shenanigans) I do this stuff through the staging script instead of relying on OS X's Internet Sharing wizard. The staging script comes later on.
Also, XAMPP runs as "nobody" but a small bit of web code will need to add firewall rules, so I granted the nobody user to use ipfw without a password, via /etc/sudoers on my laptop:
nobody ALL=(ALL) NOPASSWD: /sbin/ipfwXAMPP Setup (any AMP stack will work):
Edit httpd.conf, find the line that says "Listen 80" and change it to "Listen 81" - uncomment it if needed. On OS X, this file is in /Applications/XAMPP/etc/
Create a php script that uses the $_SERVER[remote_addr] variable to modify the firewall rule set. This page will be called by a form action or link from the metasploit capture page. Mine is really simple, and I called it "control.php" in the document root. On OS X with XAMPP this is in /Applications/XAMPP/htdocs/
<?It simply redirects you to another site, and adds a rule to the firewall, telling it to skip past any rules before 2000 for your the IP address that visits this page. Since I'll be giving this demonstration at a hotel next week, the header will redirect to the hotel's web site. Since XAMPP gets finicky if it is started from the command line, you'll have to fire up the XAMPP control app and start Apache manually. MySQL and FTP need not be started for this project.
HEADER('Location: http://www.some-local-business.com/');
$cmd="sudo ipfw add 100 skipto 2000 ip from " . $_SERVER[REMOTE_ADDR] . " to any >/dev/null" ;
system($cmd);
?>
Metasploit setup:
Download and update Metasploit Framework. I prefer to get it from the subversion repository.
The HTML file that's used with the http capture module is located under the metasploit directory, then data/exploits/capture/http/index.html
The default is ugly and almost screams "you got owned!"
Staging script:
This sets up our firewall rules the way we want, prepares Hamster for use, and fires up Metasploit. Drop this script somewhere and make sure the paths are correct for Hamster and Metasploit Framework.
The default is ugly and almost screams "you got owned!"
This is what I came up with. You can view source and steal it if you want, but you can probably craft something better. Yes, it's ugly. No, I don't care. I've seen worse. Note that the "Accept" button activates the control script that I have set up on XAMPP.
Along with that is also the karma.rc - I can't remember if this one comes stock with Metasploit or not, but it's the one I use.
Staging script:
This sets up our firewall rules the way we want, prepares Hamster for use, and fires up Metasploit. Drop this script somewhere and make sure the paths are correct for Hamster and Metasploit Framework.
#!/bin/sh
sudo sysctl -w net.inet.ip.forwarding=1
sudo /usr/sbin/natd -interface en1 -use_sockets -same_ports -unregistered_only -dynamic -clamp_mss -enable_natportmap -natportmap_interface en0
sudo ipfw -f flush
sudo ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1
sudo ipfw add 1800 allow ip from 192.168.1.0/24 to 192.168.1.0/24
sudo ipfw add 1900 deny ip from 192.168.1.0/24 to any out via en1
sudo ipfw add 2000 divert 8668 ip from any to any via en1
cd ~/hamster
sudo ./hamster&
cd ~/msf
sudo ./msfconsole -r karma.rc
Fonera Setup:
This one goes together just like it did in Part 1, but a recap:
Start with a rooted and re-flashed Fon2100. I used OpenWrt 7.09 (yes, I know it's old) - Be sure to change the root password!
I then installed all of Digininja's Jasager goodies found on his site, using the tarball method. I needed a few extra packages to make everything work - I bundled them up here. Unpack them, upload them to the fon, and install them with "ipkg install *.ipk" if you need to install them.
Change the dchp server configuration to set 192.168.1.2 as the default route, and add a public DNS server, then 192.168.1.2 as the default DNS servers. I used one of Google's public DNS IP addresses for the public one. On OpenWrt 7.09, these tasks are accomplished by adding lines to /etc/dnsmasq.conf:
dhcp-option=3,192.168.1.2dhcp-option=6,8.8.8.8,192.168.1.2
If you go back to Part 1, you'll see I also did some other tweaks, like set Karma to start by default. There is a lot of information about getting Jasager up and running, but the dnsmasq configuration is the most important bit, particularly getting the public nameserver in front of the fake one we're going to fire up with Metasploit. You'll see why in just a bit.
I also changed the default SSID from "OpenWrt" to "Guest" to make it more attractive to freeloaders. You may prefer to use "linksys", "default" or any of the popular SSIDs. This is set in /etc/config/wireless.
Putting it together:
Fire up the Fonera Router
Start up XAMPP's apache server.
Run the staging script. It should come to rest at a Metasploit prompt. This is doubly fun, because it's running modules in the background to help Hamster & Ferret, but you can just as easily launch attacks from the Metasploit console if an interesting computer falls into your trap.
Browse to the Jasager interface. This should be at http://192.168.1.1:1471/ - enable KARMA mode if desired. You may wish to keep Jasager open in its own window or tab. There's usually some interesting stuff going on.
Set your browser's proxy to http://localhost:1234 to allow Hamster to inject cookies.
Browse to http://localhost:1234 and tell Ferret to watch en0 for traffic.
Here's what happens:
Victims or freeloaders connect to Jasager, and DNS resolution will hang for a few seconds because the public DNS isn't available. This DNS request will time out (usually in 5-10 seconds) and then it'll try the second DNS server in the list. That's metasploit's fake DNS server.
At this point, any service they've tried to connect to will likely get captured by Metasploit. If it's a web browser (likely) they will get roped into Metasploit's HTTP capture and they'll get our Captive portal page, complete with the iFrames that force the browser to divulge session cookies for popular websites. These iframes will also take a few seconds to resolve, but that's okay. All the while, Ferret is gathering these session ID for us.
Once the victim clicks the "Accept" button on the captive portal, the firewall rule is created that allows outbound access, including DNS. It will instantly redirect them to a website -- preferably one that's plausibly related to a nearby business. They get out, through us. Hamster catches everything. The victim is none the wiser.
Is it possible to give Evil Wifi EVEN MORE teeth?
Of course it is! You could create scripts that automatically attack new wireless clients, wrap the wireless up with SSL Strip to catch some REALLY sensitive session IDs, and any number of other malevolent things. At this point, I think I've proven how broken things are, though.
Defense?
I have plenty of thoughts on defense. There are ways to defend yourself in the wild, ways to defend your enterprise users from attacks like this, and ways that operating system vendors could prevent KARMA-style attacks from working at all. For that, you'll have to see my presentation at Security B-Sides KC. As I said at the beginning of this post, I'll have the slides uploaded and some notes posted later.
2010-09-13
Sony has a problem.
This is that problem.
Sony has ignored, at least aesthetically, and likely functionally, that we have come to expect new features to be seamless. Wii motion control doesn't have a giant ping pong ball on the end of it. An iPhone and other smart phones have motion sensors that don't have ping pong balls hanging off of them. Laptops with motion sensors don't have ping pong balls to detect sudden drops and park the hard drive. Yet, Sony is directly marketing their total lack of understanding of how to seamlessly integrate a modern feature into their system. The only visual notice you have of motion control on Wii is the sensor bar. On XBOX the upcoming Kinect does motion with out a controller but tries to solve that by throwing a large amount of video, audio and sensor processing at the problem. That may well be an overkill approach to simple control compared to just putting motion sensors in existing controllers, however it allows a broad range of extended uses such as biometric recognition. Overall, simple motion control is a problem that was solved by proximity sensors and 3 axis accelerometers, which Nintendo and Sony seem to have successfully implemented. Sony just couldn't seem to get over the "look at us, we are hip and trendy again" goiter on the end of their controller that directly signals that Sony just doesn't get it.
2010-08-08
Book review: The Boy Who Harnessed the Wind
At near random I picked this book from the shelf, and I'm glad I did so. I had been quickly browsing the Technology section at the library, the 600 category in Dewey Decimal, and spied a yellowish orange book in the middle of the white and blue covers on most of the nearby books. It was probably the same kind of hurried situation that William Kamkwamba was in when he found the book Using Energy. A quick look through it told me about William, who had built his own windmill from scrap to provide power for electricity and water pumps for his home and village. The biographical lead up to the construction takes more than the first half of the book but it sets the scene for the achievement well. Anyone who tinkers or spent their childhood taking apart things will deeply appreciate how William brought himself out of the scared and superstitious world that his community lived in and through trials and experiments learned the basics of science and innovation, proving his "madness" was nothing of the sort. He's so "crazy" he's been asked to speak at TEDGlobal twice and many other international conferences and forums. This biography is well worth the time to read to get a real African's perspective on how simple technology can change lifestyles and conditions and how ignorant superstitions impede the flow of knowledge.
2010-07-27
Really, Verisign?
Verisign's latest snail mail spam included a Verisign-branded USB drive with information on their new SSL Certificate features. The package was heavily loaded with all kinds of "Trust" rhetoric. At the request of the guy who officially got it, I threw it into my Macbook to take a look at it. It wasn't on any network and it's not prone to any known vulnerabilities that might allow something to run directly from the USB without any interaction (unlike Windows)
Autorun, Verisign? Really? AND Lame Adobe Flash? You honestly expect us to TRUST this kind of crap? To add insult to injury, the USB drive itself is only 64MB. You can't even install BackTrack on it or otherwise put it to any productive use.
2010-07-23
(Def) #ConSurvival
There's a pretty good discussion going on Twitter about "surviving" DefCon and Black Hat, which are both coming up very quickly. Sadly, I won't make it out there this year. Asmodian X gets in Wednesday night, though. You should try to catch up with him.
It seems that every year, people say "don't bring your laptop / cell phone / PDA / etc..." but that's not really a big deal. In 2008, I posted about this same phenomenon on the ramp-up to DefCon 16. The same advice holds. You should be doing this stuff every single day, not just before you enter the hornet's nest that is DefCon.
- Back up your data
- Don't store sensitive stuff unencrypted
- Keep your software up to date
- Use good passwords
Last year, my Evil Wifi rig caught more than 100 unsuspecting attendees on the first day and gathered about 1,000 valid session cookies from sites like Facebook, Twitter, Google, Yahoo, Amazon, MSN and LinkedIn. It's a good idea to tunnel everything while you're at DefCon.
To do this, I set up both ingress and egress filtering in my firewall policy. Nothing gets in, and only tunneled traffic gets out. I also take this a step further by disabling my wireless and sticking to my tethered Internet connection. You may wish to use a broadband wireless adapter. I probably wouldn't trust a MiFi-type device unless it can connect over USB with the 802.11 disabled. It's not perfect, but you'll be better protected than most people there.
Other, less-technical pieces of sound advice being echoed:
- If you have the opportunity to go have coffee, breakfast, lunch, dinner, drinks with someone: take it. It doesn't matter how cool the talk is that you were looking forward to seeing, all the content will be on the web soon. Don't pass up the good networking opportunities.
- Take care of yourself. Try to eat healthy, take a shower, wear deodorant, brush your teeth and get at least a few hours of sleep each day. And wear sunscreen if you're outside. You don't want to come home a sunburnt, smelly, grimy tired zombie.
- Make it to B-Sides for at least a bit.
- Make sure you keep some room in your luggage for schwag, t-shirts and contest prizes.
- Go to a bank lobby if you need to use an ATM.
- Check out the rest...
2010-06-18
"Viral" Like-Jacking on Facebook
It's out of control. Perhaps you've started to see a lot of stuff like this lately:
The title is provocative, mysterious or racy. Maybe it's scantily-clad ladies, the promise of a hilarious video, or in this example: from the title, it's implied that we're about to see something bad that our own President did.
The formula is always the same, though. You're taken to a page where you need to click something to continue...
Those who are paying attention will notice that on these pages, pretty much the entire page seems clickable according to the mouse cursor. That's because there is an invisible "Like!" button floating under your mouse the whole time. Unless, of course, you're running NoScript (which I've mentioned before). NoScript won't even load the page properly. Even if you disable JavaScript protection, ClearClick will alert you to what's about to unfold. Note the "thumbs up" icon.
What's happening is that there's a little 10x12 pixel iFrame named "fbframe" being rendered on the page, and it's being set to invisible using the style tag. You can see that the iframe is loading a URL on Facebook that will add this page to your "likes." This would be in the top left corner of the page, by default.
This snippet is where the damage is done. It's at the bottom of the page, and loads a bit of code that keeps this invisible iframe positioned under your mouse wherever you hover it over the page.
The iframe will intercept your click, even if you click on something that appears to be a valid link. You end up unwittingly "liking" it, and displaying the rogue links to everyone on Facebook. Curious, some of them will click to see what it is, and be taken to the same page. I'd imagine most of these people will also unwittingly fall for it as well.
Clickjacking is nothing new. I believe RSnake named it in 2008 if not discovering it. Facebook's platform, however, is making it very easy for people to create pages that dupe unsuspecting folks into spreading links around virally. Many of these pages could be loading malware to your computer via browser bugs or exploit packs while some others are probably just trying to drive traffic to their site for ad revenue.
At any rate, use NoScript. Seriously.
2010-06-16
Slowly growing my soul back...
I'm finally getting back to where I have some time (and the drive) to tinker some more.
2010-06-09
Reprogramming Respironics CPAP and Bi-Level BiPAP Machines
-- OR --
All Your Sleep Apnea Are Belong To Us
Disclaimer: Messing with CPAP settings can cause your machine to no longer function as required by your doctor, and may lead to bad things happening to the operator. Use only the settings that your doctor or sleep technician has prescribed.
I have some oddball CPAP and BiPap machines laying around and I had to reprogram one of them for a good friend of mine. While I was at it, I decided I'd like to figure out what lies in the "forbidden" area that only sleep technicians know how to get to. I'd heard from a friend who uses a CPAP that programming them usually involves unplugging it and pressing some buttons. So I started putzing around with this older model, the Respironics SleepEasy.
It's set to apply constant pressure of 6cm/H2O. Boring. There's not much that one can do with the buttons available to be pressed. They're for things like adjusting the heater attached to the humidifier reservoir, and enabling "Ramp Mode" which, from what I can tell, starts you off at a lower pressure as you try to get to sleep.
After a few minutes, I found that pressing the + and - buttons while plugging in the power did something interesting.
It's an unlock icon on the screen. Pressing + and - now adjusts the CPAP pressure in .5cm increments.
Pressing the humidifier button in this mode allows you to cycle through a few interesting diagnostics and settings. Shown below is the menu that allows the technician to completely disable the humidifier heater. Why? No idea.
This is the screen for adjusting Ramp Mode's initial pressure.
I also got my hands on a more expensive and elaborate bi-level CPAP machine, the Respironics BiPap Plus M Series. These machines usually apply a higher pressure when they sense that you're inhaling, and then drop to a lower pressure while exhaling. There are more buttons and a higher-quality display on this model.
Usually, this is the screen you get in standby mode. Hitting + for "Setup" in the default user mode gives the operator very few useful options.
Holding + and - while plugging it in didn't work on this model. Next, I tried plugging it in while holding the arrow keys, and that did the trick.
Note the unlock symbol as well as a new menu option for "Data" which has a very rich array of statistics buried beneath it.
This machine hasn't been used.
Once unlocked, hitting the Setup menu button provides a lot of features, including the inhalation pressure...
And exhalation pressure.
There you have it. It seems like most Respironics machines are programmed by holding down +/- and arrow keys. These machines seem to be pretty popular. Maybe this quick walk-through will help someone who has to buy (or sell) a used machine.
Sorry I've been silent for so long. I'm still getting settled in at the new job. It's going great, and I have a great team, but there is a lot to do. Also, frankly, my brain is usually mush by the time I get home. Hopefully, I start playing with some cool and new shiny things outside of work again soon.
Subscribe to:
Posts (Atom)
Posts
