Reporting bugs (to Google) is useless, don’t do it

So a few days ago I wrote about a bug I found in Google’s Calendar system.  Mind you, this wasn’t the Earth shattering bug that would crack Google wide open, but it was a back end input validation bug.

So I did what I thought was the right thing, I reported it to Google.  Mind you, they didn’t make it easy.  First send an e-mail, then fill out this form, and then…. Nothing.

Nothing except they fixed the bug, and never even said thank you.

So that’s the world we live in today.  Where people find bugs in software, report them, and don’t even get a thank you.  Is this why people who find these bugs choose to weaponize them anonymously for cash?  Because doing anything else puts the “hacker” at risk?

So what I wrote above is a pretty big jump from finding a bug, to weaponizing a 0-day, but it’s reasonable.  People who find these bugs put themselves at risks, I mean look at the guy who found the AT&T bug.  After only 2 years he might actually get his life back, but nothing like it used to be.

What if, instead, he had just sold the data and not told anyone.  That would be bad, don’t get me wrong.  But you know what’s worse.  Ambivalence.  Either on the side of the people who find the bugs, or the people who should be thankful for those that are responsibly disclosing them.

Hey Google, it’s called a “Thank You”… You should Google it.

The Google Calendar Entry Bug… before Google

So I was entering some stuff into my Google Calendar, when I happened upon a bug.

Yeah.. I know.. Right.  A Bug in Google, and I don’t even spend my time trying to break this stuff.

Go into Google Calendar, click on a spot to input a new appointment, and then type in “12:25 This event starts when the 3 Wise Men arrived”.GoogCal01

Press enter, and you will see that you now have an event that started on New Year’s Eve, year 0.  Not sure if that is the year before JC was born, or the year after.  Either way, kind of cool to see that for the past 2000 years, you’ve been busy.

GoogCal02 GoogCal03

I submitted it to the Google Security group.  Not too sure it is a “wake up the Google experts” kind of thing, but it does appear to be a back end validation bug.  At least, a somewhat annoying one.

And once again, me doing a simple task like entering a calendar entry… takes an hour.

I’m Brett Thorson, and I break stuff without even trying.

 

Shmoocon Epilogue 2014 Talks – Videos

I recorded all the talks at this year’s NoVA Hackers – Shmoocon Epilogue 2014 and have uploaded them to YouTube and assembled them in a playlist:

Shmoocon Epilogue 2014 Complete Video Playlist

If you want to jump straight to a talk, here is each talk individually.

  1. Curt Shaffer & Judah Plummer – Application Whitelisting
  2. mubix – Attacker Ghost Stories
  3. grecs – Project Kid Hack
  4. Liam Randall (Hectaman) – Hash All the Things
  5. Hank Leininger – Password Topology
  6. aricon – Statistical Probabilities
  7. Sean Pierce – Educational Malware
  8. Tobias McCurry - BACKFIL – Finding those backup files
  9. N1tr0 – Gone Phishing and I Want My Hook Back!
  10. Christopher Truncer and Harmj0y - AV Evasion with the Veil Framework

If you think the video production of these videos is something you’d be interested for your organization, please contact me at Cranial Thunder Productions. –Brett Thorson

iPXE – Don’t just boot that ISO

Continuing with my trials and tribulations with PXE booting and iPXE.  Today we discuss why booting straight to an ISO isn’t the best idea in the world.

Once I got the latest and greatest version of iPXE on the system, I had high hopes of just booting ISOs straight into the machine.  I tried this earlier with ProxMox, and it booted with an error that it couldn’t find the CD-Rom.

This was a problem because the system didn’t expect to boot off of.. nothing (aka the network).  So it still involved mounting a USB thumb drive, and performing the install off that.

One of the other reasons not to just boot isos over HTTP is due to memory.  I wanted to do this, but then I found this posting that says, “Yeah, that’s great, until you run out of memory.  That’s why we all use NFS”.  Oh, OK.  I guess I’ll just use NFS.

So once I realized just to use NFS, I got to pulling apart Robin’s extensive menuing system to just the basics of what I needed. I was having troubles though with my ubuntu booting.

Since I was going to use NFS, and I got my menuing system to work, I ignored my HTTP log.  Bad move.  I was getting an error as it was trying to load the kernel and initrd.  It couldn’t find it, and then I found this little note in the documentation for the command.

 If this command is executed from within an iPXE script, then the URI will be interpreted as being relative to the URI of the script itself. For example, if the script http://boot.ipxe.org/demo/boot.php contains the line

kernel pxelinux.0

then iPXE will download and select http://boot.ipxe.org/demo/pxelinux.0.

That’s REALLY useful information.  Once I put the data in the web server (with the proper permissions, as that was another error) I could successfully boot into Xubuntu.

And then give up trying to boot just about anything else, because trying to reformat it, or figure out the secret sauce to get something like Kali or CentOS NFS booted seemed like a lot of work, I’d never really need to use.

So good luck!

PXE Gotchas – What version of iPXE are you running?

I finally got to my goal of getting PXE booting, well specifically iPXE boot working.  However, I gave up short of my goal of PXE booting EVERYTHING!  Here are a few of the gotchas I ran into, hopefully they will help you when you run into them.

Versioning aka (What version is that PXE in the booter?)

Even though you are running a 1.0.0 version of PXE boot, there seem to be wild variations in that version.  For instance, the version I was using inside KVM was 1.0.0-591-g7aee315

It looked like it was a full featured version, but it wasn’t, as you can see from my previous post about some undocumented commands.

The current scripts provided by “The Man” seem to just look at the features provided by the iPXE in the DHCP Client DHCPDISCOVER request.  However, I wanted a more controlled approach, so I wrote this little script to find out what the version is from the client, and upgrade it if it isn’t the latest and greatest.

#!ipxe

set CURRENTVER 1.0.0+ (bf15) 

#If a version is set, go check the version, otherwise upgrade to a version of
#  iPXE that will supply a version
isset ${version} && goto check_version ||
echo "No version supplied, upgrading"
chain http://192.168.1.20/boot/ipxe.pxe 

#We received a version from the iPXE loader.  Check to see if it is current
#  if it is, continue to the boot menu, if not, upgrade to a better version
:check_version
iseq ${version} ${CURRENTVER} && goto good_version ||
echo "Not the current version, upgrading"
chain http://192.168.1.20/boot/ipxe.pxe 

#Version is up to date.  Let's boot.
:good_version
# Global variables used by all other iPXE scripts
chain --autofree boot.ipxe.cfg ||
echo "Lets go to the menu"
chain --replace --autofree http://192.168.1.20/boot/mymenu.ipxe ||
echo "Well something went horribly wrong"
prompt

Now the scripts from “The Man” go through a set of feature flags.  That makes sense, as it actually checks if the version of iPXE you are trying to use has the features you actually need.  That way, you shouldn’t really care about the version, it checks to see if the features are available, and compiled into the iPXE version you are trying to use.

Also note that since I control the VM host, I could have dropped the iPXE ROM into the host system, and it would have automatically updated the system, but really.. where is the fun in that.  This way, I only have to update the file in one place, and everything else will automatically upgrade itself, or at least update itself.