How to check that the user entered the correct password when decrypting a file?

You are doing it all wrong! But that's okay, amateur cryptography is where we all started and learned. Just be aware that your encryption software will not be secure unless you had it audited by an independent third party, and even then they make no guarantees. Do not use your own hobby crypto for anything important! And do not let others use it without making sure that they know it's just a toy!

Imagine you have a file that says "attack at 10:00". Encrypted, it is something like aWJiaWtzIGliIDEzOjAw. Your enemy might know that you are sending the attack message, but does not know the password. What they can do, though, is change a byte. If the message is changed to aWJiaWtzIGliIDazOjAw (the E is replaced by a), it suddenly says: "attack at 03:00".

As you see, modifying the ciphertext, even blindly, can be an advantage to the attacker (the enemy). You want to have authenticated encryption, where a modification is detected. This also solves your password problem.

You do not need to store the password in the file, because if they enter the wrong password, the authentication check will fail. The software will notice that the decrypted text changed from the original text, and you will know it's wrong.

There are also some more details on why you should use authenticated encryption:

Security StackExchange: Why do you need message authentication in addition to encryption?
Crypto StackExchange: Why should I use Authenticated Encryption instead of just encryption?

There are a lot of resources online on how to do authenticated encryption. Some good methods to look for are AES+HMAC, or AES in an authenticated mode such as GCM or OCB. This Wikipedia article is a good introduction and contains pointers to algorithms that you might be able to use: https://en.wikipedia.org/wiki/Authenticated_encryption

As an example, let's consider the previous ciphertext: aWJiaWtzIGliIDEzOjAw. Now we HMAC it with SHA-256, which gives us 3be635.... I used a random online site to compute the HMAC and used the same password as I used for the encryption. (As a challenge to the reader, try to break it :). It's just one character.) We can store the two together: aWJiaWtzIGliIDEzOjAw|3be635. When a user tries to decrypt the contents, they enter the password, you can compute the HMAC again, and if it does not match, you know that either the message was tampered with, or their password was incorrect.

The code for this is basically:

