-//--**--//--xx--//--**--//--xx--//--**--//--xx--//--**--//--xx--//--**--//-
.o (( Reconstructing Serialized Java Objects from Sniffer logs by afx )) o.
-//--**--//--xx--//--**--//--xx--//--**--//--xx--//--**--//--xx--//--**--//-
[Introduction]
Firstly, this isn't about instant, root-in-one-pass, breaking and
entering. This isn't going to let you run out and crack a hundred
machines the minute you've finished reading... in fact, unless
you're doing security consulting, or have a specific target in
mind, it's unlikely that you'll find this of much use.
Still interested? Good.
Briefly, what I'm going to touch on is the potential that the
widespread use of Java has offered to those of you that find
themselves on the one of the many corporate nets that use custom,
networked Java software. Specifically, you'll find a brief
overview of the reconstruction of serialized Java objects from
sniffer logs, along with some necessary references.
[Details]
One of the really nice features of Java for developers, is that
it supports object serialization, allowing you do such funky
things as saving objects to disk, passing them around the network
between different machines and generally making a programmers
life that little bit more simple.
As with any new technology, the potential pitfalls of poorly
implemented systems are not well known. The end result of this
is that you may find on some, otherwise secure, networks, that
this might provide an alternative method of access to company
systems, or information.
Additionally, the serialization of Java objects also allows
one to run complex network applications over firewalls and the
like, by enabling one to send serialized objects via HTTP back
and forth between various clients, servers, and peers. Again,
this can occur over the HTTP protocol (NOT just TCP/80), enabling
these applications to work over even proxy-level application aware
firewalls, making this a great method for developing software
for large corporate networks.
What I'd like to do first, is point you to a reference that will
describe, in detail, the specifications for the serialization of
Java objects:
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/serialTOC.doc.html
The packets below were captured and printed using Ethereal. If you
don't already have it, get it! You'll find it more than useful
in learning about low-level implementation details for just about
*ANY* network protocol.
Ok, now that you have the info, here's an example of a Java client/
server application that uses message objects, and, surprise surprise,
one of the uses of these objects is to send login requests to the
server.
The first packet (several deleted for brevity):
Frame 5 (691 on wire, 691 captured)
Ethernet II
Internet Protocol
Transmission Control Protocol, Src Port: 3311 (3311), Dst Port: 80 (80),
Seq: 1498601, Ack: 410092836
Hypertext Transfer Protocol
0 0050 8b62 4dda 00d0 b717 47a1 0800 4500 .P.bM.....G...E.
10 02a5 dfce 4000 8006 1ae2 c0a8 3e33 c0a8 ....@.......>3..
20 3e1e 0cef 0050 0016 dde9 1871 8524 5018 >....P.....q.$P.
30 2238 df65 0000 aced 0005 7372 0029 6e65 "8.e......sr.)ne
40 742e 6579 6532 6579 652e 6469 7374 696c t.eye2eye.distil
50 6c65 7230 382e 636f 7265 2e75 6473 632e ler08.core.udsc.
60 4d65 7373 6167 6501 7182 0d8b 4ff1 2202 Message.q...O.".
70 0004 4900 0b69 6e73 7472 7563 7469 6f6e ..I..instruction
80 4c00 0269 6474 0012 4c6a 6176 612f 6c61 L..idt..Ljava/la
90 6e67 2f53 7472 696e 673b 4c00 036f 626a ng/String;L..obj
a0 7400 124c 6a61 7661 2f6c 616e 672f 4f62 t..Ljava/lang/Ob
b0 6a65 6374 3b4c 000b 7365 7373 696f 6e49 ject;L..sessionI
c0 6e66 6f74 002b 4c6e 6574 2f65 7965 3265 nfot.+Lnet/eye2e
d0 7965 2f64 6973 7469 6c6c 6572 3038 2f63 ye/distiller08/c
e0 6f72 652f 7564 7363 2f53 6573 7369 6f6e ore/udsc/Session
f0 3b78 7000 0000 0474 000e 2331 4c6f 6769 ;xp....t..#1Logi
100 6e41 7474 656d 7074 7372 0027 6e65 742e nAttemptsr.'net.
110 6579 6532 6579 652e 6469 7374 696c 6c65 eye2eye.distille
120 7230 382e 636f 7265 2e75 6473 632e 4c6f r08.core.udsc.Lo
130 6769 6ec3 f739 41c9 f15e 1a02 0005 4900 gin..9A..^....I.
140 0973 6573 7369 6f6e 4964 4900 0675 7365 .sessionIdI..use
150 7249 644c 0004 7061 7373 7100 7e00 014c rIdL..passq.~..L
160 0006 7365 7276 6572 7400 2a4c 6e65 742f ..servert.*Lnet/
170 6579 6532 6579 652f 6469 7374 696c 6c65 eye2eye/distille
180 7230 382f 636f 7265 2f75 6473 632f 5365 r08/core/udsc/Se
190 7276 6572 3b4c 0008 7573 6572 4e61 6d65 rver;L..userName
1a0 7100 7e00 0178 7000 0000 0000 0000 0074 q.~..xp........t
1b0 000d 6576 696c 3132 3864 6831 3264 3773 ..evil128dh12d7s
1c0 7200 286e 6574 2e65 7965 3265 7965 2e64 r.(net.eye2eye.d
1d0 6973 7469 6c6c 6572 3038 2e63 6f72 652e istiller08.core.
1e0 7564 7363 2e53 6572 7665 72e6 3356 4223 udsc.Server.3VB#
1f0 c12c dc02 0005 4300 0c64 6576 6c5f 6f72 .,....C..devl_or
200 5f70 726f 645a 0008 6973 5f6c 6f63 616c _prodZ..is_local
210 4900 0d73 6572 7665 725f 6e75 6d62 6572 I..server_number
220 4c00 0761 6464 7265 7373 7100 7e00 014c L..addressq.~..L
230 000c 6469 7370 6c61 795f 6e61 6d65 7100 ..display_nameq.
240 7e00 0178 7000 6401 ffff ffff 7400 3c68 ~..xp.d.....t.<h
250 7474 703a 2f2f 6465 7673 6572 766c 6574 ttp://devservlet
260 2e65 7965 3265 7965 2e6e 6574 2f73 6572 .eye2eye.net/ser
270 766c 6574 2f47 6f6c 6465 6e44 6973 7469 vlet/GoldenDisti
280 6c6c 6564 5365 7276 6c65 7474 0014 476f lledServlett..Go
290 6c64 656e 2048 616e 6473 6861 6b65 2044 lden Handshake D
2a0 6576 7400 0d61 646d 696e 6973 7472 6174 evt..administrat
2b0 6f72 70 orp
Ok, the first thing you are going to look for is 0xACED. This
is the magic stream indicator. In most cases, the proceding word
will be 0x0005, which is the version number.
Following this will be the serialized object, which in basic
format, is usually a description of the object, followed by the
associated data.
The first bye of interest is 73, which is the object indicator.
(Java supports the serialization of simple data types, in
addition to complex classes).
This is followed by 72, the CLASSDESC marker, and a 16 bit int
indicating the length of the description to follow, in this case
0x0029.
The next 0x0029 bytes will contain the descriptor, in this case
"net.eye2eye.distiller08.core.udsc.Message".
After this we have a flag byte, indicating whether the object
in question is serializable, externalizable or none of the above.
In this case we have 0x01, SC_WRITE_METHOD set.
Now the basic format of each element is a marker ('L' for object,
'I' for integer, 'B' for byte, etc), followed by the 16bit length
indicator of the description of that element, and so on and so
forth until we reach the TC_NULL indicator (0x70).
Noticing some interesting elements in this object: sessionId,
userId, pass, userName... anything looking interesting yet?
Ok, now proceding out the actual data associated with this object,
we start seeing some data. The 0x74 (t) that occurs at 0x01AF marks
the beginning of a string. We see that the string is 0x0d long, and
can grab out the string 'evil128dh12d7'. Noting back to the beginning,
this is the string associated with 'pass'.
Carrying on after this we hit 0x73 's' - indicating another object.
This is followed by 0x72 'r' - the classdescription, and same format
of data as for the class that we are already disecting.
We can quickly build up a list of elements and their associated entities
for this nested object, and then carry on with the elements of the
parent object.
If you noted above, the last object to be referenced prior to the
TC_NULL marker, was userName (see 0x0195 to 0x01A4). By the way, object
references are usually created from 0x007E0000, so if you notice
the bytes 0x007E????, chances are you've spotted an object reference.
Well, rather than scanning through everything, we look to the end of
the object, noting to 0x70 'p' TC_NULL terminator, and work our way
back to spot the string associated with userName - 'administrator'.
Yay! :)
Unfortunately for us, if we bothered capturing the two way communication,
the response below from the server would show us that that particular
login attempt had failed:
Frame 5 (283 on wire, 283 captured)
Ethernet II
Internet Protocol
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 3306 (3306),
Seq: 410086118, Ack: 1499199
Hypertext Transfer Protocol
0 00d0 b717 47a1 0050 8b62 4dda 0800 4500 ....G..P.bM...E.
10 010d 3a47 4000 8006 c201 c0a8 3e1e c0a8 ..:G@.......>...
20 3e33 0050 0cea 1871 6ae6 0016 e03f 5019 >3.P...qj....?P.
30 1e8f 283d 0000 aced 0005 7372 0029 6e65 ..(=......sr.)ne
40 742e 6579 6532 6579 652e 6469 7374 696c t.eye2eye.distil
50 6c65 7230 382e 636f 7265 2e75 6473 632e ler08.core.udsc.
60 4d65 7373 6167 6501 7182 0d8b 4ff1 2202 Message.q...O.".
70 0004 4900 0b69 6e73 7472 7563 7469 6f6e ..I..instruction
80 4c00 0269 6474 0012 4c6a 6176 612f 6c61 L..idt..Ljava/la
90 6e67 2f53 7472 696e 673b 4c00 036f 626a ng/String;L..obj
a0 7400 124c 6a61 7661 2f6c 616e 672f 4f62 t..Ljava/lang/Ob
b0 6a65 6374 3b4c 000b 7365 7373 696f 6e49 ject;L..sessionI
c0 6e66 6f74 002b 4c6e 6574 2f65 7965 3265 nfot.+Lnet/eye2e
d0 7965 2f64 6973 7469 6c6c 6572 3038 2f63 ye/distiller08/c
e0 6f72 652f 7564 7363 2f53 6573 7369 6f6e ore/udsc/Session
f0 3b78 7000 0007 e574 000e 236c 6f67 696e ;xp....t..#login
100 5265 6a65 6374 6564 7400 0f4c 6f67 696e Rejectedt..Login
110 2052 656a 6563 7465 642e 70 Rejected.p
Appendix A of the specifications should give you other ideas of
the dangers inherent in this protocol, e.g. modification of
in-transit data, session hijacking (at a Java application level as
well as TCP level), sending objects containing your own code
spoofed so as to be from a 'trusted' source, et al. If you can get
a system to use you as a transparent proxy, a nice tool to play
with is ELZA from http://www.stoev.org.
Have fun ;)
laterness
-=afx=-
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986- AOH
