Re: [freenet-support] Freenet speed & local threats
> On Sat, 10 Dec 2011 20:06:10 -0500, Chris wrote: >> > On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: >> >> >> [...] >> >> >> Many users have a persistent local threat that they need to be >> >> >> aware of. Leaving a server running is not an option as it could >> >> >> be compromised by an adversary. >> >> >> >> >> >> Removable media can reduce that threat. >> >> >> [...] >> >> >> >> I was not referring to zero day exploits actually. The key word >> >> here was local real-world threats. Such as an adversary gaining >> >> physical access to the server/machine running freenode. >> > >> > If the bad guys have physical access, and care, it's game over. >> > >> > I suppose you can try setting secret tripwires that might notify you >> > if the machine was tampered with (both in software, and in >> > hardware.) Those might give you a fighting chance. Although you'll >> > also need to make sure your room wasn't bugged with pin-hole >> > cameras and other spy-ware. It's a lost battle, regardless. >> >> This is completely dependent on who the adversary is, the level of >> sophistication, mistakes they may make, the resources they may have, >> how badly they want you, what they know about you, and what other >> precautions have been taken. A pin-hole camera for instance should >> not be enough to compromise a good setup. > > How do you figure? (The camera can see everything you're typing and > your screen, right? If you have any additional biometric login > requirements, they can easily be gotten from you later.) Where exactly is this camera placed? This is dependent on the user being position such that a camera can see the keyboard. > >> Nor should a MBR level key logger installation. These two things are >> easier to do than a BIOS level modification. A BIOS level >> modification gets a lot more complicated as each system uses a >> different BIOS. When there is no generic solution to a problem or >> that solution is more cumbersome it may not exist. If it does exist >> it may be used much more selectively and there will almost certainly >> be fewer adversaries who have access to it. You may not be a target >> of a significantly high level adversary (where such levels may exist). >> >> > >> >> Removable media may not eliminate the threat although there is less >> >> opertunity for a more sophisticated targeted attack. A software >> >> keylogger inserted into the MBR or similar would not be possible if >> >> the boot medium is never available to the attacker. >> > >> > But it will be available if you ever decide to boot, happily >> > recording everything. >> >> If the adversary does not have access to your boot medium how do you >> think they are going to install it? When you do boot it should not >> exist. There are few places that a keylogger or device can be >> installed. BIOS, optical drive, USB port, PC card slot, firewire, >> network etc. These are all things that can be checked. The only >> exception is the BIOS. The BIOS differs from machine to machine which >> should increase the cost of the adversary to produce a solution. I >> have never heard of a BIOS level bug. There have been conceptual >> modifications to suggest it may be possible although nothing in >> practice to show it could be done easily. >> >> >Again, if you think your machine was actually tampered >> > with, you should assume it's unusable. >> >> Nobody is arguing that a knowingly compromised machine or one that >> there is reason to suspect could have been compromised should be used. > > But any machine that the adversary has physical access to should be > suspected to have been compromised. A BIOS-level bug, as you explain, > is one great way. Personally, I would prefer lower-tech spy solutions. > Of course, you can assume your adversary is weak, but that's a risky > assumption. If I'm the adversary the question becomes how do I go about producing a bug for every machine that I might come across that I would like to bug? Porting BIOS modifications from one motherboard to another is a non-trivial task and would be prohibitively expensive. Probably even for the wealthiest nations on earth. There are easier ways to bug that .0001% of the population who might have a bug-resistant setup. Of that .0001% there are probably a handful currently whom a BIOS level bug would be needed. There are projects out there to port an open source BIOS and there are at best 100 boards which are supported. Of that there are just 5 laptops. If you think 5 models is a lot think again. Of any specific laptop it takes a specific revision of that laptop. This is a project which has bee around for many many many years with financial support from governments and corporations. Even if we assume the governments have access to the original source code to every BIOS (which you would have to have one for each model and revision of every laptop) it is still going to be expensive. Who are you that the government is going to have the technical persons on hand to arrange
Re: [freenet-support] Freenet speed & local threats
On Sat, 10 Dec 2011 20:06:10 -0500, Chris wrote: > > On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: > >> >> [...] > >> >> Many users have a persistent local threat that they need to be > >> >> aware of. Leaving a server running is not an option as it could > >> >> be compromised by an adversary. > >> >> > >> >> Removable media can reduce that threat. > >> >> [...] > >> > >> I was not referring to zero day exploits actually. The key word > >> here was local real-world threats. Such as an adversary gaining > >> physical access to the server/machine running freenode. > > > > If the bad guys have physical access, and care, it's game over. > > > > I suppose you can try setting secret tripwires that might notify you > > if the machine was tampered with (both in software, and in > > hardware.) Those might give you a fighting chance. Although you'll > > also need to make sure your room wasn't bugged with pin-hole > > cameras and other spy-ware. It's a lost battle, regardless. > > This is completely dependent on who the adversary is, the level of > sophistication, mistakes they may make, the resources they may have, > how badly they want you, what they know about you, and what other > precautions have been taken. A pin-hole camera for instance should > not be enough to compromise a good setup. How do you figure? (The camera can see everything you're typing and your screen, right? If you have any additional biometric login requirements, they can easily be gotten from you later.) > Nor should a MBR level key logger installation. These two things are > easier to do than a BIOS level modification. A BIOS level > modification gets a lot more complicated as each system uses a > different BIOS. When there is no generic solution to a problem or > that solution is more cumbersome it may not exist. If it does exist > it may be used much more selectively and there will almost certainly > be fewer adversaries who have access to it. You may not be a target > of a significantly high level adversary (where such levels may exist). > > > > >> Removable media may not eliminate the threat although there is less > >> opertunity for a more sophisticated targeted attack. A software > >> keylogger inserted into the MBR or similar would not be possible if > >> the boot medium is never available to the attacker. > > > > But it will be available if you ever decide to boot, happily > > recording everything. > > If the adversary does not have access to your boot medium how do you > think they are going to install it? When you do boot it should not > exist. There are few places that a keylogger or device can be > installed. BIOS, optical drive, USB port, PC card slot, firewire, > network etc. These are all things that can be checked. The only > exception is the BIOS. The BIOS differs from machine to machine which > should increase the cost of the adversary to produce a solution. I > have never heard of a BIOS level bug. There have been conceptual > modifications to suggest it may be possible although nothing in > practice to show it could be done easily. > > >Again, if you think your machine was actually tampered > > with, you should assume it's unusable. > > Nobody is arguing that a knowingly compromised machine or one that > there is reason to suspect could have been compromised should be used. But any machine that the adversary has physical access to should be suspected to have been compromised. A BIOS-level bug, as you explain, is one great way. Personally, I would prefer lower-tech spy solutions. Of course, you can assume your adversary is weak, but that's a risky assumption. > >> On the other hand a physical keylogger may still be possible and > >> maybe even a software based keylogger although more difficult to > >> disguise/install without being noticed. > > > > Of course. You should expect a variety of key loggers installed, in > > code, under your keyboard keys, acoustic key loggers stuck somewhere > > inside the machine (that can acoustically determine which key you're > > pressing), and a bunch throughout your room in pin holes in your > > walls and ceiling. > > None of which can't be avoided. As far as I know. Please explain. > >> I can think of at least a few different ways of getting a keylogger > >> onto a system without having access to the boot drive or having to > >> install a physical device. I would still need physical access to > >> the computer. At least one method would not even require BIOS > >> modification and would work on any x86 machine. > > > > So you're already aware that there is not much hope if the bad guys > > get physical access? :p > > I disagree. Most "bad guys" aren't as sophisticated as one might > think. Including the ones coding the bugs and exploits used. They > will create a bug and assume it works. In reality it only works if x, > y, and z are true. Provided you have taken sufficient precautions > this rarely is the case. Most adversaries need not be sophisticated > at all. They me
Re: [freenet-support] Freenet speed & local threats
On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: > >> [...] > >> Many users have a persistent local threat that they need to be > >> aware of. Leaving a server running is not an option as it could be > >> compromised by an adversary. > >> > >> Removable media can reduce that threat. > >> [...] > > I was not referring to zero day exploits actually. The key word here > was local real-world threats. Such as an adversary gaining physical > access to the server/machine running freenode. If the bad guys have physical access, and care, it's game over. I suppose you can try setting secret tripwires that might notify you if the machine was tampered with (both in software, and in hardware.) Those might give you a fighting chance. Although you'll also need to make sure your room wasn't bugged with pin-hole cameras and other spy-ware. It's a lost battle, regardless. > Removable media may not eliminate the threat although there is less > opertunity for a more sophisticated targeted attack. A software > keylogger inserted into the MBR or similar would not be possible if > the boot medium is never available to the attacker. But it will be available if you ever decide to boot, happily recording everything. Again, if you think your machine was actually tampered with, you should assume it's unusable. > On the other hand a physical keylogger may still be possible and maybe > even a software based keylogger although more difficult to > disguise/install without being noticed. Of course. You should expect a variety of key loggers installed, in code, under your keyboard keys, acoustic key loggers stuck somewhere inside the machine (that can acoustically determine which key you're pressing), and a bunch throughout your room in pin holes in your walls and ceiling. > I can think of at least a few different ways of getting a keylogger > onto a system without having access to the boot drive or having to > install a physical device. I would still need physical access to the > computer. At least one method would not even require BIOS > modification and would work on any x86 machine. So you're already aware that there is not much hope if the bad guys get physical access? :p > [...] > Lets give a scenario: > > We have to assume that a persons Internet connection is being > monitored. This might be via a sophisticated non-governmental actor > (such as by breaking WEP/WPA) or by a government act such as > monitoring at the telco. The adversary should also be assumed to be > "unethical" in that there are no rules In that case, if you're using only opennet-mode, you should assume you're screwed :p. They can replace all your opennet peered nodes, and see exactly what you're doing, more or less. This is why darknet-mode was created -- they would need to physically infiltrate all your friend's computers, which isn't impossible, but MUCH more difficult. > and can physically modify or otherwise install a software based > monitoring solution on any boot media they have access to. Then you're *definitely* screwed, regardless, as explained above. > The first question is how many peers need to be compromised to > identify the content being transmitted? All of them, to be 100% sure. Compromising opennet peers is trivial -- with a dedicated-enough adversary. Compromising darknet is a lot harder. > If a few of your freenode peers can be compromised and the adversary > can monitor your Internet connection and local area network can they > identify the contents which are being requested/sent by you? This > assumes that they can't bug the physical machine that you are using > to run freenode. As long as you still have one uncompromised peer, I guess they can't be sure what traffic you're generating locally, and what you're simply relaying for that peer (or that peer's peers, etc). But if they're able to compromise all-but-one of your peers, it's pretty darn close to game-over :p. If I was an unethical bad guy, I'd arrest you and that peer, separate you into isolation-cells, and play psychological games until one of you confesses. Or perhaps torture. (Although, if that other peer doesn't have anything to hide, or isn't your friend, I'd easily jump to the conclusion that you're the one I'm looking for :). > If you add a server with freenode (which can be bugged) to your local > LAN that is then added as one of your peers does this compromise the > security? The point of adding a server with freenode to peer with on > the local LAN would be to speed up requests since the machine that is > actually used for browsing freesites (such as a laptop) can't be left > on all the time (as doing so gives an adversary opportunity to bug > it). This means it has to run from a removable boot medium that can > be accounted for at all times. Overlooking the above points about physically-tampered machines (we *really* shouldn't overlook them), I think this setup essentially means that you can expect one of your lan peers to be compromised. But, as long a
