Toorcon 12

ToorCon 12: Computer Security Conference

Fifth Ave., downtown San Diego, CA
Fifth Ave., downtown San Diego
It's fall, and you know what that means—another ToorCon in San Diego. ToorCon, of course, is the annual computer security conference held here every year a week or so before Halloween. It's a smaller-scale, low-cost, local sister to other conventions as Shmoocon in DC or the mega-sized DefCon in Vegas. It seems to me that this year's ToorCon seems to be better attended than the past few years—people were waiting to get into some sessions due to overflow crowds—don't ask me what's different this year though.

David and Tim, ToorCon 12
David and Tim
The chief organizers are David Hulton (h1kari), Tim Huynh (nfiltr8), and George Spillman (geo), with a ton of volunteers and helpers. David introduced Johnny Long's "Hackers for Charity", which helps Ugandans establish computers and networks there. Then David and Tim discussed plans for upcoming ToorCon Seattle and ToorCamp. ToorCamp may be a Antarctica cruise ($6-10K) or a lower-cost Oregon or Washington trip.

The usual disclaimers apply to these notes. I did not attend every session. I didn't save notes for every session, even some I enjoyed. I may have misinterpreted or distorted the speaker's remarks. Furthermore, remarks here are my own opinion, and are not my employer's opinion. All errors, however, are the responsibility of my golden retriever, Fannie Mae.

Tales from the Crypto

Mark Hardy, CISM, CISA, CISSP, National Security Corp.

Mark Hardy, ToorCon 12 Mark gave the keynote, which was an interesting motivational speech, which I haven't full summarized. Basically, successful people have not just meaningless goals, but a focus on a big dream. He liked the book Seven Habits of Highly Successful People and discussed it's main points. Mark also mentioned the grandfather of motivational books, which was written in the late 1930s. One edition of it wasn't copyright renewed so it's public domain. He scanned and posted the book on his website at

Mark later gave a talk on cryptography. He began with an overview of crypto. Basic crypto uses simple substitution. E.g., Caesar Cipher (shifting letters so many positions). Easily breakable. Discussed more-complicated substitution ciphers, such as Playfair Cipher, and the Shmoocon crypto contest.

Transportation (permutation) ciphers and substitution ciphers (block or stream) are what most crypto algorithms use now. Ciphers aren't broken, but are brute-forced. Old ciphers, such as DES, can be brute-forced because the key is only 56-bits. Newer ciphers use a larger key space.

The big takeaway is: don't create your own crypto—use existing ciphers. Ciphers have weakness, and discovery of which make it easier to brute-force. New ciphers need to be peer reviewed and revised.

Smartphone rootkit and malware

datagram,, and Jimmy Shah, McAfee

These are actually two presentations, "IPhone Rootkit? There's an App for That," by datagram, and "Smartphone Ownage: The State of Mobile Botnets and Rootkits," by Eric Monti datagram and Jimmy talked about malware for smart phones (Symbian, Phone, & Android, for example). Smart phones are vulnerable to malware—it's not just for MS Windows PCs any more. Although they don't generally have MS Windows viruses, smart phones may have loosened restrictions to root or administrative privileges, allowing (sometimes signed) spyware, rootkits, and botnets to be installed, just as they are on PCs. Interestingly, Apple doesn't allow any antivirus software on it's iPhone store, so the only way to use AV software on iPhone is to jailbreak it first. My question is why do they have this restriction—is PR and perception more important than reality for Apple? Or, perhaps, are iPhones immune to malware :-).

Introducing the Domain Key Infrastructure (DNSSEC)

Dan Kaminsky

Dan Kaminsky, ToorCon 12 DNS allows one to authenticate (federate) from one domain to another. We've been trying to do this for years! DNSSEC makes it easy, but it's a pain to deploy.

Today, one must need to work outside your organization, and be able to authenticate to them. Large companies require this also, as they are really a group of tribes that only share a common name.

Bad choices for federation:

  • M-to-1 "everyone trust me" Guy on top almost always seeks rents, or others trying to get on top to seek rents.
  • M-to-any "everyone trust the cabal" Basis of X.509 CAs. Problem is too many people in the cabal, and list is not trusted.
  • M-to-N "everybody, figure out who you trust" AKA "Giant Punt"—tell customers to figure it out. Manually bring new groups into federation, which doesn't scale.

DNS is weird. People paranoid about ICANN, root manager, from day 1, and tied down with bureaucracy.

