Comments at bottom:
Allen wrote: > Curt Wilson wrote: > > [snip] > >> The current state of Windows malware as I understand it is that the user >> must generally be running as Administrator (for client-side malware; >> obviously server components running as LocalSystem with bugs that open >> ports are still a risk) in order for most malware to be able to do it's >> nastiness. If someone is a restricted user then most malware will >> probably fail, unless it's designed to do privilege escalation tricks or >> unless it's designed to snag *data* that this particular user has access >> to (decrypted, if using FDE and the system is booted, or decrypted if it >> was protected with file/folder encryption and the user had need of that >> data, or kept the data open longer than needed). I expect in the future >> to see malware that does things like leverage priv escalation attacks, >> and implement a sensitive data search to look for SSN's on the box >> accessible to the logged-in user, pack them up with a key of the >> attackers choice and HTTP upload those to the attackers malicious >> server. Maybe this is already happening. > > Curt, what you say is correct not not sufficient. > > I have loaded an earlier version of the Metasploit framework as a > non-privileged user and run it on a tightly locked down system. > (The sigs for pwdump and a couple of other tools for v3 are now > in MacAfee so they get dropped when installing, but there is not > much effort involved in changing them with some comments and nops > to change the signatures if I was of a mind to.) There are > bunches of other programs that I have run from the same machine > even though I do not have the rights to _install_ programs. > > If a program does not need the registry to run, then it's up and > running. Think the *bad* old days where every DOS program had its > own .ini or .cfg file. If you can run the program with those > files in the same directory as the .exe, you are good to go. > > Also I believe it is possible to write a program that makes > system calls at whatever level of privilege it wishes. QEMU makes > low level calls so it can't be a whole lot of effort to rewrite > it to make higher level calls. When you can write those types of > system calls then you can do almost anything you want. > > Best, > > Allen > Allen, Sure, you can load some things without being admin. However, from what I understand most malware in the wild still assumes admin. Think about apps that load drivers (such as a rootkit technique using a .sys file) or a keylogger that hooks system input functions or something that wants to drop persistent exe's in C:\ or exes/dlls in the System32 dir? (all seem to be common malware tricks seen in the wild). I am not familiar with QEMU and the potentials there, and I figure we all have interesting times ahead. But the current threat is at least partially mitigated by users not running as admin. I don't imagine it will be that way long though. Since this discussion is veering away from FDE I won't say more on this topic but am still interested in knowing others ideas on how to best use encryption to protect against modern and emerging threats. If FDE is inadequate, then you've got to profile how the data needing protection is used and find some other techniques to keep it protected. If the user can get to it, and the user is compromised then the malware has the data too. I guess there is no good way around this.... > _______________________________________________ > FDE mailing list > [email protected] > http://www.xml-dev.com/mailman/listinfo/fde > -- Curt Wilson IT Network Security Officer Southern Illinois University Carbondale 618-453-6237 GnuPG key: http://www.infotech.siu.edu/security/curtw.pub.asc _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
