What actions should I, as an end user, take in response to EFAIL?

Notably, PGP is not the problem.  The problem lies with the mail handling apps in your browser which you have allowed to use your PGP keys.  Those browser apps decrypt the message as they should, but inside that message in addition to your secret is a trojan URL which is an attackers site.  Your browser app stupidly tried to connect to the URL which has your secret appended at the end.

For most people the most practical method is (from your link):

  Short term: Disable HTML rendering. The EFAIL attacks abuse active
  content, mostly in the form of HTML images, styles, etc. Disabling the
  presentation of incoming HTML emails in your email client will close
  the most prominent way of attacking EFAIL. Note that there are other
  possible backchannels in email clients which are not related to HTML
  but these are more difficult to exploit.

Then any URL in the decrypted message will appear as text, including the trojan URL.  Almost certainly would you be able to look at the URL and know something was wrong.  If nothing was wrong, and if your mail program has a button to to allow you toggle HTML view for that single mail, you would then be able to safely read the mail.

The other method suggested:

  Short term: No decryption in email client. The best way to prevent
  EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate
  application outside of your email client. Start by removing your
  S/MIME and PGP private keys from your email client, then decrypt
  incoming encrypted emails by copy & pasting the ciphertext into a
  separate application that does the decryption for you. That way, the
  email clients cannot open exfiltration channels. This is currently the
  safest option with the downside that the process gets more involved.

could be more difficult.  On a cell phone it could be very very difficult.
On a laptop or desktop, it depends on how easy it would to set up the non-browser app, or have someone do it for you.  The fiddly time spent cutting and pasting depends on how many encrypted messages you have to process.

You would also want to be careful that the non-browser app doesn't automatically try to contact the URL.

EDIT: Adding quotes to message won't protect your sent encrypted mail.  Thanks to @Anders for pointing out the reference.


Will using super-glue on the screws of my laptop prevent it from being opened unnoticed?

Are there any seals available for securing your laptop from unauthorized access?

Yes.  Google, or look on Amazon for, "tamper evident stickers".  These stickers will fall apart if removed, making a messy residue that can't be put back in place.  You can put them so they cover screws and along the sides where the laptop comes apart.

And sealing the sides of the laptop with superglue

That seems a bit more drastic and messier than using stickers, and probably easier to tamper with (re-glue looks just like glue).  I'd just use the stickers.


What are the risks of buying a used/refurbished computer? How can I mitigate those risks?

It all boils down to which kinds of threats you want to migitate against - a determined attacker has many more options of leaving malware on your computer than just your hard drive, but it's getting increasingly complex to do so. If you're a rocket scientist working on the newest version of ICBMs you have more to fear than a college student who uses their computer for a few class assignments and some of the newest games (but in the rocket scientist's case, you won't be allowed to use self-bought used computers anyway).

Also, it depends a bit on how competent a presumed non-malicious previous owner was in protecting against malware.

And of course, "wipe clean" can mean anything from "deleting personal files, then emptying the wastebasket" to "reinstall the OS" to "completely overwrite the disks with random data/zeroes, then do an install from scratch".

The typical threats you should migitate against are random malware infections that the previous owner caught somehow. Wiping the disks clean, then reinstalling the OS should be enough to get rid of those.

Some computers, mainly laptops, come with a "recovery partition" that allows you to quickly reset the computer to factory condition; I wouldn't use that. First, because a virus might have altered the install files as well to survive a reinstallation; second, these recovery partitions often come with a lot of crapware which the manufacturer installs because they're paid a few dollars by the crapware maker. Better download an installation DVD/USB medium from Microsoft/Ubuntu/whichever OS you're using, and do a fresh install from that.

Besides that, there's many more locations that could have malware, but it's unlikely to find them on your used computer unless you are specifially targeted.

