Part I: CISC and Windows the Hardware Weak Link

By: Knighty Knight (The Shadow Legacy Report)

I must apologize for the tardiness of this article. However it was necessary
to have the Shadow Legacy Legal team review our article to protect Hack
In the Box, ourselves, and various other parties form The MS Legal Staff.
If just any Pin Head, or Script Kiddie used information that we provided
to gain access to the tools that have the power to halt e-commerce and
other e-based transactions on the net.

We will look at the logic on how to develop the tools and methods that
might be used to exploit these weaknesses. Look at how they work
and how the vehicle for transporting the code works. If you are a programer
on the platform and are knowledge of the assembly Language for the hardware
we are going to cover you?ll be able to create your own tools and code
to take advantage of these weaknesses to test these methods.

The CISC processor Architecture with it's many layers of Processor instructions
and a poorly designed operating systems and subsystems allows for hundred
if not thousands of possible exploits. Some of which are will documents,
Others of which are just now being documented, Other which have just now
started to be documented, still others that have just been discovered,
and the ones that have not yet been discovered.

What someone will need to discover about the system that they what to
take over. What CISC Processor is the system running? What OS is the system
running? What is the best method of injecting the tools? What is
the current processor and OS Serial Number (This information is very easy
to obtain by simply activating Intel?s built-in spy reporting processor
instruction subsets. This exploit is very commonly available and works
starting with the P2 through the newest P4. While Intel sets the spy to
inactive by default and the instruction subsets have been slightly altered
in P3's and P4's with a bit of testing and modifying of the old code it's
easy get the old exploit to work and, activate the Spy subset remotely
on even the newest of Intel?s and even AMD?s processors).

Let's talk first about the best methods to get tools in place without
being discovered. The best hacks are the ones that are very hard to detect.
The worst hacks are the ones the rely on brut force. We'll be looking
at the most effective it also happens to be the least detectable.
The server types we'll be targeting are a P3 running NT4.0 MSWeb Server
and Active Server Pages and a Dual P2 running Win 2K Pro MSWeb Server and
Active Server Pages. (These servers were configured using off the shelf
versions (With the exception of a test we ran using a NT 4.0 Mil Build))
The target exploit will be a little know security hole in ASP. This will
place the box tools in memory and allow the intruder to manipulate the
processes and the OS so they can gain full access to the system all without
being detected.

To get the tools in place the intruder will look for a form on the web
site. The target form would be an unlimited maximum length submit form.
It is not required that it be an unlimited form. It just makes the task
much more simple and straight forward for the intruder. If the form has
a maximum length it will just take a bit of planning to get all the tools
in place and in the right order.

To exploit ASP the intruder will need to create a special 8bit Windows
Standard encryption Header. Then they need to place the assembly code after
the header. When the form is Submitted ASP will write the Raw data file
to Memory and pass the de-encryption task off to Windows. Windows
will start a de-encryption process. Based on the header information,
once Windows encounters the Processor Assembly Code it will pass the code
off to the processor subsets, the processor then executes the code without
NT or 2000 generating any errors or warnings. Once the assembly Code is
active in the processor it will set-up it?s own kernel and own memory stacks.

Has this occurs Windows will attempt to purge the foreign kernel and
memory addresses. If the Code is correctly written this will only cause
Windows a momentary stall of less the 5 seconds. Because the kernel would
be written to reside and operate from the processor?s L1 and L2 Cache and
would have direct control over specific areas of the processor. It will
respond and counter any purge that Windows may attempt. (A note: If the
Assembly is poorly written the Foreign Kernel it will cause Windows to
Crash. While you would not normally detect what caused the
Crash. The Intruder would have to start over once the server was
rebooted.).

