mycontroller – done

November 22, 2009 Leave a comment

This was my final architecture project from a couple years ago. I had several posts in here about it, so I figured I’d post the final as well.

The goal of this project was to integrate all parts covered throughout the lab. Similar to lab7, lab8 fetches microcode from a second memory device. Extending lab7, however, it also performs very basic operations, including add, eq, nop, ld, skipz, and halt. There are 4 physical registers, which will be referred to as 00, 01, 10, and 11.

lab8report.pdf <– Write up

Logicv12 <— Multimedia Logic Source

lab8.zip <– contains the default program loaded into ram, etc

The circuitry is pretty simple – most the hard work was in decompiling the microops. Here are some shots of the circuitry.

Screenshot-1

Filed under Reverse Engineering Tagged with ,

Auto Pw Change

November 13, 2009 Leave a comment

I had to change this script a lot, so take with a grain of salt. That said, we changed about 1000 LOCAL passwords in a couple hours – which would have really taken all day and been more boring.

#!/usr/bin/python

import pexpect

#most likely should be first for speed
passlist = ["pass1", "pass2", "pass3"]
#most critical should be listed in file first for speed
user="root"
newpass="newpass"

#open hosts file
hostfile=open("hosts.txt", "r")

for host in hostfile:
  host = host.strip()
  changeSuccesful = False
  #need to find the currpass to change it
  #so auth by key may not be ideal in this case
  p = pexpect.spawn("ssh " + user + "@" + host + " passwd"
  
  #try block so it doesn't crash the program
  try:
    #different systmes vary with exact text
    conn_result = p.expect(["assword:", pexpect.EOF, "Are you sure you want to continue"])
    if conn_result == 2:
      print "accepting public key for ", host
      p.sendline("yes")
      conn_result = p.expect(["assword:", pexpect.EOF])
    if conn_result == 0:
      for password in passlist:
        print "tryin password for ", host
        p.sendline(password)
        pass_result = p.expect(["denied", "current.*assword:", "new.*assword", pexpect.EOF])
        if pass_result == 1:
          p.sendline(password)
          p.expect("new.*assword:")
        #this should execute if a key OR password was accepted
        if pass_result == 1 or pass_result == 2:
          p.sendline(newpass)
          p.expect("new.*assword:")
          p.sendline(newpass)
          changeSuccesful = True
          print "Succesful pwchange: host "+ host 
          break
    if not changeSuccesful:
      print "UnSuccesful pwchange: host "+ host 
  except:
    print "Uncaught exception: host "+ host

Filed under Pentest Tagged with

Where was the Hacker in the Room for X-FRAME-OPTIONs?

November 13, 2009 Leave a comment

Update: don’t worry, they took care of it – but as of Feb 2012 only IE:  http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Or maybe where was the Dev in the room?

Imagine you’re sitting at a computer logged into your favorite website, lolcats, and you click on a shady link while logged in. There are a lot of attack scenarios that start this way.

Browsers have a cross domain policy that prevent the shady site from accessing any of your lolcats cookies, which typically contain your authentication tokens. But BY DESIGN, the shady site is certainly allowed to do requests (eg POST or GET) across domains. So there’s nothing to prevent the shady site from framing lolcats in an invisible iframe and having you play an animated whack-a-mole game, clicking exactly where the invisible lolcats site is having you inadvertently  rank the attacker’s disgusting kitten as cute. This is performed with your very own account, because the cookies are all legitimate from being logged in. This makes all your lolcats buddies laugh at your bad taste.

This is contrived, sure. But tools are getting a lot better to automate this sort of thing. You don’t need a whack-a-mole game to do clickjacking anymore, there are whole Javascript frameworks to automate everything. In fact, the attack is as easy as just getting them to visit the shady site, no clicks required. One such tool is:

http://www.contextis.co.uk/resources/tools/clickjacking-tool/

Currently clickjacking defense is treated somewhat less importantly than XSRFf, but the fact is, the surface area for a clickjacking attack is basically identical to XSRF. Both are confused deputy problems.

One of the first ways to defend against this attack was frame busting scripts, which are snippets of Javascript and HTML to try to make it so websites can’t be invisibly framed. These are notoriously difficult, and can vary from application to application. To deal with this problem, Spencer Low went into a cave of solitude for some time and came up with a pretty good framebusting solution. Unfortunately, it turns out whatever frame busting solution you have is circumventable using IE’s XSS filter in IE8 or IE9. Details are

http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=225200337

So there is only one defense that really works to defend against clickjacking, and this is X-FRAME-OPTIONs.  X-FRAME-OPTIONs is a newish header designed by Microsoft that’s now included in all modern browsers (chrome, Firefox, Safari, in addition to IE8 and IE9). What X-FRAME-OPTIONs does is set a header that says this response cannot be framed except under certain circumstances. There does need to be work on server applications to add this header, but I believe this is fundamentally the right approach to stop clickjacking. You don’t want lolcats framed by the shady site? Just configure lolcats to put the X-FRAME-OPTIONs header in the response and it cannot be framed.

Here’s the problem, X-FRAME-OPTIONs has three options: ALLOW, SAMEORIGIN, and DENY. That’s it. And they do exactly what you’d think they do.

What if, by design, I want my application to be framed by something in a different domain? There are a lot of legitimate circumstances this happens, and they pop up all the time in Online Services.

As a security industry, what we do right now in these situations is say there’s no good and easy defense. Web applications are sometimes vulnerable to clickjacking because the fact is there’s nothing good we can really do on these edge case scenarios. We can (and do) develop frame busting scripts that takes a lot of work, probably have holes, and are certainly bypassible in IE8 and IE9 due to the XSS protection unless we just explicitly switch off the XSS protection. It’s an active problem to determine if switching off XSS protection in order to hopefully develop a script that might with enough effort prevent clickjacking is worth it.

I wonder why when designing X-FRAME-OPTIONs it wasn’t just designed as a whitelist solution. Instead of only having the ALLOW, SAMEORIGIN, and DENY options, it could have a list of domains that are allowed to frame the content. It would make so much more sense to explicitly allow domains that are allowed to frame our application instead of being arbitrarily restricted to sameorigin. It would give us flexibility while at the same time allowing us to be safe.

I applaud the IE team for coming up with X-FRAME-OPTIONs in the first place, and for other browsers to adopt it. It can protect 95% of sites from clickjacking. I just wish that we didn’t have to have vulnerable sections of applications just because of the limitation of options.

Filed under Security Tools

Follow

Get every new post delivered to your Inbox.