DNSSEC works by asking a question, and getting a signature with a signature. Lets DNS store trusted data. But can DNSSEC be easily deployed?

To setup DNSSEC, Dan envisions two steps:

  • Change DNS port from 53 to 5053.
  • Run ./phreebird

DNSSEC problems come from ability to operate offline, but DNSSEC can be configured online. To prevent DOS, cache signatures and cache nonexistence. Under heavy loads (attacks?), prioritize replies. If overload, DNS server replies with SERVFAIL (intermittent failure not for caching, but for retry). Not every DNS servers on planet needs to do it hard way—"off line". Except for major root DNS servers, they don't need to have DNS server support offline keys. Most DNS servers can easily support keys online. Offline key management unable to handle special cases well (key expiration, for example).

End-to-end secure transport (chain of trust) is important! DNSSEC originally for allowing name servers to verify data (not good for desktops—end-to-end though). Desktops originally just get a "safe" bit declaring safety. Not realistic though—a bit is not really trustworthy—no chain of trust.

Must separate DNS concept from DNS transport. Here's some transport possibilities. X.509: one possibility is to use X.509 certificates as a secure delivery mechanism. X.509 is pretty broken though. HTTP Tunneling: tunneling DNS over HTTP is actually faster than DNS alone. OpenSSL can be used to deliver DNS ("PhreeLoad" is demo software that does this). Changes all DNS lookups to DNSSEC lookups. Dan demo'ed DNSSEC with a modified curl and wget (command-line web clients).

Problem is most browsers don't run Linux or OpenSSL. Dan showed way to configure all browsers via proxy configuration. DNSSEC is outsourced to a PhreeLoad-based third-party proxy server. Linux makes it clean to hook functions inside APIs. Harder with MS Windows,, but not impossible. DNSSEC can be used to exclude, which may make it better than X.509 (X.509 cannot exclude—a big technical flaw that makes X.509 broken). DNSSEC has one root, not X.509's thousand roots. DNSSEC becomes a race to the top, unlike X.509's race to the bottom. Higher quality domain registers are sought out with DNSSEC (as only one register handles a domain). SMIME signature are useless—anyone can issue a certificate. "Self-licking ice-cream cones"—no user in the world cares, only technical experts care or understand certificates.

DNSSEC and CAs are useful. Just understand they validate domains, but are not for validating brands. That is what EV (Extended Validation) is for. EV should be ported from the web to email though. DNSSEC can finally deliver the promise of secure email.


  • Domain Key Infrastructure real
  • Federated OpenSSH works
  • Browser locks work
  • Easy application integration works
  • Email works
  • This is real, and is a big deal.
  • Code release coming up (getting registrars on board).

Exploiting SCADA Systems

Jeremy Brown, Tenable Network Security

Jeremy Brown, ToorCon 12 Well, it's another ToorCon, and that means yet another talk about vulnerable SCADA systems. SCADA systems, of course, are the command and control network for power and other utility grids. Saying SCADA systems are insecure is like saying my dog likes chewing expensive shoes and important documents—pretty obvious, but what do you do? We've been hearing for years about the loose and sloppy security for these systems, although in the past year or so I've actually heard about it in the "mainstream" press. I'm not knocking the presentation though, just the apathy. Human nature, I guess. You don't really know what threats are real until after they happen. Well, who care's—not my problem. I have enough to think about, like getting my broken garage door replaced.

What's wrong with SCADA security? First, its been implemented as an afterthought or "add-on," instead of from the ground-up. But SCADA systems are built for the long term, and not upgraded. Often upgrades require new hardware, so even if a customer wants to upgrade software, they don't do it. Shutdowns of utilities or factories are often not practical or to be avoided. Although SCADA is not supposed to be Internet-connected, it often is connected, if only indirectly (say a machine connected to another machine). SCADA software usually has no authentication.

SCADA vendors dislike hearing about vulnerability reports—they are usually ignored or vendors are security-unaware. Usually vendors ignore you until you release the vulnerability to the public. ISCCERT (Industrial Software Consortium CERT) coordinates SCADA vulnerabilities. Here's some favorite quotes received after sending vulnerabilities:

  • I'm not sure what this perl script is trying to do?
  • If a CSV file is edited, it may not parse correctly (that's because it's smashing the function return pointer!).
  • From what I can see there is no security vulnerability in our product, if a CSV file is invalid, the application won't run correctly.
  • Hi Jeremy, thanks, but please don't waste my time.
  • That sounds like a threat Jeremey, are you expecting me to pay you something?
  • Product A isn't accessible from the Internet, so is not vulnerable to attacks
  • As long as you don't open files with untrusted apps, there is not a problem
  • Product ABC uses a complex protocol which is documented only internally.