The Kernel and code would need to be created to allow access to Windows
. This access is simple to achieve once the kernel is running with it?s
discreet new network protocol. Supplied by the Processor instruction sets
that allows Intel and Microsoft to gain access to all Intel based systems
(Note: AMD processors are not immune to this exploit. They incorporate
the same processor Instruction Subset that intel?s does. The Processor
Subsets were created by Microsoft in an attempt to allow SMS, Windows Networking
and a protocol we call Ispy (in the Code comments was referred to as cheriB
when we extracted the API Subsets from Windows 95, 98, NT 3.x and 4.x,
ME, 2K and 2K Pro these mysterious Code API were discovered when we examined
the Code API?s and their API groups we determined that it was a network
Protocol that had special additional API?s and hooks into the OS
to allow a special client to gain access and take remote control of the
system,) to operate faster and with less interference from the kernel,
also in a report to AMD Microsoft states that the Processor instruction
subsets are need to add stability to the platform. (Note: the Ispy API?s
and Hooks are missing from all the Beta releases we examined. (We did an
API Extract on 2 versions of 95, 4 versions of NT 4.x, a version of 3.1.1,
a version of NT 3.x, 3 different versions of 98, 2 versions of ME, 6 versions
of 2k and 9 versions of 2k Pro) Anyone could use the Ispy processor instruction
subset for their network protocol. Then a remote system they could have
running an Ispy client that is set to look for the Processor (all
AMD Processor have a random Serial Number that is generated each time the
system is rebooted) and the Windows serial numbers that are broadcast by
the protocol from the target system.

With the foreign kernel running and having connected to the box using
an Ispy client. The intruder can manipulate the OS. Again because the Ispy
Instruction set and a client designed and written to exploit the Ispy API?s
and Hooks in Windows and the CISC Processor gaining access is easy. Ispy
has an API that allows an intruder log-on as administrator directly
from the Windows Kernel. Because the remote request is from Ispy
it brings up the logic with the Administrator no password required
the intruder just have to hit enter on the keyboard and they are logged
in as the local system administrator.

Once in Windows the intruder would kill some of the processes that log
what is going on in the system and they can create themselves a new Temporary
Administrator Account. While logged in the server through the Ispy
Client the intruder could search and see if the PDC (Primary Domain Controller)
is visible and accessible it from the server. If it is will send a remote
request to the PDC to add new Local Account to the Domain as a Primary
Domain administrator, If not then the Intruder would check to see if the
Server they are on is a Back-up, secondary or trusted Sub-domain
controller if not they might see if they can find one on the internal network
(This worked 6 out of the 7 times that I attempted it. My guess is that
I missed adding one of the Windows hooks in the Ispy Client that we created
that allows us to be seen as a Domain Administrator). Once the Intruder
had a domain login created as a Domain Administrator they might delete
or hide their Temporary Local Login Account. While logged on to the
server they might check to see if the VPN server software is installed
and starting at boot. If the Software is missing they might added it and
configure it to start-up at boot, if the software is installed but not
running re-configure it to start on boot up.

Now that everything is done they would need to send the processor a
reboot on disconnect command, (this can be done by a purge and reset all
command from the Ispy Client) this will cause the system to Reboot. The
Reboot will most likely be detected by any monitor software that might
be running on the internal network. Because most administrator's configure
their system to reboot if a core dump occurs this will be the administrator's
guess as to why the system rebooted itself.

The Box and the Domain are now completely open to an intruder.

The above is just one example by which the CISC hardware can be exploited.
We also developed an Ispy client that requires nothing more the activation
of the processor?s internal Spy instruction subset. The ability to activate
any Processor?s internal Spy instruction subset could be added to
any Ispy type Client with no real extra work. Then it would just be a matter
of starting the Client hitting the systems IP Address then connecting to
the Target with the client acquiring the data processing it sending the
key and unlocking the system.

While the above scenarios were created and tested by The Shadow Legacy.
The Shadow Legacy is sending all our research, Code, and detailed instructions
to various Agencies. These Agencies will independently evaluate our research
and code and issue warning and advisories accordingly.

Next Time: Part II CISC and Linux The Hardware Weak Link

The Shadow Legacy Report

Disclaimer: We will only answer general Questions on these methods
for gaining access. The information on gaining access by these methods
are only Provided so that you can minimize your own risks. It is not our
intension to provide anyone with the code or tools to bypass any network
or server security method. This information is provided for educational
purposes only so that Administrators of CISC and Microsoft operated
Internet Servers can take steps to monitor and minimize the risk for their
systems and to help protect confidential data.

1.) The Plague - bonghittr
2.) State of the Hack Awards #5 - madsaxon
3.) Part I: CISC and Windows the Hardware Weak Link - Knighty Knight
4.) Napster, MPAA, AOL, and how stupid people in power will kill the first amendment - unfrgvnme
5.) NetBios Shares -- Cracking Windows Machines - madirish
6.) I want my MTV - L33tdawg