Length of passwords that are rainbow table safe

Length of the password, and size of the rainbow table, are red herrings. Size does not matter. What matters is entropy.

Rainbow tables are not really relevant here, for two main reasons:

Building the table is expensive. A table "covers" a number of possible passwords; let's call it N. There are N distinct passwords that will be broken through the table. No other will be. It so happens that every single one of these N passwords must have been hashed during table construction. Actually, a lot have been hashed several times; building a table which can crack N passwords has a cost of roughly 1.7*N hash invocations. That's more expensive than brute force. In fact, brute force requires on average 0.5*N hashes, so the table building costs more than three times as much.

Thus, a rainbow table is worth the effort only if it can be applied at least four times, on four distinct password hashes that shall be cracked. Otherwise, it is a big waste of time.
Rainbow tables cannot be applied more than once. That's because of salts. Any password hashing which has been deployed by a developer with more brain cells than a gorilla uses salts, which are non-repeating variation parameters. The effect of salts is equivalent to using a different hash function for each user. Since a rainbow table must be built for a specific hash function, one at a time, it follows that a rainbow table will be able to crack only one password hash in all. Combine with the previous point: rainbow tables are simply not useful.

Now, of course, there are a lot of deployed systems where passwords are not hashed with human-level competency. Ape-driven development has resulted in many servers where a simple unsalted hashing is used; and even servers where passwords are stored as cleartext or some easily reversible homemade encoding. But one could say that if your password is to be managed by such sloppily designed systems, then extra password entropy will not save you. A software system which utterly fails at applying sane, documented techniques for protecting a password, which is the archetypal sensitive secret data, is unlikely to fare any better in any of its other components. Crumminess and negligence in software design are like cockroaches: when you see one, you can be sure that there are hundreds of others nearby.

Now let's assume that reasonable password hashing was employed, combining salts (to defeat table-based and parallel attacks) and configurable slowness (to make hashing more expensive). E.g. bcrypt. This answer is a lengthy exposition of how passwords should be hashed.

For instance, consider a server using bcrypt, configured so that, on that server, verifying a password hash takes 0.01s worth of CPU time. This would still allow the server to handle 100 user logons per second, an extremely high figure, so the server will not actually devote a lot of its computing power to password hashing.

Now, imagine an attacker who got his hands on some password hashes, as stored on the server (e.g. he stole an old backup, or used an SQL injection attack to recover parts of the database). Since bcrypt is salted, the attacker will have to pay the full brute force attack cost on each password; there is no possible parallel cost sharing, and, in particular, no precomputed tables (rainbow or not) would apply.

Our attacker is powerful: he rents one hundred servers of computing abilities similar to the attacked server. This translates to 10000 password tries per second. Also, the attacker is patient and dedicated: he accepts to spend one month of computing on a single password (so that password must protect some very valuable assets). In one month at 10000 passwords per second, that's about 26 billions of passwords which will be tried.

To defeat the attacker, it thus suffices to choose passwords with enough entropy to lower the success probability of the attacker to less than 1/2 under these conditions. Since 26 billions is close to 234.6, this means that the password entropy shall be at least 35.6 bits.

Entropy is a characteristic of the method used to generate the password, and only loosely correlated with the length. Password length does not imply strength; length is just needed to make room for the entropy. For instance, if you generate a password as a sequence of random letters (uppercase and lowercase), then 7 characters accumulate almost 40 bits of entropy, which, by the calculations made above, should be fine. But this absolutely requires that the letters are chosen randomly, uniformly, and independently of each other. Not many users would go to the effort of using a computer PRNG to produce a new password, and then accept to learn it as it was generated (I do that, but when I explain it to my work colleagues they look at me in a weird way).

As this famous question hints at, human memory can be at odds with entropy, and a longer password with more structure may be a better trade-off. Consider that the "correct horse" method ends up with "only" 44 bits of entropy for 25 letters or so (by the way, take note that a 25-letter password can have less entropy than an 8-letter password). The extra typing can be worthwhile, though, if it allows an average user to remember a 40-bit entropy password.

Despite all the propaganda of Hollywood movies, Secret Services rarely involve stupendously advanced technology (for that matter, they are also quite short on dry Martinis, leggy blondes and motorbike chases). Any rationally managed Secret Service will avoid spending 10k$ on breaking your password, since 1k$ will be more than enough to hire two goons to break your kneecaps. Ultimately, this is all a matter of relative cost.

So let's get practical. To generate a password, use this command on a Linux system:

dd if=/dev/urandom bs=6 count=1 2> /dev/null | base64

This outputs a password consisting of eight characters among lowercase letters, uppercase letters, digits, '/' and '+'. It is easily shown that each such password offers a whooping 48 bits of entropy. The important rules are:

Generate the password and then accept it. Don't go about producing another one if you don't like what you got. Any selection strategy lowers your entropy.
Don't reuse passwords. One password for each site. That's the most important damage containment rule. If you have trouble remembering many passwords, you can "write them down" (password managers like KeePass may help).
If 48 bits of entropy are not enough, then you are using a password in a weak system, and that is what you need to fix.
Your enemies are after your money, not your freedom. Don't try to defeat phantasmagorical three-letter agencies; concentrate on mundane criminals.


Sealed Room Security - Possibility of writing assembled binary code

If MSOffice is a full installation including the macro subsystem, this should be simple. The macro language is also called Visual Basic for Application and is very close to a VB development environment. You now have two options:

if you have prepared your malware as a VBA script, just type and execute it.
if you have the hexadecimal dump of your malware executable, it should not be too hard to write a piece of VBA code that translates back hexa values in raw bytes.

A vanilla Windows installation comes with very few tools, few of them allowing to deal with binary data. The only one I can think of is Power Shell. Unfortunately, I am not proficient at it, and cannot know whether it is possible/easy to translate hexadecimal to bytes.


How to ensure same BCrypt hash on different platforms?

My intention was to hash password in HTTP request body and only compare the strings on server side. Does it makes sense from security point of view?

Not really. While it makes it harder for someone to gain the clear text password, they don't have to. But an attacker won't have to care about the password. They can pass the hash. The hash is effectively the password, stored in clear text, in this scenario!

If users are perfect, and use unique, strong password, this would be equal to storing the passwords in clear text. As users are not perfect, and reuse passwords, it'd be a bit better than storing them in cleartext in real life. But not for your application.


Does the order of characters in a password matter to its security?

No, the order in the second password is NOT "more random". Randomness is not in the password itself, but in the way the password is generated; it does not relate to what the password is, but to what it could have been.

Password security is probabilistic: security is about the average success rate of the attacker. A single password is just that: a single password. To talk about the space of possible passwords, you need to envision the repetition of the scenario a huge number of times. The attack scenario really is the following:

The defender generates a password. The generation method uses some random choices (that the attacker does not know) and a deterministic mixing (that the attacker may know).
The attacker then tries to work out the password by trying possible password values, until he hits the right one.

We assume that the attacker knows everything except the random choices, and thus tries possible password in optimal order.

For instance, suppose that the generation method is: "take five random lowercase letters, followed by four random digits". This generation method may produce exactly 265·104 = 118813760000 possible passwords, and they are all equiprobable, so the optimal attacker will have to try half of them on average (59406880000).

Now, suppose that the generation method is: "take five random lowercase letters, and four random digits, and order them randomly". That generation method can produce 14970533760000 possible passwords, there again equiprobable. The attack cost raises to 7485266880000, 126 times the cost implied by the previous method.

Let's now switch again the generation method to: "take two random letter, followed by a random digit, then a random letter, then two random digits, then two random letters, then a random digit". The number of possible (and equiprobable) passwords is now back to 118813760000 and the attack cost is 59406880000 (on average).

Now is the important part: your first password example (klens4275) is possible with both password generation methods 1 and 2 -- but in the case of the second method, the attack cost is much higher. Similarly, your second example (kl7e25ns4) is possible with password generation methods 2 and 3; and, again, the attack cost is much higher with method 2 than method 3. So this shows that a password does not have strength "by itself". What matters is how the password was produced, because the generation method defines the space of possible passwords, therefore the optimal attacker's strategy and average cost.

Note that attack strategies are also probabilistic, and make sense only on average. If you consider a single password cracking effort, the best attack "strategy" is: get lucky, just try the right password on first step. This is intellectually unsatisfying. The notion of "optimal strategy" really means: the strategy which will yield the smallest attack cost on average (over billions of cases of password cracking).