Why is SCADA software auditing important? Kevin Finisterre is a SCADA security researcher, who released a SCADA exploit. His favorite quote is "if you outlaw SCADA exploits, only outlaws will have SCADA exploits."

MODBUS Fuzzing (Python script) helps discover SCADA vulnerabilities. It fuzzes random data to TCP port 502 (or any other port). "Tunneler" Protocol has no documentation, but can be reversed-engineered with network packets and needs auditing. Playing with lengths can be fun (or useful or not).

Sploitware (C & Perl) is a framework for SCADA systems (similar to Metasploit). No release plans. Helps write/find exploits, and has automated checking for known exploits.

Next, Jeremy demoed some exploits. One, not public and unpatched, adds an administrative user to Windows XP.

Recommendations to SCADA vendors:

  • Vendors should try to break it before ship it. Check out TAOSSA book
  • Vendors: please don't back door software. Jeremy named a few vendors that do this
  • Clients: do a security eval before purchase (Jeremy does this)
  • No vendor takes security seriously enough, but Siemens is probably the best in this respect

Advanced IBM AIX Heap Overflow Methods

Tim Shelton, redsand, Hawk Network Defense & Black Security

IBM's UNIX-based AIX OS is important, of course, because it's an enterprise platform used by many large corporate customers, along with Oracle or DB2 mission-critical databases, CRM, or Enterprise Resource Planning.

"Introduction to Heap overflows on AIX 5.3L" by David Litchfield (2005) discusses use of heap free()/rightmost() functions. Five years later, it still works today, on AIX 6.1 PowerPC systems. Modern processors and OSs (Solaris, Linux, but not AIX) have stack checking and other controls. AIX is still living in 1985.

David's methods uses double linked list corruption—only needs to 8 bytes to exploit: first 4 bytes is location of a fake heap frame, and 4 bytes is heap size. Sixteen bytes is better (RPC code):

  • 4 bytes branch instruction
  • 4 bytes no-op
  • 4 bytes value to overwrite
  • 4 heap size

Method allocates memory, writes more than allocated, frees, and depends on heap code to execute (return to) exploit function. Jeremy showed a demo perl script that installed, via gdb, hex PowerPC assembly code did the exploit. Can use AIX heap debugging tools ($MALLOCDEBUG) to help corrupt the heap, especially useful for setuid binaries. Can buy cheap PowerPC and RS6000 systems on eBay to develop AIX exploits (neeed Power6 or Power7 architecture). IBM has seen this presentation, but doesn't seem to care about stack exploits. AIX is everywhere, but it is behind the scenes.

How I Met Your Girlfriend (PHP, Javascript, and other web-based exploits)

Samy Kamkar,, Fonality (IP PBX company)

Samy Kamkar, ToorCon 12 Samy Kamkar talked about new web attacks. Samy does it for fun, not professionally. Created MySpace XSS worm, then was raided by the US government. Served 700 of community service and probation.

Why the web? It's cool, exploitable code-distribution channel. Web browsers are powerful, even in ways not originally designed (extendible, such as SMTP).

Samy reviewed PHP sessions. Session cookies have IP address, date stamp, & random value (160 bits). This is all sha1-ed. PHP session cookies used for Facebook, bank accounts, etc. Can the cookie be brute forced? 160 bits take 900 quadrillion eons. IP is easily obtainable. Date is partly predictable and only 20 bits used for microseconds. Random value is 64 bits, but is just pseudo-random (prng), and can be reversed. PHP throws together 2 random numbers though, so it's harder to reproduce. If you get the seed, you know all the pseudo-random numbers. Seed based on TOD of PHP (web server) startup. 20 bits of TOD unknown (microseconds). Also uses process PID, which is only 15 bits (and often obtainable from the default Apache or PHP info page). Only 40 bits left, which can be brute-forced (1 million cookies). Can use 500K requests to brute force cookie (time/memory trade-off). Facebook not vulnerable because they use compiled PHP, and don't use PHP session cookies. PHP session attack possible on other PHP sites though.