# Encrypt
password = user_input()
plaintext = "attack at 10:00"
ciphertext = encrypt(method = "AES-256-CTR", key = password, data = plaintext)
auth_code = hmac(method = "SHA-256", key = password, data = ciphertext
write_file(name = "encrypted", data = base64(ciphertext) + "|" + auth_code)

# Decrypt
password = user_input()
ciphertext, auth_code = read_file(name = "encrypted").split("|")
computed_auth_code = hmac(method = "SHA-256", key = password, data = ciphertext)
if computed_auth_code == auth_code:
    plaintext = decrypt(method = "AES-256-CTR", key = password, data = ciphertext)
    print(base64_decode(plaintext))

So far so good, but...

This method allows an attacker to guess a password very fast. The HMAC operation takes a few microseconds to compute, so an attacker can do many of guesses per second on a standard computer. The code is very simple:

ciphertext, auth_code = read_file(name = "encrypted").split("|")
for password in load_file("password_database.txt"):
    if auth_code == hmac(method = "SHA-256", key = password, data = ciphertext):
         print("The password is " + password)

Because the only operation in the for loop is hmac(...) and a quick comparison, it is very fast.

Before using the user's password for anything, you should apply a slow key derivation function (KDF). How to do this best is answered in the question: How to securely hash passwords?.

Your code should now look something like this:

password = user_input()
password = argon2(iterations = 1_000_000, memory = 100_000_000, data = password)
# Below here, the normal encryption/decryption code

Now, an attacker's code has to look like this:

ciphertext, auth_code = read_file(name = "encrypted").split("|")
for password in load_file("password_database.txt"):
    password = argon2(iterations = 1_000_000, memory = 100_000_000, data = password)
    if auth_code == hmac(method = "SHA-256", key = password, data = ciphertext):
         print("The password is " + password)

Now the attacker has to do this argon2 thing, which is super slow. If it takes 1 second on your computer, then it will also take roughly 1 second on their computer (maybe a little faster, maybe a little slower). This means an attacker can only do one password guess per second. That's much safer! Of course, an attacker can use 100 computers, but that's a serious investment, and they would still have only 100 guesses per second instead of millions or even billions per second.


Is it insecure to send a password in a `curl` command?

Regarding the connection there's no difference: the TLS is negotiated first and the HTTP request is secured by the TLS.

Locally this might be less secure, because:

The password gets saved to the command history (~/.bash_history) as a part of the command. Note: This can be avoided by adding a space in front of the command before running it (provided you have the setting ignorespace in variable HISTCONTROL).
On a shared system, it will usually be visible to others in ps, top and such, or by reading /proc/$pid/cmdline, for as long as the command is running.
Storing the password unsecured in a script might pose a security risk, depending on where the script itself is stored.


Possibility of undetectable encryption system

Steganography is an answer to your question. Namely, you find a medium which normally contains a bit of "noise" which should be random looking (e.g. in the least significant bits of pixels in a photograph). Then, you replace that noise with your encrypted message: if the encryption system is any good, then the encrypted message will be indistinguishable from a sequence of random bits, except by using the encryption key. This is not very easy to build and somehow prevents using public-key cryptography (too much structure...). Properly applied, you get innocent-looking data with steganographic contents which cannot be detected through statistical analysis.

Without a "random noise" channel, things become much more difficult. You can "hide" information in text through some conventions; e.g. you decide that the first word of every sentence in an email will encode a 0 if it consists of an even number of characters, a 1 otherwise. You then can write your text around that convention, and it will be innocent-looking, but the data bandwidth will be very low; if you want to increase bandwidth, then this adds constraints and will make it more difficult to make text which has some meaning and does not look contrived. There again, encryption should be applied to the data which is to be hidden, so that it is externally "random" and thus does not show up in statistical analyses.

(Proper encryption would use, e.g., AES in CTR mode, with a random IV which is included in the message.)


Is the DES "mangler" function invertible?

No, it is not invertible.  It is possible to find two 32-bit inputs that, when fed to the DES "mangler" function, both produce the same 32-bit output.  This is one of the benefits of the Feistel structure: the "mangler" function does not need to be invertible, and we still end up with an invertible block cipher.

In fact, Biham and Shamir's famous differential cryptanalysis attack on DES makes important use of this fact.  They take advantage of the fact that, when a pair of 32-bit inputs satisfy a certain relationship, then they often produce the same output after applying the "mangler" function.  This enables them to find a differential characteristic with relatively high probability, which lets them attack DES.  The differential cryptanalytic attack on DES is not really practical, but it was a tremendous advance in the science of cryptanalysis and block cipher design.

P.S. By the way, I've never heard a cryptographer call this function a "mangler" function.  I've typically heard it called a Feistel F function.  So, if you walk up to a cryptographer and ask them about the DES "mangler" function, they might give you a funny look; now you know how to talk their language.


How can I execute a XSS when a web application transforms a data from lowercase to uppercase?

You can encode the letters using ampersand and numbers (html encoding). a = &#x41; or &#x65; and so on.

JavaScript code can be encoded without using alphanumeric characters. The easiest way to do this is to check out: http://www.jsfuck.com/
This site can encode it for you.


I'm asking this because I've read somewhere the expiration date in OpenPGP is more of a notification mechanism and can be changed even after a key has expired.

OpenPGP's expiry date is generally fine, but is no security feature (considering the primary key). I discussed the expiry date in depth in Does OpenPGP key expiration add to security?.

  Are expired keys eligible default keys?

This can easily be tested by generating two keys, the first expiring next day, the other one without expiry date. faketime allows to travel into future without fiddling with your system time.

$ gpg -K
sec   1024R/644AC000 2016-07-09 [expires: 2016-07-10]
uid                  Foo Bar <foo@example.org>

sec   1024R/0457686A 2016-07-09
uid                  Batz Quix <batz@example.net>

Using the default key for signing, immediately after key creation:

$ echo foo | gpg --sign

You need a passphrase to unlock the secret key for
user: "Foo Bar <foo@example.org>"
1024-bit RSA key, ID 644AC000, created 2016-07-09

Now let's travel in time and see what happens the day after tomorrow:

$ echo foo | faketime '2 days' gpg --sign

You need a passphrase to unlock the secret key for
user: "Batz Quix <batz@example.net>"
1024-bit RSA key, ID 0457686A, created 2016-07-09

  Or should I manually set the default key in gpg.conf?

Just to be sure, I'd do so anyway: barely any effort, and better have GnuPG fail with an error message than doing "weird stuff" just because the system time was wrong or something like this. And as you're at it, use the full fingerprint -- especially short key IDs (as listed in the example output above) are insecure.


Have botnets been used as a TOR-like network?

1 You don't necesserialy need an exit node when using Tor. It has HSs. HS's can be used as C&C which can't be taken down because their addrsessing is based on crypto.

2 It is more profitable to ship TorProject's Tor with a troyan than to make own probably buggy implementation of Tor.

3 Allowing other people to use botnet allows malware owner to say "I was just using Tor".

So, some trojans are really shipped with Tor.

The problem with this approach is that AV vendors start target Tor. For example MS deleted an obsolete version of Tor from user's computers. It seems to be OK (as long as Tor is a security software, an obsolete versiion is a security risk and it is natural to expect their users to have the latest version), but it isn't : Iranian Tor users can lose an access to Tor website and become unable to download a new version because torproject website itself is blocked in Iran.


Does the NSA X-Keyscore apply for HTTPS traffic?

Feds put heat on Web firms for master encryption keys:

  If the government obtains a company's master encryption key, agents could decrypt the contents of communications intercepted through a wiretap or by invoking the potent surveillance authorities of the Foreign Intelligence Surveillance Act. Web encryption -- which often appears in a browser with a HTTPS lock icon when enabled -- uses a technique called SSL, or Secure Sockets Layer.
  "The government is definitely demanding SSL keys from providers," said one person who has responded to government attempts to obtain encryption keys. The source spoke with CNET on condition of anonymity.
  The person said that large Internet companies have resisted the requests on the grounds that they go beyond what the law permits, but voiced concern that smaller companies without well-staffed legal departments might be less willing to put up a fight. "I believe the government is beating up on the little guys," the person said. "The government's view is that anything we can think of, we can compel you to do."

How they do it? probably like this (see wikipedia):

  Room 641A is a telecommunication interception facility operated by AT&T for the U.S. National Security Agency that commenced operations in 2003 and was exposed in 2006.

and this:

  GCHQ taps fibre-optic cables for secret access to world's communications
  British spy agency collects and stores vast quantities of global email messages, Facebook posts, internet histories and calls, and shares them with NSA, latest documents from Edward Snowden reveal


Is authentication + authorization a good idea at gateway level when using microservices?

How are your microservices locked down?

If an attacker is internal or finds a weakness somewhere else within your organization and attacks your microservices are they completely segergated so only requests come through the gateway?

Do any of your microservices perform any actions that are considered more privelged that the rest? Example several services generate page content while another processed payments?

My view is you should be passing an auth token to all your services after authenticating at your gateway but this is going depend on your system threat model.


BCrypt's 72-character limit and using it as a general digest algorithm

The accepted mechanism is "don't do it".

What is bcrypt good at ? It is good at being slow. Why would you want a cryptographic function, or just any function, to be slow ? This makes sense only when the input to the function is a low-entropy secret, which means "some value which the adversary could conceivably, and realistically, explore exhaustively". Passwords are low-entropy secrets: it is well-known then when human beings are allowed to choose secret strings in the privacy of their brain, most will select "witty" passwords which are utterly weak against dictionary attacks. The only remaining defense is to enforce the use of an inherently slow hashing process, which is equivalent to sending all involved computers (and, in particular, the attacker's computers) back to the early 1980s, when 1 MHz was a very high CPU frequency.

In your case, the "secret value" is the server's secret; it should not be of low entropy (the server is a machine, not a human; it can remember long keys). If the server's secret is a low-entropy value, then you are doing it wrong.

Therefore, no need for bcrypt or any other deliberately slowed function here. What you actually want is a Message Authentication Code: you want to store some values on the client side (as a cookie), but you also want to check that you are not fed back forged values; this is a matter of integrity, and a MAC is the right tool for that. Use HMAC/SHA-256, with the "server's secret" as the MAC key (your homemade hashing of several values, including the server secret, is just a homemade MAC in disguise, so you could just do it right by reusing the standard, robust, expert-vetted solution, and that's HMAC).

Of course, once we begin to use client-side storage, it becomes tempting to store values which the client himself should not learn. To the integrity requirement, we add confidentiality. For that, we need encryption. Doing encryption properly is difficult, and combining encryption and a MAC even more. In that case, do yourself a favour: use an authenticated encryption mode, which will do it properly with minimum hassle (I recommend EAX).

By suggesting Keccak (SHA-3), you demonstrate that you are afflicted with a very common disease, which can be called the "iPhone syndrome": you crave for the newest gadget. Stop it. When dealing with security in general and cryptography in particular, this will lead only to massive suffering. In cryptography, "new" is another name for "bad".

The best kind of cryptographic algorithms is old algorithms which are still alive. There is no better criterion for security. In that sense, SHA-2 is better than SHA-3, and will remain so in the future, until a problem is found with these functions. The NIST people themselves explicitly recommend SHA-2 and deny any suggestion that SHA-3 would be better than SHA-2.


Are there technical differences which make Linux less vulnerable to virus than Windows?

There are several reasons why Windows is so heavily inflated with anti-virus products. (I am pointing to out-of-the-box (OOTB) experiences).

Windows users are, by default, local administrators, so any social engineering done on Windows can usually lead to an execution of software. Modern Linux has users set-up as low-privilege local users. It requires your password to elevate privilege.

Windows tried to simplify as many things as possible including security and looking back at its history their butchering (Windows Vista anyone?) of security controls left their user-base numb to constant false positives about software. The proverbial "Do you want to install this software? Do you REALLY want to install this software?" lead to just click-throughs or disabling UAC.

Software repositories vs standalone installs:

Linux has had software repositories forever and they provide a good mechanism for installing software. These are usually signed, approved, software being protected by companies with budgets for security following standards for security. (I know about the breaches to repositories in the past, but this is generally good). Windows users are used to pulling sources from everywhere and installing on their system, unsigned or not.

Users generally have different mindsets:

Windows is an all-purpose, all-user platform. It generally tries to solve everyone's problems and in doing so, OOTB doesn't protect the user like it should. This why Microsoft pushes so hard to force every piece of software to be signed by a "trusted signer". There's plenty of debate on this, but generally from a security standpoint this is smart; Microsoft just happens to have a track record that leaves trust to be desired.

Linux users are generally technical and the systems are usually server systems. That's why software usually comes with GPG keys and/or SHA/MD5 hash for comparison, as these are from a Linux administrator perspective, de-facto processes for installing software. I know many Linux users who ignore this, but I have yet to see a Windows administrator even think about it.

So it does go beyond market share.

Expansion:

I will address a few things from the comments (which have valid points.)

Repositories:

From an OOTB experience modern Linux distributions have pre-signed packages which are more for identifying that a package works with the distribution, but also proves a secure method for verification.

Other package management system have been discussed such as pip and npm which are independent of the distributions themselves and are servers to install specific packages for their particular programming language. It can be argued that there is no inherent way for verification on these systems. This is primary because Linux has a philosophy of programs doing one specific thing and doing it well. This is typically why multiple tools are used such as using GPG or PGP for integrity.

Script Downloads

cURL | sh has been mentioned and are truly no different than clicking on a .exe after you have downloaded the file. To point out, cURL is a CLI tool for transferring data. It can do authentication, but it doesn't do verification specifically.

UAC vs sudo

Lastly, here are a few things about these two security features.

UAC is an approval process for untrusted software installation. A user which has local administrator rights simple gets a yes or no (the behavior can be changed, but it's not default). I am still looking to see if this behavior has changed on Windows 8+, but I haven't seen anything on it.

Sudo is a fine-grained permission elevation system. By default it's essentially the same thing as UAC, but it has more ability to be configured to limit accessibility.


I think someone might be tring to hack my website. What should I do?

Welcome to the internet.

This happens all the time. The last time I checked, it took around 20 minutes after connecting a server to a public IP address which had not been used for several months before someone started attacking it.

There is nothing you should do in direct response to these attempts. There are lots of things you should do when provisioning a server on the internet - the list is far too exhaustive to go through here. And simply reiterating that here is of little benefit. You need to understand what the risks are, and implement appropriate measures to mitigate them. Applying a whole lot of configuration and additional code/software you don't understand doesn't help much with security. Your biggest security wins come from knowledge, motivation and good patching practices.

OTOH a proportionate response for a server hosting 200 photos of your cat is different from a proportionate response for a host containing millions of users personal data and providing the livelihood of hundreds of staff.

The stuff you see in your logs will be almost exclusively attacks which failed. Proactively scanning your logs for signs of successful attacks is a good idea for high value assets, but well down the list of priorities.


Safely generate a non-log file within an application server

It depends on "safely". If you want to avoid read or write access from other users of the same machine, then you should rely on the access rights provided by the operating system (if the OS is hostile, then you already lost). On Unix-like systems, use the mkstemp() function, but take care to use an OS where the access rights are set sanely. E.g., with Linux, mkstemp() does things correctly beginning with glibc-2.07, but previous versions made the file readable and writeable by all users on the machine, which was inconvenient (the problem could be mitigated by doing a fchmod() immediately afterwards, but this was still vulnerable to a race condition).


Why does OAuth2 demand client credentials in an authorization header?

One possible reason is that the request parameters are generally available to the web application, whereas depending on the platform the password used for basic authentication may be removed by the HTTP server from the HTTP sever variables set to prevent it being available to semi-trusted applications.


Can someone bruteforce my OSX? (Macbook)

Sure, John the Ripper for example and other tools can crack the passwords.

Always choose a secure and random password.

Bruteforcing applies to any OS.

You can encrypt partitions and complete disks.

Without any secure encryption anyone can read the data from the disk with the right tools. There are great opensource IT forensic tools available.

There are also known bruteforce attacks on the EFI PIN and iCloud lock used for locking the device.


Eliminating the password in favour of SMS and app based authentication

Sms or authenticator based login can provide a better security in the sense that you negate lots of attacks like dictionary and brute force. It is not a fail-safe mechanism though.

There are some problems that are caused when you use just sms or app based systems:

If you lose your phone, you can't login till you get a new sim at the very least.
If you lose your phone and is found my some malicious person, it is very likely that your email would be synced on your phone. They can try to login to your website and both email(one of your alternatives) and sms based tokens will be available to the attacker.

As you already mentioned in your question, 2 factor is better than this. If you had to use a single factor, choosing one that is always guaranteed to be known to the user would be better.

EDIT: There was a comment about device encryption and passcodes to protect the system. Majority of Android phones that I have seen use patterns which are not very secure as mentioned on Android SE . Also, whether to use this technique eventually depends on your threat model and assumptions on user's level of maturity. If the users of your app are expected to keep their devices safe, then great otherwise it's a risk.

Opinion: I agree that if they lose their phone, you can have a forgot password kind of prompt but that is still not good enough according to me.


Self signed certificate secure when just client sends sensitive information?

As long as all clients verify the fingerprint of the self-signed certificate (and you gave them the correct fingerprint through another way, like having a special application which has this fingerprint pinned, e.g. not the usual browser) it is secure.

Which effectively means: as long as the user is is using a normal browser, does not know the fingerprint of your self-signed certificate ore clicks through warnings anyway, it will not be secure, because the user is not able to distinguish your certificate from any other certificate of say a man-in-the-middle. This is like trusting any sheet of paper which claims to be an ID issued by a state.


The Tor client ships with a hard-coded list of "directory authorities": servers that maintain a list of known Tor nodes.  On startup and at intervals afterwards, your client connects to them to get a copy of this list.

Once your client has the list, it builds the circuits itself, selecting entry, middle, and exit nodes more or less at random.  From a theoretical security perspective, it doesn't really matter if some of these nodes are evil, as long as you don't get both an entry node and an exit node controlled by the same evil person: an entry node knows who you are but not what you're doing, an exit node knows what you're doing but not who you are, and a middle node knows nothing.

That said, there are a number of evil exit nodes out there.  The more obvious sort injects advertising, malware, or other modifications into the traffic, but the Tor community is generally fairly good about spotting and removing these.  More worrying is an unknown number of exit nodes that silently record or otherwise monitor traffic passing through them: if that traffic contains readable identifying information (say, an email address), the exit node now knows both your identity and your activities.  This is why you should only use encrypted communication methods (eg. HTTPS) over Tor.

If you've got more questions about the details of how Tor works, there's a dedicated StackExchange site for it.


Can I HMAC my plaintext for use as a NACL SecretBox nonce?

It is one of the options to choose a nonce. Using all of the messages than hash it ( or HMAC that will require a key). Note that in this case the same message will have the same nonce and therefore the observer will notice that.
Keep in mind that it will still have collisions, too, but those are not likely to occur. If you use SHA256 (or HMAC-SHA256) you need to trim the output to 24 bytes since the nonce size is 24 bytes. If we assume the output is evenly distributed than you will hit the same nonce in approximately O(2^96) messages with 50% probability.
Using all of the message is similar to SIV mode (SIV stands for “Synthetic IV”). In the future we will see more about the AES-GCM-SIV. SIV mode actually a nonce misuse-resistant authenticated encryption.
Another bad side of using all of the message is the performance. One has to read all of the message than encrypt. In other words, there is a double pass over the message. This is considerable especially the messages are big.
There are other options;

Random nonce: This require a good random number generator and there may not be possible for every place. So we dismiss this case. Note that the 24-byte random have negligible chance of colliding.

Use counter or LFSR and This is advised in NIST Special Publication 800-38D. This will make sure that a nonce is never occurs with the same key again. For each encryption increment the nonce ( or advance the LFSR). There is one problematic case for this once. During the system failures the current stage of the counter/LFSR may not be stored properly and this can cause the nonce usage. A mitigate is simply negotiate a new key.
This is also has a drawback; it can giving away
traffic information and that is costly for an attacker to collect this information.

Combining the random and counter/LFSR: if we split the nonce like 12-12 bytes and select the first 12 byte by random and use 12 bytes with counter/LFSR than we can also mitigate the system failure without changing the key. This still require a good random number generator. In this way, one can use the same key for 2^96 times.

If the performance is not issue you can use hashing the message while keeping in mind that the same message will have the same nonce. This is more common than it seem, considering forwarding a picture to the different people.
If the performance is the issue, the combining mode will be the choice.


How do I add application level encryption to an Android BLE connection?

First, a word of advice: StackExchange is not for recommending specific products, so I'm going to be relatively general here. Whoever reads this in the future may be in a world where there are new and much better alternatives, or even where the old guard has been found to be broken.
There are several high-level crypto libraries that - given a pre-shared key - will handle message or possibly stream encryption (and related security requirements such as data integrity) with a minimum of effort. Simply searching for "easy crypto library" will find you some candidates. Note that lots of people ignore the advice against rolling your own crypto, and some of them publish it, so you do want to make sure the library you pick is well-reviewed by experts, ideally unrelated to its development.
You'll also want to consider what exactly you want (and need) from your library. Does it need to support arbitrary-length encrypted streams (or very large messages that don't easily fit in memory), or will a simple message-based protocol work? Must the library be very small, in install footprint or RAM usage? Very fast, on a particular CPU? Compatible with any particular other library? Use specific ciphers or other primitives for compliance reasons (I hope not)? Available in a particular language?

For a few well-regarded examples as of mid-2020, consider LibSodium or Monocypher. Both are well-regarded, reviewed, and focused on ease of use. Other alternatives are NaCl, LibHydrogen, and so on. Note that not all of these focus equally on security, speed, or convenience; for example, TweetNaCl emphasizes minimal code size, sacrificing a lot of speed and potentially some security in the process, compared to the original NaCl.


Does user need to keep updated with the certificates locally when using TLS with smtp?

I see GTS CA 1O1 valid until Dec 15, 2021. So by Dec 15, 2021, I should regenerate the local crt file by openssl x509 -inform DER -in GTS1O1.crt -outform PEM -out gmail-smtp.crt

If google at any point changes their certificate, and you statically trust only a single certificate, you will have to refresh it, yes.

The proper way to do this would probably be to use your OS' set of trusted certificates.  On Debian they're by default located in /etc/ssl/certs, and google uses certificates that's trusted by almost all operating systems. This would avoid any manual work on your part, but reduce security slightly. The guide you follow tells you how to do this:

tls_trust_file /etc/ssl/certs/ca-certificates.crt

This will make it trust all certificates that your distribution (Ubuntu) includes as trusted.

I would suspect that you have no guarantee that google will return identical certificates on all connections, nor that they won't change them well ahead of expiry time.


Restriction to ui panel on BeEF+Bettercap generates error login

Finally they solved the problem. It was a bug on bettercap's side:

https://github.com/evilsocket/bettercap/issues/356


Does compiling from sources "kinda" protects from buffer overflow attacks?

It is mostly untrue. Using a compiler of a different version than the one used for the "mainstream" binary, or using it with different compilation flags, may result in a few things ordered differently, but chances are that most of the code elements will appear in the same order. Insofar as it changes anything with regards to buffer overflow leveraging, recompiling things may ease things for the attacker in exactly the same way that it may make things more difficult.

Most buffer overflow leveraging consists in trampling a code address (e.g. return address of a function, on the stack, or a function pointer somewhere, in particular in vtables for objects in C++) so that the attacker forces execution to go where he wishes to. Traditionally, the attacker tried to make execution jump to the data he just filled the buffer with, but non-executable stacks and more generally the so-called W^X model prevent that from succeeding: the data will not be interpreted as code. So the attacker now targets the C library (or a similar system library, depending on the OS), which contains nice functions to execute other files, e.g. a shell. This entails guessing where the said nice function is in memory. Bottom-line: if you want recompiling to have any effect on that, then you must recompile the C library, not the application.

Address space layout randomization is just a generic way for making the address of a function unguessable. It is much more thorough than recompiling (even assuming that recompiling really swaps things around, which it does not) because address space layout randomization is randomized again at each execution. In particular, an attacker will not gain any insight on the target function address by getting a copy of the executable file, because that address has not been decided yet.

Yet address space layout randomization is not a silver bullet since it must operate under severe constraint: it cannot put the library just anywhere because of alignment (usually, the loading address must be a multiple of 4 kB) and fragmentation issues (a 2 GB address space -- on a 32-bit system -- is too small to allow scattering libraries everywhere; this would artificially prevent allocation of big memory blocks).

(Also, a "silver bullet" is a way to kill werewolves. It is an "ideal solution" only if your idea of medicine is shooting patients.)

An a buffer overflow is a bug. If the attacker can make your application overwrite parts of its data with bytes chosen by the attacker, in a silent way, then there is no a priori limit on the damage the attacker can do. That's the reason why languages like Java were invented: at least, with Java, on a buffer overflow, you get an immediate thread crash, not a silent data corruption.


How can I protect myself from someone taking over my mobile phone number?

As a 'consumer', you can get a HackRF One, and run OpenBTS on your PC. You can make your own low-power IMSI-catcher, but more interestingly you can view most of the physical layer stuff of mobile networks. You can view the signal strength of towers and peers. You can make your PC beep if some parameters change. OpenBTS is very well-documented. Don't worry too much though, just assume pwnage and act accordingly.

Use OpenVPN/Opera VPN, and additionally use Wire/WhatsApp/Signal/Facetime/iMessage/etc for calls and messaging, don't use normal SMS and voicecalls. You can't stop IMSI-catchers with off-the-shelf phones anyway, and one individual with a HackRF can snoop on your old-world calls and texts, after downgrading you to 2G/GSM. Who you gonna call?


Yes, but only if the other side can reliable detect if that certificate/pubkey is actually in use or if it has been replaced by a different one. (And if the private key is kept safe.)


What does this attack string do? How do I mitigate it?

I don't know what he is trying to do but returning 400 is fine. It stands for "Bad Request" so you server did not process the request further. You don't need to do anything as this request did just nothing.


Security of Windows Processes using "RunAs A Different User"

There is so many variables to this question with that been said but I'll provide an few scenarios.

Scenario 1:
User machine has been infected by an "virus.exe" which is executing under the user context "TokinRing" which is not an administrator account. You've decided to run an application "cool.exe" as an administrator account. Default windows security for "virus.exe" will not prevent to use any APIs such as OpenProcess, SendMessage and so on against "cool.exe" since it's executing under higher permissions.

However, if "cool.exe" is using is vunerable to buffer overflow which can be influenced by non-administrative account. So, let's say "cool.exe" reads an file which any user can write to. If "virus.exe" creates an file to cause buffer overflow and execute shellcode to do whatever under an higher permission process.

Scenario 2:
User machine has been infected by an "virus.exe" which is executing under the administrator/system context this virus can execute in any any process in the system and could impersonate any local user.

If you could make your question more specific I'd gladly give you much more indepth answer.


Does PCI-required WiFi testing apply to all company facilities?

I agree with Jonah B but I would make sure that there were no devices within the facility that either have the ability to administer any devices in the CDE (authentiation servers) or have access to those devices (jump boxes).

If the provisions for satisfying Req. 11.1 elsewhere are not going to apply to a facility, then all of the devices within that facility have to be out of scope.

We're looking for rogue APs. When is that ever not a good idea? If I have no data flows there that affect storage, processing, or trasmission, you're good - the devices are out of scope. I'm curious why rogue APs would be tolerated, but you're good.


Usually the mechanism is matching IMEI with the phone number.
However GSM networks, which use a SIM card embedded with the phone number, don't have such a matching mechanism. So you can use the SIM card on different phones, thus phone numbers are not fixed on devices.

Here's a Wikipedia article to explain that.
But, this subject is not relevant to cryptography.

Authentication itself is, of course, achieved by a simple cryptographic function using an authentication key.
This article explains it a bit.


I found it difficult to understand the exact architecture of your network, so im trying to give somewhat a generic answer for your problem:

To make sure if you are being attacked or not, run the arp -a command from one of your computers while ESET alarms you.
This command will dump all the ARP records of the computer to the screen. Check against the other machines if their MAC addresses are correct (specially against the router, or the other computer in the ptp connection). Do this in windows using the command ipconfig /all and in *nix systems using the command ifconfig. If so, there is no risk of ARP spoofing attack, or ESET succeeded in stopping it.

If you want to understand the source of ESETs notification try running Wireshark and write arp in the filter box at the top. Show the result to any IT pro and ask him if he/she find it suspicious or not, they should know...


How is Facebook determining my location when I don't have the app installed?

Here's a couple of channels that may leak your location:

friends tagging you in photos
friends being in the same place as you (facebook finds friend groups, so if one of your friends is at bowling then FB may just try to advertise bowling to the whole friend group)
other sites may have "share with facebook" buttons which report your current ip to facebook

You can test these hypothesis by:

not appearing in photos
going out to somewhere non-typical alone
not opening internet while being outside

Man, hiding from social networks is hard :(


Firewall says that a program that I'm developing is trying to connect to the Internet

A couple questions first:

what do you mean by "the same big internet company"?
Is it MyProgram.exe or MyProgram.vshost.exe trying to connect?
What happens when you run the application in release mode without the debugger?

It could be that the Visual Studio debugger is trying to download debug files for CLR assemblies and the firewall is mistaking the request as coming from your app instead of the debugger hosting your app.


You should look not into IDS technologies but Database Activity Monitoring (& Prevention).  DAM(P) software shims itself in to watch all SQL queries and results and uses a combination of generic rules and guided knowledge to detect and in some cases prevent inappropriate use.

An IDS will catch SQL injection, which is more specifically aimed at web applications (and impacts databases as an end-state).  It generally won't have any rules specific to normal database operations.


SELinux Privilege Escalation Metasploit Nexus 5 Android 5.0.1 LRX22C after Stagefright

Use Dirtycow kernel vulnerability. I guess with the downgrade you did, the kernel is vulnerable to it.

You can use it on android kernels too: Dirty Cow Android PoC.

A video example about it: https://www.youtube.com/watch?v=4xdMteqm994

Once inside the device, you can download via wget or however the exploit and compile it to gain root. Check your kernel to see if vulnerable, I guess it is.


How to prevent a hosting company from accessing a VM's encryption keys?

You can't, plain and simple. If you don't trust the hosting company, you don't host with them. This is law #3 from 10 immutable law of security:

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

The hypervisor always have privileged position over your virtualised machine, you can't protect yourself from rogue hypervisor.

One way you can do to benefit from their network location but still keeping your code secure is to do a colocation hosting. In a colocation hosting, you bring your own machine that you put in someone else's datacenter.

Basic colocation itself should discourage most opportunistic attackers, but a targeted/determined attacker might connect into your machine anyway. If this is a concern for you, you should put your machine in a tamper-evident/tamper-proof server casing, so that the only unlocked port to the outside world is the power cable and network cable, and you encrypt all network traffic going into/out of the machine. This way you can put your machine in their network and benefit from the network's low latency, and they won't be able to steal data from your server unless they break the server's chassis.

If protecting your data is very important, you would also want to do a regular audit that the case hasn't been tampered with. If you have infinite budget, it may also be possible to design tamper proof chassis that have various sensors that can raise an alarm and initiate shutdown (discarding all sensitive/encryption keys) if they detect that the chassis had been tampered with, but of course these gets expensive really quickly.


Unable to See Network Clients during Deauth Capture Issue

If all the tools are failing... the most probably answer is that the problem is not related to the tools. Probably you have some problem on your driver or on your OS installation.
In theory, the chipset you have is able to be set in monitor mode, capture handshakes, etc... at least on airgeddon. Check the "whitelist" of the fully working cards: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/Cards%20and%20Chipsets


how does AES encryption's algorithm actually work?

There is a nice explanation there, as a comic strip. It is probably as clear and simple as these things can ever get.

If you are more mathematically inclined, you can read the FIPS-197 standard which is quite readable for a standard; but it helps a lot to have some non-negligible background in algebra (especially finite fields of characteristic 2, and vector space).

AES-128, AES-192 and AES-256 are similar algorithms, but with distinct numbers of rounds. AES is described as a sequence of elementary operations called rounds; rounds are (mostly) identical except that they use distinct subkeys (extracted from the main encryption key), and they are successive (each round takes as input the output of the previous round). AES-128 has 10 rounds, AES-192 has 12 rounds, and AES-256 has 14 rounds. The computation of subkeys, called the key schedule or the key expansion, also differs a bit between the three variants: with a larger key, the key schedule must work over, indeed, a larger key, and must also output more subkeys since there are more rounds to feed.


Why are signatures considered a valid authentication method?

Why are signatures considered valid methods if identification when paying with a check or credit card?

Historically, we didn't have anything better. In theory, signatures are very good authentication methods, since hand musculature is relatively unique and it's quite difficult to forge someone's signature accurately without a lot of analysis and practice.

However, in practice, the people who check these signatures work in high-street stores. They aren't security people - they just want to process your order as quickly as possible and move onto the next customer. As such, even if your signature is only vaguely reminiscent of the one on the card, they will likely accept it.

On the plus side, many stores do store the stub with your signature on it, or send the stubs off to the bank for archiving. This means that you can go back and look at the receipt later if fraud is claimed.

Is this acceptable? From a security perspective, it isn't. It's not very strong, and in practice can easily be exploited. From a business and cost perspective, it's good enough and saves them a lot of money in terms of buying new equipment. The cost of fraud to the retailers is less than the cost of rolling out a better system, so they don't do it.

  For that matter, what do those credit card readers do with my signature when I sign them? Are they validated or compared to my signature stored at the DMV?

I can't say I've had any experience of the DMV, but I've used similar systems at the bank. From what I can tell, they display the signature on-screen for the cashier, with some kind of overlay of the stored signature. It looks like it tries to point-match the two for a better idea of whether or not it is genuine. Arguably it could be defeated, but it does seem to be a better solution than a purely human validation. Of course, I'm also relatively sure that the cashier could accept or reject the signature regardless of what the computer shows - it's simply a visual aid.

One thing I have seen done, which does increase the strength of a signature as an authentication method, is directional matching. When you write your signature down, you do so in a very precise order. The direction of the loops and changes in acceleration / deceleration as you write are very difficult to forge. Observing a signature on paper and attempting to forge the way in which it was written is much harder than just forging the final product.

  Extra points for people who can point to ways that companies are trying to better validate that I am actually authorizing payment for something.

Most countries (especially in Europe) now use chip + pin, which is significantly more secure and, as a bonus, much more eco-friendly! Less pens, less paper, less waste. I'm personally surprised that it's taking so long for the USA to adopt it.

Another new technology that has come out recently is contactless payments, which a few banks have adopted in the UK. It's a balance between the security of chip + pin, and the convenience of just using your card without any authentication. Essentially the card contains a small NFC radio, and you can make payments of up to £10 without entering your pin just by holding them against a payment system. There is usually a limit of 3 transactions before you have to enter your pin again.


Exploiting an Open Redirect in POST body?

Usually you would need to have this in a GET for it to be exploitable (in the sense of being able to redirect the user to an arbitrary URL after they've visited the link), however a couple of points occur about this

It might be possible to convert the POST to a GET and still have it process correctly, depends on the server-side logic.
That form may well have another issue which is that the target of the main is specified as a parameter.  If an attacker can modify that parameter then they can use this form to send spam to arbitrary addresses.  From a security standpoint the mail_to parameter should be held server-side not sent from the client (if it has to be sent from the client it should be white-list validated before the e-mail is actually sent)


Is logging into SSH with a 2048 bit SSH password less secure than logging in with a a 2048 bit private key?

Theoretically, brute forcing a 2048 bit password (with proper entropy) should be exactly as difficult as brute forcing a 2048 bit private key, correct?

Not quite. A 2048-bit RSA key only have 112-bit effective entropy (explanation).

An SSH public key is safer than a password because in the case that an attacker manage to take over your server, they would be able to capture your password. If you reuse the same password anywhere, they'd be able to login to those machines with the captured password.

With SSH key, an attacker that compromised your server can't go anywhere else.

There's also a slight advantage that once you kick the intruder out, you won't need to change your SSH key. You couldn't lock out the intruder without changing your password.


Api authorization basic concepts in detail

http://en.wikipedia.org/wiki/OAuth

http://en.wikipedia.org/wiki/OpenID

OAuth is an open standard to authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. The client then uses the access token to access the protected resources hosted by the resource server.[1] OAuth is commonly used as a way for web surfers to log into third party web sites using their Google, Facebook or Twitter accounts, without worrying about their access credentials being compromised.[2]

OAuth is a service that is complementary to, and therefore distinct from, OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard.


proxy traffic coming from outside server

How do you route traffic coming from an outside server?

As far as HTTP goes, the Client initiates the connections. So your computer will first connect to this proxy and then the proxy will send that request to the Web Server. This also means that the Web Server will respond back to the Proxy and the proxy will then forward that response back to your computer.

But if you want to Route all of your traffic through a particular device, then you are looking at a Router/Firewall at that point and not just a Proxy.

  The server (the infected machine) is going to send the packets to my home computer. What if I want it to send it to a proxy first and then to me?

If you are worried about Viruses and Malware an Anti virus/ firewall will do. some even come with a builtin Proxy. here is one such opensource product.

  you can rent a server and configure that server to redirect all the traffic to you but wouldn't that server be directly connected to you?

Yes and No

Yes - because your computer is establishing a TCP Connection with this Server(proxy).

No - Because there are Proxy Service Providers out there, who may host their server(proxy) outside the jurisdiction specific to you.

In many cases, the traffic can be traced back to you. Also TOR doesn't protect you from an infected Web Server.


Prevent MITM between custom phone app and local server

Won't WPA+802.1X solve this?

AFAIK, this means that no client can sniff the others' packets. I'd recommend that you double-check this before moving forward, but that's what I've understood from some brief re-reading (I haven't used 802.1X in years).


How do traffic correlation attacks against Tor users work?

This is called an end-to-end confirmation attack.

The idea is  simple: Instead of attempting to decrypt the content of packets, an attacker who manages to observe both ends of the communication channel tries to find patterns in the traffic to match outgoing and incoming data in order to deanonymize users. This can be done by correlating the volume of transmitted data or by comparing the times at which packets are transmitted. For example, a user streaming a video exposes another pattern in terms of timing and traffic volume than someone browsing a website.

Correlation attacks are a hard-to-solve problem in low-latency anonymity networks like Tor and the Tor Project explicitly stated in a blog post that they don't protect against these attacks by design:

  The Tor design doesn't try to protect against an attacker who can see or measure both traffic going into the Tor network and also traffic coming out of the Tor network.
  [...]

  The way we generally explain it is that Tor tries to protect against traffic analysis, where an attacker tries to learn whom to investigate, but Tor can't protect against traffic confirmation (also known as end-to-end correlation), where an attacker tries to confirm a hypothesis by monitoring the right locations in the network and then doing the math.

There's quite a lot of research suggesting that correlation attacks are still a major threat to Tor users. For example, this paper from 2013 analyzed realistic correlation attack scenarios, concluding:

  The  results  show  that  Tor  faces  even  greater  risks  from  traffic correlation than previous studies suggested.  An adversary that
  provides  no more  bandwidth  than some  volunteers do  today  can
  deanonymize any given user within three months of regular Tor use
  with over 50% probability and within six months with over 80%
  probability.

The thesis "Defending End-to-End Confirmation Attacks
against the Tor Network" (2015) contains some more recent correlation experiments on the live Tor network with the insight that "end-to-end confirmation attacks can be successfully applied against the current size Tor network". The author also proposes a concrete defense technique based on dummy traffic that is supposedly "simple, easy to implement and deploy as well as usable" but to the best of my knowledge hasn't found its way into the Tor protocol, yet.


There are a lot of possibilities for that:

1- No ports are really open other than 80.

2- Firewall is not blocking your IP but it might be evade your results and this only with advanced firewall.

3- NMAP by default scans only 1000 TCP ports and there are other open ports so make sure to scan full TCP & UDP port range.... namp -sU -Pn -p 1-65535 will scan full UDP range.


How to exploit this include_once vulnerability in PHP?

Sigh. Here is the reasoning for me posting a link in lieu of a long answer. Original post wants to inject/disaffect/exploit through the lang variable in cookie:

GET /en-us HTTP/1.1
Cookie: xxx=eng.php/../../../anotherfile

He then states he tried and failed:

ErrorException:
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

"No such file or directory" to me means one of a few things:

1) His directory traversal is off:

/export/htdocs/xxxx.com/base/languages/content-eng.php
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/anotherfile.php

If the structure is exactly as above, there is no directory traversal vulnerability period.

2) eng.php is not detailed enough to know what it does. This would have to be the vulnerable weak link on the chain

He is relying on an error, thinking: "Oh well I have an error, I am headed on the right track"

OP: You could fiddle with the directories a bit more. It is telling you "I can't find this file" the issue becomes "what are you finding" if you state you have access to the machine, the solution I would use would be to place tokens in folders to determine where you are landing:

/export/htdocs/xxxx.com/base/languages/**option1**/token1
/export/htdocs/xxxx.com/base/languages/**option1/option2**/token2
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/token3

Then try another POST/GET perhaps:

Cookie: xxx=eng.php/token1
Cookie: xxx=eng.php/token2
Cookie: xxx=eng.php/token3

Cookie: xxx=eng.php/../token1
Cookie: xxx=eng.php/../token2
Cookie: xxx=eng.php/../token3

Cookie: xxx=eng.php/../../token1
Cookie: xxx=eng.php/../../token2
Cookie: xxx=eng.php/../../token3

Just because you got an error, does not mean directory traversal is present. For all you know it's is a global error you are getting. The initial link I sent was to guide you on a "known known" (variable you control) lang.

EDITING FOR SPACE CONSTRAINTS:

OP: "The base is /export/htdocs/yyy.com/base/. The anotherfile.php is in /export/htdocs/xxx.com/anotherfile.php"

Unless I am misinterpreting this:

/export/htdocs/yyy.com/base/

/export/htdocs/xxx.com/anotherfile.php

Are these on separate sites? If xxx.com is your own server/test machine, I'm under the impression you're trying an LFI exploit:

you --> modify cookie (hey, take this anotherfile.php from my machine) --> yyy.com

Again, the reasoning for my initially posting a link in lieu of an answer. If you meant the other way around (typo):

/export/htdocs/yyy.com/base/

/export/htdocs/yyy.com/anotherfile.php

Then you need to modify your insertion to ../../anotherfile or move another file into:

/export/htdocs/yyy.com/base/


How can I restrict what an application can do with my computer?

Excellent question.  Unfortunately, there is no really good way to do what you want.
I don't know of any way to see in advance what resources a desktop application may access.  Instead, the only approach is to run it within a sandbox or constrained environment that restricts what it can do.  There are two general approaches:

Use a sandbox.  You can run the application in a sandbox that limits what it is able to do.  However, you may need to specify a policy for the sandbox, or run it using a default policy that is tightly constrained.  On Windows, it's hard to find good sandboxing software for running general-purpose software; the best option might be Sandboxie.  HP also built a sandboxing system called Polaris, but as far as I know it was never commercially released.  On Linux/BSD platforms, check out Plash, Systrace, Capsicum, Subterfugue, and Rainbow.

Use a virtual machine.  A simpler and more pragmatic solution is to use a virtual machine and install your application in the virtual machine image (in the guest OS).  This will let you run the application, with reasonable confidence that it cannot escape the virtual machine.  This may work fine if the application does not legitimately need access to any of your personal information, but if it does need that kind of access, you may find that it is hard to provide the application with partial but not complete access to your data, devices, and other resources.
On Linux, Qubes and Virtics provide a secure desktop that uses virtual machines to sandbox every application you run, though I believe they are research-quality prototypes, not robust finished products.  They might also be worth a look at, if you are willing to deal with less-finished software.


What is the impact of "urgent Firefox update" malware?

If it is a brand new laptop I would just reinstall the OS.

The malware that you executed will not be fixed by removing Firefox. If your computer had more time invested in it, it may of been worth while trying various malware/virus detection/removal products. But as it is brand new just reinstall the operating system.

As for what effect it could have, did it prompt to "make changes to your computer"? If yes and you clicked yes, then the malware could do almost anything, from installing new software, to modifying the operating system, to installing device drivers.

The most common thing for malware to do is to install something that autostarts and contacts another computer and requests instructions. These instructions are normally either to be part of a botnet, being part of a DDoS attack, sending spam emails, clicking on ads on webpages. Or installing crypto-locker which would encrypt all your files on your computer and demand money to decrypt. There are lots of other things this could do, these are just some examples.


Application security vs network penetration testing

1) Try the 'Natas' wargame on OverTheWire.org, it is good for learning concepts and getting to learn them in action. They have a bunch of insecure applications that you can practice exploiting. Also OWASP has a practice (insecure) application to test called WebGoat.

2) The same company(offensive security) who offers the oscp also offers the OSWE (Offensive Security Web Expert). I would definitely recommend taking the OSWE if you are looking to go the application route. The OSCP touches the application side but is more focused on the network.

3) Application security engineers are going to be working strictly on applications/code. Network testers work with the entire network. A network can consist of PCs, Servers, Routers, Firewalls, Switches, etc. So they are going to focus more on the network design, how an attacker can move around the network and exploit the machines on it. Application will be solely focused on a specific application/software.

Webgoat: https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

Natas: http://overthewire.org/wargames/natas/

OSWE: https://www.offensive-security.com/information-security-certifications/oswe-offensive-security-web-expert/


How to manage customer-supplied encryption keys in a multi-tenant cloud SaaS?

It is impossible to guarantee security in the cloud from the cloud provider itself, the cloud provider can (be forced to) take a memory dump of any running VM instance and extract any encryption key from a running instance. It is even possible to continuously and automatically monitor a running VM and extract AES keys as soon as they are used, especially when the VM is using AES-NI.

A truly secure solution would avoid decrypting, let alone using, the keys on the server.
So do the encryption client-side and use the server purely as blob storage.

Fortunately you can do quite a bit of crypto in the browser these days, that includes KDF and AES.
For KDF you can use e.g. scrypt-js, and for AES aes-js or aes-es.


Do I need a new CSR for a certificate renewal?

The short answer is that while yes you can reuse the CSR, it doesn't mean you should.

It's worth considering that encryption methods can improve over time (e.g., generating RSA keys @ 2048 or 4096 vs 1024 awhile back, sha256 vs. sha512, etc) so it's probably best to just generate a new one considering how trivial it is and increasing the private key strength if it's outdated.


Confusion about keepass portable and keyfile on an USB-stick

Yes, you should keep your keyfile separate from the database.

But the keyfile does not change often (if at all), so you don't need to keep moving it around with you in a vulnerable manner - just load it ONCE on each device, and that device will remain authenticatable.
You can do this manually - consider it a "device registration" process, and do it any manual way you want, just don't leave copies of the keyfile floating around anywhere EXCEPT the registered devices.
You can keep carrying the database file around with you on a USB stick (or float it in the cloud), and keep it up to date.

I am assuming, of course, that you are talking about a small set of pre-defined devices - your computer, your laptop, your phone - and not just any arbitrary computer you happen across.

If you do need to read your keepass database on arbitrary computers you do not control - then don't. If you really really need to - don't.
Once you unlock the database file on an untrusted computer, all your secrets are leaked out. So don't do that.


How does openvpn work for only certain servers?

This is called split-tunneling. It is done by establishing a VPN tunnel to the company but then routing only a specific network range through this tunnel. All other traffic is handled the same way as was done without VPN. Note that the commands you show are unrelated to this split-tunnel setup.

Or to put it more simply: Can my work see my other internet activities(via dns queries or similar) while the vpn is connected?

This depends on what your DNS server is. This is not visible from the config you've shown but it might be part of the config. If it is a server where the company has access to the logs then they might also monitor which sites you access.


What prevents a man in the middle from requesting a certificate for your server?

A CA is supposed to make sure that the certificates it issues contain only truthful information. How they do that is their business; serious CA are supposed to publish detailed "Certification Practice Statements" that document their procedures.

In practice, when you want to buy a certificate for a www.myshop.com domain, the CA "challenges" you, so that you demonstrate that you indeed have control of that domain. Some classic methods include:

The CA sends you a piece of random data, to include as a host name in the domain. You thus demonstrate your control of the DNS related to the domain.
The CA sends you a piece of random data that you must put for download (over plain HTTP) from the www.myshop.com site. You thus show that you control the main server that corresponds to the domain.
The CA sends that piece of random data over an email sent to admin@myshop.com. You return back that data to them, thereby demonstrating that you can read the emails sent to the administrator of the domain.

None of these mechanisms is really strong; and, moreover, it suffices for an attacker to succeed in fooling one CA among the hundred or so that are trusted by default by usual Web browsers. Nevertheless, fraudulent certificates appear to be a rarity (say, once or twice per year, worldwide), so one has to admit that these authentication mechanisms, however flimsy they look, must be good enough for the job.

As for mistyped domain, it is a very classic method which is commonly handled by either buying those mistyped domains, or unleashing your lawyers on whoever tries to buy a domain that seems to be "too close" to your own domain.


Are all anchor tag href attributes considered XSS vulnerabilities?

Is this technically considered XSS

Absolutely.When the user click's the tag the javascript will get executed in the context of the domain.So it is a legitimate XSS.

  If so, how can I mitigate this "attack"?

OWASP XSS prevention cheatsheet is an excellent resource for such questions.

They state that

  Do not encode complete or relative URL's with URL encoding! If
  untrusted input is meant to be placed into href, src or other
  URL-based attributes, it should be validated to make sure it does not
  point to an unexpected protocol, especially javascript links. URL's
  should then be encoded based on the context of display like any other
  piece of data. For example, user driven URL's in HREF links should be
  attribute encoded.


How does Windows/IIS keep a certificate protected or should I never run Apache Webserver on a Windows server?

A generic remark is the following: if you can reboot the machine, and the server becomes operational again automatically, without any further human intervention, then, by definition, the machine disk contents contain everything that the machine needs to access the private key. Correspondingly, someone gaining full access to the machine (as "root" on Linux, "Administrator" on Windows) will be able to recover the private key as well.

On Windows, software-based private keys are stored in the DPAPI. To make the story short, the private key is linked to an account (the machine's own account for the "Local Machine" store) and the protection ultimately relies on encryption using the account's password as key. For an IIS which starts automatically, the corresponding password must be written somewhere in the entrails of the system. There can be layers of encryption and indirection, but it can be unravelled by anybody with sufficient rights. See this answer for pointers as to how to do that practically.

Also, if someone gains administrative privileges on the live machine, then he can just attach to the running Web server process and plunder its RAM contents directly, with ReadProcessMemory().

So any protection will be, ultimately, relative to how well the operating system will prevent unauthorized users from gaining administrator privileges. From that point of view, there is not much difference between Apache/Tomcat and IIS: you could store the private key for Apache in a file and set some ACL to make this file readable only from the specific user who will run Apache. People with administrative rights will be able to bypass that, but, as explained above, they can do anything on the machine.

Now there can be quantitative subtleties. Down to the core of the machine, there is the kernel; kernel code, by definition, is God. It can read and write all the RAM, access all the hardware. The kernel is also the gatekeeper who decides who can do what. In the view of the kernel, each applicative code runs with a set of privileges, which describe exactly what the code can do. Some privileges are god-equivalent, meaning that a process which has that privilege can arrange, more or less directly, for obtaining the same power as the kernel. In a traditional Linux system, any root process is god-equivalent, since root can create and load kernel modules, i.e. custom code right into the kernel itself. By transitivity, any process who can take control of a process with god-equivalent privileges is also god-equivalent.

God-equivalent processes are juicy targets for attackers. There more such process there are, the more probable it becomes that one of them has an exploitable vulnerability that will allow the attacker to achieve godhood. Thus, reducing the size and scope of god-equivalent process may help in increasing practical security. There will still be, deep in the machine, some god-equivalent code (if only the kernel itself), but fine tuning may help keeping that code small.

Linux and Windows, by default, are roughly equivalent in that respect (a lot of process which run as root / System account), but offer different tools to trim that down. On Linux you would play with chroot and, more generically, SELinux. On Windows you can do a lot of tuning and restricting with Group Policies. In both cases it is quite easy to lock yourself out, so take care.

Summary: There is nothing wrong with Apache/Tomcat on Windows. Protections applied on private keys as used by IIS are not qualitatively different, or stronger, than access rights on files. A good sysadmin will achieve a similar security level in both cases, on the same machine.

In any case you would be well advised not to let any unprivileged user run arbitrary code on servers with sensitive data. Experience shows that when attackers are allowed to run unprivileged code locally, the number of exploitable holes raises sharply.


Log Monitoring

You could do it through log monitoring and trigger some alerts.
Check out a commercial solution like Splunk. This allows you to manage and read your logs by creating dashboards, thresholds, and alerts.

Whenever you are being probed, you could pop an alert through log monitoring.

Soon enough you'll find yourself creating dashboards and alerts for all kinds of things!

Also check out GrayLog and ELK (ElasticSearch, Logstash, Kibana) which I believe are open-source and free.


Difference between Encryption and Verification certificate

Your terminology looks weird, but here are some explanations which are likely to be relevant to your question:

When doing "secure" emailing with S/MIME, you actually use two distinct features:

Email encryption: emails sent to a recipient R are encrypted, i.e. made unreadable for everybody, except for R, who can reverse the encryption process. R can do that because the encryption is done using R's public key, and R knows the corresponding private key (public and private key are mathematically linked together, but only the public part is made public).
Email signature: emails sent by a sender S are signed, i.e. S adds to the email (usually as an "attached file") a value (the signature) which is specific to the email contents and can be computed by S alone; but everybody can verify that the signature matches the email. Computing the signature uses S's private key, but verification is done with S's public key.

In a full-featured emailing system, every user thus has a private key for signatures, and a private key for encryption. You use your private key for signatures when you send an email (to sign it) and you use your private key for encryption when you receive an email (to decrypt incoming emails). Either way, the people you exchange emails with must know your public key(s) with some certainty, so public keys are distributed through digital certificates. A certificate is a container for a name and a public key, bound together in a compact packet which is signed by a certification authority.

Depending on your key type, what is written in the corresponding certificate, and some policy choices, your key for signatures and your key for encryption may or may not be the same (even when it is technologically possible to use the same key for both usages, there are good reasons to keep them apart from each other). With S/MIME, you mostly have the three following situations:

Your signature key and your encryption key are the same (of type RSA). You have one certificate for your one public key. (That's the most common case.)
You have two distinct keys for signatures and for encryption; each public key is distributed in its own certificate.
You have a key for signatures, and the public key is in a certificate signed by a regular CA. For encryption, you have another key pair, where the public key is not stored in a certificate signed by a CA; instead, it is distributed as an SMIMECapabilities object which is added to the signed messages you send (and it is then part of what you sign). In effect, you are then acting as your own CA when publishing your encryption public key.

Regardless of how many keys and certificates you have, you send it all when you send a signed message: this means that every signed message that you send contains everything that recipient must know if they want to send encrypted messages to you. For instance, the certificate which contains your public encryption key (if such a certificate exists in your case) will be added into the signature object that your mailer agent (Outlook) adds to your outgoing emails. Therefore, it is customary to initiate a secure email conversation with some other user B by sending him a signed email.

In integrated environments, certificates and/or SMIMECapabilities objects can also be distributed through other means, such as LDAP servers (aka "Active Directory" in Microsoft terminology).


OpenIdConnect: Is there an advantage to using code flow over implicit flow with form_post?

I don't see any security advantage of using the authorization code flow in your case (traditional web application). Indeed, form_post is not vulnerable to referrer leaking or browser history leaking. Posting tokens is nothing new, it's how SAML2, the predecessor of OpenID Connect, worked well without bringing in any specific security weaknesses.

And form_post indeed avoids one round-trip to the AS to authenticate the user. It's just that it cannot be used with javascript SPAs or mobile applications.


Why would you do that? It's the Password-Based Key Derivation Function 2, and ECIES doesn't work with a password but with a DH shared secret, thus not suffering from the same issues that plague passwords (such as low entropy-density).

Not to say it wouldn't suffice, but if you need something a straight hash or HMAC doesn't provide, KDF1 and KDF2 are your friends.


Does signing in via OAuth 2.0 compromise account security if the OAuth 2.0 service decides to become malicious?

The explanations in this answer are a bit imprecise and simplified to make them more understandable for someone that has only basic knowledge of OpenID and OAuth.
I assume that you are talking about OpenID instead of OAuth.
OAuth is used when for example a google user delegates access to parts of his account to you - for example to allow you to see his contacts in GMail.
You use OpenID when you want to know about the identity of someone. In that case you tell OpenID provider that you want to know the identity of the current user. The OpenID provider then sends you a token that holds information about that user - after the user logged in at the OpenID provider.
You then read that token and identify the corresponding user in your database. If that is successful the user is logged in within your application.
In this process you obviously trust the information in that token. The OpenID Provider has created that token. So you trust the information provided by the OpenID Provider.
In the end the OpenID Provider could create malicious tokens faking someone else's identity. However - without the presence of a vulnerability in your application or the OpenID Provider - an active attacker within the OpenID Provider would be necessary.


Identity and Access Management (IAM/IdAM) deployment guide

Hopefully this helps.

Identity Management Systems

Identity Management System are often defined by trusted sources. These are the systems we rely on for a source of record for an individual. These are not really a single piece but a combination of systems designed to manage people.

Identity Data Trusted Source

This is data of people, typically found in your HR systems. They are wide ranging, and can be as simple as AD for a small organisation.

Authorization/Authentication Trusted Source

This is a system or systems which your organization uses for AAA. In many organizations, that is just Microsoft's Active Directory, however, there are several directory based services out there and larger organizations can have systems split into different sources.

Single Sign On

Most organizations that uses SSO within the organization likely uses some sort of Federated Identity Service which allows users to have a single ID across multiple AAA systems.

Modern Federated Services allow for both SAML and OAuth 2.0 communications. If you want to be technical, OAuth isn't targeted at Authentication, it's Authorization. It does provide a mechanism for Authentication Exchange, but that's not its intent.

SAML is on built for both, and is typical for Enterprise SSO services.

If these are custom applications, one standard I have added to my development work is JWT (JSON Web Tokens) which is not really SSO per-se, but more of a mechanism to enable SSO features in modern applications, but it can handle both Authentication and Authorization.

Common IDM systems Examples

Oracle Identity Manager (Link)
Sailpoint IdentityIQ Link

I work with both these systems. I have many reservations about them. Sailpoint is more modern, Oracle is, well, Oracle (Lots of ups/ LOTS of downs). I always think I could build a better one (which I might attempt for fun one day).

Do it yourself setups

Understand that IDM/IAM/IdAM (Or whatever abbr you want) are designed to provide a common set of administrative functions around people and access to resources. This includes being a central repository for identity access, role management, policy deployment, and provisioning/de-provisioning of resources. Wiki for reference.

Your actual goal sounds less like IDM and more like resource management, I.E something that is not achieved by these system specifically. A few things:

You need to identify which systems are going to allow to authenticate and/or authorize resources.
You should have a policy around future apps about their ability to authenticate to those systems.

I think you may want to start with Federated Services and research them. This will give you an understanding of what their purpose is. Most organizations looking at SSO at scale, are looking to Federated Services to simplify thing.

This is where the term Microsoft shop comes into play, so mentioned because all their apps are MS and can authenticate to AD. I've never been to an organization that had this but, kudos if you have that simplicity.


Is there any way to mitigate against a compromised CA as a client on Firefox?

Mitigating Effects of Malicious/Compromised Certificate Authorities

There aren't very many things you can do yourself as the client, but I will outline several solutions available anyway.

Remove Untrusted Certificates

If there are CAs that are trusted by your browser and/or operating system that you do not personally trust, you should remove them. This is easier said than done, as there are many you cannot remove without breaking a significant number of websites. That said, there may be some you can definitely remove without harm, such as foreign governments and others that aren't commonly used. This can take some trial and error.

HTTP Public Key Pinning (HPKP)

From Mozilla Developer Network Docs:

  HTTP Public Key Pinning (HPKP) is a security feature that tells a web
  client to associate a specific cryptographic public key with a certain
  web server to decrease the risk of MITM attacks with forged
  certificates.

  To ensure the authenticity of a server's public key used in TLS
  sessions, this public key is wrapped into a X.509 certificate which is
  usually signed by a certificate authority (CA). Web clients such as
  browsers trust a lot of these CAs, which can all create certificates
  for arbitrary domain names. If an attacker is able to compromise a
  single CA, they can perform MITM attacks on various TLS connections.
  HPKP can circumvent this threat for the HTTPS protocol by telling the
  client which public key belongs to a certain web server.

  HPKP is a Trust on First Use (TOFU) technique. The first time a web
  server tells a client via a special HTTP header which public keys
  belong to it, the client stores this information for a given period of
  time. When the client visits the server again, it expects at least one
  certificate in the certificate chain to contain a public key whose
  fingerprint is already known via HPKP. If the server delivers an
  unknown public key, the client should present a warning to the user.

So, if a certificate is presented to the client that doesn't match the pinned public key, or doesn't match the pinned CA's public key, the connection should fail. While there are some clear benefits to HPKP, Google and other initial supporters now recommend against it due to the possibility of long-term denial-of-service or hostile takeover.

DNS-Based Authentication of Named Entities (DANE)

DANE doesn't rely on CAs at all, and can operate independent of/without them. A DNS query over DNSSEC for a domain's TLSA returns information about what certificates should be treated as valid. I am unsure how widely DANE is deployed, but it could possibly be enabled through a browser addon.

Detecting Compromised CAs

If a CA itself doesn't know it's been compromised, there is really no way you would be able to determine that yourself. The only way I can imagine to catch a newly-compromised/malicious CA is if you knew CA "A" is usually in the chain for a domain, but you observe CA "B" in the chain instead. I imagine that a browser extension could keep track of this information and alert the user to any changes, but I fear that false positives would be indistinguishable from malicious events.


Remove possibility to read system files with PHP from Apache

This is not a vulnerability in Apache. It is a vulnerability in your PHP code.

The function include(x) includes the file x. If you let the user pick any x, they will be able to include any file. If you don't want them to be able to do that, then don't write PHP code that lets them. I suggest you only pass constants or values from a whitelist as parameters to include().

If you are worried about your developers uploading bad code like this to the server, there is nothing you can do other than getting better developers (educate or replace) or a better review process. A PHP script could in practice be written to do anything the PHP interpreter has priveliges to do, and that is a lot. You could for instance write a backdoor in PHP giving anyone full access to your server.

To repeat, there is no magic config file that will make PHP inherently safe. The only way to keep you server safe is to only upload safe code to it, be it PHP or any other language. You can't get security with the push of a button; you need to integrate the perspective into your entire development process.


Since you have no root access yourself I consider this compromise only restricted to your own account. Otherwise the owner of the server would probably have taken care of the issue already.

The best way is probably to nuke the site and set it up again, but only after checking how the attacker came in and make sure it is no longer possible.

The best way to check where exactly your server is compromised is to compare all data with a known good version. I don't know about your setup but it is common to make the site development on a local system and then mirror the data to the remote system. Thus it should be possible to compare these both versions or to simply restore the site from your local copy. Not that you need to check also if files exist remotely which don't exist locally.

If instead you have done all the changes on the production system and do not have local copies then I'm very sorry for you since this effectively means that you have to look at all the files and see if they differ from what you remember. File modification times might be an indicator of a change but are not reliable since they can easily be set to other times (also older) without needing special privileges.

Additionally there might be changes to the database. If you web application dynamically creates HTML based on fragments in the database then you have to go through all records an look for anomalies.

If you have access to the log files of the server these are also a good source when looking for abnormal behavior, but it is up to you to know how your site works and what would then be considered abnormal.

And finally your site might be vulnerable by remote file inclusion attacks (RFI). In this case you will not find much traces on your local system, because the files used in the attack might reside on a remote system. Thus make sure your web application is secure. You should do this anyway because otherwise chances are high that you get compromised again fast.

Note that simply searching for known malware is not enough because even small modifications on existing malware will leave the malware working but you will not find it any more.


No. Structured Exception Handlers (SEH) are a Windows-only thing, so Linux cannot be exploited in the same way.


How secure is it to use secret directory names to share files on unix?

This is called "Security by Obscurity", and is not a reliable form of hiding files at all. There are plenty of tools that can search a whole filesystem and index the files within, regardless of what permissions you're assigning to some randomly named folder.

You have conflated an adversary not knowing something with them being unable to learn it. In your example, you aren't actually doing anything to stop someone who obtains the folder name from listing and reading the contents. Once the name stops being secret, the jig is up. This is unlike a password, as passwords are stored in a one-way hash, whereas folder names are in clear text on the filesystem.

An analogy: You have a house, with a door, and you want to keep people from just walking through your door. You can move the door to some hard to find spot on the house that isn't visible by just walking around the outside. But there's nothing stopping someone from pressing on various parts of your house to find the door.

Or, you can put the door in an obvious location, but prevent anyone from just opening it, with a lock.


GPG armor output ending with == followed by four characters

The public keys you're describing are encoded as per RFC 4880 §6:

  OpenPGP's Radix-64 encoding is composed of two parts: a base64
  encoding of the binary data and a checksum.  The base64 encoding is
  identical to the MIME base64 content-transfer-encoding [RFC2045].

  The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to
  four characters of radix-64 encoding by the same MIME base64
  transformation, preceded by an equal sign (=).

Base64 encoding is always padded with 0-3 '=' characters at the end; OpenPGP adds another '=' and follows it with 4 characters of checksum.

Since the checksum is always 4 characters, and Base64 pads to reach a multiple of 4, there is never a need for '=' padding after the checksum.


Sharing a JWT between devices in close proximity of each other

Answer to Q2:

You are not really inventing something here as far as I can see. You are using a very simple One-Time-Code generator.

Generate the code locally on the Pi, keep it valid for a constrained amount of time (a few seconds maybe), require it to be entered into the phone and once used invalidate it immediately.

Use the Pi as a local Wi-Fi AP with appropriate security and it should be more than enough for the quick in and out you need. Even if someone gets onto the Wi-Fi, as long as the rest is secured with HTTPS and your OTP, it should be fine.

To save yourself a load of work and avoid the local invention problem, use a standard set of libraries on the Pi. Node.JS with ExpressJS and standard modules such as Passport, Helmet, Lusca or similar can handle the login and app security. A locally generated certificate should be enough for HTTPS.

This seems like a nice simple, standard and reasonably secure approach.


Without a CA, you need some type of other secure secret exchange.  It could be a side channel exchange of the thumbprint or use of some pre-existing shared secret.  Web of trust can also be used, though this is basically another form of side channel.

Using the UID as you suggest however, is likely insecure.  The UID of a phone isn't a secret and an attacker could obtain the UID and then impersonate the device.

Now, if you don't actually care about the identity of the phone, it could just submit an anonymous public key and you will know that it is the same phone in the future, but you will know nothing about the identity of that phone.  You don't need to involve the UID (and shouldn't) for that though.


How do I store session data on a server securely

In general session information is not usually encrypted on the server side. It is generally assumed, as part of the threat model, that if an attacker gains access to the server then they already have everything they need. Session data itself is usually not any more sensitive than the rest of the contents of the database.

There are a few options:

Store them on the filesystem in plaintext. If your threat model suggests SQLi is more likely than filesystem access, this is an easy move.
Encrypt session IDs and data using the database's inbuilt encryption routines. This protects you against cases where a database backup is compromised, but won't protect you against disk theft or an attacker with SQL access.
Encrypt your session IDs and session data in the database, using a key set in a config file on the server somewhere. The benefit of this is that the attacker would need access to both the database (e.g. via SQL injection) and the filesystem at the same time in order to decrypt the session IDs and session data.
Encrypt session IDs and data using a randomly chosen key which is cached within the server daemon process (e.g. APC or memcached for PHP). This would be exceedingly difficult for an attacker to gain access to without full code execution on the system, but has the downside that all session data would be invalidated if you restart the server process.

I recommend the use of authenticated encryption, with separate encryption and authenticity. Pseudocode for encryption is as follows:

iv = secure_random(16)
encrypted = iv || AES-CBC-128(session_id || session_data, enc_key, iv)
auth_encrypted = HMAC-SHA256(encrypted, auth_key) || encrypted

Pseudocode for decryption is as follows:

mac = auth_encrypted[0:31]
encrypted = auth_encrypted[32:]
expected_mac = HMAS-SHA256(encrypted, auth_key)
if mac != encrypted_mac:
    session was tampered with
else:
    iv = encrypted[0:15]
    encrypted = encrypted[16:]
    decrypted = AES-CBC-128_Decrypt(encrypted, enc_key, iv)

This provides authenticated encryption to prevent tampering with session data on the server side.


Is it possible to determine which type of packet is sent over TLS?

As @Sjoerd proposed in his answer you can look at the port number. But this does not help if it is not simple a TLS enabled protocol (i.e. smtps instead of smtp, ftps instead of ftp...) but if Bob is using a proxy server or VPN to tunnel the protocol.

In this case one could try to detect the protocol by flow analysis because different protocol have different traffic characteristics regarding which amount of data is sent at which time in which direction. And this behavior is visible from outside the TLS tunnel too.

For example both SMTP and FTP start similar in that the server first sends a short welcome message which is then followed by several small exchanges (i.e. USER, PASS, .. with FTP and EHLO, MAIL FROM, RCPT TO... with SMTP) which are then followed by a larger transfer from client to server with SMTP (i.e. the mail) and most times from server to client with FTP (directory listing). With HTTP instead the clients sends usually a small request (but noticeable larger than the commands within SMTP, FTP) while the server sends a much larger response back.

While it is not possible to be fully sure about the protocol spoken these manual heuristics already provide a way to classify the traffic. Classifying the traffic this way is also relevant outside of TLS because deeper traffic inspection just for classification is often two expensive and slow. If you just search for netflow traffic classification you will find lots of scientific papers and other information for further research.


Is it okay if apps in pre-production environment can be accessed without VPN?

It is not common practice. its generally not advised because developers dont usually code the application to behave exactly the same way in a test environment. Sometimes the js isnt minified, sometimes there are controllers that have debug urls,that could give somebody insight into how the application behaves behind the scenes.
Ultimately it comes down to what information is available in that environment, and of what use would it be to somebody attacking the production application.
This is assuming of course that you have no real data in the application.


Trustworthiness of kernel.org post attack

Well, in regards to the use of Git, it turns out that the software and distributed nature does a lot to protect code and detect malicious modification. For starters, no old commits can be altered unless they match the corresponding SHA-1 hash. Even if one commit did match a certain SHA-1, it would affect the child SHA-1 hashes, so that's out. Nothing older than the date of the breach could reasonably be altered or it would break the repository and syncing.

Commits could be added in that 17 day period. Because timestamps are part of the SHA-1 hash for a commit, we can narrow down the list of "suspect" commits by looking at anything older than the last commits before the breach or anything where the child date of the commit is younger than the parent date. If you've ever tried to alter a commit in git after it reaches a shared repository, you understand how severely obvious it is that something historical was altered.

Because full copies of the kernel hash that contain full history are so widely distributed and are always incrementally updated by following a chain of commits that can't be rolled backwards without the user being aware, the kernel source code is actually remarkably safe even when the hosting website is compromised.

Finally, because only a limited number of individuals are able to legitimately commit to the  kernel, we can expect that they would be able to note any updates to their sections that they don't expect. The human controls of sign-offs (kind of a technical control, but kind of not) plays a big part in knowing where the content came from.

All in all, compromising the kernel source in an undetected manner while it is in Git would be one of the more impressive hacks of the decade. One would have an easier time slipping in code via proper channels that looks innocuous but is malicious.


You can turn on 'audit' mode when unsigned code is run and that will generate Windows event logs which you can ingest into your SIEM and have that alert you. See here for in-depth guide. Why are you interested in unsigned files being loaded? If it's a malware prevention step then it might help but I think you'll receive so many false positives on a network where users are allowed to install their own programs it won't be worth it. There's also the issue that malware is frequently signed nowadays, see here and here.

For your second question about having Defender use custom malware sigs the answer is no, you can't write your own rules. What you could do is run ClamAV on all the endpoints and you can write your own custom rules for that, see this and this. Do you really need signatures though? Can't you push out a script to endpoints to return a list of installed programs and use that?

I think you've got bigger problems though, as an IT admin you should have the power to enforce that users aren't able to install whatever they want on your network. That also suggests have admin rights on boxes as well? I think code signing is the least of your worries and you should start implementing some basic IT security best practices before starting with more advanced ones. This can be a tough sell to management but if you Google around for the cost of malware compromises and network outages and sell it in terms of revenue it might help.