So we can summarize as follows: a "random placement of letters" increases security if (and only if) it is indeed part of the random choices made for each password generation. In my example "password generation methods", only method 2 includes such an element. Note, though, that the following fourth method is actually even better: "take 9 random letters-or-digits". This raises the number of potential passwords to 101559956668416, almost 7 times as much as method 2 (and that's the best you can get if you want the password to always consist in 9 signs which are only lowercase letters and digits).


What browsers support encryption or decryption using local certificates, or smartcard readers?

All major browsers support client SSL certificates for authentication of SSL/TLS tunnels.

However, doing any directly crypto in javascript is a bad idea and as a such the browsers do not allow any access to the certificates at all (infact, they won't even give use extension API's to implement firefox extensions like perspectives, convergence and certificate patrol without some very ugly hacks and including our own implementations).

If you want to just use the browser implementation as is, then you are fine, you just send a command over ordinary https to tell it to generate client certificate or have your uses import the certificate file into the browser and make sure the server sends the optional please send client cert in the TLS/SSL handshake, of course this does not allow local encryption.


How do RATs access computers through routers?

The communication between computer goes both ways, so there can be two cases:

The RAT is a server: this is the case for many well-known and legit remote access tools, like remote desktop, VNC etc... In this case, you need to allow port forwarding on your router to be able to access the computer.
The RAT is a client: the tool will try to connect to a "centre of command" somewhere the hacker can accept the inbound connection. Then the client offers a remote shell. In this case, there is no need for port forwarding on the router.


Hashing password longer than 14 characters in wpa_supplicant.conf

There is no sense in hashing the password when using md4 as a hashing algorithm.

The threat you are trying to defeat with hashing the password is either:

Someone getting physical access to the device and extracting the password from the file system.
Someone getting remote access and privilege escalation to root to be able to read the password.

Now, both of these threats can be expected to have access to reasonably recent hardware that can brute force through md4 as if it was plain text.

To help against

you could use full disk encryption to keep the password safe,
you should be considering that someone with remote root access already has access to the network (either because the connection comes out of that network or because the device in their control is already connected to the network).

As it is generally preferred for several reasons to pivot through an already compromised host rather than connecting the attacker machine to the network itself, there is not much gain for the attacker in compromising the WPA password from the configuration - and if there was, md4 would not - as addressed earlier - hinder an attacker sufficiently.


I'm leaving my job and want to erase as many personal details etc. as possible; any tips?

The proper answer for this question is very situational, and dependent upon the policies and procedures in place at your company.  Many companies have in place methods of backing up portions of the drive meant for user data, or even the entire drive, across the corporate network.  If they've performed such backups on your system, there's nothing you can do to prevent them from accessing your data.

Beyond that, if your company allows, the only things you can do to definitively prevent restoration of your data off the laptop drive, is to do a secure wipe of that data or the whole drive, degauss, or outright destroy the drive.

EDIT:  While the above discusses what you might be able to do about your privacy now, there really is a larger issue at hand.

If you're really concerned about your personal privacy, don't use corporate resources for personal purposes.  Most companies have included in their Acceptable Use Policy or similar documentation, a clause that specifically says you may be subject to monitoring and have no expectation of privacy when using their systems.  In many jurisdictions, this means that they can do whatever they want to observe and record your activities with or without your explicit consent (generally, your consent is given implicitly upon your agreement to the AUP) and/or knowledge - causing any retroactive attempts at personal privacy to be futile and ineffective.

Case in point:  At one former workplace, I heard of a user who decided to do some, let's say, "very personal" web browsing on a company laptop while he was on his home network.  Apparently he was under some delusion that whatever he did with the company's hardware was none of their concern if he did it on his own Internet connection.  To be safe though, I'm sure he had some good history cleaning software in place and in use.  He was also technically savvy enough that he probably did some manual cleaning of his own, periodically.

What he didn't know was that the company had monitoring software installed locally and running in the background.  This software would record his Internet activities at all times, and relay the logs to the corporate servers whenever the laptop was connected to the intranet.  You can imagine the resulting disciplinary actions when this occurred.

TL;DR:  Keep your business on your hardware, and company business on company hardware.


arp spoofing and https reading doubts in bettercap tool

Can an ARP table contain a range of ip-s instead of a single one as an entry?

There is no need for a range. But an ARP table can have multiple IP associated with the same MAC. It is actually not uncommon for servers to have multiple IP addresses on the same physical interface.

  ... but what I know is that https is no more than http over SSL (TLS), so I was not expecting the tool to read https headers... What am I missing?

The https proxy is doing a man in the middle attack against TLS, i.e. generating certificates on the fly. Of course, unless the https client is either buggy or specifically setup to accept these certificates as trusted, the client will complain that the connection is insecure because the certificate is not trusted.


The traditional answer is computing 2^(2^x) mod n for a semi-prime n. This has some nice properties:

It's efficient to computer for the challenger, because there is a shortcut when you know the factors of n.
The construction cannot be parallelized. So the attacker needs to compute squarings sequentially, preventing them from speeding up the attack by throwing more resources at it.

But the attacker can still exploit the parallelism within a squaring using custom hardware, giving a considerable speedup compared to standard CPUs.
The number of iterations needed is deterministic. You can't get lucky or unlucky.

LCS35 Time Capsule Crypto-Puzzle by Ronald L. Rivest has the details, including Java code to generate a challenge.

Letting the attacker brute-force a (short) key is not a good time puzzle. It's trivial to parallelize, if you throw twice as much hardware at the problem, you solve it twice as fast. In addition to that, the runtime is random and you can only choose the expectancy value for the required effort (this could be fixed by having a number of separate challenges).


What are the advantages of a ZKP authentication system?

The additional security gained, is that a attacker cannot pass a previously obtained hash, to authenticate, and in same way, a complete transaction at the site cannot be replayed.

Transmitting the hash of password over the wire is as bad as passing the password itself, as the hash then becomes the password itself, which would allow a attacker to authenticate anyways.

In other words, ZKP adds challenge-response security to a password based protocol. However, ZKP is still vulnerable to client-side attacks such as keyloggers, malware and such, why the optimal is to instead use some sort of 2FA authentication, for example a challenge-response token.


What differences are there between built-in Administrator and other Administrators?

Some applications are incorectly coded to look for the SID of the well known Administrator account.  This was an issue in the early days of NT4 but don't think it's an issue now...

I don't think any applications match on the name "Administrator" since that is Engish specific and is a very poor programming practice.  "Administrateur" and other language matches would have to be accounted for.

Instead applications should match on the SID of the local group Administrators


Generate pair of large primes with openssl library in c

If you want to know how you can do the functionality of openssl prime -generate in C code have a look at the source code of OpenSSL which is open source and easily accessible. Specifically have a look at apps/prime.c which implements openssl prime. There you can see that BN_generate_prime_ex is used to generate the prime:

if (generate) {
    ...
    bn = BN_new();
    ...
    if (!BN_generate_prime_ex(bn, bits, safe, NULL, NULL, NULL)) {
        BIO_printf(bio_err, "Failed to generate prime.\n");
        goto end;
    }


NFC used in place of contact based smart card two-factor authentication

Whether and how to integrate NFC into an industrial application is a shopping question, and off-topic for this site.

But the advisability of using NFC for 2nd factor authentication is interesting. NFC use in ID cards isn't quite as popular as the more broad RFID specification, on which NFC is based. But the challenges are the same: specifically, if the ID token is a simple number, then reading the card is all that needs to be done to clone the card. The proxmark3 is a popular tool among penetration testing teams which can read and then replicate most popular ID tags at a fair distance.

If the ID tag instead embeds a cryptographic key, then the tools and architecture around it has to be dramatically more complex. But such a card should be resistent to drive-by cloning.


Where do I get "Mercury" by MWR InfoSecurity?

According to MWR InfoSecurity:

  Drozer (formerly Mercury) is an open source software, maintained by
  MWR InfoSecurity

Also if you take a closer look at their logs, Drozer is what they were always headed for and Mercury was just a pre-name for (maybe) the incomplete version of what they intended to release. I don't know if you are specifically looking for an older release of Drozer (which is Mercury v2.2.1) or not but when you say:

  now I get redirected to some product called drozer.

It seems like you are unaware of the facts I mentioned above.
Hope this helps :-)


Is this FTP transfer secure? Do I need a new FTP client?

Username and password are protect since the control connection is switched to TLS using AUTH SSL before the login credentials are sent. But it is unknown how good they are protected, i.e. if they are protected with a strong or weak cipher and if the servers certificate was checked properly. Especially properly checking the certificate is a well known problem and since the client is old chances are high that no check or nor proper check is done and the connection is thus open to man in the middle attacks.

Apart from that no PROT command is issued which means that the data connections (i.e. directory listing, transferred files) are not protected.


The include_path directive is a list of directories to look for included files first, similar to bash's $PATH environmental variable.

So an absolute file name/path like this:

include_once('/var/www/domain.com/htdocs/includes/header.php');
include_once('/var/www/domain.com/htdocs/includes/footer.php');

Can be replaced with a relative filename like this:

include_path('/var/www/domain.com/htdocs/includes:.');
include_once('header.php');
include_once('footer.php');

This is at least how I understand it. It has nothing to do with security and restricting directories, it is to create a custom search path for common includes.

open_basedir is what you are looking for, it limits the reading of files to the directories specified. Based on your question, it looks as though it is operating as designed.


The level of security regarding a TeamViewer host deployment

In general with services, in your case Team Viewer, that you have security concerns about it because they communicate over non-trusted networks such as Internet, the approach that I follow is basically to tunnel the service from source with SSH. On the server side the service is only accessible from a trusted network and is not exposed to the Internet. On the client size, the user just need to make a ssh tunnel and use all the security that ssh brings you, and the configure your service to use the exposed port by Team Viewer.


Is it acceptable to generate salts with a hash of the username?

Good salts are unique over the whole range of space-time.

A user does not change his name when he changes his password: that's a failure of uniqueness over time. (Similar case: an old user account is closed, a new user is registered and reuses the same name.)

A user has the same name on several distinct servers, which may employ the same hashing strategy: that's a failure of uniqueness over space. (Think, in particular, of all these users called "Administrator".)

User names are thus rather sloppy as salts. They are much better than no salt at all, but it is highly recommended to use proper random salts instead. 16 bytes (or more) from a cryptographically strong PRNG will give you much better uniqueness.


Can a host access a VPS disk's encrypted directory directly while running?

Yes
Your situation violates three of the Ten Immutable Laws of Security, namely:

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

Law #6: A computer is only as secure as the administrator is trustworthy

With enough effort the admin definitely can dump the memory and extract either the key or decrypted data while the VPS is running and the directory is decrypted. Alternatively, (since the disk is not encrypted) the rogue admin could modify the SSH server binary to log the password in cleartext.
What can you do?
The only way to be absolutely sure would be to host your own server.
Or you could look into Confidential Computing VMs. However, I am not sure how foolproof these are, so proceed at your own risk.


Encryption happens in memory, not on the disk.
You are misunderstanding how disk encryption works. It does not read the entire disk and replace it with a decrypted version. Rather, when a file or sector of encrypted data is accessed, it is read into memory and decrypted in memory. Likewise, when writing to the disk, data is encrypted in memory before being saved to persistent storage. Operating systems keep copies of data that have been read or is to be written in memory (the filesystem buffer) as a performance optimization. It is in this memory that the encryption and decryption take place. This allows data to be read from the disk and decrypted once, but subsequently accessed many times from memory. Incidentally, using memory to store frequently-accessed files is why so many people mistakenly think Linux eats too much RAM.
I also want to point out that the bottleneck is often I/O, not encryption. You say that encrypting gigabytes of data takes a long time, but on most modern machines (including mobile devices), encrypting gigabytes of data can take only a few seconds (especially with hardware acceleration, encryption is really, really fast). However the solid-state drive in most modern Android devices is unable to read or write data at nearly those speeds. So no matter how fast you are trying to read or write data to the disk, the bottleneck will generally always be I/O, not encryption.
Older hardware often did suffer reduced performance when encryption was in use. This was because, at that time, storage speeds were improving faster than processor speeds. The lack of dedicated hardware acceleration for cryptography and the inefficient algorithms often caused a noticeable slowdown when accessing the disk. On modern systems, this is reversed. The processor is so fast that the storage device struggles to keep up. Any overhead is negligible.


Reliability of scanning tools on icmp timestamp responses

one of our server has returned a icmp time stamp response such that the scanner (nmap) is able to guess the uptime of the server. Does this constitute a real threat and should I be concerned?

It is an informational threat.  It allows an attacker to gather information that may be useful in determining what other attacks might work.  For example, if nmap can tell me that it looks like a Centos OS and it has an uptime of 60 days, then I I know that any kernel security update packages released in the last two months have not been installed and activated.  As a result, I may be able to determine which attacks against that system are likely to work.

For an internal server, you should only be mildly concerned.  For an Internet facing server, you should be slightly more concerned, and should limit ICMP access to that server as a matter of best practices.  But this is not a major concern in either scenario.

In any case, if the OS vendor has a patch or a configuration workaround, you should apply it - no reason not to, and it might even help.

For a minor issue like this, the largest concern is usually placating your auditor.  If this is the biggest thing they find, you're doing well!


How can I remove an unknown device from my wifi network?

If it can get on now, and you kick it off (rebooting your router would definitely kick it off, for example), it's just going to get on again.

To kick it permanently, do the following, in this order:

Change your router's admin password
Download updates for your router
Disable WPS if it's enabled

ESPECIALLY WPS-PIN (the "enter the digits") because it's ridiculously vulnerable; see Reaver

Change your Wifi to use WPA2-AES
Change the PW to use a long (20 character plus), strong (cryptographically random, like KeePass generates) password.
You will need to change the Wifi password on all your devices, of course, but this should last you for awhile.
Don't give out the new password to anyone.
Don't let them put it in their device; they can pull the password out of their device at their leisure.


SAML is used over the Internet. If you have a web application you would use SAML. SAML is just a standard data format for exchanging authentication data. You would typically use it for a web SSO (single sign on).

Kerberos is used in an enterprise LAN typically. Kerberos requires that the user it is authenticating is in the kerberos domain.

Not really a lot of overlap in my opinion.


Where do browsers store HTTP Authentication details

Interesting questions indeed, but the answer will vary depending on the design, implementation, and protocols the browser you're talking about was built in compliance with.

Let's take some real examples of Google Chrome:

Chrome stores login credential data-base under C:\Users\<username>\Appdata\Local\Google\Chrome\User Data\Default\Web Data
It also stores several sensitive user data under C:\Users\<username>\Appdata\Local\Google\Chrome\User Data\Default
Read more about Chrome Security issues here.

For other browsers this can also be true. Example: Extracting sessions passwords from RAM (aka: Memory forensics). There are many tools to help you with that.

Some people may argue that this is not a serious security issue, because it is assumed that you protect your user account and the operating system that hosts your browser.


WebGoat is an application that is designed to be susceptible to network attacks. Theoretically, your computer becomes vulnerable to a network attack when you're running WebGoat. Imagine if an attacker were to leverage the WebGoat vulnerability for the lesson about performing code injections, This would allow the attacker to execute commands on your computer. Very bad.

An attacker will need network access to your computer to execute the attack. You likely have a firewall on your network that will limit attackers to your local network. That said, you are still reducing the safety of your computer by running WebGoat. Especially as firewalls sometimes are misconfigured or have vulnerabilities that can cause them to let packets from the internet into the local network.

WebGoat's recommendation is to disconnect your computer from the internet which will remove the risk of a network attack. That means unplugging your network cable and/or disconnecting your WiFi connection. It seems like a reasonable protection to me.


Technically, you could use the password as the shared secret in SessionLock, but then the web site needs to store the password in the clear. So, as you suggest, you could use the password hash, but then the password hash suddenly becomes almost as good as the password itself, since knowing it is sufficient to set up a secure session with the server. So that's a pretty good reason not to use the password hash.

But mostly, my design goal, in SessionLock, was to not entangle the method of authentication with the security of the session. What about before you're logged in? I still don't want someone stealing my session. And what about on systems that use HTTP auth, or some other password-storage-and-checking abstraction that generally makes it difficult for your web app code to get at the password data, even its hash? Or a larger web site where login happens at login.*.com, and then a session cookie is set and that's it, the various service1.*.com, service2.*.com don't have the actual password.

For all of these little reasons, SessionLock doesn't tie its shared secret directly to the credentials.

And as other commenters mentioned, be careful. SessionLock only prevents passive network attackers from stealing your session. The payload is still readable by eavesdroppers, and you're out of luck against active network attackers.


Explanation of illegal multi-byte encoding leading to XSS

If your webpage considers 'E3 80 22' as one sequence then the '22' won't be escaped... if you deliver this page to a browser who considers 'E3 80 22' as 'E3 80' + '22', stripping the illegal sequence results in '22' then you have an '22' in there you don't want and this allows XSS attacks.


Securing confidential information between users

I would perfer Nr1 due to simplicity, but take Nr2 if:

(a) In your case, Encryption and Decryption really -is- slow for some reason. So slow that its a problem for Usability. Perhaps massive amounts of Data or user machines with very bad processing capacity.

(b) It was not a typo in Option 1 that they use a third party key. In my opinion they could make the public keys available to all system users, then encrypt data with the public key of the intended recipient user when the data is requested (then only he/she can decrypt it with his/her private key).

RSA have a padding issue you might consider reading about, What specific padding weakness does OAEP address in RSA?.

When it comes to these sort of things, SIMPLE is often the wise choice.

With the implementation of every encryption method, every little row of code there exists the possibility of absolute and crushing failure. Thus complexity of solutions should be reduced to as simple as it can possibly be, but not more simple then that.

One encryption method, one crypto library, one process to create one type of keys, few points of failure.

How often are data updated? How much does data storage cost? How is the HMAC generated? Such things needs to be considered.


Is binding all private services to the 127.0.0.1 address and then accessing them via SSH using an RSA key pair of 4096 bits secure?

You description of local services which you only access through secure SSH forwarding is to vague to evaluate the security of your setup. What this setup is doing is restricting the access to the service to specific hosts, but nothing more. Use of 4096 bit encryption of the transport does not magically make the service itself secure, it protects only the forwarding against sniffing and manipulation.

The following setup similar to yours I've seen several times and while it looks secure at the first glance it is not:

some web interface to administrate a device
forwarded through SSH to the local machine
accessible there as http(s)://127.0.0.1:some-port/

If you visit this web interface then with the same browser you use for your normal browsing an attacker can mount a CSRF attack against the server on 127.0.0.1, i.e. your forwarded administrative interface. Or it might use a DNS rebinding attack to access the device from the internet by using your browser as a relay.

Thus securing the transport and restricting the access to specific hosts is only part of securing a service. Especially with web services you have to take a look at all the usual web based attacks, which don't vanish just by using an encrypted transport. There are probably similar things to watch out for other kind of services.


What organizations have 1B faces to train a facial recognition neural network?

Almost certainly Google. There are probably others. At the end of the day, you can just make a crawler and scrape images of the web. It is not necessarily 100% legal (grey area IMO), but it is not something anyone could prove in court anyway.


Storing Old Password History and Information

Security:

It might sound like a security hole to you. But trust me, It is one of the strongest security pattern.
It prevents you from avoiding you to create an old password of yours even in your hurry times. It is really necessary for you
not to re-create your old passwords, since there is always a chance of some people knowing your history(friends or foes, it still
 counts as a threat to your privacy).

Convenience:

You have no idea how useful it is to an user when they are notified that they entered their old password by mistake OR they changed it this
time back,etc., It will really help a user who genuinely typed his old password by mistake.

Getting hacked:

Just by knowing that you changed your password last month will not help an attacker to guess your current password. It is based on
the information that you put out there online.

For example, when an attacker comes to know that you changes your password two days before, he might
check out your blog or social network sites you are involve in. If you put any related info that could lead to guessing your current password, thats when
you are officially busted and it not because of your networks but by you.

Conclusion:

So just be careful with your online data. Update strong passwords frequently and bother less about your old passwords stored by Facebook,Google,Twitter. After all they exist to make money by your usage which means they are desperate enough to secure your identity and information as they secure theirs!


Can TrueCrypt encrypt SSDs without performance problems?

Hard disk encryption is not supposed to alter SSD life time: "encrypted" bits are not harder to read or write than "normal" bits, and (properly done) encryption does not enlarge data. Indeed, the SSD device has no idea whether what it is asked to read or write is encrypted or not. One megabyte is one megabyte.

(Edit: about "encrypting empty space": this implies only one write pass of the whole disk area; this needs not be done regularly, only once. Flash memory can be rewritten about 10000 times before failing, so this extra encryption should not shorten the SSD lifetime by more than 0.01% -- not enough to be detectable.)

The current state of TrueCrypt being what it is (the "official" software has all but disappeared), it is hard to get definitive answers, and even recommending TrueCrypt can now be a matter of delicacy. Thus, claiming that TrueCrypt will or will not use AES opcodes can be too bold a statement. This article says that, back in 2011, TrueCrypt 7.0a supported AES-NI, and could follow the speed of a SSD (at least the SSD they used for the benchmark).

Performance, in general, is a matter of measurement and should be benchmarked rather than discussed; especially for something as fuzzy as "general computer performance" from the point of view of a human user: the user's feelings are as important as raw figures. The main perceived boost from a SSD comes from the much reduced latency more than from the raw throughput for single-file I/O. We can still speculate that AES-NI allow for more than 1 Gbyte/s raw encryption speed on a 2 GHz CPU; thus, half a core worth of CPU ought to be enough to follow the throughput of a decent SSD (my SSD runs at 500 MB/s and I find it decent enough).

Of course, installing a whole-disk encryption system has the potential, in case of some stupid incompatibility with your OS and/or BIOS booting system, to make your machine unbootable. Make backups ! And prepare a "recovery disk".


On TLS 1.2 with Diffie-Hellman Key Exchange, how does the client make sure the server has the certificate's private key?

The ECDHE key exchange does not care about the private key of the certificate. The private key is only used for authentication, which is like the key exchange part of the TLS handshake. But authentication is not part of the ECDHE key exchange.
Basically, the authentication is done by the server signing some data which are at least in part depend on client data. The client can  then verify this signature using the public key in the certificate.


Is an ATM alert system triggered by typing the PIN in reverse a secure solution?

This is an urban myth. The FTC looked into the whole thing in 2010 and could find no bank or manufacturer of ATMS in the US who had ever implemented such a system; they also concluded that it would be expensive to implement and probably not work very well.

Duress codes do exist in other areas - some home alarm systems have them, either in the PIN or in the code used over the phone to the alarm company to cancel an alarm.

There's an interesting paper from the University of Waterloo that points out some of the issues with such systems. For example, because of Kerchoff's principle, we must assume the bad guy knows there is a duress code, so she can demand the victim tell her that as well and improve her chances to 50%. And of course there's the old chestnut of attacking the password change process.


You should configure your web server, so that any HTTP requests result in an HTTP 301 redirect to the HTTPS equivalent URL.

However, this is still subject to MITM. For example, if an SSL Strip server can intercept the HTTP requests, then it could speak to your server in HTTPS, but the user is using insecure HTTP on their end

To prevent SSL Strip or similar MITM attacks, you should implement HSTS. This way, if the user connects one time to your site correctly (either with an untampered connection, or to an HTTPS url for your site), then the browser will automatically remember that all HTTP urls should be converted to HTTPS before attempting to connect to your site.
Note: Once this happens, the only way to get the browser to stop using HTTPS will be to clear browser cache, so do not implement HSTS if you expect to discontinue HTTPS for this site.

I do not know how to specifically acheive these on your particular webserver. I'm sure the Stack Overflow or Server Fault folks could help you.

Once HSTS is implemented, ideally you should get your HSTS domain pre-loaded in major browsers. This way, even if a user has never visited your site before, they will benefit from HSTS, even if their first visit is on an SSLStrip or other bad-guy network.


What are the accepted naming convention for the terms "public/private keys" and "certificates"?

The following are the "accepted naming", i.e. the terms that I would accept:

A public key is a mathematical object; it is half of the cryptographic key pair. For RSA, a public key is a pair of big integers (modulus and exponent), nothing more.

A private key is a mathematical object; it is the other half of the key pair. For RSA, a private key is a bunch of big integers (namely n, e, d, p, q, d mod p-1, d mod q-1 and q-1 mod p, where n and e are copies of the two corresponding values from the public key).

A key pair is a public key with the corresponding private key.

A certificate is a signed object which some elements and binds them together. That's what X.509 is about. Most certificates contain a public key (not the private key) and an identity (a "name") designating the owner of that key (i.e. the entity who controls the corresponding private key).

That being said, a lot of people use sloppy terminology and you can encounter a lot of jargon abuse. E.g.:

For usual algorithms (everybody uses RSA), the public key is easily recomputed from the private key (with RSA, the public key is a subset of the private key, so this recomputing is trivial). This leads some people to talk about "key pair" when they mean "private key" or vice versa.
Some people (in particular a substantial fraction of Microsoft's documentation) talk about "certificate" when they mean "the certificate and the private key corresponding to the public key which is in the certificate". PKCS#12 archive files (also known as "PFX") are usual containers for a certificate and its private key.
Many people don't grasp the difference between a certificate and a public key, and use the two terms in a seemingly random way.
Confusion is further enhanced when people being to talk about "public certificates" or "private certificates". Part of the problem is that games with key pairs and RSA-like algorithms are called public-key cryptography as opposed to "normal" cryptography, i.e. symmetric algorithms like AES. In symmetric cryptography, keys are secret and no key can be made public. So there is an expression: secret key. This term normally designates a key for a symmetric algorithm, which is a bunch of bits. But some people say "secret key" when they mean "private key", or vice versa.
I have also encountered "digital identity", "private identity", or "digital credentials", meaning a certificate, a private key, both, or something else. Depending on who does the talking.
There is also a notion of secret-key certificate which is either someone who considers "secret" and "private" to be interchangeable, or the specific case of a certificate used in some advanced "blind signature" schemes. This is research-level work, nothing standardized.

Bottom-line is that if you want to be reliably understood, then you must take care to define your terminology properly. Similarly, be prepared, when reading documents from other people, to encounter just about anything. Decent standards begin with a glossary which unambiguously defines the meaning of terms within the standard.


Gaining shell access on a Unix Webserver

Can you launch commands in a shell even with standard user privileges? Look what kernel has with uname -r. Maybe is vulnerable to Dirty Cow exploit, affected kernels. Or maybe you can use the old Semtex exploit. Always should be a directory to write... check for /tmp.

If you have access to the mysql, you can launch system commands from there using \!. Check this out.

The post-exploitation is more difficult sometimes than the first intrussion! Be imaginative. Here are a lot of useful commands. Good luck!


Is there any practical weakness to using MT19937 to generate passphrases?

You don't have to worry about the cryptographic strength. Indeed you will not be getting enough values from it for that attack to matter and even if you did, nobody can observe those values. (Of course if you create millions of passwords and assume that some percentage of them is compromised that might change things.)

What you do have to be careful about is what your initial seed is. If you use for example the time then an attacker only has to guess at what time you created your password.

Knowing the PRNG only helps to reduce the entropy if the PRNG is extremely bad. Way worse than MT19937.


I am not sure this is the place for this question. Maybe refer to SuperUser but...

I use uBlock Origin. It is a highly customizable tool for ad blocking, malicious site blocking and much more. It allows black listing and white listing of domains and uses public lists of malicious domains to block.


You are trying to protect your web application via Apache, but instead,
the proper way to protect your apache/web-application is to make sure that attackers are denied access at lower level of OSI model. For example you can use fail2ban which protects on OSI level 3 (Network) thru iptables, as it bans entire IP address.

Apache is OSI level 7 (application).

So instead of having

<If "%{HTTP_USER_AGENT} == '^\W'">
    ErrorDocument 403 "403 Forbidden - Request blocked due to malformed user agent."
    Require all denied
</If>

in your config, you should rather create custom log file by adding

LogFormat "%a %{User-agent}i" ipagent

And

CustomLog /var/log/apache2/useragent.log ipagent

And proceed with fail2ban config as explained at answer given here https://serverfault.com/questions/251988/blocking-apache-access-via-user-agent-string

Aditionally to further harden your server, make sure to install apache's mod_security with OWASP rules, to do it, check my answer, given here:
Some bot keeps posting this to my server


Can a physican website be on a non-HIPAA server?

An ordinary website, such as one advertising office hours, contact information and related media should be fine, so long as it is completely separate from the HIPAA-compliant network & systems that serve the doctor's office.

This also means that you cannot use this webserver for any remote-access services (ie: VPN portal), regardless of the fact that the webserver itself will not be "storing" any PII.


What is the most secure way to send emails using PGP?

The most secure way to send and receive emails via PGP is to sign and encrypt them.

Signing provides integrity, allowing recipients to verify that the message was sent by you and has not been tampered with.

Encryption provides confidentiality, ensuring that any person who intercepts the message will not be able to read it.

Both of these are important aspects of security, although in some cases you may decide you only need one and not the other when sending mail.

For receiving mail, the one you are most interested in is signing, otherwise you cannot guarantee that the message is indeed from the sender. If you receive an unencrypted message, other people who are/were able to obtain it would be able to read it, but there's not much you do about that if its already been sent (unless you wanted to encrypt it for storage on your own PC, or to forward on to other people).


XSS - arbitrary file in background-image css property

No, that's not possible.

A value to background-image will be rendered as an image. Even an SVG with embedded script code would just be displayed as an image when loaded via background-image. So XSS isn't possible here (the same way an arbitrary value to <img src="..."> can never lead to XSS).

Even if you couldn't just change a background-image value but inject new CSS, you most likely wouldn't be able to get XSS. The techniques to inject script code via CSS expression(...) or url('javascript:...') don't work in modern browsers. In other words, even embedding an entire user-controlled CSS file can lead to severe side-channel leaks but not to plain XSS.


DLL injector in C doesn't inject the DLL

Your code works fine. The problem is that you're almost certainly trying to load an x86_32 DLL into an x86_64 processor, or vice versa.

I compiled your code and tested it against VLC and Notepad, and in both cases the operation succeeds when the target path is for a 64-bit DLL. Keep in mind that many "random" binaries in the System32 folder are not 64-bit even on a 64-bit OS.

The other failure case might be that you're targeting a process with an image loading policy or a binary signature policy applied, and the target DLL does not meet the requirements. The most common case is either that the DLL does not have a Microsoft signature, or the DLL file has a low integrity label applied.


Return-oriented programming: how to find a stack pivot

Have a look at mona by corelan

https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/


Anyone can make a pair of cryptographic keys that provide digital signing.

Anyone can claim that a private key they have is the private key of the pope. (They'd probably be lying, of course, which is my point.)

The value of cross-authenticated signatures is that you have a third party saying that your public key is indeed yours.

This provides an extra level of non-repudiation.  If you want to take credit for something that has been signed, you probably don't need a cross-authenticated digital signature. Just prove that you have access to the same private key that matches the signature by signing something else.

However, if someone else wants you to sign something, then later prove that you did indeed use your own private key for that, they need a third party to demonstrate that the private key did belong to you at the time. Otherwise you could just say it wasn't you, and stop using that key pair.


Have I really been hacked or am I falling for a phishing scam

This is a popular online scam so you should delete the email and move about your business.

See the FBI's Public Service Announcement on this scam specifically.

https://www.ic3.gov/media/2020/200420.aspx


What constitutes submitting payment at a different address for PCI-DSS?

Only a QSA can give you a qualified answer, but I can give you my view.

It's probably making a distinction between SAQ A and SAQ A-EP. Does the BookingBug widget work via an iFrame or does it do a whole page redirect? In that case you're likely SAQ A so #1 would apply.

If the credit card data touches your frontend interface at all, then you would be bumped up to SAQ A-EP, so #2 would apply. If it touches your server, you'd be bumped to SAQ D.

You're responsible for ensuring your third party services are PCI compliant and are handling it in such a way as to reduce your scope. Short answer to make sure the widget is using an iFrame or full page redirect.


There are a few possibilities how he did it:

You and him were connected to the same WiFi network and he used a software like Dsploit that allows him to intercept the traffic and performing man in the middle attack - solution to that is use VPN software that will encrypt the connection.
More advanced attack. He forced your mobile device by using Karma and WiFi Pinneaple to connect to his rouge access point - The best way to protect yourself from this kind of attack is to 'forget' networks as soon as you have finished using them, just remove them from the list.
He had access to your mobile device and he installed a keylogger - solution is to reinstall to whole system in your device.


Actually most languages are "secure" with regard to buffer overflows. What it takes for a language to be "secure" in that respect is the conjunction of: strict types, systematic array bound checks, and automatic memory management (a "garbage collector"). See this answer for details.

A few old languages are not "secure" in that sense, notably C (and C++), and also Forth, Fortran... and, of course, assembly. Technically, it is possible to write an implementation of C which would be "safe" and still formally conforms to the C standard, but at a steep price (for instance, you have to make free() a no-operation, so allocated memory is allocated "forever"). Nobody does that.

"Secure" languages (with regards to buffer overflows) include Java, C#, OCaml, Python, Perl, Go, even PHP. Some of these languages are more than efficient enough to implement SSL/TLS (even on embedded systems -- I speak from experience). While it is possible to write secure C code, it takes (a lot of) concentration and skill, and experience repeatedly shows that it is hard, and that even the best developers cannot pretend that they always apply the required levels of concentration and competence. This is a humbling experience. The assertion "don't use C, it is dangerous" is unpopular, not because it would be wrong, but, quite to the contrary, because it is true: it forces developers to face the idea that they might not be the demigods of programming that they believe to be, deep in the privacy of their souls.

Note, though, that these "secure" languages don't prevent the bug: a buffer overflow is still unwanted behaviour. But they contain the damage: the memory beyond the buffer is not actually read from or written to; instead, the offending thread triggers an exception, and is (usually) terminated. In the case of heartbleed, this would have avoided the bug from becoming a vulnerability and it might have helped to prevent the full-scale panic that we observed in the last few days (nobody really knows what makes a random vulnerability go viral like a Youtube video featuring a Korean invisible horse; but, "logically", if it not had been a vulnerability at all, then this ought to have avoided all this tragicomedy).

Edit: since it was abundantly discussed in the comments, I thought about the problem of safe memory management for C, and there is a kind-of solution which still allows free() to work, but there is a cheat.

One can imagine a C compiler which produces "fat pointers". For instance, on a 32-bit machine, make pointers 96-bit values. Each allocated block will be granted a unique 64-bit identifier (say, a counter), and an internal memory structure (hashtable, balanced tree...) is maintained which references all blocks by ID. For each block, its length is also recorded in the structure. A pointer value is then the concatenation of the block ID, and an offset within that block. When a pointer is followed, the block is located by ID, the offset is compared with the block length, and only then is the access performed. This setup solves double-free and use-after-free. It also detects most buffer overruns (but not all: a buffer may be a part of a bigger structure, and the malloc()/free() management only sees the outer blocks).

The "cheat" is the "unique 64-bit counter". This is true only as long as you don't run out of 64-bit integers; beyond that, you must reuse old values. 64 bits ought to avoid that issue in practice (it would take years to "wrap around"), but a smaller counter (e.g. 32 bits) could prove to be a problem.

Also, of course, the overhead for memory accesses may be non-negligible (quite a few physical reads for each access, although some cases may be optimized away), and doubling pointer size implies higher memory usage, too, for pointer-rich structures. I am not aware of any existing C compiler which applies such a strategy; it is purely theoretical right now.


A single file upload should not effect performance if the server is set up correctly. Generally speaking, download speeds are faster than upload speeds, and this is especially true with home connections. You will much more likely reach your bandwidth cap before the server does, making this a very poor denial of service attack.

Web servers are multi-threaded and will not block new connections because you already have one open. There are some limitations on certain browsers due to the number of worker processes spawned, and the amount of memory these processes use.

If you add more than one client to the equation, it becomes a Distributed DOS and is much more feasible. The idea of uploading content in a DDOS is still inefficient. When DDOSing, you often times look for a force multiplier built into the protocol. This is where you send a small amount of data, and the server sends back a much larger reply. This can be seen with DNS Amplification Attacks, where its possible to reach a 1:70 ratio of client:server data.

All operating systems have methods of determining file size, please refer to the documentation that came with your OS.


Is a Windows installer that doesn't require admin rights dangerous?

Installing something without needing admin privileges is no more dangerous than running a no-install program with standard user permissions. This is also less dangerous than installing something WITH admin privileges (or indeed, running anything with admin permissions).

Running a random program downloaded off the internet, of course, is potentially dangerous - even if it doesn't require admin.

If your ISSO's concern is "you're running random internet code, and the author of that code makes it easy for you to be lazy about asking me to vet it", then this is quite valid and factual. (you might debate the cost/benefit, but it is valid)

If the concern is "this installer is more dangerous than other installers or no-install programs because it doesn't escalate its access level", then no, this is factually incorrect.


Yes, it is more or less consubstantial to the Web of Trust in OpenPGP. In the Web of Trust, you can validate a public key by building a chain of public keys, each signed by the previous public key, from a key you trust (yours) down to the key to verify. This works only as long as you can recover such a chain, mostly by interrogating key servers. In fact, since the WoT is an "everybody is a certification authority" system, you should build several such chains, with no common link, so that all these redundant proofs add up into some decent level of trust in the target public key.

One way to see that is the following: by signing the key of somebody else, you vouch for the link between the identity and the key of that somebody else. You announce to the World at large: yes, this is his key, I verified it. It makes little sense to make such an announcement... without actually making the announcement. By definition, key signing is meant to be public.

PGP's Web of Trust is indeed at odds with privacy. Although "PGP" stands for "Pretty Good Privacy", PGP's Web of Trust was never meant to hide the existence of the relationship between people.See p. 90, "Avoiding the Web of Trust," of PGP & GPG: Email for the Practical Paranoid by Michael W. Lucas.


source code of metasploit payloads(shellcodes)

The source code of Metasploit shellcode can be found in the directory external/source/shellcode/windows/x86/ folder. Depending upon the type of shellcode, the asm file is placed in separate sub folders. For example, the source code for the shellcode windows/shell_bind_tcp is at the location:

source/shellcode/windows/x86/src/single/single_shell_bind_tcp.asm

If you look at the conents of the file, it refers to other files which are included in the main shell_bind_tcp.asm source file. The first file included in the shell_bind_tcp.asm file is the block_api.asm file where the main logic of setting up the environment for executing the shellcode. The line of include look like:

%include "./src/block/block_api.asm"

The next block included is that of block_tcp which setup up the TCP transport, then the logic of ExitFunction through (ironically) exit_funk.asm.

Take a look at Modifying Metasploit's Stager Shellcode blog post from Raphael Mudge on how to edit and then compile the modified shellcode. The source files of the shellcode are documented so you can easily follow what is going on in the Assembly instructions.


There will be a cronjob which runs logrotate daily as root, you can check the configuration in /etc/logrotate.conf and /etc/logrotate.d/*. If you make any changes you should run /usr/sbin/logrotate -dv /etc/logrotate.conf to make sure there are no errors in the new configuration.

In addition to auth.log you should also rotate and keep wtmp and btmp (the second one tracks failed login attempts), most systems will keep just one rotation of those.

The normal setup is that /var/log/ is not word-writeable, log files within are also not world-writeable, and sometimes not world-readable (the latter for files like auth.log which may accidentally contain passwords entered into username fields, CWE-532).

You should check the file permissions are as expected, it's the job of logrotate to create new log files and set the correct owner/permissions (see the create directive). However, the default is to apply the permissions and ownership of the current file: if owner/permissions are changed once, those will be maintained on every new instance of that log file (so a previous mistake can come back to haunt you).

Even though a normal user cannot write to or directly modify those files, a local user can probably append to them indirectly via syslog:

logger -p auth.info -it sshd \
  "Accepted password for root from host.badguys.com port 31337 ssh2"

(The situation is worse if you accept syslog messages via UDP over the network, but that's not usually enabled by default in any sane configuration.)
This is an example of CWE-117, and shows one of a number of problems with syslog.

A different method must be used to actually overwrite or delete data if a login is acquired by an attacker (or untrusted user), e.g. privilege escalation, or creative use of setuid/setgid programs.

But, there is opportunity for denial-of-service type attacks here. If you don't have some form of rate-limiting or lockout on sshd, an attacker may be able to flood your logs with connection logging (and if he breaks in, may be able to cover his tracks with forged entries). If logrotate is using size-based rotation (not default) he may be able to rotate telltale entries out of existence, with no extra privileges. If you use time-based rotation, he may be able to trivially fill the filesystem you are logging to, and prevent further events being logged.

To summarise:

if the log file permissions are wrong, yes an attacker could remove telltale log file entries
(if an attacker can leverage some other local privilege escalation, he can do this anyway of course, but then you have a bigger problem)
you should check the log file permissions are to your satisfaction, e.g. not world-writeable, and possibly not world-readable — most configurations do not hard-code paranoid permissions in the logrotate.conf
standard syslog has a number of problems, including authenticity, integrity and rate-limiting
consider using /etc/hosts.allow to whitelist your remote IP blocks for sshd access, if possible, it's a reasonable mitigation measure
you should use some type of dynamic blocking (on a Pi you might look at Micro Fail2Ban)

One of the best ways to limit what an attacker can do to your log files is to log them to a different system over a secure network. Other possible solutions include append-only files enforced by the OS (see this on Unix & Linux.SE), this is tamper-resistant.

You can also read about improvements to *nix logging in the rsyslog maintainer's blog. One of the features discussed there is linked-timestamping, which is tamper-evident.


Precondition for Session Fixation via XSS

The precondition is as you mentioned that the session id does not change on login, as otherwise session fixation does not work.

Additionally, the session cookie must either not be httpOnly (as you couldn't overwrite it from JavaScript) or not exist yet (ie the user is not currently logged in).

Alternative Attacks

Why would you want to perform session fixation via XSS? For it to work, the victim must enter their login credentials so that the fixated session id is associated with their account.

You could just as well read out the entered password. Now you have full access to the application (not just temporary access), session restrictions do not apply (bound to IP or useragent for example), and it doesn't matter if the session id is regenerated on login.


As long as the user is not a local administrator on the machine they should not have permission to kill any processes run as other users (including domain administrators).

However unless you have an unusual physical setup the user can always kill the process with the power button or physically removing the power supply.

I would suggest additionally your process reports back success on completion. Any machines not confirming success could have the process redeployed and on multiple failures an engineer sent out.


How does this AppLocker bypass work, exactly? ("Squibblydoo")

Brief introduction to COM
COM is a Microsoft standard for the binary layout of objects in memory.
This standard is independent of the programming language used though is similar to the well-known C++ virtual dispatching through the vtables.
Basically, COM consists of objects and interfaces.
Object are abstract entities, they are a collection of interfaces.
Interfaces are identified by an UUID (known as CLSID) and optionally a more user friendly Program ID (ProgID).
An interface consists of a set of methods and an eventual parent interface.
A programmer never uses objects, only interfaces. They have to somehow get a pointer to an interface and invoke its methods.
At the low level, an interface pointer is just a pointer to a vtable.
If the programmer already have a pointer to any interface of an object, it can get any other interface of the same object because all interfaces inherit from IUnknown that exposes a QueryInterface method.
However to get the first interface a side band mechanism is needed.
Particularly, the module where the object (interfaces) implementations reside must be loaded in the calling process address space (if it's an in-process server) or must be started and an IPC/Network channel established (if it's an out-of-process server).
All the work is handled by the CoGetClassObject API that given a CLSID will do all the hard work and return a pointer to the given interface (eventually through an in-process proxy).
Brief introduction to COM server registration
For CoGetClassObject to work it need to find the type of server and the associated module (DLL or EXE) from a CLSID or a ProgID.
This information is stored in the registry (Under HKCR and HKCR\CLSID), when missing a COM client will fail to invoke methods on the server.
It's the responsibility of the server module to create the right keys. Microsoft developed a convention (or it's a standard?) so that a programmer didn't need to conceive their self with the registration burden: A module will export DllRegisterServer and DllUnregisterServer and the installation wizard will call them for each COM component (EXE module may use different names, I don't remember).
The tools performing the registration is regsvr32.exe, when given the path of a COM module it will load the module and call one of those functions.
Optionally a module can export (DllInstall) which is used to perform additional installation steps besides the pure COM registration.
This function accepts a boolean parameter to tell installation from uninstallation (note: there is no DllUninstall, the doc is wrong) and a string denoted as the "command line".
The implementation is free to use it however it wants.
When used with /i regsvr32 will call DllRegisterServer and then DllInstall with the given command line.
If /n is also passed, DllRegisterServer is not called (which implies that /n alone is not valid).
If /i is not given DllInstall won't be called.
If /u is used, the uninstall path is taken (DllUnregisterServer and DllInstall with FALSE).
/s is for not showing message boxes.
Brief introduction to COM Scriptlet
Writing COM components is easy if you use VB6 or VC++ or Delphi but otherwise is painful.
To enable scripting languages to write COM component Micosoft introduced a new format for the COM server: the COM Scriptlets.
They are XML files with the source code and a bit of metadata.
<?XML version="1.0" ?>
<scriptlet validate="true" error="true" debug="true">
   <registration
    description="XXX"
    progid="YYY"
    version="1.00"
    classid="ZZZZ"
   >
   </registration>

The metadata are just the ProgID, the CLSID and a description plus a version.
A full example is here.
The code inside the registration tag is executed as part of the server registration, unregistration process.
<registration
    ...
    >

    <script language="JScript">
        <![CDATA[

            ...

        ]]>
    </script>
</registration>

The scriptlet can (must?) also declare the methods of its COM interface.
The srcobj.dll
I don't know what srcobj.dll is used for in Windows.
I just fired up IDA and retrieved the DLL's debug symbols to see what's going on.
First, the DLL exports all the COM registration methods:

The DllInstall method, regardless of the bInstall parameter, will load the scriptlet given in the command line argument calling RegisterScriptlet

RegisterScriptlet will in turn create a ComScriptletSite object to get a ComScriptletConstructor to invoke LoadFromPath:

The chain of call is a bit deep from here, it goes like this: LoadFromInput > ...  > CompileScriptlet > ... > CompileRegistration.
Later the scriptlet registration code is executed as part of its initialisation.
The bypass
The net effect of loading a scriptlet is that some script code is executed in the context of regsvr32.exe (as part of the registration phase).
As regsvr32.exe is a trusted (signed?) executable, this bypass the Windows restriction on allowed executables (AppLocker).


What is the difference between https://google.com and https://encrypted.google.com?

According to Google, the difference is with handling referrer information when clicking on an ad.

After a note from AviD and with the help of Xander we conducted some tests and here are the results

1. Clicking on an ad:

https://google.com : Google will take you to an HTTP redirection page where they'd append your search query to the referrer information.
https://encrypted.google.com : If the advertiser uses HTTP, Google will not let the advertiser know about your query. If the advertiser uses HTTPS, they will receive the referrer information normally (including your search query).

2. Clicking on a normal search result:

https://google.com : If the website uses HTTP, Google will take you to an HTTP redirection page and will not append your search query to the referrer information. They'll only tell the website that you're coming from Google. If it uses HTTPS, it will receive referrer information normally.
https://encrypted.google.com : If the website you click in the results uses HTTP, it will have no idea where you're coming from or what your search query is. If it uses HTTPS, it will receive referrer information normally.

The same topic was covered in an EFF blog post.

EDIT: Google dropped encrypted.google.com as of April 30 2018. According to Google, this domain was used to give users a way to securely search the internet. Now, all Google products and most newer browsers, like Chrome, automatically use HTTPS connections.


Before an attacker attempts to exploit eval(), how would they suspect that it is being used by a target application?

The attacker does not directly know this but they scan the website with probes for detecting RCE / RFI / LFI vulnerabilities and inject specific code in requests and single GET / POST parameters.

When they know that the result changes depending on the supplied user input they test single parameters with different codes for different attacks.

eval() is mostly not needed and should never be used for input which can be manipulated by attackers.

This is also mentioned in the official documentation of PHP, where they warn about the risks.

http://php.net/manual/en/function.eval.phpCaution

  Caution

  The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

As web developer I have never used nor needed eval().

But this is still unrelated to JavaScript, even if there is the eval() in JavaScript, but for executing only JavaScript code.


It is impossible to answer your question, as you did not provide any additional details. There are known WAF bypass techniques, which work with certain firewalls. It also depends on the place in the query, where SQL injection occurs. Try to fingerprint your WAF.

Btw, the behavior you have described, looks like WAF reacts to the information_schema and other standard keywords in your request and drops the connection. What makes you think there is an actual SQL injection?


Cleartext data in a session cookie: which kind of vulnerability?

Yes, this information should be considered sensitive, particularly in the aggregate.  E-mail addresses are always PII, and adding date of birth, gender, and first name only makes it even more so.
It is definitely an example of CWE-315.  It may be an example of CWE-319 as well, if the cookie is ever transmitted over HTTP.  If it is only ever transmitted over HTTPS, it is not a CWE-319 issue.

I agree that regardless of whether HTTPS is required or not, this is definitely a issue that you should report them.   This is not an acceptable practice, and more so if the cookie is a persistent cookie, and not just an in-memory session cookie.


The latter (whole code to "think" about it to find the vulnerable point?) if it's white-box testing where you require expertise to go through the code and pick out vulnerabilities or even security weaknesses which could be escalated to a compromise.

If it's black-box and an attacker has to guess the source which is behind firewalls, the web application, etc.. he has to go through trial and error but obviously in the right directions (which means he should have knowledge on which part could lead to weaknesses and where he should start, e.g. entry points, parameters {if in web applications}).

Now, this doesn't mean what's the vulnerability. You have a threat agent which is obviously an attacker in this case (which you term it as a hacker), now since there is a threat agent, there has to be a weakness to exploit and hence there must be existence of a vulnerability to be able to exploit or compromise a system or a part of the system. It doesn't matter what route you take (for e.g. wireless to sniff the passwords and then compromise, or hijack session and then compromise or exploit SQL Injection to compromise databases and then extract passwords, or a buffer overflow), what it only matters to any time independent attacker is the fact that a vulnerability should exploit a system.

If it's a hacker in bad terms - he'd compromise for financial or reputation gains, if not he's merely just acting as a hacker and having his day job as a security practitioner.

Note: hacking just because you're curious is again sound-fully illegal these days according to laws of state.


How does bidirectional authentication using SSL work?

I'm assuming the threat model is that there may be a man-in-the-middle attacker between Alice and Bob, and that Alice and Bob are not on the same trusted sub-net. That's what SSL/TLS is designed to protect against, and that's why Alice should check Bob's certificate in your example (at least).

From Bob's point of view, checking that Alice's request come from a known IP address isn't of much use. Attackers could forge and alter packets to make them look like they come from the IP address they wish. Subsequently, DNS lookups are useless too: all you'd need is to make sure you forge the packets to use an IP address with the correct DNS entry.

When Bob requests a client-certificate from Alice during SSL/TLS handshake, this will also make Alice send her certificate and use her private key during the SSL/TLS handshake to assert her identity. When the handshake has completed successfully, Bob will then know that Alice has the private key for that certificate and will have to verify it trusts this certificate.

Whether or not the request comes from behind a proxy or not doesn't matter when you're using SSL/TLS. An HTTP proxy merely tunnels the SSL/TLS connection from the original client to the target server.

What matters to Bob is how he's going to verify Alice's certificate. Typically, this will be done using a PKI in the same way as Alice verified Bob's certificate, although this needs not be the same CA as Bob's (it needs to be something that Bob trusts). Note that this doesn't need to be using a PKI either. It's possible to verify the certificate against a given list (if Alice and Bob have met before, for example), but this can be a bit more complex since Bob may have to tweak the accepted issuers list it sends (e.g. send an empty one, which is explicitly allowed by TLS 1.1, but not specified either way in previous versions, see Certificate Request message) and use custom code to verify that certificate. (I've implemented this sort of scheme in the past and it works fine.)

There is an exception to this when using what I'd call "MITM proxy servers", that is proxy servers that are configured to spoof the actual SSL/TLS server by inserting their own certificate (see Squid's SSL Bump). In this case the certificate Alice sees wouldn't come from Diginotar, but from another CA (typically a corporate CA when this is done on a corporate LAN).

Although Alice might allow herself to trust such a MITM proxy, using SSL/TLS client-certificate authentication would make Bob realise there is a MITM and the connection would fail. This is because Alice is supposed to sign the entire SSL/TLS handshake (as seen by both Alice and Bob) in her CertificateVerify message to authenticate with a client-certificate. Since the MITM proxy would have replaced Bob's certificate, the signatures sent by Alice and Bob wouldn't match.


Is it safe to have an opened port on my PC with a proxy server listening?

First of all, if a port is opened it's usually because there's a service listening on that port which responds using whatever protocol it is based on.

The first question is: What kind of service responds on that port, and what protocol does it respond with?

The second question is: Are there known vulnerabilities regarding to that particular service or protocol?

When the port number is uncommon, but open, the attacker send probes on that port to match the service behind it, and in case of positive responses, he tries to find answers to the second question.
Sometimes, he can find undocumented vulnerabilities using a technique called fuzzing.

Some others, when the source code of the service protocol is opened (opensource), he can find vulns simply by reading the code.
You should query yourself on the first question and keep in mind this easy advice: Always close unnecessary services and specific ports behind them to lower the risk of attackers gaining access to your computer by exploiting bugs in the service that is listening on that port.


How safe would it be to store encrypted files on an unknown server?

In theory, no — that's essentially the entire point.

In practice this is much more difficult, but simply storing static, encrypted files on a remote machine is actually one of the less error-prone uses of cryptography. There are comparatively fewer avenues of attack than, say, encrypted session protocols or cryptosystems that manage and federate access to multiple users.

Of course, there are ways to complicate this; for instance, Tarsnap stores encrypted backups on a remote server, but uses novel cryptographic tricks to do so while performing aggressive deduplication. Once you start adding complexity like this, the possibilities of a privacy-destroying mistake increase. But if you're using something like GPG with reasonable key lengths, outside of any major breakthroughs in cryptanalysis, you can reasonably expect your data to remain private.


What factors do you use to choose data loss prevention techniques to use, if any?

As described by this talk at Confidence'09, There are some arguments against the deployment of certain DLP solutions (I realise that this is a contentious issue but these concerns should at least be evaluated).

In essence many of these solutions are in fact nothing more than legitimate rootkits. The research behind the linked talk found that one of the DLP solutions investigated was actually a modified version of a well known rootkit found on rootkit.com! This could potentially been seen as a problem for a number of reasons. One of which is that if as described by the research none of the rootkit detection solutions successfully detected any of the DLP solutions, isn’t it possible (likely?) that AV vendors (intentionally) may not detect their own (or others?) DLP solutions with their rootkit detection kits? Would it therefore be possible to modify these allowed/legitimate DLP rootkits to produce a highly covert rootkit with very little chance of detection?

There could also be room for concern over the overall security of these solutions. By collecting and distributing reams of potentially sensitive information and providing ring 0 (system) control over every end user system on the corporate environment to a management server, you're placing a hell of a lot of trust in the security of the DLP solution itself. Wouldn't an attacker go straight for the DLP solution? That is one serious single point of total failure!

It's a subjective point I know, but what about the wider implications of spying on users to this degree? I know many who would seriously resent a company taking these actions. Doesn't it eliminate any notion of trust between the individual and company? I am a pragmatist at heart and so do see the benefits of these solutions (and indeed can empathise with a CISO attempting to protect corporate interests) but for an industry that invests such energy into the promotion of privacy doesn't something just plain feel wrong about engineering solutions which so completely destroy this for the individual in the workplace?


How's an office, house or school network map?

Networking part:

There's a few types of devices in networking. At the basic level you have the host, a switch, and a router. A host would be your computer. A switch (at a basic level) allows you to talk to everyone connected to that switch. A router (again at a basic level) allows you to talk to everyone else not connected to that switch.

As for your example, your computers, the hosts, (in that room) connected to a switch. This makes it so all the computers in that room could communicate to each other if needed. That switch then would connect to a router, other rooms switches would also connect to that router. That way your room could talk to the room next door.

An example of communication. You have computer 1 and 2 in the same room and computer 3 in the room next door. If you want to communicate from computer 1 to computer 2 then the information would flow from computer 1 to the switch in the room to computer 2, because they are connected to the same switch.

If you wanted to talk to computer 3 from either computer 1 or 2 that's a bit different. Computer 1/2 cannot talk to 3 directly because it's in a different room. AKA not on the same local area network (LAN). It would be on a wide area network or a WAN. So computer 1/2 would send information to the switch into the room. From that switch it would send the information to the router. From the router it would "route" the information to the correct switch that has computer 3 connected. That switch would send the information to computer 3.

Security part:

At each layer there is some form of security. At the physical it can be said that the security is physical tampering/protecting equipment. Think behind a locked door and not exposing wiring/leaving ethernet ports open in a room.

At the data link layer you have security provided by switches which can stop the connection of non-approved layer 2 addresses, shut down ports, etc. But it also has some security in the frame itself with the cycle redundancy check which would allow it to ensure the frame is correct.

At the network layer there are too many security mechanisms to list. For your example though it would be similar to protecting the interior network (the LAN, aka each computer room) from the outside world. You would utilize a port address translation or network address translation technique to protect the interior IP addresses from exposure to the world while also allow the interior network, which is on non publicly routable (can't work on the internet) to use a publicly routable address for communication. It uses a lookup up table that maps internal addresses to the external address(es)

There are other mechanisms at the higher layers, and a bunch more at the layers i did the quick and dirty basics for, but there are books that hit that topic. entire books.

Note: I used very, very basic examples here. A LAN is any local area network, which can technically span incredible distances through use of different technologies.


If you want to be as sure as you can be, reinstalling the operation system from read only media is a good idea.


Is it dangerous to add a custom cert authority to a browser?

It is pretty dangerous. The owner of this CA can use it for man in the middle attacks or to impersonate arbitrary web sites since your browser will trust the CA to create certificates for arbitrary sites. Using such attacks he can then intercept your passwords and other sensitive data.

  For example if my friend develops a webapp with a custom cert and I add them as CA to my browser, ...

There is no need to import the certificate as CA into the browser. You can just import this specific certificate as trusted as server certificate but not as CA certificate. If you do it this way it can only be used to MITM and impersonate sites which are covered by the certificates subject/SAN.

Or you can just add an exception if the browser warns you. In this case the certificate is only treated as valid for the site you visited but not for all the other domains which might be covered by the subject/SAN.


Third party cookies - does secure, httponly matter?

The TS* cookies belong to an F5 load balancer, which also acts as a security device (especially via it's Application Security Module (ASM)).  The cookies and their various uses are described here.
I would interpret the web site describing these cookies as "Security" as meaning they're put in place and used by a security device, as opposed to the web site itself.  They are, in fact, not marked secure by default, although it is possible to add that.


How to deal with MySQL's Errcode 13 when trying to write a shell

This error is happening because MySQL does not have write privileges to this directory: /var/www/html/dvwa/.

Most modern Linux distributions use AppArmor or SELinux to isolate daemon processes.  It is likely that /var/www/ cannot be written to with MySQL.  However,  it maybe possible for MySQL to read from this directory.  This statement holds true for Ubuntu's AppArmor rule-sets at the time of this post.

I bypassed this limitation under Ubuntu by writing my PHP payload to /tmp,  and then used a Local File Include vulnerability to execute the payload.  This enabled me to write a remote code execution exploit for PHP-Nuke.


How do we mitigate the unpatched vulnerability "AtomBombing" code injection under Windows machines?

As far as I can guess (not completely sure):

  Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

First we must consider how Atom Bombing works:

It works by injecting some malicious code in the Windows Atom Tables. Atom tables are a kind of tables where any program can "save" some data strings to use later or to share with any other application.

So it gives any potential attacker the chance to use this method as a hijacking or privilege escalation vector, but not for a direct attack or intrusion.

Why? Well, unless another vulnerability/bug is used, Atom Tables can only be modified locally. That means: Only when you're already in, you can add something to the atom tables to inject malicious code.

So, there are multiple ways to exploit this vulnerability, BUT, when you're already IN (using a malicious.exe , exploiting another vulnerability to get into the system and then using Atombombing for privilege escalation, etc., etc.).

  What are the best practices to mitigate the unpatched vulnerability
  under Windows machines?

The only way for Microsoft team to patch this would be removing the Atom Tables, or adding many extra security measures.

The easiest way to defend against this kind of threat, is just checking any atom data saved before using it (on programs) and/or any security system/program/module taking a look constantly on those Atom Entries.

The way to fix this shall be by using a pìece of software that checks periodically the Atom Table entries, looking for malicious code. That's probably going to be added by some anti-malware (or antivirus) firms.

You can check those articles for more information:

To know more about the attack: http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions
To know more about the Atom Tables "API": https://msdn.microsoft.com/es-es/library/windows/desktop/ms649053(v=vs.85).aspx


extracting JSESSIONID from document.cookie

You can read the values of cookies using document.cookie or other client side solutions only if that particular cookie is not flagged as HttpOnly (assuming the browser you're using supports this flag).


In general, there's no way to vet links unless you have significant resources.  Even if you visit the site, the domain may expire and be acquired by a malware distributor who wants to benefit from the old owner's reputation.

You need to white-list protocols, e.g. only allow http, https, and mailto.  javascript: links cannot be trusted.

Besides that, you can rely on most modern browsers to include some kind of malware checking, and possibly not serve links to older browsers.

Either way, you should use nofollow to make sure that malware trackers do not conclude that these links are more reliable because your site links to them or that your site is less reliable because it links to them.


Do the skills of a software developer transfer well into working in computer security or white hat hacking?

As a developer of 15 years who has moved into a pen-test role,  I can say that yes there are many transferable skills, some of which will put you at and advantage to testers who came from a pure security background.

Firstly and foremostly you understand the developer mindset, this means that you probably understand why a developer chose a particular solution, and understand some of their thought processes.  As a developer you have a knowledge of their 'language' how they think and talk, and as such you should be able to communicate any security findings and recommendations in a manner that a developer can understand.

Secondly you probably have a much better programming base than many pen-testers, this will come in very useful for developing tools and apps to help out (really I've seen some of the hacked together tools, it's a wonder that they work at all ;)

Code Review... This is an obvious big winner, you just need to start looking for insecure patterns and insecure language idioms.

Your understanding of software development practices (agile, waterfall etc), can be quickly augmented with learning about BSIMM, SAMM, and SDL

Depending on your developer background you may have a good understanding of OS/networking innards.  I spent some time in the networking/OS world, which I found useful to inform other developers what the computer was really doing with their code.  Likewise if you have spent your time in the Web world, that's where your focus will likely be.

It's worth noting that you may feel that there are vast areas of knowledge that you are lacking, but there are no pen-testers who know it all.  You will bring your own knowledge and skills, and as long as you are prepared to learn and teach, it will be a very rewarding career move.  It also has the advantage of making your really hire-able in two fields.


Which web server is more secure, Apache, nginx or lighttpd?

The OS and web server with which you have the most experience are usually going to be the most secure.

Security depends on all of the layers, not just the web server.  If you pick one with very few vulnerabilities, but don't understand how to configure it, you will most likely not understand how to configure it securely.

They are all mature web servers, so the one you understand the best is the one you are going to be able to secure the most.


Is providing a website password over the phone any less secure than other identifying information?

I'm going to disagree with some of my colleagues and suggest that the Bank's solution is much safer than your proposed alternative. Though it's not ideal either. Let's look at each solution and it's attack profile.

Address, SSN, DOB, etc.
We should all be able to agree that these are absolutely terrible ideas. Facts make horrible passwords and should never be used. No exceptions. Literally no exceptions. If someone can research it, then you can't use it to authenticate yourself. Period. Nearly all security questions fall flat on this rule. It's embarrassing. This technique is exploited frequently, often with high-profile targets.  We should know better but we keep using it. This needs to stop.

Website Password
While not ideal, this solves the research problem. It can still be used with secure hashing since the support rep should have to type in the password verbatim to verify it rather than read it off the screen. Your potential attacks are: (a) someone listening can re-use it to impersonate you over the phone, and (b) someone listening can use it on the website. Still, if more companies did this we'd be a lot safer. We can do better, but at least you don't have to worry about someone looking up what street you grew up on or the last digits of your credit card number and then using that information to take over your account.

Call-In Pin
This is Godaddy's solution. You have a 4-digit number on your account that you must provide when you call support. It's better as it solves problem (b) above -- you can't use the call-in pin to log in to the website. But problem (a) remains. The pin doesn't change unless you reset it, so an attacker who hears your conversation can impersonate you. Besides the below, other "call in passwords" tend to fall into this category and are susceptible to "replay attacks".

One-time pass-code
This is PayPal's solution, and it's the best solution available. When you click "contact us" on your PayPal account, you're given a single-use time-limited 6-digit pass-code that you must provide over the phone. It expires after 60 minutes or after you use it once, so an eavesdropper can't impersonate you. And it's random so it can't be predicted. If you're going to implement a solution for yourself, this is the way to do it. PayPal has been doing this for many years and it's worked for them so far.

The "tell me some facts about yourself" way of authenticating over the phone, as you suggested, really shouldn't be allowed; it's a shame so many companies do this. Giving your website password over the phone is much better (to be fair, anything is better), but it presents some problems. Authenticating online and then getting a one-time secret code -- that's a solution I can respect.

Note that the fact that the bank is willing to fall-back to asking for your SSN or Address, etc., is the real scandal here. If you refuse to authenticate yourself securely, you should not be given the option to provide some facts about the victim you're trying to impersonate.