PHP defense: upgrade to PHP 5.3.2 (has a lot more entropy, as Samy told them about the problem and they were quick to respond with a fix). Create your own session values.

Next, Samy discussed an IRC exploit with NATs. NAT pinning confuses the browser and router. Sends thousands of port connection requests with Javascript. Eventually, overflow the port space (only 64K ports). Browser doesn't truncate to 16 bits, but NAT does truncate, bypassing browser security checking. Can hit and scan any port a client has open.

Prevention. Can prevent with a strict firewall on your computer.

  • Use a good firewall
  • Update browser
  • Use Firefox NoScript.

Next Samy discussed finding where a client is located. You can use JavaScript to determine the computer's router's brand. Can find use JavaScript AJAX to get external router MAC address. BTW, Apple routers are not exploitable (no JavaScript on router, no web interface). Can use data from Google's StreetView car to geolocate IP address (router MAC address and GPS coordinates are stored unencrypted). Unencrypted data can't be deleted due to legal process.

Modern browsers (HTML5) also have geolocation (disabled by default, but not the default). How to prevent? Don't know—privacy is dead.

Further information

The Law of Computer Search and Seizure (Fifth Amendment

Marcia Hofmann, EFF senior staff attorney

Marcia Hoffman, EFF, ToorCon 12 EFF exists to protect civil liberties in a digital age. Will talk about Fourth amendment and how it applies. Fourth amendment talks about unreasonable government searches and seizures. Area is frustrating because answers are not known yet, as founders weren't thinking about computers. Have to think about what founders "would have wanted" if computers existed then or if amendment would have been written today. BTW, fourth doesn't apply to private searches (work, for example).

Main question: does person have reasonable expectation of privacy? If so, police need warrant based on probable cause. No warrant needed if consent given, plain view, search incident to arrest, for automobile, or "exigent" circumstances. Exclusionary Rule says if Fourth violated, evidence can't be used.

What is a computer like? Is it like a home? Is it like a box? What about a file cabinet, brief case, phone? Courts say a computer is like a container (e.g., suitcase). It's sealed and closed with a reasonable expectation of privacy. So a warrant is needed to search a computer.

What are computer files like? Paper? Files? Book? Some courts say a file is like a separate container (e.g., suitcase). Other courts say a file is like the "stuff" in a container. Big difference, legally. If files are stuff in a container, you can access everything in a container (computer). If files are separate container, you can access only one file.

The rules courts made for search and seizure don't translate well to data.

  • Example 1: "open" v. "closed" dichotomy. What is open on a computer? Does it have to be on a network? What about a private network?
  • Example 2: Is copying a data (without removal) a "seizure"?
  • Example 3: storage and retrieval. Access is a lot easier and faster on a computer, with targeted, automated tools.

Electronic communications (e.g., emails) are regulated by Wiretap Act (content), Stored Communications Act (stored records), Pen Register Act (routing info), and state laws. How Fourth applies to this is unclear, which is surprising considering how long email has been around.

Fifth Amendment is the right to remain silent. Why have this? Founders concerned about you being put in a tough bind, otherwise: you can be held in contempt of court (say nothing), held in perjury (if you lie), or prosecuted (if you tell the truth). Fifth only applies to testimony (not documents) and only applies to criminal, not civil law. Protects innocent against prosecution when there's no evidence.

What's a password like? A key? A container :-)? Court says a password is like a combination lock. Act of entering combination is incriminating.

Conclusion: current rules are not a good fit and there's a lot more questions than answers.

SSLSmart: Smart SSL Cipher Enumeration

Gursev Singh Karla, Foundstone, McAfee

Singh Karla, Toorcon 12 Gursev discussed a SSL tool. for SSL pen testing. It's open source, Ruby-based, with a GUI interface. SSLSmart is more granular than existing test suites, to help reduce false positives and to allow focusing on particular problems. You can select specific ciphers, key lengths, SSL/TLS versions, target host URLs, and proxy routing. The tool only connects to the target hosts—it does not try to access content. SSLSmart verifies X.509 certificates it receives.

Garret Gee, Toorcon 12

Building a Portable Security Environment with Binpack

Garret Gee,

Binpack is a full portable penetration testing environment. Other tools require a full OS environment: Linux (Knoppix, Backtrack, Pentoo, etc.), Windows (WinPE, BartPE). Or you need a full app suite such as Windows' LiberKey. Also available are app collections, such as PAFL on Linux, or winPenPack, DemocraKey on Windows.

Wanted everyone in group to have the same tools and training, to allow for rapid repair, and easy incorporation of new tools. Wanted it modular (for easy upgrade), portable to various OS environments, and to deploy rapidly. Started out with 30MB of tools 2007, which grew to 900MB of tools in 2009. Categories of tools are development, forensics, installers, multimedia, network, security, and utils. Includes existing SecTools100 ("Top 100" pen tools) collection. Binpack installs the tools for you and sets up the paths and environment.

LANRev's Multiple Vulnerabilities come to light

Joel R. Voss, Leviathan Security

Joel Voss, Toorcon 12 A Pennsylvania High School used student-issued laptops to spy on them, using LANRev (to prevent theft). LANRev give school admins camera access (and, it turns out, hackers, due to bad software). LANRev privacy is opt-in and surveillance is opt-out. Joel is using LANRev as an example of poorly-written software and how to find vulnerabilities.

The first thing you try is gathering lots of packets and play them back. usually you have a few seconds to replay packets before it's not allowed. this allows reverse engineering. python and its socket library is great for replaying packets. socket.socket() is your friend. Also Scapy (packet forging library), and Middler (arp spoofing, packet rewrite; uses Scapy).

LANrev has three ways to access the webcam (decrypt shot, background program, or foreground program). Adobe Flash has built-in camera access. LANrev is implemented with a root kit.

Public key crypto is hard to do correctly. Public keys only good if the key is secret, and even then it doesn't authenticate. Static symmetric keys don't secure—they obfuscate. One key is useless—allows easy replay once the key is known. LANrev didn't use multiple keys do not lose control of laptops.

Why Security People Suck

Gene Bransfield, Tenacity Solutions

Gene Bransfield, Toorcon 12 Security people suck because they don't get the word out. They fix it, but non-technical people don't understand the language. Security people preach to the choir, but need to speak the language of the ignorant (business types, developers, & end users).

Culture is essential for communication. Unspoken (implicit) understandings exist before you speak: male/female, old/young, proper/improper. Understand FUD of different cultures: business guys are "noble philosophers," developers are "ignorant barbarians," and end users are "peasants." People don't listen to technical talk.

Business types. If you don't influence business types, vendors will do this. Should argue on cost/benefit analysis, and financial risks/rewards. Risk is annual loss expectancy. Use Andrew Jacquith Security Metrics—best chapter is chart creation. Also Gene Siciliano Finance for Non-Financial Managers (cash is king and don't pay bills on time). Example: worms in .zip files at Air Force National Guard. Gene argued in terms of putting mission at risk, and opportunity cost of downtime from worms. He proposed a simple solution—training "peasants" with detailed instructions to handling .zip files.


