tag:blogger.com,1999:blog-24586388.post6658513522828638474..comments2023-11-24T09:52:43.963+01:00Comments on The Invisible Things Lab's blog: The Game Is Over!Joanna Rutkowskahttp://www.blogger.com/profile/07657268181166351141noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-24586388.post-77215124609046599722007-08-23T14:31:00.000+02:002007-08-23T14:31:00.000+02:00Of course, being being two firewalls/ids kinda mea...Of course, being being two firewalls/ids kinda means you ARE using the network. That being the case you're vulnerable - period!<BR/><BR/>So, forget about services... turn 'em all off. They actually carry more rigourous security than clients which can be a far simpler vector.<BR/><BR/>So, a client exploit and some escalation code and you CAN get rootkitted. <BR/><BR/>The poster who says his system is secure has a very simplistic view of security and is making way too many assumptions.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-83310542087189112302007-07-05T19:00:00.000+02:002007-07-05T19:00:00.000+02:00Q: "I can guarantee 100% that my system is hack-pr...Q: "I can guarantee 100% that my system is hack-proof. It is not accessible to hackers."<BR/><BR/>I see. you obviously have some restricted definition of the term 'hacker' which precludes defeating alarm systems, tampering locks and other B&E. How about tempest, perhaps you should place said system in a faraday cage or perhaps even better, just secure-format it and remove the target completely.<BR/><BR/>The truth is that if you have a USEABLE system, it IS crackable... and this should not be restricted to only evaluating remote intrusions or standard exploit methodologies as you understand them.<BR/><BR/>But lets accept your definition. Do you stay up to date with your patchlevels? Yes? On CD from the manufacturer? In which case I have an attack vector. Using automatic updates? If so, I have an attack vector.<BR/><BR/>If you would care to make a sizeable wager on the security of your system I'd welcome the opportunity to take you up on it. After all, even an unconnected system in a room is only as secure as the room itself.<BR/><BR/>And, if there are passcodes that exist SOLEY in your head, well, I garauntee that for the right fee I'd get those too... entered or not. *IF* you allow the me, the attacker, carte-blanche as in a real scenario. However, you may not like that.<BR/><BR/>Q: "With that in mind, I can almost as well guarantee the same even if my system were connected to the Internet, behind at least two firewalls/IPS, and all unnecessary services turned off. Why should I worry about theoretical rootkit installations, when undoubtedly you'd need local access? Or maybe you would like me to install something for you first?"<BR/><BR/>Think OUTSIDE the box Q. You're making some pretty sweeping assumptions there. Firewalls are not the key issue here nor is IDS. Much of your traffic is tamperable and much of it the FW is set up to allow.<BR/><BR/>An upstream transparent node placed at a telco connection point, for example, can often absolutely wreck the most rigid security schemas. These exist even for modern DMT based comms and cover everything from ISDN to FrameRelay and xDSL to SONET. <BR/><BR/>Such devices can often turn their victimes strengths against themselves - particularly when it comes to rigourous patchlevels.<BR/><BR/>I have a funny feeling that if I were to challenge you on this at a convention you'd lay down many restrictions such as 'Must be a remote exploit' and 'cannot place hardware upstream' ... or perhaps insist on strict time limits or other arbitrary obstacles such as must consider the installation location as inviolable. Of course... all things that YOU DO NOT CONTROL in the real world.<BR/><BR/>But... if you were to offer a 100,000 prize for cracking your box at a 7 day security conference. And you placed that box in a secure room with a modern alarm system and PIRs well, I can pretty much garauntee the data will come off. Connected or not.<BR/><BR/>And if its encrypted? Well... you'd perhaps be required to regularly access the data over the course of the conference. You know, just to give a fighting chance and demonstrate that we are talking about a system which you are unafraid to access.<BR/><BR/>But for a cool 100,000 and 7 days I can see enthusiastic attempts to place radio-cameras in your PIRs, serial bugs in your keyboard and even some overly-enthusiastic profiling your keypress audio. <BR/><BR/>If online I'd expect your uplink to get spliced too - watching for common apps and OS components performing auto-update checks and subverting them.<BR/><BR/>Seriously, if you want to posit the security of a system NOT connected to the internet then you'd have to allow the attacker carte-blanche.<BR/><BR/>But, if the price is right, I garauntee you'll lose that wager.<BR/><BR/>I've performed full-blackhat pen-tests before and I can safely say that no system I've seen has ever came off as adequately secure.<BR/><BR/>Indeed, when working corporate espionage jobs there are SO many alternative avenues of attack that the idea of securing a system by unplugging it (PTP Security) is just nonsense.Ancienthttps://www.blogger.com/profile/01337685950268059189noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-87294345200123016952007-05-07T20:01:00.000+02:002007-05-07T20:01:00.000+02:00I can guarantee 100% that my system is hack-proof....I can guarantee 100% that my system is hack-proof. <BR/><BR/>It is not accessible to hackers.<BR/><BR/>With that in mind, I can almost as well guarantee the same even if my system were connected to the Internet, behind at least two firewalls/IPS, and all unnecessary services turned off. Why should I worry about theoretical rootkit installations, when undoubtedly you'd need local access? Or maybe you would like me to install something for you first?Qhttps://www.blogger.com/profile/04107128526009093155noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-21099755321674221102007-05-02T13:23:00.000+02:002007-05-02T13:23:00.000+02:00It seems one of the reoccurring problems in detect...It seems one of the reoccurring problems in detecting any kind of comprimization is:<BR/>How can a bios / kernel / OS detect his own comprimisation?<BR/><BR/>The answer to this question is in my opinion very similar to the answer to the following question:<BR/>How can a fool detect his own foolishness?<BR/><BR/>Short answer; he can't.<BR/><BR/>Looking at this problem in a hierarchic structure, I think there can be only one 100% tight solution.<BR/><BR/>A hierarchic structure which consists of a flawless static top (comparible with a company structure that has an utopic flawless director with utopic flawless managers that don't depend on anything they control nor share the same resources)<BR/><BR/>This way the board should be able to detect any kind of flaw.<BR/><BR/>Question in that case is; what is the approach when a flaw is detected an thus the system is potentially comprimised?<BR/><BR/>Reboot??<BR/>(I wouldn't install Windows in that case)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-24788053880815388442007-04-04T22:13:00.000+02:002007-04-04T22:13:00.000+02:00interesting post. the freebsd project had a google...interesting post. the freebsd project had a google summer-of-code project in either 2005 or 2006 called "securemines", meant to implement something that resembles what you're talking about (a way to know when a foreign intruder is messing with the system).<BR/><BR/>I don't think it ever got written, but the evolution of it was to create a framework for writing intrusion detection modules.<BR/><BR/>perhaps it's time to look into it? ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-62349184221859243762007-03-30T07:15:00.000+02:002007-03-30T07:15:00.000+02:00As somebody living in the real world (and I mean t...As somebody living in the real world (and I mean this not be an offense, just wanting to state that I'm doing a more hands-on approach while you are using a more research approach, which could cause our opinions to differ), I want to say that 95% of all malware out there is very primitive (in the sense that it's all usermode code, sometimes with big glaring mistakes - like assuming that Windows is installed in C:\Windows and not calling GetWindowsDirectory :)), an other 4.99% starts to get smart (but still relies on techniques which were known for a - relatively - long time) and less than 0.01% are doing something innovative.<BR/><BR/>Now admittedly it may be the case that we don't see those "uber-malware" because it hides itself so well, but I still stand by my opinion that there is a very low risk associated with it.<BR/><BR/>I said it and I say it again: there is no such thing as "perfect security". Security is a process. A numbers game. Can you be 100% sure that your machine wasn't rooted? No. But you can get pretty close to it by using layered security. And pretty close if good enough for most of the people. Or to state it an other way: as long as a huge percentage of the users / companies uses such lax security practices that malware such as mentioned in the example above (which assumes that Windows is installed in c:\Windows) people / companies who have allocated adequate resources to security can sleep well, because the "bad guys" will go after the easy targets first. There is no reason to loose sleep above theoretical attacks, imho.<BR/><BR/>PS. I would like to state it again that your work is very interesting and this comment isn't meant to be dismissive of it. I just want to clarify that in "the real world" the current security measures (while far from perfect) are good enough - I just wish that everybody would apply them.Cd-MaNhttps://www.blogger.com/profile/05030326541176171725noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-65654503753686166082007-03-29T21:09:00.000+02:002007-03-29T21:09:00.000+02:00Joanna,Better than setting up some anticipated int...Joanna,<BR/><BR/>Better than setting up some anticipated intrusion algorithm, why not just wipe,clean, reinstall every Nth moment in RAM...<BR/><BR/>who needs a "bloody" hard drive anyway...<BR/><BR/>Personally, I side with the initial premise<BR/>"game is never over"<BR/><BR/>good workAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-50176926000849391962007-03-29T10:50:00.000+02:002007-03-29T10:50:00.000+02:00Dear cdman83,in order to be able to, as you said "...Dear cdman83,<BR/><BR/>in order to be able to, as you said "wipe/reinstall/patch" or even to "hire a skilled third party [to investigate the incident]" you need to first know that something has happened and that you need to take some action. But without detection we simply can not know that something wrong has happened, so it's a vicious circle!<BR/><BR/>Or, maybe, we should start relying on probability, as you suggest, and just say that e.g. "this server is compromised with a probability of p=1-0.95^n, where would be some magic parameter symbolizing the number of exploitation approaches (following your model). And then, of course, we will assume that once p is greater then some threshold value we need to "reinstall"... I even have a sexy name for this: "quantum security"! :)<BR/><BR/>[This is bullshit]Joanna Rutkowskahttps://www.blogger.com/profile/07657268181166351141noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-47847581212326937452007-03-29T09:32:00.000+02:002007-03-29T09:32:00.000+02:00When you are "rooted", its pretty much game over b...When you are "rooted", its pretty much game over because:<BR/><BR/>-all the available "scanners" can be bypassed (because there is no inherent guarantee - like the Ring0 / Ring3 divide - provided by an external party - like the OS or the hardware)<BR/><BR/>-the people who would be able to do a competent security analysis are few and far between (I don't mean this to be an insult, I just want to state the fact that a very low percentage of the security professionals has the skills of doing reverse engeneering on the level which is required to trace kernel malware).<BR/><BR/>The only option for small companies and home users is to wipe / reinstall / patch / pray and only large corporations can afford to hire a skilled third party (but most probably they don't do it many times).<BR/><BR/>As for the security measures like ASLR or stack canaries: I agree that all of them can be bypassed, but the question is how much of a reduction in exploitation probability do they provide? For example if I have an exploit which is 95% effective against systems with none of these protections and only 5% effective against systems with these protections activated, would you use them? Of course you would! In the end (for businesses and most people) security is not a goal in itself, it is a part of the everyday risk, and a solution which reduces a particular risk almost 20 times is very good one!Cd-MaNhttps://www.blogger.com/profile/05030326541176171725noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-61336404437077135962007-03-27T03:43:00.000+02:002007-03-27T03:43:00.000+02:00I second the comment by David Karnok. Binary verif...I second the comment by David Karnok. Binary verification can be achieved by replacing the x86/x64 instruction set with one that is more amenable to security analysis. Then only the compiler from intermediate binary to machine binary format, and a minimal run-time component, need to be trusted.<BR/><BR/>Generally though, security analysis can never be fully automated because it can only ever detect accidental faults, not essential faults. Accidental faults are those where an algorithm is misimplemented; essential faults are those where the algorithm itself is wrong. We may eventually get to the point where we can code exactly what we mean and thus eliminate all accidental faults, but we will never eliminate all the possible faults in our thinking.<BR/><BR/>We can systematically remove a large class of faults, but another large class of faults will remain.denis biderhttps://www.blogger.com/profile/02662743799740973736noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-71848860098288136072007-03-27T00:50:00.000+02:002007-03-27T00:50:00.000+02:00You might want to take a look at Secure64. (http:/...You might want to take a look at Secure64. (http://www.secure64.com) It has a secure operating system that offers compartmentalization and protection ID. It's the only operating system I know of that not only works, but can also support root trust authentication for the entire code base and subsequent applications.<BR/><BR/>PeterAnonymoushttps://www.blogger.com/profile/07858074897556111844noreply@blogger.comtag:blogger.com,1999:blog-24586388.post-63085575026443071462007-03-26T21:10:00.000+02:002007-03-26T21:10:00.000+02:00Maybe some day a quantum algorithm will be able to...Maybe some day a quantum algorithm will be able to do it right and fast.<BR/>What about typed assembly language? Or any language designed directly for OS and Driver development other than C?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-85141939224337536132007-03-26T20:55:00.000+02:002007-03-26T20:55:00.000+02:00I found your description of "sound static analysis...I found your description of "sound static analysis" interesting. I'm the CTO of Klocwork, a company that provides static analysis tools, and have experienced both sound and pragmatic approaches to this problem.<BR/><BR/>The challenge with provable scenarios is execution time and general scalability. Proving correctness for an embedded system of 50K LOC is a very different proposition than for a 1M+ LOC modern OS.<BR/><BR/>Pragmatic approaches, while considering a considerably larger superset of execution paths (by definition), and which therefore have relatively typical precision/coverage challenges, do provide reasonable and valid guidance to a human observer, as opposed to attempting to bypass that observer by producing the "right answer" at all times.<BR/><BR/>Given that this domain is subject to the halting problem, I would question the validity of any approach to system validation that didn't include an expert observer, frankly.<BR/><BR/>Finally, whilst one day (rose tinted moment) we will hopefully be able to sit back and ask our compilers not only to tell us where we made syntax mistakes but also where we are subject to security vulnerabilities and design flaws, in the meantime I can't help thinking that any solution (sound or pragmatic) is better than nothing.<BR/><BR/>Binary validation is another matter entirely and strikes me as somebody looking to cure symptoms rather than root causes (but then, I would think that, wouldn't I ;p).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24586388.post-13005204234211842722007-03-26T17:37:00.000+02:002007-03-26T17:37:00.000+02:00And what about MS Singularity, which is 90% manage...And what about MS Singularity, which is 90% managed code, and each driver and program gets compiled during install and verified?Anonymousnoreply@blogger.com