OTB @ DC16: New rules. New game. Same schmuck running the contest.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

A sample order:

FIRSTNAME: Manchu
LASTNAME: Shen
ADDR: 2755 Allison Avenue
CITY: Virginia Beach
STATE: VA
ZIP: 23464
PHONE: 757-578-7179

ORDERAMT: $32.70
CCN: 5364 9083 9935 7592
CCNEXP: 5/2011
CVV2: 6804

CUSTORDERHASH: K8fB87zHs6NRoLM8Vmdk

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

The available protocols by which you can accept orders from [redacted]:

SFTP:
Filename will be $CUSTORDERHASH.txt
File contents will be in the format above.

SMTP/TLS:
Email subject line will be "$CUSTORDERHASH Online Order"
Email contents will be in the format above.

HTTP(s):
As a POST:
The contents stated above, sent as an HTTP post to a URL you provide.

As a GET:
your.server.address/yourappname.ext?FNAME=Manchu&LASTNAME=Shen&ADDR=27 55%20Allison%20Avenue... (etc, etc)

Other Transfer Methods:
We are open to discussion. Since the scorebot has to be able to talk to your widget, we need to talk before con so we can implement something.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

You have to implement TWO methods. One of them HAS to be HTTP(s).

To acknowledge successful transmission, you have to resend part of the order back to [redacted] corp, via an HTTP request in the following format:

ordertrack.jsp?CUSTORDERHASH=K8fB87zHs6NRoLM8Vmdk& vendorID=[your ID]

... Or it might.

These guys are a little tough to deal with. Seems like the Accounts Payable guys keep changing their mind. They definitely want the order hash, but they're not entirely sure if they also want names, addresses, order contents...

Best to do something modular, you never know.

You get $1 per transaction successfully acknowledged. There will be lots of them.

Each transaction forged by an attacker (attacker sends a GET with the same hash) costs you an undisclosed compliance penalty that drops your score.

Entry that processes the most transactions at the end of con, or when the scorebot dies (whichever comes first), wins.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

The network:

128.66.0.0/16
gw 128.66.254.254

All orders (and all attack traffic) will come from IPs in that range, but it's hard to say where.

Mail me / msg me and tell me what you need IP-wise and I'll start keeping track.

DNS? Not likely.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

Well have fun. At least you saved me the air fare.

I already have over a grand invested in hardware and I still won't attend under these rules, I bet others won't as well. It's not pwn the box anymore.

If you want participation, a little less NASCAR a little more Demolition Derby. Sorry.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

while i think that Homeslice's comments may have been a bit abrasive, i am inclined to agree that these new specifications in the contest will likely result in some people pushing back, myself included.

I simply don't have the time to write a lot of code and script modular components together to fit within this framework. OK, to be fair... it's not a lot of code by any real stretch, but (not to sound negative here) i have a very strong belief that this contest will take at least half a day to really get up off the ground... while people figure out why the subnet isn't talking to itself and why their particular box which they tested at home suddenly isn't playing nice at all with others.

Fortunately, you made this announcement well in advance of DefCon, so some of us (myself included) may still opt to participate... but when i consider the time and resources involved (including plain old shipping of the hardware to and fro, which is also getting more costly these days) it seems like a high hurdle to participation.

I liked it when you had designed the contest simply as "here's your own unique crypto file... put it somewhere on the file system that people shouldn't be able to access" and let people go to town.

I love the concept of your new contest design, don't get me wrong... but i think that the actual implementation will (a) cause you some headaches and (b) result in diminished participation overall.

People liked your game because they (at least the defenders) could do the bulk of their work before DefCon. They just had to show up, plug in, and see which boxes lived. Now, there's a good chance (just my prediction, mind you) that people will show up and spend half a day dicking around with their settings trying to get stuff to function right. Defenders will miss the first day of talks, games, and fun and attackers will move on to other things as opposed to getting started in that initial rush of "omg! so much to do at con! what should i play?"

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

My frustration perhaps showed through too much. Wasn't trying to be abrasive, just disappointed at the direction it was taking. In my case, the hardware is very limited and not able to hang with the rest of the pack if it has to process data in a simulated production environment.

My biggest issue is the money already spent with the idea that the contest would be as you referenced above. I really don't want to be glued to my box writing code or tweaking some stupid app so that it plays nice with a system I've never seen before. I hate coding with a passion and I want to sit down and have some time to mingle, check out the vendors, drink beers with you guys and learn.