Developers. They want to build a beautiful system. Need to have a Security Policy (Sarbaines-Oxley, HIPPA, NIST are not written for developers). Problem is schedule pays better than security for developers: don't worry—be crappy. First to market is important. Solution: write a security policy, build a system of rewards (Microsoft has this), act upon that system, and enforce standards.

Barbarians (masses). People defend against external threats, but forget to take their medicine. Disease is number #1 killer, but is not a visible threat. So, the solution is to change things from the inside. Must talk to the filthy masses.

Building the DEFCON Network: Making a Sandbox for 10,000 Hackers

David Bryan and Luis Eduardo,

David Bryan, Luis Eduardo, Toorcon 12 David and Luis setup the DEFCON wifi network for DEFCON. They do the wired and wireless parts respectively, along with six othes. DC6 had a T1 (Plaza). DC7 exploded in use (but not capacity). DC13-14 had 5mbps (Alexis Park). DC15-18 at Riviera Hotel had 6-100mbps.

Goals is reliable connectivity, secure-ish, and fast interweb. WiFI everywhere with speakers, events, humans. Segmented network among public, speakers, press, greenroom, CF networks, OpsNet, Infobooth, contests (several), public servers, and reg desk.

Want low cost. Beg, borrow, steal, eBay. Cost is not cheap—$5-$10K for a week. Dealing with unions is painful (can't DIY), union fiefdoms. Riviera has fiber infrastructure (unusual).

Wifi. Recently, a lot of demand with 3G smart phones—no 3G in hotel, so a lot switch over to wifi. A lot more ubeser density than with laptops.

Challenges: 1 week on-site, 3 days setup, 8 people team. Broken up into infrastructure, wifi, and video. Requires preplanning and logistics.

High-level network view. Firewall with ~150 vlans. Implemented with FreeBSD (previously OpenBSD). No cross-talk with vlans: 50 unsecure wifi, 50 encrypted wifi, 30 internal. All static routes.

Wireless network has 40 APs—half are on, and are turned on and off based on demand. All traffic goes directly to firewall. Firewalls are stateless and uses layers 2 & 3. Channel allocation is automatic to avoid conflicts (using Aruba controller). (802.11b/g channels 1, 4, 7, 11). Shutoff troublesome nodes based on MAC address.

Future is more GBs capacity. Maybe 802.11n. Maybe IDS, maybe logging. IPv6 is a goal, but not well understood (especially security implications and configuration) and stability is more important. Internal debate about IPv6. IPv6 worked fine at Shmoocon.

Lord of the Bing Taking Back Search Engine Hacking from Google and Bing

Francis Brown, Stach & Liu

Francis Brown, Toorcon 12 Google Search and Microsoft Bing used to give interesting results when searching for vulnerable systems (~2005). Much of this is now filtered. Google stopped issuing SOAP API keys 2006, making it hard to use Google search database directly (unless you already have a key). Bing disables inurl:, link: and linkdomain: searches.

Google Diggity uses AJAX APIs, and Google custom search without violating Google's TOS. Bing Diggity uses Bing 2.0 SOAP API, profiling, and it's own hacking database. Google API limit you to 64 results per query. Bing has no limit and you can specify 1 IP address.

Defenses against Google/Bing hacking. First, hack yourself—problem is it's hard to setup, time-consuming, and there's no historical data. Stach & Liu publish now Google alerts for about 2400 live vulnerabilities. shows newly-vulnerable sites and use publically-available rss feeds. Alerts and tools are at Francis will be releasing a gadget that will filter these results for a specific website (yours, for example). In meantime, can subscribe to all of these rss feeds and search for your website.

Legal Panel

Kurt Opsahl, EFF (moderator), Marcia Hofmann, EFF, Professor Pamela Samuelson, UC Berkeley, Mitch Dembin, Assistant US Attorney, Sergey Bratus, Darthmouth College, Anna Shubina, Dartmouth College

Software as a Witness

Legal Panel, Toorcon 12 Dr. Bratus talked about trust of software on the witness stand. What can or can't be trusted with software-generated evidence? In one case, UMG v. Roy, was a RIAA p2p file sharing lawsuit. Evidence was a 940-page PDF from a computer program. Software was the only "witness," which automatically & autonomously finds targets, decides wrongdoing, and records evidence. Recognizes video and audio files and records a user as a <IP:port>.

Problems with evidence: packet contents not printed (non-printables printed as a dot). traceroute output was nonsense, SHA1 sums didn't match any known version of the recordings downloaded. Time synchronization is unknown. in summary—no evidence printed out. We entirely rely on the software being correct in correctly-analyzing download. ISP had dynamic IP address, but no MAC address to tie the download to the defendant.

For software, who can we call to witness stand? Developer? Operator? Software conflicts of interest exist in algorithm (bias to over-detect, ignore context), in code (bugs), or configuration (timing, network view). Examples of bias exist in red-light cameras. Defendants have the right to confront accusers in criminal cases. Who do you confront when software is the accuser?

Case outcome: case settled for defendant, with prejudice and no money.

Kurt Opsahl pointed out in federal criminal cases, only two software programs are used in criminal cases (NCASE?, EDGECASE?). Both software tools have been thoroughly veted.

Kurt and Marcia talked about the recent MySpace suicide case. Prosecution was with LA US Attorney. It was based on a horrible incident (a suicide induced after a mother faked a personality and online relationship and drove the victim to suicide). Case was based on "exceeding authorized access" of a computer (the website) based on the website's terms of use. Criminal prosecution based on this is rather shakey, as the TOS can be changed any time, without notice, to any terms. Unauthorized use of a computer is clear-cut. Exceeding authorized access is more of a gray, unsettled area of law.

Disclaimer: the statements in this blog are my personal views, not that of my employer.

<script type="text/javascript" src=""></script>
<script src=""></script>

Post a Comment:
Comments are closed for this entry.

Solaris Verified Boot, cryptography, and security.


« June 2016