lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: everbeeninlove at gmail.com (Ankush Kapoor)
Subject: Bios programming...

Very interesting software indeed, though i am not sure how many people
would like you keeping them honest and nice! Also, i wont be surprised
if someone soon attacked your website for making something that ruined
one of the few businesses on the net that make real money, namely
porn. Not that I am a patron of porn, but you sure will have a lot of
people knocking on your company's network.

anyway, I hope you manage to make this great little utility. I would
love to lay my hands on something like this to install a backdoor! ;)
Now, why didn't anyone think of that?!!


regards

Ankush Kapoor


On Thu, 3 Mar 2005 15:33:09 -0500, Matt Marooney
<matt@...amicanswers.com> wrote:
> 
> Thanks for the feedback Valdis!
> 
> I've been doing some reading about custom BIOS chips that include
> security programs, so that may not be the way I want to go...
> 
> I definatly want the program to behave like spyware, but not show up on
> scanners! :)
> 
> The intent of the BIOS portion of the program was just to have a small
> bit of code that checked for the existence of the main monitoring
> program on the disk, and if it was not there, reload it somehow.
> 
> The main program would run from the disk, not the BIOS.
> 
> 
> -----Original Message-----
> From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu]
> Sent: Thursday, March 03, 2005 3:19 PM
> To: Matt Marooney
> Cc: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] Bios programming...
> 
> On Thu, 03 Mar 2005 13:44:39 EST, Matt Marooney said:
> 
> > 1. I would like the program to be "un-installable".  I've heard of a
> 
> Did you mean "un-installable", as in "an inability to be installed", or
> "non-uninstallable", as in "not removable"? :)
> 
> In any case, some time with Google will probably find you an Agobot or
> spyware that will give you lots of hints on how to create a
> hard-to-remove program. ;)
> 
> > couple of hardware security tracking services that can load a very
> > small setup package in the CMOS and if a computer is stolen, and the
> > hard drive is replaced, the app reloads itself and the next time the
> > computer is on the internet, it sends out a beacon.  Does anyone have
> > any insight about how to do something like this?  I want the CMOS
> > program to run on boot, and check to see if the monitoring software is
> 
> > still installed. If it is not, the boot process reloads it.
> 
> Note that this would almost certainly require an additional PROM chip,
> and hooks into the BIOS to invoke it at the right points.  Note that
> about all it can probably do is "If the disk is different, toss a
> crafted packet out the Ethernet and hope for the best".  Note that
> you're probably screwed if they either reboot while not on the net, or
> re-flash the BIOS with the original vendor BIOS (which implies further
> hardware hacks to make the box not bootable with the original vendor
> BIOS image).
> 
> If you want it to additionally run a program in the "background", you'll
> have to get the operating system to cooperate.
> 
> > 2. obviously, the program does not need to be very large, so I want it
> 
> > to run in the background and not be visible to the computer's user.
> > This is easy, I know, but I want the process to be completely
> > invisible. (even to super-geeks)
> 
> Remember that in general, the BIOS is in control before boot, but after
> boot, the BIOS is not in any meaningful control anymore.
> 
> Ask yourself what happens if your problem user boots a Knoppix CD that
> doesn't want to play nice with your CMOS?
> 
> > 3. I would like to figure out a way to monitor traffic for multiple
> > protocols (HTTP, FTP, File Sharing, Chat, etc.) .  I'm wondering if
> > there is a way to figure out "bad" requests on a packet level.
> 
> Take a look at Snort or other similar IDS, that tries to do that -
> particularly in terms of the size of the binary, and the system load
> impact.  And then ask yourself if something that big is easily hidden
> inside the BIOS functionality (and consider carefully how many vendors
> ship totally borked ACPI DSDT's or just broken BIOSes)....
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