The computer BIOS might be altered to do stuff even before booting, for example, it could have a keylogger trying to steal your passwords, or even keep a few cores of your CPU busy mining bitcoin for the previous owner. It can't hurt to check the manufacturer's website for the newest BIOS update, and flashing the newest version of it, even if that's the version you already (seem to) have. This is already quite paranoid, but still something you can do in a few minutes so doing it won't hurt you much.
The hard drive firmware itself could be altered. Someone published a proof-of-concept a few years ago who installed Linux on the hard drive - no, the computer didn't run Linux; the hard drive itself ran Linux, ignoring the fact that it was supposed to be a hard drive (see http://spritesmods.com/?art=hddhack - on page 6, he adds a backdoor by replacing the root password hash with a known one every time the disk reads /etc/shadow, and on page 7, he boots a linux kernel on the disk itself).
The CPU microcode itself could be altered to do .. stuff, including ignoring any further microcode updates. Unlikely that this could be done without cooperation from Intel, but still a possibility if the NSA is trying to target you. (However, if the NSA were targeting you, "hope he'll buy the spiked used computer we put on ebay for him" wouldn't be their primary strategy, I assume).

So, if you're just a random guy, wiping the hard disks and doing an OS reinstall from scratch provides good protection against the kinds of threats you can reasonably expect.
However, if you have any reason to assume someone is actively targeting you - this includes MDs keeping patient data on their computers, credit card processors, ... - "Just don't buy used computers" is the first thing in a long chain of measures you need to take.


According to hashcat's wiki, you can paste the hash directly into the command line:

Usage: hashcat [options]... *hash*|hashfile|hccapxfile [dictionary|mask|directory]...

You can also use hash mode 1710 as in:  1710 | sha512($pass.$salt)| Raw Hash, Salted and/or Iterated

Putting it all together, it would be hashcat -m 1410 -a 0 hash:salt --username test_user /usr/share/wordlists/rockyou.txt where the hash contains the password and salt (in that order).

If the hash is salt/pass instead of pass/salt, use 1420 instead.


This kind of depends on how strong you want your network security policy to be.

Lets point out the main good and bad things about a WiFi network:

Good:

Convenient for the office workers to work from anywhere in the office
No need for cables and switches (This saves money and time)
Keep better track of your users and have more control straight from the AP control panel

Bad:

Using cables a hacker will have to come into your office and plug his hacking device into the network while on WiFi he can do this from standing a few meters away from your office or maybe even on a different floor.
Can be easy hackable or social engineered since people do not understand how important a WiFi password can be.
On a WiFi it is very hard to set up vlans and so if all devices are connected to the same AP an attacker can find all of them and preform attacks on each node.

In conclusion:

While WiFi might be a good solution for the IT team, security wise, having a WiFi network that is poorly configured(Which is the usual case) is a bad idea if it is not necessary and should be avoided.


Sha256 hash + secret GUID + RNGCrypto random number to hash passwords

If the Sha256 is used with only 1 iteration, then you should recommend to switch to a dedicated password-hash function in any case, BCrypt, SCrypt, Argon2 and PBKDF2 are good choices.

The problem with using SHA-* is its fastness, common hardware can brute-force about 3 Giga SHA-256 per second. Salting and peppering (the GUID) are good measures, but they protect form different threats.

You are right with the assumtion that an attacker needs the GUID from the server, but it depends on the attack, whether this GUID stays secret. On should plan for the case, that all necessary information is known, and then the slowness of the hash function is the only protection left.


Strange symbols in Firefox address bar with https

When the connection is insecure due to mixed content, and you've disabled mixed content blocking, the strike through is supposed to be solid line over the https scheme name:

(source: mozilla.net)

That yours show up as broken lines is probably a graphical glitch.


Should I set different passwords for different Wi-Fi bands?

Sure there is! In the absence of a "guest" SSID feature on your router, use one of the bands for guests/visitors, and the other band for private use. That way you can regularly change the password for the guest/visitor WiFi without disrupting connectivity on your own devices.

Granted, this is more of a practical consideration (even though you do gain some small modicum of security by regularly changing your guest WiFi password).


Is it safe to store hashes of possibly non-existing passwords in a less safe way?

If the processing of a failed login attempt, failed because the login name does not exist, incurs a smaller cost on your side than a failed login because of a wrong password on an existing login name, then the attacker may be able to see it: your server responds faster in that case. Therefore, the attacker will still be able to know which login names exist and which do not, and then concentrate only on the existing login names.

If you really want to hide to the attacker whether a given login name exists or not, then you must emulate it properly: regardless of whether the login name exists or not, do a complete bcrypt invocation. Even simply sleeping for the approximate right amount of time will not be sufficient, because your server will be able to "process" many more login operations per second when the login names do not exist, then when the login names exist. The attacker can still notice it.

Though Tradition calls for not revealing whether a given login name exists or not on your system, I'd say that proper password hashing is more important, so you should simply reject attempts on non-existing login names. If you want to hide the fact that a given login name does not exist on your server, then you MUST pay the computational price; but I think it is not worth the effort.

As for detecting brute force attacks, this is normally done with statistics on the source (the IP address of the client machine) than on the target (the name of the target user). If you limit the login rate to one attempt per second or less (or any other "slowness" policy) and per source IP address, then you will detect most brute force attacks, regardless of whether they target one login name or several, existing or non-existing. This is a more robust method, and it also covers your next step, i.e. when the attackers tries different passwords on many different login names (and they can certainly do that !).


How does one go about building a system with which to Van Eck Phreak?

What you're really talking about here is unintended electromagnetic emissions, and that goes way outside of the scope of grabbing monitor data via EM.

The main thing you're going to want to look at is TempestSDR. This is a project explicitly designed for doing exactly this kind of thing against real modern hardware. All you really need is an SDR, a decent antenna, and the software.

If you'd like further info and more cool stuff to take a look at, here's a huge link dump:

Melissa Elliot abusing laptop shielding problems to dump screen data at DEFCON21: https://www.youtube.com/watch?v=5N1C3WB8c0o
The seminal paper on LCD TEMPEST: https://www.cl.cam.ac.uk/~mgk25/pet2004-fpd.pdf
Making audio tunes with TEMPEST on a radio: https://www.youtube.com/watch?v=oLQbp6hj7-c
In-browser TEMPEST test for CRTs: http://www.janschejbal.de/projekte/tempest/
https://www.cl.cam.ac.uk/~rja14/Papers/ih98-tempest-old.pdf
https://www.cl.cam.ac.uk/teaching/0910/R08/work/slides-ykrt2-videorf.pdf

Then we've got more modern attacks against ICs and electronics in general using EMI probes and SDRs:

https://csrc.nist.gov/CSRC/media/Events/Non-Invasive-Attack-Testing-Workshop/documents/03_deBeer.pdf
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-811.pdf
https://www.esat.kuleuven.be/cosic/publications/thesis-182.pdf


No, an X.509 certificate does not include it's own fingerprint.  The X.509 fingerprint values used are a hash of the entire certificate.  For the obvious reason, you can't include the result of a hash operation into the source of the hashed data without invalidating the hash.

Other fingerprints may be included in the certificate; see What is the actual value of a certificate fingerprint for a good answer on this topic.


The content of the request barely matters. It's the content of the resulting certificate that counts.

No self-respecting CA (and hopefully none of those that are bundled by default with our browsers) should copy attributes in the CSR into the certificate without vetting them by another way. Therefore, there is little point in putting attributes in the CSR itself for CAs, since they really should decide what goes in by another means. (I've actually tried once to add extra extensions to a CSR and the commercial CA I used stripped them away and only put in what they said they would in accordance to the application form, quite rightly. Most of the time, they'll also remove the RDNs in your Subject DN for which they cannot vouch for, e.g. O= for a Domain Validated certificate.)

If you really want extensions in your request, turn in on in your openssl.cnf file (you may also have to use the -reqexts option with the openssl req command):

req_extensions = v3_req

(and fill in the corresponding [v3_req] section).

To issue End-Entity Certificates with the CRL distribution attributes, you need to add this to the openssl.cnf file.

(I'm assuming you have a copy of openssl.cnf in your current directory)

You'll be able to get your crlDistributionPoint extension as follows:

Add this line to the [ v3_custom ] section:

crlDistributionPoints = URI:http://example.com/my.crl

Make the issuing process use these extensions:

openssl x509 -req -days 365 -in file.csr \
             -signkey ca.key -out file.crt \
             -extfile openssl.cnf -extensions v3_custom


Accessing user data by a public 'token' - is it a potential vunabilility?

Token ids are a common tool. They originate into the 80's where the Kerberos protocol used a random token to identify a user for a period of time without requiring to give again a password.

The rationale is that only the legimate user should know the token, and that the duration of the token is short enough  to have it to expire before it will be captured. It is generally seen as a very long password with a rather short duration (between one day and a few months). So what is assumed that it is harder to steal than a normal password because the latter has to be easily memorized by its user, so it requires less protection and can sent along with the URL.

For the weaknessess you asked about:

brute forcing the token string - it is a large random string and a brute force attack on it would certainly be noticed before it has a chance to success, and the livetime of the token should make it expire before the attacker could exhaust the possible strings. In addition, incorrect token should occur scarcely, because they are normally sent by a machine with no risk for typos. So token errors should soon blacklist the attacking address, even for a small period of time making brute force attacks impossible
the token can be extracted from logs and browser history. Hmm... one of the security laws says that if an attacker can control your system, it is no longer (only) your system. One recommended counter measure is to educate the users to change their token as soon as they think that someone could have used their browser. For the log part, it only means that logs become sensitive data and that they should require administrative priviledges to be read. And it is useless to try to protect a system against its admin...

TL/DR: you are true by saying that using tokens enlarges the attack surface and for that only reason lower the overall security. For that reason, they should not be used for highly sensitive systems. Nevertheless, they are still commonly used and are generally seen as compatible with standard security requirements.


In short: Nmap works on the tcp or udp layer, nikto works on the http layer, proxy is a function on the http layer.

Slightly longer: to traverse a proxy, the client needs to establish a http connection. Nmap only sends out ip packets and analyzes the responses.


Can any website secured using TLS can be impersonated using a rogue certificate issued by a rogue CA?

There is potential protection in the form of certificate pinning.  This can be done in an application, and some browsers (hopefully all in the future) support it in the form of certificate pinning.   Certificate pinning can take two forms, first, you can submit the fingerprint for your certificate to the browser vendors (Google and Mozilla, currently) to be included in the browser itself.   Secondly, you can add the pins to an HSTS header, which will tell browsers that have visited your site in the past if the cert they're now seeing is kosher or not.

Because certificate pinning happens at the individual certificate level, it mitigates the threat of certificates signed by malicious or compromised roots.


What are the security risks with rolling out your own Authorisation server implementation

Security concerns are always very relative.

The major risk of rolling your own is doing a worse job than known good established frameworks. Which happens to be very common.

If you know what you are doing, understand the requirements, implementation details, are aware of security implications and have done your threat assessment, and have the time/budget/will to roll your own, then I see no issues with that.


How is my employer accessing my router when employer's laptop is wirelessly connected to my home network

As far as I understand you are connected through the employers VPN to the employers network. This means, there is a direct tunnel between the laptop and the employers network.

This tunnel can be used by you to access the employers network. But it goes in both direction and thus can also be used to access the laptop from the employers network. It does not matter what kind of additional protection you have  below this tunnel at all, all what matters is that this bidirectional tunnel (i.e. the VPN) exists.

And, once your employer can access the laptop from remote he can also access any systems connected to this laptop (like the router), the same as you do when you are sitting in front of the laptop.


How much entropy does a smartphones' pattern lock have?

You cannot reach 42 bits of entropy with a regular android unlock pattern. The 3x3 grid is limited to 389,112 distinct patterns, giving you an entropy of 18.57 bits. This is less than you might assume since a dot cannot be selected twice and you cannot skip intermediate dots on a straight line.

Additionally, research has shown that many actual patterns are predictable and in fact much less complex than they could be. For instance, a majority of users begin their pattern in one of the four corners.

Besides the low entropy there are other security problems with unlock patterns such as the smudge attack. If a pattern alone can be a suitable security measure has also been discussed here.

BTW, some mods (e.g. Cyanogen mod) support bigger grid sizes but I personally find a truly random pattern harder to remember than an equivalent PIN code.


What's the advantage of TLS-SRP over self-signed certificates?

The main advantage of SRP is that it can work over a low-entropy shared secret. Namely, a password. Passwords are not as strong (in general) as, say, RSA private keys, but they can be stored in human brains.

If you use a pair of self-signed certificates, then each party (client and server) will have to store a hash of the peer certificate (that's easy) and also its own private key (that's the hard part). Storing private keys is hard because it makes the storage device highly sensitive, e.g. theft becomes a critical issue. Passwords, on the other hand, can be kept in your mind, which (theoretically) is immune to theft.

TLS-SRP, in that sense, contrasts with TLS-PSK, in which the shared secret must have high entropy (because what travels on the wire allows for offline dictionary attacks). TLS-PSK does not offer any security advantage over self-signed certificates (it may have performance advantages, though: smaller messages, less computations...).


As reported on Wired in March 2010:

  More than 100 drivers in Austin, Texas found their cars disabled or the horns honking out of control, after an intruder ran amok in a web-based vehicle-immobilization system normally used to get the attention of consumers delinquent in their auto payments.

Other than that, not much, as Sophos says:

  The dangers of cyber attacks on cars has all been theoretical so far: at this point, there’ve been no real-world attacks, as far as we know.
  Only security researchers have managed to send cars into the weeds.


Are PGP's public and private keys a two-way street?

First of all: it depends. There are cryptographic algorithms that can be used both ways like RSA, but also others that can only be used for encryption or signing (in OpenPGP, those usually occur in pairs, like DSA for signing together with an ElGamal subkey for encryption).

  Is it possible to encrypt a message with my private key and have the recipient decrypt it with my public key?

In the case of RSA, signing a document technically is equivalent to encrypting the hash sum of the document with your private key; if a third party can decrypt it with your public key, the document must have been encrypted by your private key (and given you did not hand that out, it was encrypted by you).

Other encryption algorithms like ElGamal cannot be used like this, on the other hand signing algorithms lika DSA cannot be used for encryption.

  I know that this would provide no real security since my public key is widely known.

It would of course not provide confidentiality,  but also authorship can be considered security!

  It would also be a very impractical way of establishing that I authored the message since PGP already supports signing.

Considering OpenPGP specifically: If you create an RSA primary key that has both signing and encryption capabilities set, you actually use the same public/private key pair for both encryption and signatures as you described. In GnuPG, you will have to provide the --expert flag while creating the key. Doing so is discouraged, though; splitting duties might prevent some (yet unkown) attacks at least for some usage of your key/key set.


How can an attacker eavesdrop on users in public WIFI?

When accessing a public wifi an attacker might use applications such as wire shark to capture packet information (the data of users), if encrypted the attacker will most likely attempt some kind of MitM

MitM ARP poison, this will essentially tell the victims machine "Yo, Im the next hop I swear". with this the traffic could be directed through the attackers machine.

how would the attacker deal with this? well thats tricky because an attacker could either redirect all 443 traffic to 80 but alot of websites patched that common easy problem years ago.

The attacker could DNS steal and send the user to his own custom webpage (which could be a spoof of a common website and it would appear ligit)

being within a network as well gives you in depth sight to those on a network and their activity, some times people even broadcast their files to the world. Also not just this but you can also try more attacks out which firewalls may be strengthen from.

There are many more possibilities of what an attacker could do but this is a few points!


Confidentiality doesn't provide integrity, but it does enable it?

Updated to make the explanation clear

Whether or not a given message follows a particular syntax is a very weak integrity check. It could also be a bug on the sender side which could result in messages not being of a particular format.

As mentioned in this answer, many common ciphers are trivially malleable. This means that it is possible to modify the encryption text to generate valid plaintexts. You are trying to go a step further by ensuring that the set of valid plaintexts is smaller. Sure, that makes the task a bit harder for the attacker but given enough time and datasets,  the attacker may be able to pass your integrity check as well.

Consider the following scenario:
Alice is talking to Bob and Eve is listening to the conversation. They are using block cipher for confidentiality. After listening to the conversation for a while, Eve has enough ciphertexts to play with the block cipher that they are using. The next message that Alice sent is intercepted by Eve, merged with some other previous ciphertext and Bob is able to decrypt it and see that the format is correct. This message passes the integrity check even if it is a forgery.


Java applets attempted to lock down a privileged standard library from within the process.
APIs like serialization and URLConnection were intended to work in both a full access mode (Java out of the sandbox) and untrusted mode (applets, web start). Privileges were determined by checking the caller’s class loader. This created an attack vector for gadgets: stringing together a sequence of API calls to trick a privileged Java class (say JEditorPane) into performing a privileged action on behalf of an unprivileged class.
It didn't work because the boundaries and responsibilities were unclear. Why was JEditorPane responsible for enforcing URLConnections security rules, only because it used the URLConnection APIs?!
My understanding is that WASM has no complex standard library that needs to work in both privileged and unprivileged mode. Avoiding that design mistake doesn't guarantee WASM security, but it makes it much easier to implement correctly.


Can network traffic between Docker containers be sniffed?

Yes, you need to secure the traffic.

Reading docs.docker.com:

  "if you need Docker to be reachable through the network in a safe
  manner, you can enable TLS by specifying the tlsverify flag and
  pointing Docker’s tlscacert flag to a trusted CA certificate. In the
  daemon mode, it only allows connections from clients authenticated by
  a certificate signed by that CA. In the client mode, it only connects
  to servers with a certificate signed by that CA."

In the article Top 20 Docker Security Tips by Jeff Hale, the author writes

  "Docker provides private container networking, too. This prevents a
  container from gaining privileged access to the network interfaces of
  other containers on the same host. So a Docker environment comes
  somewhat isolated, but it might not be isolated enough for your use
  case."

The article brings more ideas for strenghtening Docker security, including:

limiting privileges
avoiding running as root
using trusted and signed images
using minimal images and resources
managing keys securely
updating libraries
considering Docker Enterprise

Source:

docs.docker.com/engine/security/https
docs.docker.com/engine/security/security


How to rank the security strength of a cloud SaaS app

First of all you need to understand what threats and vulnerabilities you protect from and measure your security level against identified risks (e.g., it's useless to have an ability to encrypt sensitive data if you don't have such data). So you need to complete the following steps:

Identify risks and possible threat vectors.  NIST SP 800-53 with its risk assessment approach would be helpful to start with that.
Define applicable security controls. Cloud Security Matrix and Self-Asessment Questionnaire from Cloud Security Alliance would be helpful.
Map security controls to the risks you identified on step 1. As a result you will recieve a matrix with information what your solution is protected from and existing security gaps.

These steps are applicable to a new service or to the existing one. Of course, other secure SDLC techniqes such as penetration testing, static code analysis, dynamic scanning etc. should also be in place and should be performed on regular basis.


Yes, videos loaded over HTTPS will be encrypted when in transit.

HTTPS employs TLS/SSL over HTTP connections. This provides confidentiality - that is, no one on the network is aware of what you are watching, and integrity - no one can alter the video stream to substitute in a different video. Although which video you are watching could be deduced by other means - a side channel attack could be used to analyse the amount of data sent over the wire and attempt to determine possible videos that match the traffic profile.

Using HTTPS for streaming does add privacy. However, the real reason would be to protect session cookies on the rest of the site from being intercepted to protect user accounts as it is not possible to serve plain HTTP content on an HTTPS page without the browser warning the user.


As I understand it, the answer is no, there are no CAs involved in user authentication.  Users generate a public/private key pair and provide the public portion to the server, but there is no certificate or signing operation in response.  Instead, the server probably stores a fingerprint of the public key (or perhaps the whole key, I haven't looked at a server implementation) and uses challenges signed by the client to verify the key.  The authorization API only speaks of a key id.  Telegram's own FAQ only speaks of  nonces:

  Various secrets (nonce, server_nonce, new_nonce) exchanged during key generation guarantee that the DH-key can only be obtained by the instance that initiated the exchange.

This is neither like the CA system used for X.509 nor the OpenPGP web of trust, but is instead a highly-centralized system that assumes a single operator for the clients.  There's no need for CAs here -- Telegram is the only trusted third party involved.

(Clients do verify the server by a certificate presented via TLS, but this certificated is pinned in the official clients, so the CA signature is not the only thing verifying the server identity to the client.)


What are the implication of having Apache Tomcat servlets available publicly?

This has been documented in the past, where researchers discovered that some of the Tomcat examples left on a default install were vulnerable to exploits. In "vulnerability assessment/auditing" tools/programs, many will flag this directory as being at a high risk due to these applications being left on a system after an installation. A best practice approach to hardening systems is to remove defaults. (Default directories that are not needed, default passwords, change usernames, and so forth.) It is simply an open vector for an attacker to determine more information that can be further used to propagate attacks.


No, Snort is not designed to log all application and events occurring in a system.  A HIDS is not just a NIDS limited to just one host; it's a separate and additional layer of protections that can only be performed locally (like looking at files, processes, logs, and user contexts).  Snort doesn't even try to do any of that.


Is it safe to answer to a suspected email as long as I don't click any link?

If somebody has emailed you they currently have no idea whether your email is even used in the first place, so replying will do nothing but flag that there is somebody on the other end, therefore making your email more "valuable" to other scammers. You shouldn't click any link in the email AT ALL. A simple trick would be to add an "unsubscribe" link at the bottom of the email, it could lead anywhere and end up with your data, address etc. being in the spammer's hands.

ARTICLE
http://www.pcmag.com/article2/0,2817,2376031,00.asp


What are Encryption/Decryption Key Management Best Praticies

That is a very, very broad question. You should split it up into several questions. As it is, it would fill an article.

General Encryption

For data at rest, use symmetric encryption. Asymmetric is way too slow anyways (most so-called asymmetric encryption is actually hybrid).

Use AES. Because it's the standard, it has the most eyes that looked at it, you will never have to explain why you picked AES and not something else, and the performance etc. advances of some others are unlikely to come up in your application in a meaningful way.

Also, MongoDB supports AES out-of-the-box.

Keys

Your DB keys are the crucial ones. Keep them securely locked away and keep a few backup copies stored securely (i.e. encrypted). Key generation is its own topic, but probably MongoDB handles that for you already, check it.

TLS

For communication, use TLS, aka HTTPS. It's the standard, all browsers support it and all webservers support it.

Certificates

If you want to use client-side certificates, as your question about key distribution indicates, read up on PKI. That's too much of a topic to put into a textarea field on SE. :-)

That should get you started in the right direction. For more details, I advise you ask more questions with a more narrow focus.


What are known domain hijacking methods?

Here are a few ways to hijack a domain.

Use DNS cache poisoning to redirect users to your server.
Register the domain the moment the registration gets expired (domain sniping).
You can of course just hack the server or the hosting provider if you find a vulnerability.

There are also indirect methods of hijacking a domain, such as:

Phishing with unicode characters that are similar to the original (scary stuff):

https://www.xudongz.com/blog/2017/idn-phishing/

Typesquatting: register a domain one typo away from the actual domain.
Bitsquatting, where you register a domain with 1 bit difference of the actual domain. When non-error-correcting RAM flips a bit, users might end up on your page.


Is it always safe to type [i.e. run Get-Content] on a file in PowerShell?

No, but if its a binary disguised as a text file, you'll just see a bunch of jibberish in the output.

Personally, I'd check the file type prior to running any commands with the file. On *nix machines you can use the file {filename} command. For Windows see this post on SuperUser.


Using public/private key to validate multiple devices

I would take a quick look at what a digital certificate is here.

The short:

What you are proposing is basic Public Key Infrastructure. In Large Organizations, they may have their own CA as a Trusted source, primarily because it cost money to use a third party to sign a cert for internal use.

If you customers are external to your business, than I highly advise looking at the Third part signing solution.

What you are most likely trying to accomplish is:

Use the Serial Number of the device as a unique identifier. (See Wiki above).
Create a digital cert signed by a CA.
Use this cert for authentication of the device.

This is more commonly refereed to as Certificate-Based Authentication.

The infrastructure to do this a little tedious for smaller organizations, but their both commercial, opensource. I also direct you to this RedHat doc. You may not be using Linux, but they a great job of discussing the bits and pieces.


The CEH and CISSP certifications will likely help quite a bit.  I suggest ongoing trainings (and certain certifications) through specific services, such as Amazon Web Services (AWS), Microsoft, IBM or Google.  It could also be beneficial to learn about various other security vendors and explore training opportunities (and possibly joining partner networks) for multi-factor authentication (Duo, etc.) and virtualization tools (VMware, etc.) and continuously follow research on "DevSecOps" and other industry best practices.  I also suggest following development and communities / trainings, based around open source security tools and best practices, such as Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/Main_Page


No MX Records on a Possible Phishing domain?

Does the domain need an MX record before sending phishing emails?

No.  According to RFC 2821, if there is no MX record, then mail delivery will look for an A record instead:

The lookup first attempts to locate an MX record associated
with the name.  If a CNAME record is found instead, the
resulting name is processed as if it were the initial name.
If no MX records are found, but an A RR is found, the A RR
is treated as if it was associated with an implicit MX RR,
with a preference of 0, pointing to that host.


Why is it even possible to forge sender header in e-mail?

tl;dr

It's very easy to spoof a domain even with SPF controls enabled.

The solution is to use DKIM + DMARC, or SPF + DMARC

The email client is responsible for telling you if the message passes DMARC Display From verification

The email protocol allows for legitimate spoofing using Resent-* headers and Sender headers.  The email client (MUA) should display this exception whenever it exists.

There are a few misconceptions about SPF, namely:

SPF does not prevent email spoofing.
SPF alone doesn't affect, influence or, control the RFC 2822 Display From.
By default, the usefulness of SPF is to prevent backscatter issues and very simple spoofing scenarios.

Microsoft attempted to solve this issue with SenderID, (making SPF apply to the Display From address) but it was too complicated and didn't really solve the whole problem.

Some background
First know that there are two "from" addresses and two "to" addresses in every SMTP message.  One is known as the RFC2821 Envelope, the other is the RFC2822 Message.  They serve different purposes
The Envelope:  (RFC2821)

The envelope is metadata that doesn't appear in the SMTP header.  It disappears when the message goes to the next MTA.

The RCPT From: is where the NDRs will go.  If a message is coming from Postmaster or a remailer service this is usually <> or someSystem@place.com.  It's interesting to see that salesforce uses this similar to constantContact as a key in a database like toUserContactID@salesforce.com to see if the message bounced.

The RCPT TO: is who the message is actually being sent to.  It is used for "to" and "bcc" users alike.  This doesn't usually affect the "display of addresses" in the mail client, but there are occasions where MTAs will display this field (if the RFC2822 headers are corrupt).

The Message (RFC2822)

The message portion begins when the data command is issued.

This information includes the SMTP headers you're familiar with, the message, and its attachments.  Imagine all this data being copied and pasted from each MTA to the next, in succession until the message reaches the inbox.

It is customary for each MTA to prefix the above mentioned copy and paste with information about the MTA (source IP, destination IP, etc).  It also pastes the SPF check details.

This is the Display From is placed. This is important.  Spoofers are able to modify this.

The Mail From: in the envelope is discarded and usually placed here as the return-path: address for NDRs

So how do we prevent people from modifying the Display From?  Well DMARC redefines a second meaning for the SPF record.  It recognizes that there is a difference between the Envelope From and the Display From, and that there are legitimate reasons for them to not match.  Since SPF was originally defined to only care about Envelope From, if the Display From is different, DMARC will require a second DNS check to see if the message is allowed from that IP address.
To allow for forwarding scenarios, DMARC also allows the Display From to be cryptographically signed by DKIM, and if any unauthorized spammer or phisher were to attempt to assume that identity, the encryption would fail.
What is DKIM?  DKIM is lightweight cryptographic technology that signs the data residing in the message.  If you ever received a message from Gmail, Yahoo, or AOL then your messages were DKIM signed.  Point being is that no one will ever know youre using DKIM encryption and signing unless you look in the headers.  It's transparent.
DKIM can usually survive being forwarded, and transfered to different MTAs.  Something that SPF can't do.  Email administrators can use this to our advantage to prevent spoofing.

The problem lies with the SPF only checking the RFC2821 envelope, and not the Display From.  Since most people care about the Display From shown in an email message, and not the return path NDR, we need a solution to protect and secure this piece.
This is where DMARC comes in. DMARC allows you to use a combination of a modified SPF check or DKIM to verify the Display From.    DKIM allows you to cryptographically sign the RFC2822 Display From whenever the SPF doesn't match the Display From (which happens frequently).

Your questions

Why is it still possible to forge "From: " header in e-mails?

Some server administrators haven't implemented the latest technologies to prevent this sort of thing from happening.  One of the major things preventing adoption of these technologies is "email forwarding services" such as a mailing list software, auto-forwarders, or school alumni remailer (.forwarder).  Namely:

Either SPF or DKIM isn't configured.

A DMARC policy isn't set up.

The email client isn't displaying the verification results of the Display From and the Resent-* or Sender field.

What prevents users from simply discarding the e-mails in which the source domain of the sender doesn't match the domain of SMTP server?

What doesn't match: the envelope or the body?  Well according to email standards the envelope shouldn't match if it's going through a remailer.  In that case we need to DKIM sign the Display From and make sure the MUA verifies this.
Finally, the MUA (email client) needs to show if the sender is DMARC verified, and if someone is trying to override that with a Sender or Resent-From header.


How to make authenticity of text verifiable without third party services?

You can use commitment schemes such as the one way hash chains or Merkle trees for this purpose to provide authentication.


Is there a way to know if a server is using ssh public key or password?

Running ssh -vvv host, at some point, you will see something like:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password

The first two lines describe what methods are offered by the server and the last one is what is offered by your client (PreferredAuthentications option from ssh_config). From this log (to my Raspberry Pi), you can see that server is able to accept publickey,password authentication methods. This list might also differ for different users or for different source addresses (AuthenticationMethods options in Match block in server sshd_config), but it does not say that the authentication can succeed (eg. the user have a password or public key, nor whether the root login is allowed is you try root login).

Most of the servers will give you this "fingerprint". Some of them will give you just publickey, which says they do not accept passwords. Having server accepting passwords and not accepting pubkey is very rare.

In short, you are able to gain some information as described above, but it is not much useful in most of the cases.


Is Django's built-in CSRF protection enough?

Django is using a Double-Submit Cookie and it is accepted as a safe method of CSRF prevention. Why?  Because, It is impossible for an attacker to control the cookie filed in a CSRF attack.  A CSRF attack is relying on the fact the browser manages cookies,  and will include cookies associated with a target domain to the forged HTTP request. It is possible to read and modify the non-HTTPOnly cookies using XSS,  however, almost all Anti-CSRF measures can be undermined by XSS.

To answer your question:
Yes, Django's CSRF protection system will prevent a CSRF attack from succeeding,  so as long as the application isn't vulnerable to XSS.


In Kali Linux, how can I open files in a safe manner without disconnecting internet?

Use a virtual machine which hasn't any interface connected to the internet. Use Host-only or NAT to isolate the machine.


Are you targeting to dump all the plaintext password of all users in AD?

As far as I know, you can use mimikatz sekurlsa module in dumping  passwords, keys, pin codes, tickets from the memory of lsass in selected workstations, not in lsass of AD Server.

Refer to this https://github.com/gentilkiwi/mimikatz/wiki/module-~-sekurlsa#logonpasswords

If you want to dump all the user password hash in Domain, another thing you can do in mimikatz is DCsync which you can pull the password hash, as well as previous password hashes, it retrieves the password hashes from the NTDS.DIT. DSsync requires a privileged account with domain replication rights.

Refer to this link: https://adsecurity.org/?p=1729


Is there a way to know that a cookie is "HTTP Only" on the first user request?

Given the type of attack you're referring, to... XSS would be the most likely vector for exploitation.

As I've mentioned in my comment, the specific example you are showing is often used as an attack against 404 pages that show a fragment of the URL in the page body without sanitizing for HTML content. So yes... this is a perfectly normal type of XSS attack, but it's not the browser that's broken.

Would XSS be the only way for a session fixation attack? Probably not. If an attacker managed to first execute a Man-in-the-Middle (MITM) attack, and inject their crafted sessionID before login, it would allow them to continue to use that session from their remote machine after the attack occurred.

MITM is harder to execute than XSS... but it's still possible. And if the vector for establishing session fixation were MITM, checking HTTP-only on the cookie would be ineffective, since the cookie could have been modified over the wire.

The best protection against this vector would be TLS, and user education to keep them from clicking through certificate errors.


How to detect if someone is using airmon-ng [Aircrack-ng] in my wi-fi network

You can't tell if they're doing it because they are scanning your network promiscuously, which means they are just monitoring traffic and not generating any of their own.

You can normally prevent this type of attack by using an appropriate level of encryption and passphrase sizes, something such as WPA2-PSK instead of WPA.


Is it a security risk if the user enters html characters in a textbox and they're reflected on the next page in a website? (not script tags)

things can be bolded, in a list, italicized, etc, but script tags are not allowed due to XSS vulnerabilities.

That's not enough, your site is still vulnerable to XSS.

Here are some XSS examples that don't require


Cisco says Software-Optimized Encryption Algorithm (SEAL) is more secure than AES256, How?

I think they were lazy with the graphic and we're all overthinking this.

The graphic seems to be simply ranking them by key size, in which case the proper order should be:

  DES, 3DES, AES128, SEAL, AES192, AES256

My guess is they wanted to avoid visual clutter so they condensed all the AES's into the lowest one (added bonus: it makes SEAL look better than it is).

Whether that's flat out wrong or merely misleading is a flame war I'll stay away from.


Giving remote access via the VM, will compromise the network?

If your VM has access to the network and they can use it unsupervised then they of course have access to your network.
Also you really have to trust your VM-Product there.

What people do a lot (no judgement here) is isolating a machine using the Firewall/Packetfilter/Security-Gateway for "outsiders".

Anyways: If your companies ICT rules say, you cannot give remote access to outsiders you are pretty much given all information you need. Don't do it. You might run into legal trouble as well as all of the other problems that this rule was made up for.


Could this specific edit to the registry to fix UI scaling be harmful?

No, this file is fine. It is a Application Manifest that tells Windows that a program has no support for high-resolution displays.
Application Manifests are used to tell Windows about certain capabilities or requirements for a program.

The registry key is used to override any internal manifest files that are embedded in the program executable.

Important: If there is already a .manifest file beside the program executable (e.g. photoshop.exe.manifest for Photoshop) don't delete or change it. Or at least make a backup of this file before tinkering.

Details:

The first two <dependency> blocks are references to two common Windows libraries. Without these the program may no function correctly. (If there is no .manifest file Windows assumes these two are necessary)

The <trustInfo> block says that the program does not require elevated privileges and should be run with the same rights as the user that started it.

The <application> block tells Windows that the application was written without support for different DPI settings.

More Info on MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx


How secure is end-to-end encryption using user password?

Yes it is weaker and it has bigger risks

If a background service uses your password as an encryption key then that means they have an on demand access to your password. This is a bigger risk (you mentioned it too). It is not uncommon for people to have the same password across various services. Pushbullet doesn't actually do that. It derives a key when you enter your password and uses that key for it's encryption.

If a system uses a user generated string as a key to it's symmetric encryption scheme, then it would likely be a smaller key compared to say a random 256 bit key. Not only do smaller keys have a smaller search space for brute force but user generated keys are also susceptible to other ways of attack like predicting the modification or same key as some leaked key.


Superceding a passphrased key with a token-based key

I think you are mixing and, possibly, confusing two different concepts:

1 .- Using a Yubikey (or similar) for ease of use vs typing a long passphrase.

Yes, that's good, and has some other advantages (and inconveniences too). Go for it, but you need not change your key, just load your current one in the Yubikey. And just make sure you also keep you key in "normal" form for the day the Yubikey is lost or broken.

2 .- Moving to a new key. You don't need to for the simple fact of using a hardware token. If you do it, be it for other reasons. Don't do it just because of buying a hardware token.

And, lastly, if you want to have a new key and the advantages of a hardware token and also need to work with your old key, why not buy two tokens, one for the new key and one for the old one?


Root certificate key usage (non-self-signed end entity)

The Key Usage extension, when present, contains the exhaustive list of usage types that are allowed with the public key. When a system processes a certificate, it does so for a given purpose, and thus must verify that the Key Usage extension, if present, allows that usage. Specifically, when a system analyses a CA certificate and wants to use its public key in order to verify the signature over another certificate (that the CA purportedly issued), then this is a "certificate sign" usage; so if the CA certificate contains a Key Usage extension, then the system will require that the extension contains the keyCertSign flag.
Nothing prevents a Key Usage extension from containing other flags as well ! The verification is positive-only: systems check whether the flag they want is indeed there; they never check that a flag they don't want is absent.
Since a CA is supposed to issue certificate and CRL, it should have, on a general basis, the keyCertSign and cRLSign flags. These two flags are sufficient. If the CA does not intend to sign its own CRL, then it may omit the cRLSign flag; however, a CA without the keyCertSign flag makes little sense. One may want to include other flags if the CA key is meant to do other things as well (although this is not recommended: a general rule is that a cryptographic key should be used for one thing only). One may imagine, for instance, doing some key escrowing by encrypting the private key of issued certificates with the CA's public key, so that the CA may recover the private key under certain conditions (this is not a bad idea when the user's key is meant for data encryption).
Therefore, nothing prevents the Key Usage extension from containing other flags. Alternatively, the Key Usage extension may be missing altogether; this is equivalent to "all usages allowed".

Microsoft's "Off-line CRL signing" is just another name for "CRL signing". Indeed, the page you link to says this:

To apply this key usage if a CA certificate is requested, type the following at a command prompt, and then press ENTER:
echo 03 02 01 06>File_Name.txt

We here recognize the ASN.1/DER encoding of a BIT STRING of length 7 bits, with bits 5 and 6 set, and bits 0 to 4 cleared; this is the encoding of a Key Usage extension with flags keyCertSign and cRLSign. Though they use their own terminology, Microsoft actually conforms to the standard for that point (they did not invent a new, non-standard key usage flag for "offline CRL signing").

All of the above is the normal interpretation of certificates. It so happens that, as far as standards are concerned, "root CA certificates" do not exist. A "root" is called a trust anchor and consists in, mostly, a name (DN) and a public key. It is Traditional to encode trust anchor as "certificates", i.e. sequence of bytes which follow the encoding rules of certificates (such certificates are often self-signed, because the format for a certificate has a non-optional slot for a "signature", so there must be something in that slot).
Since this is non-standard, interpretation of certificate extension in such a certificate-like structure is open to local variants. Some implementations interpret the Key Usage extension in a root certificate in the ways explained above. Some ignore that extension altogether.
In general, it is safe (for interoperability) to fill root CA certificates with contents which would be perfectly valid if that "certificate" was a real one, instead of a convenient encoding vessel for a trust anchor.


How can I verify my machine is not vulnerable from a specific exploit?

No - it does not mean you are not vulnerable.

The patches you have installed may have fixed the particular vulnerability, but failure of a test does not automatically mean you are safe - it could just be the case that your test version is misconfigured, failed due to a local configuration or bug, or has had some other problem.

The usual way to gain assurance is to look at the CVE description and patching recommendations and cross reference with your own patching/versions.

If in doubt, use a professional penetration tester.


Why is phpMyAdmin & Apache connecting to random IPs?

Those IP-addresses are almost certainly related to phpmyadmin doing a version check.  This is to show whether your version is up-to-date. See libraries/VersionInformation.php where it will do a request for www.phpmyadmin.net. My computer returns 195.59.222.12 for this host. But because this is a CDN your results may be different.

You can disable the version check in the configuration by setting:

$cfg['VersionCheck'] = false;

in config.inc.php


Does recompiling a binary from source code make it more secure/obscure?

In general, modern compilers are deterministic.  That is, for most sets of options, given the same inputs, they will produce the same outputs.  That's why reproducible builds are even possible.
Moreover, this is the behavior you want: the compiler's job is to produce an executable or shared library that faithfully reproduces the source code when executed in object code.  If it produced wildly different behavior or binaries with different security behavior when presented with the same options, that would make it hard to reason about the behavior of the code or the security of it.
So no, recompiling a binary with the same compiler and options provides no measurable difference in security.  Features such as ASLR that use random addresses are handled by the dynamic linker at runtime and are therefore not baked into the binary.
Users may wish to compile source for various other reasons, though.  For example, users may want to modify the code, audit the code for vulnerabilities, verify that the binary produced matches the source code, or various other reasons.  Those are valuable and desirable reasons to compile from the source code even if the security properties of the binary don't change.


How do you trust your developer to be competent security wise?

To trust someone, you need to establish a basis for trust. That might be knowing about past work, questioning them about their ideology and morals and so on. There is no easy route to trust.

To trust their professional skills is no different. Have they done similar work? Who recommends them? How do they act online and in the real world? Do they exhibit qualities of trust everywhere? Do they have a track record?

But there is a slightly different question that would be a much better one for this forum.

"How can I trust code that a developer has written if I don't understand it?"

Again, there are no magic bullets but there are things you can do to reduce any risks:

Do you trust the person? e.g. the first question. If they have a track record of trust, that's a good sign.
Make an attempt to understand the code - well written code will be modular and it should be relatively easy to understand when read, even by non-programmers - if it is important and you really have nobody available to make sense of it, get someone in.

Incidentally, if someone has written code for you and it is incomprehensible then there is a pretty good likelihood that they've done a bad job.
Use tools to analyse the code for common errors and flaws.

You should also be making sure that you specify the requirements correctly. If your spec to any programmer doesn't make clear what quality criteria you need - regarding security, readability and documentation for example - you only have yourself to blame if it all goes horribly wrong.


How does the NOP sled work with MSFVenom?

Your NOP sled is there, it's just encoded. If you compare the actual end output, you can see that the 2 buffers are different lengths if you don't use a sled.

The line: 86/shikata_ga_nai succeeded with size 355 indicates the size of the main payload before the appending of the sled, so that reported size will not differ with or without a sled.


How can people send me spam emails from the future?

That's not an "exploit", rather the way e-mail works.

Datetime, sender, receiver, and all other headers of an e-mail message can be set by the sender to whatever value he wishes; mail protocols make no security check on them.  Hence, spoofing the sender of an e-mail (as spammers, scammers, and phishers often do) it's a child's play.

As Priyank correctly said, if you look at the full headers of the message you received you'll see that only the first hop (the sender) bears a date in the future; all the other hops (the MTAs between the sender and you) are correctly timestamped with the actual date.


How can cloudflare read encrypted request without private key?

One of the ways you use cloudflare is by setting the NS records for your domain to cloudflare's name servers which in turn resolve www.mydomain.com to their IP addresses. This means that when you go to www.mydomain.com setup with cloudflare, it hits one of their servers. The SSL certificate for that domain is not yours, it's theirs. Check the SSL certificate for your website, you'll see that it was issued to something.cloudflaressl.com and your domain is just one of the many in the Subject Alternative name.

The "Full SSL" setup just means that all client traffic to cloudflare is over SSL (using their certificate), and all traffic between cloudflare and your actual server is over SSL as well (using a certificate matching your server name).

As you can see, cloudflare by definition decrypts all traffic for your website but it can do so because cloudflare technically is your website. Your actual server is just something cloudflare grabs data from when it doesn't have it cached. If you think about it, how else would it cache anything?


what are the consequences of increasing the "--risk" option of sqlmap?

Level

By default sqlmap will test all GET and POST parameters specified, however in some cases you might want to test additional entry points such as HTTP headers. It is possible to specify it with specific options, but the most straight forward technique is to use the --level option. There is 5 levels available in sqlmap (default being level 1). Level 2 adds HTTP Cookie header testing, level 3 adds HTTP User-Agent/Referer headers. I can't provide to you more info about higher levels because there is no more info about them on sqlmap wiki.

Risk

Regarding the risk. There are 3 risk values. The default value is 1 which is innocuous for the majority of SQL injection points. Risk value 2 adds to the default level the tests for heavy query time-based SQL injections and value 3 adds also OR-based SQL injection tests.


I am not connecting to internet, do I still need the windows firewall on?

Firewalls generally operate at the network layer, if you have no network (you state the network adapters are disabled) there is nothing for the firewall to do, therefore, from a security perspective, turning off the firewall isn't going to be an issue.

Obviously this only holds true while the network adapters are disabled.


Buffer Overflow Works Locally But Not Remotely

EDIT: Your xinetd configuration file contains the line user = ctf, meaning the program is run as user ctf when invoked over the network, which (probably?) doesn't have read access to the flag.txt file it tries to fopen() after overflowing the buffer; hence "flag{g3t5_m3_3v3ry_t1m3}" not getting printed.

You can verify this by checking whether the returned pointer stream is NULL. I hope this demonstrates (yet again) that one should always check return values, especially when dealing with libraries handling external resources.

Leaving the original answer/guess below for the time being for reference sake:

That buffer overflows the same in both cases, but whether or not this particular example program will show you the evidence thereof depends on when its output buffer is flushed:

When a program is outputting to a terminal, output is line buffered, meaning that it's flushed whenever a newline character is printed.

In contrast, when accessing the program through xinetd, output is redirected from the program to xinetd through a unix pipe (expressed as a | in the case of shell commands), and not being a terminal, a unix pipe by default has its output block buffered, meaning it only flushes the output once the buffer fills up or the program terminates. However, if that termination happens to be a segfault, the output buffer of the program gets destroyed; meaning xinetd on the other end of the pipe receives nothing.

You can work around this by adding fflush(stdout); to the end of your flag function, which will cause the buffer to be flushed immediately.

See also this answer to a related question, and the manual page for the setbuf and fflush functions.

Credit to user Joseph Sible-Reinstate Monica for improvements and noticing a crucial inconsistency in my original theory.


What information should be scrubbed before posting email headers in public?

You can try using an email analyzer tool like this one to get a better sense of what kind of data is in the header. (ex. http://mxtoolbox.com/EmailHeaders.aspx) Note that when you use a tool like this that you are giving the provider of the service your header information so you will need to trust mxtoolbox.com if you decide to use the service.

Mask all URLs (x.xxxx.com) and the first three octets of any IP addresses (x.x.x.13). You can also mask, say half of the message ID and any other ID strings. Message IDs aren't going to be very useful to anyone unless a.) they know what mail server to look for, b.) they have access to the mail server, or c.) they know someone that has access to the server.

Depending on the issue, you could also try duplicating the problem using an email address and email server that is not attributed to you.

If the IP addresses and URLs are key to solving the issue then you will need to post them. In that case just simply mask any IPs and URLs that are directly attributed to you. (e.g. your email server, your company IP, etc.)

Also make sure that names and/or any other identifiable information is masked from the message content if you plan on posting that as well.


Should I have two accounts in my NAS (ex.: Bob as user and Poseidon as admin, both controlled by me)?

This seems like a reasonable practice. Just be sure that the password on the two accounts Bob has access to are different and that both (but especially the admin account) accounts have strong/complex passwords.

Also don't forget to rotate passwords periodically.


How to execute an exploit without user interaction?

Yes, certainly.  Malware that affects network accessible services very rarely require user interaction.   A worm such as SQL Slammer is a prime example, which propagated across the Internet looking for exposed SQL Servers that had a blank password for the sa account.

Client machines may also expose vulnerable services, but even if they don't, they can still be infected without specific user interaction through mechanisms such as drive-by-downloads, where a malicious website or component (like an ad from an infected ad network) uses a vulnerability in a browser or browser plugin to escape the sandbox and silently install.


What is the -sk ending for ssh key types?

In OpenSSH FIDO devices are supported by new public
key types "ecdsa-sk" and "ed25519-sk", along with corresponding
certificate types.
To quote:

FIDO/U2F Support

This release adds support for FIDO/U2F hardware authenticators to
OpenSSH. U2F/FIDO are open standards for inexpensive two-factor
authentication hardware that are widely used for website
authentication.  In OpenSSH FIDO devices are supported by new public
key types "ecdsa-sk" and "ed25519-sk", along with corresponding
certificate types.

Source: https://www.openssh.com/txt/release-8.2


How to react on a message about a pending account ban on Facebook?

In general, you should contact the Facebook support or abuse team about messages like this. If the warning is real, they will be happy to confirm it. If it is not real, it is itself an abusive action and Facebook will be happy to learn about it.

In your case, the mentioned URL does not point to facebook.com but a domain that is not owned by Facebook. Therefore this message is a fake and you should not open the address. (Please see What malicious things can happen when clicking on links in email?).

The easiest thing is to just ignore it. If you have some time, you can report it to Facebook as a phishing attempt.

In case you already went to that page and entered your password there, make sure to change on all sites, where you used it.


Is Window's system restoration useful for getting rid of malware?

System restore does not track all system changes. This is a myth. Most files are not covered by system restore, and certain system settings (e.g. BCD) are not affected by a restore.

System restore makes backups of:

Registry hives
Resources monitored via Windows File Protection
The local user profile
COM+ and WMI databases
IIS metabase

It also keeps tracks of changes to files with certain extensions, in order to provide diff-based backups.

Since most malware persists on disk, with a registry key to make itself start on boot, a system restore should disable most malware. It most likely will not remove the malware from the disk, though. Other persistence mechanisms, such as code injection, will allow the malware to persist beyond a system restore.


What is the safest method to send authentication data to API?

Don't use Basic authentication, it's an old authentication scheme that provides no benefit over cookie or token based session management. When using basic authentication credentials serve as a session identifier, therefore needs to be sent in every request. This has two big downsides:

Credentials are stored in the browser's cache in plaintext which may be abused in some scenarios
Session can not be terminated as it's attached to user credentials and credentials have no concept of expiracy as JWT, cookies or other kind of tokens have (Note: When saying expiracy I'm not referring to password expiracy as in "Need to change password every 3 months" but credentials as an authentication scheme)

Even if you attempt to use basic authentication to then send a session cookie browsers will keep sending the credentials in the authorization header.

If you're using AJAX requests my advice would be to stick with cookie based authentication or migrate to JWT. Note that if the API is being called from a different hostname (f.e. www.example.com calls an api in api.example.com), the corresponding CORS headers to allow credentials should be properly set


Two initial points to start:

Location tracking

If you don't want to be location-tracked, you cannot carry a smart phone, or flip phone with a cell provider contract.

The phone you carry on high frequency intervals is communicating with cell phone towers, constantly, 24/7, establishing its triangulated position with them and confirming its ability to receive calls and to transmit data. The service provider records this location history and may share it in some aggregated or sampled form with third parties that you have never heard of (along with some you have).

The phone of course has a number of hardware components the IDs for which are included in these communications and are unique, so individual physical phones have individual histories. In terms of associating those histories with specific humans, all providers make it possible for third parties to have business arrangements wherein it becomes possible to associate those IDs with specific customer account data- name, snail mail address, etc.

There are numerous third parties that had previously built out historical databases of names, including spelling variants, and snail mail addresses, and turn those into whole family histories- parents, grandparents, siblings, children- along with neighbors and other coarse location associations. Some of these are participating in more granular cell-based location tracking arrangements.

Third parties are sometimes not supposed to use this data for certain purposes, or to save it for an extended period of time, and in general they can be trusted only to completely fail to not use this data or to not save it for an extended period. From time to time these failures and the resulting exposures are egregious enough that they make the news.

(Note that if you also leave wifi on, the same is happening with hot spot providers, who are under even less obligation to not do whatever they want with the observation that MAC address x:y:z comes into range of hotspot 12345 every Friday night at 11pm, etc.)
Google

If in particular you want to not leave a data footprint with google, you cannot own or use an Android product. The Android OS is in frequent communications with Google servers to convey various sorts of telemetry. This happens independently of whether you are using any Google-branded apps.

I have not studied what happens if you use a third party OS on Android hardware. They are all to a degree based on the upstream Android source. My scepticism is that all traces of interactions with Android server infrastructure, under all edge cases and so forth, had been excised, would be high.

If you do not want to leave a data footprint with Google then you also cannot visit any websites, because nearly all of them use Google Analytics.

So, with that background, the specific questions:

  Q: if I factory reset my phone, will Google recognize me when I next use it? I presume so, as they have at least a fingerprint of hardware/installed apps/whatever.

A: Yes. Phones have unique hardware identifiers. Those identifiers are not changed with a factory reset.

  Q: In any case, if I use the same SIM card, I image they will tie me to the device.

A: There is a difference between the cell service provider- for whom the SIM card services as a unique identifier- and Google- which has its own identity infrastructure based on Gmail accounts. Google servers receiving network traffic that originated from the device then comes to Google from the cell provider egress are able in many cases, though not all, to associate that traffic with a unique account at a cell provider. But Google's identity management is not based on the SIM.

  Q: would a new 'phone help? If I did not get a new SIM/'phone number?

A new phone, in order to use the cell network, needs to be associated with an account, and that account has to have an identifiable owner- either a person with a name, SSN and address, or a business with a name, TIN, and address. So as long as you have a SIM tied to an account in your name with a cell provider, your use of whatever physical phone with that SIM will associate telemetry data with that account.

  Q: what if I get both a new SIM card/phone number and a new 'phone number simultaneously?

See above. One has to think about the concept of "account" in a different way.

  Only LinkedIn - and am happy to use that in private mode, via a VPN.

Neither of these things matters if you are authenticating with LinkedIn. All that's happening in "private" mode is that the permanent cookie LinkedIn wants to save with your browser doesn't get saved. But as long as you authenticate- surprise- they know it's you!

Similarly, VPN makes little difference. Sure, the IP address you seem to be coming from may be the VPN provider's, but many VPN setups are broken and the real IPs are easily leaked. There are also numerous tells in searches and communications on LinkedIn that can inform regarding the location of the account. LinkedIn has relationships with third parties with whom some of this data, at coarse levels of granularity, is shared.

  I am willing to make some effort, but not extremis.

This is the most important point to follow up on. What exactly is the concern with location and other kinds of tracking?

At the end of the day, ad targeting, while unpleasant, in the US at least is largely innocuous.

There are plenty of places around the world where tracking of various kinds is not innocuous, and where there isn't even the pretence to various forms of privacy. But usually the concerns in those cases center more directly on various authorities and less on specific companies.


Server pagination with key in response to fetch next page

I eventually found out that this is an overkill.
Instead I use Spring JPA PagingAndSortingRepository to manage my pages.


How to prevent "TSource Engine Query" DDoS attack?

While I have not encountered such attacks when running game servers, I always had control over the box I was running them on.

In your case, you are being flooded by A2S_INFO requests, and according to US-CERT, this kind of attack is amplified by about 5.5x that of a "standard"  query and response for information over UDP.

Information Security deals extensively with risk management. As we will consider this attack as a risk, there are three options to take (or combine):

You can mitigate it:

Use an IPS or firewall to blackhole/shunt the packets by volume of requests.
Ignore requests from certain IP addresses (limited in comparison to legitimate traffic).
Cache the requests, and respond to new ones with a cached version.

You can transfer it:

Notify your service provider that you require specialized DoS mitigation.
Transfer to a service that understands you require mitigation of UDP traffic.

You can accept it:

While not an answer you may want to hear, it is valid only if you loose little with the downtime.

Additional readings:

https://www.us-cert.gov/ncas/alerts/TA14-017A

https://developer.valvesoftware.com/wiki/Server_Queries

https://forums.alliedmods.net/showthread.php?t=273129


Can I use CloudFlare if I want to avoid NSA and FISA secret orders?

First of all, just because you use CloudFlare does not mean that the traffic will pass through the US. CloudFlare currently has 102 edges, and requests will be sent to the nearest one. This is what is called "anycast". So if someone in Europe requests your page the request will go from them to an edge somewhere in Europe, and from there to your origin. In other words, using CloudFlare will not force the majority of your traffic through the US.

Concerning the use of TLS, CloudFlare offers three different models:

Flexible SSL: Traffic is only encrypted between the end user and CloudFlare, and not between CloudFlare and your origin. Obviously, this is not safe against government actors...
Full SSL: Traffic is encrypted all the way, but you have to give CloudFlare your private key so they can decrypt traffic. So your private key is only a court order away from the NSA.
Keyless SSL: You do not how to give them your private key, but they still "decrypt, inspect and re-encrypt traffic". Read about how it works here. You don't need to have your tin foil hat on to suspect that the US government could preassure a US company into providing data from servers located outside the US.

So, in conclusion, what you need to worry about is not the traffic passing through the US, but that CloudFlare will share your decrypted traffic with the US government. There is no way for a CDN to get around this - to do their job as a reverse caching proxy, they need to decrypt the traffic. Either you trust your CDN, or you don't use one.


What is the benefit of the X-XSS-Protection: 0 header in a production environment?

Some years ago, in 2009, Internet Explorer had a really buggy early implementation of the XSS auditor, and it was found that perfectly safe websites could be made vulnerable, ironically, by that mitigation. There have also been a few security articles out there showing how IE8's and Chrome's XSS Auditor could actually be used as an attack vector to implement XSS attacks.

More recently, in 2014, XSS auditors are shown to be still very much bypassable.

Facebook did not trust implementations of XSS auditors in browsers from the beginning, and used X-XSS-Protection: 0 since 2009. This also shows some confidence in their template system (XHP), which should be strict enough to avoid introducing XSS vulnerabilities by default.


You will have fallowing problem:

What if my original computer is dead and/or I want to use some other computer, where will I get public key?
Nobody will be able to decrypt the data.

I would suggest you to do something like that:

Each user has his own passphrase
When user enter the data it gets encrypted with the symmetric key that build from some random key +  passphrase
random key get saved next to the data in the DB (but not the passphrase)
When user wants to view the data he needs to provide the passphrase and then the data get decrypted


I would call it a security trade-off rather than a security weakness.

Password managers help solve the problem of duplicate passwords (mine scolds me if I use the same password twice, so I fix it.) and of easy passwords (mine makes it easy to generate 20 characters of gibberish and "remember" it) so I don't have to write them down or use variations of my dog's name for each one.

The possible duplicate that @BadSkillz linked to above provides a good answer to your question that details the trade-offs.

  you've essentially given him one target to get all your passwords

If I was a pentester, I would identify as many password managers as possible for the organization I was targeting and then start guessing passwords, hoping that somebody used an easy one.

  is there a secure way to use programs like this?

Risk can be mitigated by two-factor authentication as offered by Yubikey or SMS messaging.  This makes it less convenient, of course.

I've found that in an effort to compete, these password managers are adding convenience "features" (such as credit checks, autofill, syncing with other devices) that introduce complexity and therefore insecurity.  These "features" need to be evaluated seperately for security.  In this case, risk can be mitigated by turning off the extra features.


Difference between secure design patterns and a generic coding guidline?

There are multiple terminology variants around there, so there won't be an absolute answer.

I'd say that "secure design pattern" is an expression which will be used by people who believe that developers are some kind of ape who can achieve Security if made sufficiently obedient to strict formal rules. While "coding guidelines" would be employed by more realistic people who have understood that developers are best cajoled with "empowerment" (and bananas), and may achieve some decent level of security if offered guidance. A really crucial requirement for security is that people understand what they are doing.


The presented case is the prime example why a self-signed certificate provides almost no security at all: it can encrypt the data but is impossible to authenticate it. Anyone can create any certificate in name of anything and have it encrypt data.

That's why there is the certification chains in HTTPS and key signing on PGP keys, for example.

In this case, Alice and Bob cannot make sure they are talking to each other. If both know a certain trustworthy John, and John signs their keys, Bob and Alice can know for sure that the key is valid.


An Apache server can be hosted and the random file can be targeted to be created in the /var/www/html folder with name random, hence all other machines can access the random file with wget command like the following:-

wget random-machine-ip/random


is spoofing CA to sign application possible?

CarbonCopy  creates a self-signed certificates which looks like the original certificate, i.e. subject, issuer etc seem to match. But, the certificate is not signed by the specified issuer at all. This means if a proper validation of the certificate is done no local trust anchor will be found and the certificate will be rejected as untrusted.


How to Scan nearby routers IP addresses using Nmap?

Are you talking about other people's public IP addresses or routers on your home network?

If you're attempting the former you best stop there, if you don't have permission you shouldn't be scanning ANYTHING. You can even get in trouble scanning your own public IP address with some ISPs.

If you're attempting the latter, give NMAP your private address range to scan, not your public address. Your routers most likely sit behind an ISP owned device that hands out private addresses to your local network.

Again, if you're scanning public IP addresses, have permission to do so, or you could get yourself into hot water.

I see now in your comment you have said the ones that are "within your Wi-Fi range". What you are attempting to do could be considered illegal, even if it is a grey-ish area. Just don't. Want to point your NMAP at something to get some practice? Find a bug bounty website (like bugcrowd or something similar), join, and point your scanners at the companies who are actually asking to be scanned. Or, setup a home lab environment. Scanning public addresses isn't a good idea.

Nmap actually hosts scanme.nmap.org for testing purposes just like this one (no DoS, DDoS, or vulnerability exploitation allowed).

If you'd like to do a little reading on the subject, nmap has a page on their website dedicated to the discussion of legality and port scanning. Essentially, port scanning isn't explicitly criminal (at least in the USA), but it is an extremely complicated issue, and you don't want to be one of the outlier cases, so it's best to only scan where you've been given permission.


These are probably the parameters of an RSA key, as you can see here: https://www.gnupg.org/documentation/manuals/gcrypt-devel/RSA-key-parameters.html

The naming convention matches with that one used in the JWK:

n-mpi
    RSA public modulus n.
e-mpi
    RSA public exponent e.
d-mpi
    RSA secret exponent d = e^-1 \bmod (p-1)(q-1).
p-mpi
    RSA secret prime p.
q-mpi
    RSA secret prime q with p < q.
u-mpi
    Multiplicative inverse u = p^-1 \bmod q.

Cheers !


How to verify if SSH Client is not recording my login information?

It is hard to verify that your login information is not being transmitted to third parties. A malicious application could choose to share your credentials directly (or at a later moment) with an attacker (possibly in encrypted form).

Possible solutions or mitigations:

Use an opensource SSH client such as ConnectBot, the source code is available so you could audit it or build it yourself.
Use SSH keys instead of password-based authentication. While an attacker can also copy the private SSH key to a third party, revoking a SSH key should be easier than changing and remembering a new password.
Trust on the (number of) users and reviews of the product, check the background of the author.


This is what you are looking for - Subresource Integrity:

http://w3c.github.io/webappsec/specs/subresourceintegrity/

Summary: http://qnimate.com/how-to-make-browsers-verify-fetched-resources-content/

Subresource integrity is only supported by the latest browsers.


How do poor-quality initialization vectors affect the security of CBC mode?

There are two distinct "dangers" with CBC. Remember that CBC works the following way: to encrypt a block, first XOR it with the previous encrypted block. The IV is just the "previous encrypted block" for the very first block to encrypt. The idea is that a block cipher is a deterministic permutation: with the same key and the same input block, you get the same output. The XOR with the previous encrypted block is meant as a "randomization". So the dangers are:

Block collisions.
Chosen-plaintext attacks.

Block collisions are when, through bad luck or lack of randomness, the XOR of a block with the previous block leads to a value which was already obtained beforehand.

For instance, if you use a fixed IV (all-zero or not, it does not matter), then two messages which begin with the same sequence of bytes will yield two encrypted streams which also begin with the same sequence of bytes. This allows outsiders ("attackers") to see that the two files were identical up to some point, which can be pinpointed with block granularity. This is considered a bad thing; encryption is supposed to prevent such kinds of leaks.

If using a counter as IV, you may still have such collisions, because counters have structure, and "normal" data also has structure. As an extreme case, suppose that the encrypted message also begins with a counter (e.g. it is part of a protocol in which messages have a header which begins with a sequence number): the counter-for-IV and that counter may cancel each other with the XOR, leading you back to the fixed-IV situation. This is bad. We really prefer it when encryption systems provide confidentiality without requiring some complex requirements on the plaintext format. A high-res clock as "counter" could also incur the same issue.

Chosen-plaintext attacks are when the attacker can choose part of the data that is to be encrypted. With CBC, if the attacker can predict the IV, then he can adjust his plaintext data to match it.

This is the basis of the BEAST attack. In the BEAST attack, the attacker tries to "see through" SSL. In SSL 3.0 and TLS 1.0, each record is encrypted with CBC, and the IV for each record is the last encrypted block of the previous record: an attacker observing the wire and in position to input some data in the stream can push just enough bytes to trigger emission of a record, observe it, and thus deduce the IV which will be used for the next record, whose contents will begin by the next byte the attacker will push.

Of all the IV generation methods you show, only the first one (IV generated with a cryptographically strong PRNG) will protect you against chosen-plaintext attacks. This is what was added to TLS 1.1.

On a specific situation like your credit cards in a database, some of the possible attacks may or may not apply. However, don't try to "cut corners" too much. If you put user data in the database, then chosen-plaintext attacks may apply: an attacker who can look at your database (e.g. with some SQL injection technique) may also act as a "basic user" to feed you with phony credit card numbers, just to see what shows up in the database.

In particular, in that scenario, if you use deterministic encryption (and that's exactly what you get with a fixed IV, be it all-zeros or not), then the attacker can simply brute-force credit card numbers: a number is 16 digits, but one of them is a checksum, and the first four or six digits are from the bank, and the remaining one are not necessarily "random", so such kinds of attacks can be effective.

Bottom-line is that if you use CBC, then you must use CBC properly, i.e. with a strongly random IV. If you prefer a monotonic counter (or clock), then don't use CBC; instead, use a mode which is known to be perfectly happy with a monotonic counter, e.g. GCM. It is already hard enough to achieve security when cryptographic algorithms are used by the book, so any "creativity" here is to be shunned.

And, of course, contents which has been encrypted with a given key is no more secret than the key itself. When an attacker has read access to your database, he might have read access to more than the database -- in particular, to the encryption key itself. It depends on where you store the key, and also on the extent of the attacker's access (SQL injection, stolen backup tape, front-end system complete hijack,...).


Would a massive blacklist of guessable passwords be useful?

Those passwords are based on offline attack -- that is, the attacker has the hash and is trying to crack it.  If that's your concern, use something like scrypt, bcrypt, or PBKDF2 to harden your password hashes and make them harder to attack offline.

If you're concerned about online attack, just limit the rate of account logins with some sort of exponential backoff, or block the IP after some number of bad login attempts.  Either way, you'll make the online attack so slow that the attacker won't get past 'p4ssw0rd'.


What encryption and signature systems (don't?) allow for plausible deniability of the OP's key being used?

If it is encrypted, just knowing the public key it may be possible to conceal the key that was used. As the public key will just be encrypting a random key for a symmetric cipher, a large enough key length means it can't be bruteforced. The owner of the private key simply decrypts the key and tries if the data is properly decrypted (eg. an attached hmac). Mallory simply can't test all possible keys.

On the other hand, if the data is signed, by its very definition it must be possible to verify that key A signed data. So Mallory could always determine which of the public keys it has signed that file.
(OTOH if Mallory doesn't have your key or eg. a database with the keys from every suspect, even on schemas that contain "metadata" it typically only provides the fingerprint of the key used, so it's useless)

The simple answer is to encrypt(sign(data)).

Obiously, the metadata -such as sending email account- shouldn't be leaking your identity.

This only achieves plausible deniability for the given scenario of blindly matching keys to messages. Bob would be perfectly able to prove that the message he received was sent by Alice. Usually, the term plausible deniability is used to mean that Alice can even deny that she wrote that. For that you can use a protocol like OTR.


Where are the symmetric keys stored when using ssh?

With SSH, TLS and similar protocols the symmetric key is created during a handshake phase using key exchange protocols like Diffie-Hellman Key Exchange. The generated key is kept in memory for the duration of the session, i.e it is not written to disk. Thus to get access to the key you would need to dump the memory of the client or server or would need to rely on functions to explicitly export the key, if available.


The solution is garbage because they store unsalted MD5 hashes of passwords in the database. That is the weakest link in the solution. Nothing else matters.


CVE-2017-7494 Samba remote call. How do I know if Samba is running or not on my Ubuntu server?

I feel that the other answers, while undoubtedly useful, do not answer exactly what you asked for... that is, whether Samba is running, but either whether Samba was installed at some time (by looking at files on disk, which might be left over) or whether Samba is installed with the system's knowledge, which might not be always the case.

dpkg will not tell you whether Samba is installed; it will tell you whether it was installed using dpkg/apt or not. If you install Samba from scratch via a tarball, for example, the whole Ubuntu installation system will truthfully tell you that it's not aware of Samba ever having been installed... even if Samba is up and running.

To verify that samba is installed you do indeed try to run it:

smbd -V

If installed (even if it is not running), it will report its version.

The same check can be done with the client part of the Samba suite, which is not necessarily installed with the server:

smbclient --version

For the file system support, just in case, you do mount.cifs -V instead. Strictly speaking this is CIFS support, not Samba.

To know whether the Samba program is running, you can either check the running processes of the Samba suite (smbd, nmbd, winbind):

sudo ps waux | grep "[sn]mbd"

This will return either nothing if the program is not running, or a list of the processes part of the Samba suite:

root     23942  0.0  0.3 299100 15176 ?        Ss   May24   0:00 /usr/sbin/smbd -D
root     23943  0.0  0.1 298532  4744 ?        S    May24   0:00 /usr/sbin/smbd -D
root     23944  0.0  0.1 298556  7408 ?        S    May24   0:00 /usr/sbin/smbd -D
root     23946  0.0  0.2 299092  9504 ?        S    May24   0:00 /usr/sbin/smbd -D

Or you can verify whether they're listening to ports:

sudo netstat -nap | grep "[sn]mbd"

This will return nothing if the processes are not running, or it will tell you which ports are they listening to:

tcp        0      0 192.168.2.200:445       0.0.0.0:*               LISTEN      23942/smbd
tcp        0      0 192.168.2.200:139       0.0.0.0:*               LISTEN      23942/smbd

Above, for example, my smbd is listening on ALL (0.0.0.0) remote addresses.

Another way is to check whether anything is listening in Samba's place on TCP ports 139 and 445:

sudo fuser -n tcp 139

This will return either nothing (program not running) or the PID of the running process:

139/tcp:             23942


How to prevent ddos and brute-force attack by restricting IP's on Wordpress website

I read that you don't want to install plugins, but there is no other practical way to do this given your other restrictions. Wordpress actually has some good info I found after doing a little searching:
https://wordpress.org/support/article/brute-force-attacks/
I don't have much experience with it so someone can probably suggest a specific plugin, but there is a list of them under the plugins suggestion you could test. This way a specific IP failing a specific amount of times will be locked out, which makes brute forcing impractical and shouldn't effect you at all.


How can you find out who hacked your accounts and sent out dirty messages on your email and snap chat

Firstly, for your college email account you can consult and report it to your school administration. They will investigate your login activity and they can check the email header to figure out the source of those malicious emails. So basically they will do a forensic scan of your account.

Secondly, for your Snapchat Account, you should enable security features of login activity and also the 2 factor authentication by adding your cellphone number or you can use Google authenticator https://support.google.com/accounts/answer/1066447?hl=en

To figure out who accessed your account, the Snapchat team should be more than happy to assist or if you want to go further with this, 3rd party services can do the investigation for you as they know the legal procedures need to be followed.

To stay alert, I would recommend signing up to services like https://haveibeenpwned.com may be your email was leaked on a certain site and they got access to your credentials.


Possible to use buffer overflow on DLL-injected code?

Bufferoverflow allows an attacker to let the processor jump to an arbitrary address of the process' memory. Since the DLL injected code will be part of the attacked process' address space, it is possible to jump to the injected code. The challenge will be to find out what foo's address is.