Topic: Yet More Packet Analysis... (Read 172 times)

Omikron · « **Reply #15 on:** November 19, 2002, 06:00:00 AM »

QUOTE (Zander @ Nov 19 2002, 12:31 PM)

opjose,

QUOTE

By performing the same trick on the MAC address you can get a working eeprom. However there is something more to it than this, somehow the header values (I believe) are tied to the Serial/Mac keys, although it could well be that the online serialization is at fault as I have not had a chance to try this.

After talking to a couple of guys last night, I might be at a brick wall. The online key burned into the eeprom during the xbox's creation IS stored in the back-end database on the XBL network. I can tell this because as apart of the kerberos spec as defined in RFC1510, the key is a shared secret key, the key is never put over the wire, it's already known by both parties. AS.XBOXLIVE.COM knows this key by querying the back-end (which I'm sure is Active Directory) and it get's the key needed for authentication, this key matches the eeprom.

Now here is where it get's sticky, and I get out of my field. What if the online key is semi-random upon creation? Among a few other things in the eeprom, you have the following (as near as I can tell).

time
audio setting
video setting
serial #
MAC
hdd key
online key

now IF that online IS random, they we may have a problem. There would be no way to determine the online key based on the serial number or MAC of the xbox unit that someone is trying to "clone" to get it online via Live, you would need to open the box and get the contents of the eeprom. IF the online key is a hash somehow of the MAC or maybe HDD key, then we could have something to work off of.

But I'm afraid if the online is random, then we are screwed. Thay means getting serials off of unit means nothing (this would explain why the serial is transmitted in the cleartext during the conversation, it means nothing, it's just used by the back-end to lookup a key to be used for encryption.

Thoughts?

Z

Congratulations Zander,

You have hit on a point I have been thinking about for some time now. I know for a fact that kerberos tickets are very reliant on synced time. I know this because my university uses kerberos extensively and the community here has done some probing into our infrastructure. If your computer clock is too far off from the server clock, the kerberos tickets are invalid and access is denied. I have yet to test my theory with my xbox because someone is borrowing it but I am sure this has something to do with it. In addition, it would not be too hard for them to implement other checks, besides time hash, to generate tickets. If there are other checks however, it has to be based on non-dynamic data or predictible data. The video mode can be changed at will and there is no way for them to "know" in advacne what mode you are using. Other aspects however, such as MAC,HDD Key, Serial, Processor Number, and even perhaps *Region Codes*, may be used to hash out something. It's really early in the morning so you'll have to forgive any minute errors I may have made but that is my little contribution for today.

Now I must go back to studying for my Chem exam...

PillMonster · « **Reply #16 on:** November 19, 2002, 06:07:00 AM »

Zander:
Sounds good - best I've heard so far.

mod7 · « **Reply #17 on:** November 19, 2002, 08:29:00 AM »

Wow what do you know....man in the middle attack like I freaking mentioned what was it 5 days ago. If any of you use linux/unix out there here is a start. Try ettercap from http://ettercap.sourceforge.net/ by Alor and Naga....I am a beta tester for this and can help test I just cannot do too much c programming yet....so if anyone would like to try some of this stuff I am game....I have the sniffing/man in the middle knowledge if you have the c programming knowledge. btw already have packet sniffs etc performed on a sidewinder box on the inside nick and outside etc using tcpdump ettercap and other bits of info.....also this brings up a great program as well that is windows based it is called hailstorm....hmmm lets see url is http://www.cenzic.com/ they have an eval there for it....what it can do is capture all packets sent from a specific node and save it and regenerate it.....what needs to be done is a filter for ettercap written in c to replay the good packets from a non modded chip....i.e. your box with mod disabled then renable the mod and do a man in the middle attack and shoot off the good packets....not actually that hard cause all we have to do is send packets....I am however worried about time stamping should'nt be too much of an issue etc....pm me.

Omikron · « **Reply #18 on:** November 19, 2002, 08:35:00 AM »

QUOTE (mod7 @ Nov 19 2002, 03:29 PM)

Wow what do you know....man in the middle attack like I freaking mentioned what was it 5 days ago. If any of you use linux/unix out there here is a start. Try ettercap from http://ettercap.sourceforge.net/ by Alor and Naga....I am a beta tester for this and can help test I just cannot do too much c programming yet....so if anyone would like to try some of this stuff I am game....I have the sniffing/man in the middle knowledge if you have the c programming knowledge. btw already have packet sniffs etc performed on a sidewinder box on the inside nick and outside etc using tcpdump ettercap and other bits of info.....also this brings up a great program as well that is windows based it is called hailstorm....hmmm lets see url is http://www.cenzic.com/ they have an eval there for it....what it can do is capture all packets sent from a specific node and save it and regenerate it.....what needs to be done is a filter for ettercap written in c to replay the good packets from a non modded chip....i.e. your box with mod disabled then renable the mod and do a man in the middle attack and shoot off the good packets....not actually that hard cause all we have to do is send packets....I am however worried about time stamping should'nt be too much of an issue etc....pm me.

Unfortunately, the man in the middle attack will be next to impossible. You forget that kerberos uses time as part of its authentication procedure. In addition, kerberos tickets EXPIRE. I do know what MS has set the expiration time to but it could be as little as 5 minutes. Hell of a window of opportunity, eh? For these reasons you cannot "replay" kerberos authentication procedures. They weren't stupid when they designed kerberos. In fact, they designed it *specifically* to thwart such attacks. You have to understand that kerberos isn't some dinky protocol MS wrote for xb live. It is a super-secure authentication protocol used in many classified environments.

MS using kerberos on the xbox is the same as using a biometrics retina scan to open your bedroom door. The only way to spoof such a security check is to rip out someone's eye, or in the xbox's case, the EEPROM. Good luck spoofing that.

Zander · « **Reply #19 on:** November 19, 2002, 08:38:00 AM »

Reading RFC1510, it doesn't seem all that hard Omikron...

It WOULD be that hard, if we didn't know the online key needed to decrypt the response from the AS server so we can get the session key to decrypt the ticket from TGS.

Z

mod7 · « **Reply #20 on:** November 19, 2002, 08:50:00 AM »

I told you that I am concerned about time stamping and I do not think this kind of attack is impossible. Nothing is impossible when it comes to network packets except for ssh protocol 2....now thats a hard one. I will do more research as it looks as if I will need to do this all myself....I need a c programmer for ettercap I will talk to alor and naga as well pm me if you know c and want to hook up.

Zander · « **Reply #21 on:** November 19, 2002, 08:52:00 AM »

As far as the time stamping goes, I've resent a AS-REQ packet out about 3 minutes after that AS-REQ packet's creation (with eeye's Iris sniffer btw) and the AS server still responded with a AS-REP.

Finding out what the timestamp lee-way is I think will be easy.

Z

mod7 · « **Reply #22 on:** November 19, 2002, 08:56:00 AM »

and also regarding time auth.

Each host on the network must have a clock which is "loosely
synchronized" to the time of the other hosts; this
synchronization is used to reduce the bookkeeping needs of
application servers when they do replay detection. The degree
of "looseness" can be configured on a per-server basis. If the
clocks are synchronized over the network, the clock
synchronization protocol must itself be secured from network
attackers.

btw keep in mind that a relay attack is not the same as a man in the middle attack.

http://www.netbsd.or....pl?number=8376

Zander · « **Reply #23 on:** November 19, 2002, 09:04:00 AM »

Basically, what is making kerberos secure, hinges on the "shared secret key" used to start the conversation, and used to transmit the session key. If you know the shared secret (which is the online key) you can watch the conversation and decode it.

You SHOULD also be able to intercept and modify it, re-encoding and regenerating the checksum all the while. Neither party every knowing any different.

Z

mod7 · « **Reply #24 on:** November 19, 2002, 09:25:00 AM »

Here is another start by the man the myth the legend dugsong!

http://marc.theaimsg...47881324253&w=2

also probably what were up against this time.

http://www.MS.com/te...dp_log_ovqw.asp

and something from that article that makes me smile

"These service tickets can then be used to access network resources without having to re-authenticate the client as long as the service ticket remains valid. These tickets contain encrypted data that confirms the user's identity to the requested service. Except for entering an initial password or smart-card credentials, the authentication process is transparent to the user."

without having to re-authenticate is the keyword here so attack is only on connection I would think.

mod7 · « **Reply #25 on:** November 19, 2002, 10:41:00 AM »

Sorry to keep replying again and again....but as opjose stated if we can determine what the difference in packets is good versus bad using a diff on a *nix box then we will know what the differences are. Ettercap provides functionality to filter a packet on the fly....i.e. say yomomma and gretchen are talking on yahoo messenger that kind of thing well in ettercap I can replace the name yomomma with dildo smacker and the name is changed on the fly for one party of your choosing....if we can determine whats missing in the invalid packets then we can filter that value out for the correct value using arp poisoning and filters with ettercap...ettercap now has a win32 port if that what u guys are on....what you need to do is run it on linux as that is what the devel uses and it works the best....just my 2 cents. damn I wish I was at home.

ArMaGeDdOn · « **Reply #26 on:** November 19, 2002, 11:37:00 AM »

QUOTE (Spree @ Nov 19 2002, 08:43 AM)

Dude man no offense but we are trying to keep the thread technical. We don't need crap like that blocking the view.

i'm just trying to cheer opjose on! this way he'll post even more technical info!!

and yeah. i'll shutup now.

but you're evil!

Zander · « **Reply #27 on:** November 19, 2002, 02:56:00 PM »

I haven't given up hope..... yet. ALthough I do have a major headache now because of this.

Z

Author Topic: Yet More Packet Analysis... (Read 172 times)