No offense to Skoot who I know is just trying to do the best he can to move the contest forward. I just wish that if that was the direction the contest was going to go I could have known with more advance notice, like maybe before I started soldering. Sorry if I came off disgruntled or unduely pissed off.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

Okay,

I'm going to have to ask that we all put the nix on this line of thinking.

Not everyone out there does E-Commerce, B2B, or transaction processing. This approach requires a bit of coding server side with any number of possible solutions, using anything from cgi-bin scripting, beans, etc. etc.

That is not the point of this contest, to specify one particular threat profile; it severely limits the possible offerings.

I'd like to ask that the goal be retrieval of a specific set of files places throughout each specific construct, that allow each participant to know to what level there respective offerings were 'owned' (hacked/cracked/jacked/smacked/spanked/exploited - etc.) and to what extent each entry resisted penetration by adversary actors.

With respect to infrastructure, the main requirements are for:
1.) Space
2.) Power
3.) Cooling
4.) IP address assignments
(10 per entry, to allow for virtual/multiple servers, admin nets, special interfaces, etc.)
5.) Switching fabric to allow for adversaries to plug in on one side of room, and have a contained access to targets (entries). Just use flat space, IPv4. No subnets or VLANS; it is useless, trivial to bypass, and the point is to stand up end points for exploitation, not waste time getting past the infrastructure, and spending half a day getting 'set up'.

The contest is not for demonstrating sys admin heroics of volunteers reconfiguring network at the last minute to support exercise. At work, I usually have such types sacked after completion of the exercise; no need for the drama of non-programmers. They are useless to the system.

Also, no NIDS, filtering routers, firewalls or infrastructure protections - just a closed sandbox with 100 to Gig throughput.

6.) Limit each contestant (defender) to 3 boxes (or some reasonable number = how many power plugs/amperage req.)

And finally, *highly* recommend limiting prizes to tokens that need to be retrieved (specify which ones shold be placed in A.) a user home dir B.) root file system C.) app dir - that should be plenty to prove box was owned.

That's it. If that is too much work, just say so, and we'll chalk it up to fun on a bulletin board, no big shakes...

Best, HAL

"It's all fun and games until you get to hang and bang on the Net with the Major....."

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

Did I err?

I fully respect the power of the forums. It's kind of like in the QA world where they say to pay attention the complaint desk. For every one customer with a complaint there are a hundred who remained silent but had the same problem.

And yet (!) last year nothing was reported owned, and I have a stack of CDs with really cool plaintexts that I spent a bunch of time putting together (the full text of the first DefCon announcement, the text of Neuromancer and The Fugitive Game, old Bell manuals, etc, etc) that no one deciphered...

We had fifteen or so entries that dutifully set up, plugged in, and were monitored with varying degrees of attention between "set it and forget it" to "sleep in the hallway outside the room".

We all had lots of fun, but as a defender contest? Fail.

So in chewing on this for a year, I concluded:

• Hardened-to-the-nuts boxen with minimal services, chroots, vms, and umpteen other things are nearly (but not quite) impossible to pop in 3 days.
  
• Not having requirements for what protocols are and some kind of actual measurable logic or function meant lots of default installs, static web servers, and stuff that said "200 OK Gofuckyourself."
  
• No one is going to drop a Vista kernel remote for a free eMachine. Just ain't gonna happen, folks. Dragos and pwn2own had free high-end laptops and ZDI money. This is DefCon. You get a t-shirt.

I promise you, I want wacky shit, I want bizarre and unexpected stuff (and after an offline convo, Homeslice definitely has this in spades with his contraption that may or may not make it past TSA), but I have to be able to measure it, somehow...

Is my approach above the right way to do that? Who knows? I don't see it as that high of a bar to do, but I fully respect that the web app focus is a derail. That said I saw last year as a success in terms of participation and interest but not in terms of the contest itself, and I'm trying to find a way to fix that.

I'm starting another thread and going from square one asking you all for input. It's your contest, not mine, but it needs to be measurable somehow. Much of what we figured out last year came from input on the forums from interested parties taking a half-cooked idea a bit closer to al dente. I hope we can find the magic balance somewhere of controlled chaos to do that.

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

I am all for the "retrieve token" idea. What about one freely available token for the bot to check that the machine is still alive?

Re: OTB @ DC16: New rules. New game. Same schmuck running the contest.

Moved to the right thread.