On Sat, May 2, 2009 at 11:03 AM, Holden Hao <[email protected]> wrote: > > So the application mkdir in the system is the real one but it is not > the one that is being executed but a "function" called from the kernel > itself?
yup :-> the flow goes like this... 1. userland's mkdir calling mkdir system call 2. hacker's system call hook called... do something and after that either return back to number 1 or go to number 3 3. original system call hook called. > So the hacker installed his own kernel. yup.. to be exact.. installed his own kernel extension on the fly thru /dev/kmem... > It is a > sophisticated hack. A thorough security audit is a must. expect more sophisticated hack.. this one is im not sure if the hacker is a stupid one or not as he let himself identified thru giving an error when a numeric file name or directory name was given... expect a sophisticated one where it doesnt touch any files in the system... because the hole was already identified.. what the hacker is going to do is to infect the system thru that hole... if the system is rebooted and the injected code is gone... the hacker is going to infect it again... another flexibility with this technique that i can see is that...the first phase of an injected code is just an executioner of the real commands (second phase) waiting from its master externally thru port knocking technique using udp protocol... since udp is unreliable protocol.. the hacker doesnt need a real source ip... therefore he can spoof the source ip address so that he will not be traceable... the commands are the payload of udp packets... you wont see any his port listening in your system as he take over the network driver to watch for his own packets using the port knocking technique.... the executioner construct the commands that it receives and execute it... after the execution.. destroy the commands.. and waiting again from his master... commands can be encrypted using PKI to be more sophisticated... and the executioner can morph from one place to another place in the system so that it wont traceable... >> http://www.theregister.co.uk/2009/03/24/persistent_bios_rootkits/ > > Very interesting and scary! just always prepare for your bios firmware file and reprogram the bios before you reinstall the server... with a UPS of course :-> it recalls me something during my college days when i was still a student... we got infected by the first computer virus for pc called cBrain... it is a boot virus... intentionally infected my disk so that i can study the code... cBrain virus is a pretty simple virus... put the initial code in the boot sector and load the rest of its code in the data area reference with a bad cluster marked in the fat area... the problem with cBrain was that it puts a bad cluster in the fat area even the data area is good to use.. with this.. using a disk editor.. you can easily identified if your disk was infected or not without using a virus scanner... what i did.. i wrote my own improved and stealth boot virus.. instead of marking a bad cluster and putting the code in there... i put my code outside the standard track of a disk.. for example for 5 1/4 disk... the number of tracks is 40... i reformated track 41 and put my code in there.. same also with 3 1/2 disk.. number of tracks is 80 and reformated track 81 and put my code in there... for hard disk... i put it in a reserve sectors... track 0, head 0, from sector 1 to N where sector 0 is the mbr.. it was a friendly virus ...it wont harm and slow down your system...as you wont notice that you were infected... it was pretty optimize as the code fits only to one sector (512 bytes) using assembly language.. later on.. i was thinking to make a hybrid one.. a combination of boot and file virus.. studying the programmable bios if i can put my code in there... but during at that time you cannot... we even made a laughing stock to those students claiming he will make a cmos virus without knowing it first if it can be done or not...i dont have any books or materials regarding to this programable bios... what i did at that time was to trace the ROM code which was very painful because one mistake...your debugger will hang and you have to start from the start again... the hybrid virus didnt materialize (as it was supposed to be the first hybrid virus) because our computer laboratory head (while i was a computer laboratory student assistant at that time) adviced me to use your talent in a productive way... but of course to be productive... during at that time 80386 was the newest processor... i already created a program how to crack a cmos password :-> now there is a space in the programmable bios... we will see their creativity and prepare for the defense.... fooler. _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
