• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

Project: Injecting code on locked down systems

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Physical Security and Social Engineering

View previous topic :: View next topic  
Author Message
M3DU54
Trusted SF Member
Trusted SF Member


Joined: 11 May 2002
Posts: 1
Location: Las Palmas de Gran Canaria

Offline

PostPosted: Tue Dec 14, 2004 3:32 pm    Post subject: Project: Injecting code on locked down systems Reply with quote

Code Injector
by M3DU54 of +44

A dongle which, using only the AT or PS2 keyboard connector, will automatically inject code into a locked-down target system and execute it


The project

Heres an interesting little spinoff to the wireless keylogging article which you will find >here< - It uses similar hardware to achieve a different goal.


I have a friend, we will call... umm... Jim. Now, I met Jim at a grey-hatted conference Jim works for a telecommunications company and was more than a little bored. Y'see the computers Jim uses at work are tight - very tight. No USB, No Serial, No Removable Media, Intranet but no Internet access and poor ol' Jim was finding it impossible to load his own 'utilities' onto the system. Which is a shame because, as I later discovered, Jim has some *very* nice utilities.

Well, me and Jim got to talkin' and there was a weakness that Jim had spotted. Its a weakness you will find on just about every windows network - debug.exe hadn't been locked down on the workstations. And why would it? I mean who uses MS-debug these days?


Debug

For those of you that haven't used debug heres a brief overview.

Essentially debug.exe is a console mode program which assembles and dissassembles code among other things. Its quite simple to use and will display a program as either Machine Code (Hex) or Assembly Language (80x86 Mnemonics). It also lets you edit the code by inserting Hex or Asm wherever you wish. By the same token one could create software this way, if they had a hex-dump of the program they wish to create -or- knew how to program in Assembly Language. Its also the most useful and overlooked tool you will ever find on a targets system.

The problem is that Joe, despite his many talents, was unable to code in 80x86 assembly language (Quite a serious shortcomming for a hacker) and his interesting utilities were far too large to enter manually in hex. Something had to be done.


Keyboard interfacing to the rescue.

After a few bottles of Bud Ice(tm) and some hastily drawn diagrams on the back of a conference flyer we came up with the following plan:

A device will be constructed which powers from the keyboard interface. It will have a non-volatile memory. This memory will hold a simple binary image for a program.

When connected the device will generate keypresses required to ...

-Open the 'RUN' dialog (By pressing '[Windows-key]+[R]')
-Open MSDOS (Type 'CMD [RETURN]')
-Create a dummy file called x.exe large enough to contain the program
-Start debug.exe to modify the x.com file
-Using debug commands will populate this file with a copy of its binary image
-save the changes to x.exe
-Close debug.exe
-Execute x.exe

Thus we would have a dongle which, when connected, will automatically create and execute some software. However, we hit upon two snags

1. This would require a seperate dongle for each program
2. The time taken to copy the software onto the PC would be significant


More problems

So, a couple more bottles of Bud Ice and we finally had a design. Before I give you the solution we used heres a little background on the problem...

To enter 8 bytes of code at position 100 using debug you need to enter the following keystrokes
e 100 01 02 03 04 05 06 07 08[ENTER]
that is 30 keypresses.

If you have to use 30 keypresses to enter 8 bytes then thats 3.75 keypresses per byte (Quite a significant increase)

Each keypress typically requires around 3 bytes to be sent through the keyboard interface bringing the total number of bytes to 90. This represents a further increase of 200%. Therefore, to enter a 32kb program we're looking at sending 320kb via the keyboard interface at the speed of an old 1980's modem. Lets face it, its gonna take some time to complete - and every second increases your risk. We need a way to speed things up a little.

Also, Joe has more than one utility and it would be nice if a single dongle could hold a few different programs - but how to select between them without grouping them all together into a windows cab file? The solution to both these programs is a 'bootstrap' program. Heres how the bootstrap works...


Bootstrapping...

The dongle...
-Opens the 'RUN' dialog (By pressing '[Windows-key]+[R]')
-Opens MSDOS (Type 'CMD [RETURN]')
-Creates a TINY dummy file called x.com large enough to contain the loader
-Starts debug.exe to modify the x.com file
-Using debug commands it populates this file with the loader code
-save the changes made
-Close debug.exe
-Execute x.com

x.com then listens for the dongle

A microswitch on the dongle steps through the program titles in circular fashion until the button is not pressed for >1sec. It then dumps that binary image as keypresses which x.com sees and dumps to an appropriately named file. Have you ever 'tapped out' telephone numbers on a telephones hookswitch? Well, almost exactly the same system but a little more forgiving for the fumblefingered among us.


Connecting the dongle we see a flurry of activity and a command prompt opens and around half a page of '.'s flash past (Creating a dummy file full of periods into x.com) then we see...

C:\>debug x.com
-w
Writing 000E5 bytes
-q

c:\>x
BOOTLOADER STARTED...


Repeatedly clicking on the dongles button we might see the following output on the screen...

PrivEsc_2k.exe (15,756 bytes)
PrivEsc_XP.exe (14,495 bytes)
nc.exe (59,392 bytes)
samtool (18,023 bytes)
nothing (0 bytes)
PrivEsc_2k.exe (15,756 bytes)
PrivEsc_XP.exe (14,495 bytes)
nc.exe (59,392 bytes)

... and when we stop cycling witht he button for a second we see...

Installing nc.exe 13%


Starting x.com with the '-q' option is silent and displays no messages (Its up to you to remember how many times to press the button in order to inject the program you want)


The x.com bootloader speeds up the time it takes to transfer the software considerably by sending the bytes in a more compressed format and by omitting to generate the usual 'key up' messages.

The device can have new programs added and deleted via a one-way 2-wire serial interface from a regular PCs serial port, and can be designed to use any of the large-capacity SRAM memory chips currently available. We opted, in our design, to use a Samsung 72Mbit SRAM (9mb on a single chip) but the first prototypes only held around 2.4mb


And that is basically it. The device, dubbed a 'syringe', is capable of automatically installing (And optionaly executing) software on any PC running windows provided that debug is available. having used it at a number of internet cafes and various unsuspecting clients I can testify that this covers most windows based workstations. It really is the easiest and fastest way to install unauthorised software on a locked-down machine. If your injectable arsenal includes priviledge escalation exploits and a sam editor you are well on your way to owning just about any box you inject.

The construction is simple (Two-chip design) and lends a great deal from the keylogger article >here<


Regards,
M3DU54 of +44


Last edited by M3DU54 on Tue Dec 14, 2004 3:56 pm; edited 1 time in total
Back to top
View user's profile Send private message
capi
SF Senior Mod
SF Senior Mod


Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal

Offline

PostPosted: Tue Dec 14, 2004 3:54 pm    Post subject: Reply with quote

Great article as always, M3Dz.

An innovative and well presented idea - and certainly useful Very Happy
Back to top
View user's profile Send private message
delete852
Just Arrived
Just Arrived


Joined: 19 Nov 2002
Posts: 4
Location: Washington DC

Offline

PostPosted: Tue Dec 14, 2004 5:12 pm    Post subject: Reply with quote

what capi said.


Good stuff man, I rememmber seeing a whole file with your stuff. I liked it alot.
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
squidly
Trusted SF Member
Trusted SF Member


Joined: 07 Oct 2002
Posts: 16777215
Location: Umm.. I dont know.. somewhere

Offline

PostPosted: Tue Dec 14, 2004 5:36 pm    Post subject: Reply with quote

delete852 wrote:
what capi said.


Good stuff man, I rememmber seeing a whole file with your stuff. I liked it alot.


Delete852, The file is still floating round of all his stuff from secureroot. Just google him.
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger
liquidz
Just Arrived
Just Arrived


Joined: 27 Aug 2004
Posts: 0
Location: /dev/null/

Offline

PostPosted: Tue Dec 14, 2004 5:38 pm    Post subject: Reply with quote

Very nice, it has to make you wonder why most people don't lock down executables like debug.

My guess is that not too many people understand what all is in the windows directory.

Would'nt a serial port be faster than a PS2 port? ( I can't remember the exact speeds of each) It would seem possible to use this keyboard trick to load a simple program onto the victim PC, and then utilize the serial port (which is on most pc's) to transfer much larger programs at a faster rate.

Another fix for this (besides locking down the various exe's in the windows directory) would be to rig up a lockable metal box/door to prevent devices from being pluged into the back of the PC. However that costs money and companies don't like to spend money. It could be worth it in a top secret facility though.
Back to top
View user's profile Send private message Visit poster's website
capi
SF Senior Mod
SF Senior Mod


Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal

Offline

PostPosted: Tue Dec 14, 2004 9:22 pm    Post subject: Reply with quote

liquidz wrote:
Would'nt a serial port be faster than a PS2 port? ( I can't remember the exact speeds of each) It would seem possible to use this keyboard trick to load a simple program onto the victim PC, and then utilize the serial port (which is on most pc's) to transfer much larger programs at a faster rate.

Note that this would not apply in the particular situation M3DU54 describes:
M3DU54 wrote:
Y'see the computers Jim uses at work are tight - very tight. No USB, No Serial, No Removable Media, Intranet but no Internet access [...]
Back to top
View user's profile Send private message
M3DU54
Trusted SF Member
Trusted SF Member


Joined: 11 May 2002
Posts: 1
Location: Las Palmas de Gran Canaria

Offline

PostPosted: Thu Dec 16, 2004 6:27 am    Post subject: Reply with quote

capi wrote:
liquidz wrote:
Would'nt a serial port be faster than a PS2 port? ( I can't remember the exact speeds of each) It would seem possible to use this keyboard trick to load a simple program onto the victim PC, and then utilize the serial port (which is on most pc's) to transfer much larger programs at a faster rate.

Note that this would not apply in the particular situation M3DU54 describes:
M3DU54 wrote:
Y'see the computers Jim uses at work are tight - very tight. No USB, No Serial, No Removable Media, Intranet but no Internet access [...]

Yes, the machines involved are designed as smart terminals rather than workstations. The company is so paranoid about data theft that the keyboard and screen are the only real IO. I guess they are worried about serial storage devices. There is a mouse but all the interraction is done through mainframe clients attached to an AS400 via ethernet.

More importantly, you'd not get the quite same functionality from a com port without having some software on the machine to perform it... which leaves you either in a catch 22 -or- with a messy twin-interfaced device. (Well, not totaly a catch 22 as MSDOS does give us a klunky way to redirect comport data to a file - However, this leads us to a serial-only device and some required manual intervention) but we think the method we chose has its advantages. Besides, it is considerably more fun to have complete automation : )

M3Ds of +44
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Physical Security and Social Engineering All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register