How to establish a secure channel with authenticated and authorized access to a remote entity I have the following problem:

There are 3 parties A, B and X.
X is holding 2 entities on behalf of A and B.
A communicates with X to operate it's own entity. B also communicates with X to operate it's own entity.
Permissions could be revoked at any time for A and B to access their entities.
Permission revocation is done by Y.

I want to do all this in a secure way.

First, I will try to boil it down to some requirements. Does this look correct?

I need a secure channel between A <-> X and B <-> X so that no MITM can happen
X needs to be able to authenticate who the caller is. Is it A or B who is trying to access the entity.
X needs to be able to authorize the operation on the entity. That is, is the operation still permitted or revoked?

My proposal:

A (likewise B) contacts Y with it's ID and the permissions it is requesting ( -- OAuth style or something else ... not sure how this works)
Y approves (or rejects) the permission. If approved, it returns back a token ( -- this token is encrypted and can only be decrypted by X. It is signed by Y and X can verify that Y has signed this token. The token contains a unique id as well a a note saying "I verify that the token holder is actually A")
A establishes a TLS channel with X.
A provides the token to X.
X verifies the signature of the token. If successful, A is permitted to perform the operation on it's corresponding entity.

Question:

Does this look correct? Any flaws?
What will I do if I cannot use a CA to establish a TLS channel?

You need to ensure the following items for the approach to work:

There needs to be a way to ensure that the tokens can't be replayed even if by just A.
There needs to be a way for Y to invalidate the tokens. Otherwise A's token will provide them with access even after Y has revoked it.

Also, Is it necessary for the tokens to be only decrypted by X? What if the tokens are just signed by Y and X can read them. This will make the design easier while ensuring that nobody other than Y generates the token.


Connection timeout error using HTTP Status Code Checkers on a website PROBLEM

When I use online tools to test www.bestbuy.com URL's, I get a timeout connection error.

By online tools I mean HTTP Status Code Checkers or Redirection Checkers.

EXPECTED BEHAVIOUR

I expect to receive a 200 HTTP Status Code, same as if I were visiting the website with a normal web client.

MY GOAL

My goal is to understand exactly what is causing this behaviour (technology and configuration). I'm really curious about this implementation since it can be useful for future projects.

WHAT I TRIED

I tried different methods to replicate the connection timeout error, but couldn't achieve my goal.

TEST 1

First thing I did was to check different online tools. Tested at least 20 of them, and everytime I receive a connection timeout response. Example:

web-sniffer.net
builtwith.com
urlitor.com
httpstatus.io
tools.searchbrain.it/chain-of-fools
redirect-checker.org
internetmarketingninjas.com/header-checker

My first thought was they were blocking specific IP ranges, but some of the tools I used were not that famous. Only tool that didn't hang up is W3 Techs Sites Info, but it may be old data.

In this case I tested with different configurations of User Agents and HTTP Headers, using exactly the same as if requesting the URL with my browser.

TEST 2

Tried to replicate the behaviour with a browser. Tested different user agents and HTTP headers. Also navigated the website without javascript, cookies or cache enabled, but nothing.

Some User Agents get a 403 Forbidden HTTP Status code, but most of the time I still get a 200.

TEST 3

I very much doubted that the online tools that I used ALL left some kind of fingerprint. I mean, in the end is still a simple HTTP request, right?

But to leave no stone unturned I still quickly set up two local HTTP Status code checkers, one in PHP using cURL and the other in Python using Flask and Requests.

In this case I also tried different setups, HTTP Headers and configurations. The only time I receive a timeout is if I don't set up a User Agent at all, but in all the other scenarios I still always get a 200.

TEST 4

I also researched online about Akamai and Nginx configurations that could be causing this behaviour, but found nothing definitive.

Tried visiting the website through the TOR network and I get a 403 Forbidden.

CONCLUSION

So my final conclusion is that of course there are different network security measures in place, but I really don't know what is causing the timeout connection error using online tools.

There is the theory of the blocked IP ranges, but as I said before I used multiple tools, even not so famous ones, so my doubt persist. And if that is the case I still don't know exactly what kind of configuration could block all those online tools or if a public list exist because is the first time I see this happen when analyzing a website for competitive research.

I even reach out one employee at BESTBUY in charge of network and IT management, but unfortunately couldn't help with this issue.

I am probably missing something because I'm not an expert in this matter and maybe I am tackling the issue from the wrong perspective, so thought the only place I could get a definitive answer was here at StackExchange.

Help a poor fellow, cannot sleep with unsolved problems and I'm running out of my coffee supply :D

Without seeing the internals of Best Buy's network and their firewall/network device configuration it would be hard/impossible to come to a definitive answer for this.

With that said, we could speculate about possibilities.

you've already eliminated possible problems with request headers by trying a variety of options.

The most likely alternative, to me, would be that the application is filtering based on the source IP address of the request.

I notice when I visit that page from the UK that it asks which country I'm from, recognizing that I'm not in the USA/Canada/Mexico.  So it's likely that they're using some form of GeoIP lookup database to establish that fact.

It could be that their system is doing additional checking on the source IP addresses used to contact it and is recognizing that they're not from ranges belonging to residential ISPs in the US (I'd expect most of these services to be hosted in a hosting company/cloud company network somewhere).

As it could determine that the source IP address is unlikely to be a real customer at that point, it could choose to block it.

Now this could very well not be the case, however if they're not filtering based on something in the request format, the other piece of information that they could be making a choice based on would be source IP address.


What is the term for adding benign code/behavior to malware to evade antiviruses? Some malware authors add benign code/behavior to their malware just to throw off antiviruses and IDSs which employ machine learning to detect malware. There is a name for this technique (and even a Wikipedia page somewhere) but I can't seem to figure out what it is or find it on Google.

I think the technique is called obfuscation using "dead code insertion" where you add routines that don't perform any function to throw off AV static and dynamic analysis.
I read it here
Also this wiki leaks paper shows experiments with AV that use techniques of adding functions that dont do anything but bypass AV dynamic analysis


What are some important concepts to teach developers about cross-site scripting (XSS)? I'm helping with a one-hour training for developers (~100 of them) on cross-site scripting. What are some concepts you think are indispensable to get across to them? Right now we have:

Difference between reflected and stored
Layers of defense (WAFs, browser defenses, server headers, and secure coding)
Secure coding and context of encoding parameters

And most of all, the potential impact of vulnerabilities.

From a developer's perspective, the first two points you have are not very relevant. Stored and Reflected XSS have the same mitigation: properly escape things you output according to their context. Layers of defense will likely only be viewed as an excuse for poorly implementing this mitigation: "The WAF will catch it for me."

Instead, focus on these code hygiene practices:

Validate, not escape, at input. Input validation should be only for ensuring the input makes sense, not that it is "safe". It's impossible to know at this point whether it is safe, since you don't know all the places it will be used.
Assume all data is unsafe. Never make the assumption that some data has been escaped, or does not include tags or quotes or entities or whatever. Understand that unsafe input can come from anywhere: HTTP headers, cookies, URL parameters, bulk import data, etc.
Escape at point of use. Escape the data for the context in which it is used, when it is used. Only want to escape once to improve performance? Name the destination variable according to where it is safe to use: jsstringsafeEmail, htmlattrsafeColor, htmltextsafeFullName, etc.


Can a TLS HMAC be used after the fact to verify the authenticity of a message? If I were to capture a TLS session (and shared secrets) between myself and a web site operated by another party, could I later use the HMAC (or something else?) to verify to a third-party the authenticity of the downloaded data, i.e. prove that I did not alter it?

Note that your description is missing an important party: that to whom you wish to prove you did not alter the message.  The question really is, can that party trust you not to produce a message you didn't exchange with the other party in the TLS session.

The answer is no, because you have saved the key, and thus you can generate valid tags for any messages as you like, which you might not have sent to the other end of the TLS connection.


Do the most used browsers have similar security? I read that Pwn2Own stopped attacking Firefox, apparently because it didn't make "serious security improvements" since the last competition.

Should I understand it as "Firefox is significantly more vulnerable than other browsers", or can I continue to use it safely? Is there currently any big difference in the security of Chrome, Firefox, Edge, Opera and Safari?

I know all the advices one must use to stay secure on the Web. I'm just not comfortable using a browser that could easily be exploited.

I know of two examples of differences in browser security:

The SameSite cookie flag is a countermeasure against CSRF. Currently Chrome and Opera are the only browsers that support it.

For an extreme example, there is Chromodo, a customized version of Chrome that disables some important security features.

So it definitely matters which browser you are using, but it may not be possible to objectively say one browser is "more secure" than another.


Should antivirus HTTPS scanning be left on? Is it secure? Some antivirus software MitMs, or through other methods, HTTPS connections in order to scan for malware, for example, Avast, and maybe other vendors too.

Is the method they (let's say Avast as an example) use secure? Is their claim that the data never leaves my computer true?
Should HTTPS connections really be scanned? I'm not asking whether HTTPS automatically protects from viruses, it doesn't, but is the probability of getting such malware from an HTTPS secured website high enough to enable this feature?

~4 sources that will make you think twice about the security of AV TLS decryption:
Antivirus Software Weakens HTTPS Security: Researcher

“It seems strange that it turned into something people consider a
legitimate security technology. Filtering should happen on the
endpoint or not at all. Browsers do a lot these days to make your
HTTPS connections more secure. Please don't mess with that.”
ESET representatives said the company is aware of the issues presented
by the researcher.
The researcher reported that Kaspersky’s product is vulnerable to
FREAK attacks, in which an attacker can force clients to use weaker,
export-grade RSA encryption. This can be problematic considering that
Kaspersky intercepts HTTPS traffic by default for important websites,
the expert said.
“I also found a number of other issues. ESET doesn't support TLS 1.2
and therefore uses a less secure encryption algorithm. Avast and ESET
don't support OCSP stapling. Kaspersky enables the insecure TLS
compression feature that will make a user vulnerable to the CRIME
attack,” Böck reported. “Both Avast and Kaspersky accept nonsensical
parameters for Diffie Hellman key exchanges with a size of 8 bit.
Avast is especially interesting because it bundles the Google Chrome
browser. It installs a browser with advanced HTTPS features and lowers
its security right away.”

That was in 2015;
And:

Validating TLS certificates in non-browser software is the most
dangerous code in the world

See "DNS Over TLS" here: https://dnscrypt.info/faq or the source here.
Some Bitdefender products break HTTPS certificate revocation (Source):

If a website’s certificate has been revoked by a certificate
authority—for example, because it was issued fraudulently or because
its private key was compromised by hackers—affected Bitdefender
products will still accept it as valid. More importantly, as part of
their HTTPS scanning feature, they will convert the revoked
certificate into a certificate that local browsers will trust, despite
the fact that under normal circumstances those browsers would reject
the original certificate.

Ditch the HTTPS Scanning feature of your antivirus (Source):

Users might be vulnerable while accessing secure HTTPS websites, and
their antivirus is to blame. A thorough research, conducted by experts
at Mozilla Firefox, Google, Cloudflare and three American
universities, shows that several popular antivirus software
“drastically reduce connection security” and expose users to
decryption attacks. This isn't new by any means and the HTTPS
interception technique used by anti-viruses has been the subject of
debate for several years.
And here's the problem: Security software vendors are poorly handing
inspection after the TLS handshake, according to the researchers.
They’ve looked at eight billion TLS handshakes generated by Firefox,
Chrome, Safari, and Internet Explorer, with antivirus software on.
Researchers have analyzed Firefox’s update servers, a set of popular
e-commerce websites and the Cloudflare content distribution network.
“In each case, we find more than an order of magnitude more
interception than previously estimated,” the paper reads. They found
interception happening on four percent of connections to Mozilla's
Firefox update servers, 6.2 percent of e-commerce sites, and 10.9
percent of US Cloudflare connections. What’s worrying is that when
intercepted, 97 percent of Firefox, 32 percent of e-commerce, and 54
percent of Cloudflare connections became less secure.
“As a class, interception products drastically reduce connection
security. Most concernedly, 62% of traffic that traverses a network
middlebox has reduced security and 58% of middlebox connections have
severe vulnerabilities,” the report reads.
Not only do security software reduce connection security, but also
introduce vulnerabilities such as failure to validate certificates.

That was in 2017,
The large attack surface and many variables of TLS stack like TLS cipher suite/false_start/secure negotiation, session identifiers, RTT-0, downgrade protection, Privacy oriented OCSP Stapling/public key pinning, and other parameters may be broken, downgraded, modified or unavailable by AV TLS and replace specifications of the browser. To be as secure as a browser, all these security mechanisms must be included, and kept up with the times, which is something dedicated web-browsers excel in. It would be best if they could detect and mimic browser settings. HTTPS interception also affects non browser connections. Hopefully they have and will continue to improve rapidly, but the "most dangerous code in the world" is something I would be cautious with. Replacing hundreds of points of failure (one cert in place of hundreds) with one point of failure is risky. Cutting this out may be a necessary change home & enterprise environments to ensure malware is not inadvertently assisted by MITM AV or Middlebox AV. Better alternatives include cisco Encrypted Traffic Analytics: Detection without Decryption


Is there a way to answer security questions privately while in public? Is there a strategy for answering security questions via telephone modestly securely while in an insecure environment? For example: I am at a coffee shop and am locked out of my account, I call the helpdesk to unlock and they ask for my userID, DOB, and last4 of social. I would like to protect all of that information so that no one listening could catch it.

For instance, I imagine a system where the technician says, is the month Jan, I say no, then ask, is it Feb, I say no, then is it Mar, I say yes... and so forth until we confirm all the secrets. This is really the only method I can think of short of a situation where the technician plays a game of 'is this your card'. There are drawbacks to both of these methods and so I'm wondering if there are better ones?

Also is this threat even real and/or is it worth securing against?

You could standardize on all secret questions being number based.  Then, when the questions are asked, they could include a bit on the end to add or subtract some.

So for instance, the questions would be:

What is the last four of your social security number plus 11?
What is the street number of the house you grew up in, minus 2?
What is your birth year plus 13?

Anyone hearing the answers would hear only the numbers, without knowing the actual questions.  Each time the questions are asked, the numbers on the end could be randomized by the caller, so they would be different every time.  (For instance, the next time, the questions would be, "What is the last four of your social security number minus 7?, etc.")


Best practices for securing an iPhone As this question on voicemail protection got answers veering more to protecting the mobile phone, I thought I should add a specific question on this topic.

There is already a question on protecting your Android phone

There is a wide range of attacks including the THC femtocell attack so all pointers welcome.

You have to define what you are trying to protect and against whom. There are several assets:

Your geographical position
Who you call and who calls you
The contents of your conversations and SMS
Your phone bill

Then things are quite different, depending on whether the phone operator is a cooperative friend, a not-too-competent neutral third party, or an active attacker.

The phone bill is the simplest. If the operator is an attacker, then you are doomed. The theoretical countermeasure would be a tamper-resistant phone which records usage in a way which could convince a judge; I do not know of anything like that, although most phones keep a log of the most recent calls. If the operator is not an attacker, you have to trust the operator for not being hacked, and you also need to avoid your phone getting hacked, too. Smartphones, being full-fledge complex computers in their own right, with one or several network links active at all times (think about Bluetooth...), are susceptible to external hacking. So a non-smartphone may be advisable.

Anonymity concerns (geographical position, who you call and who calls you) are a hard problem. I heard that in some places, police services use cell phones to keep track of protesters in manifestations: a fake base station is setup, and broadcasts a big fat message of "I am the most powerful base station here, all phones in vicinity are to report immediately", and all the phones gladly answer "I am here !". If that situation is a concern for you, then you will need to "rotate" through numerous, short-lived receptors and accounts (obtained with fake names, of course), so this is expensive; and you will not receive calls, unless you use some VoIP software inside a VPN (so the operator sees that you connect to the VPN, but not what exits at the other side of that VPN).

A famous example of an anonymity concern, involving a satellite phone, occurred in 1996 with somewhat drastic consequences.

For the conversation contents, this is a question of encryption. In GSM phones, an algorithm called "A5" is used, with several variants: A5/0, A5/1, A5/2 and A5/3. A5/0 is "no encryption at all". A5/2 is "weak encryption", meant for export to countries of questionable reputation. A5/1 is a stream cipher which uses a 64-bit key but is actually weaker than that, with protection around 242.7 (the number may vary depending on how you count and some operational conditions such as the size of known cleartext; see this article for some details); that's much too low for comfort, so it should be assumed that the contents of A5/1-protected data can be learned by determined attackers (the Wikipedia page on A5/1 also cites some cracking efforts based on rainbow tables). A5/3 is also known as KASUMI and comes from the UMTS and GPRS worlds; it has some weaknesses but nothing fatal so far.

In any way, A5 encryption is only from the mobile phone to the nearest base station, so if the operator is an attacker (e.g. you are trying to evade legitimate eavesdropping by law enforcement agencies with which operators cooperate), then A5/x will not help you, regardless of what 'x' is. To survive that kind of attack, you need end-to-end encryption, which in turn requires a change of protocol, hence VoIP with custom encryption. An existing product is Zfone, from Phil Zimmermann (of PGP fame).

The biggest security conundrum here is that the standard protocols being quite bad at ensuring your security, you need a smartphone with custom software to obtain a reasonable level of protection; but security of the phone itself is also of paramount importance, and is much easier to achieve with a dumbphone.


Is CSRF token validation required for http method other than POST and GET? If I set actions for logged in users to be performed through HTTP methods other than GET or POST, then Javascript HTTP requests respecting the Same Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS) is the only way to perform those actions with credentials isn't it? (Since it seems to not be possible with basic HTML.)

In modern browsers, requests with methods other than HEAD, GET and POST can't be sent cross-origin without a CORS permission.

If your application verifies that the request method is, say, PUT, an attacker can't forge that request in a CSRF attack, unless you explicitly give permission, e.g. with an Access-Control-Allow-Methods: PUT header.

See also: Examples of access control scenarios


Perfect forward secrecy in Instant Messaging with multiple devices I have read multiple sites online about PFS and DH but I still have a few questions.

I understand that in order to have PFS you must use different keys to encrypt messages. So your IM client could be generating a new key for every message you write (or every few messages).

This would mean that DH exchange will happen to generate a new key and then both IM clients should have that key so the sender can encrypt the message with it and the receiver can decrypt it.

Did I understood it right so far ?

So in that case, if I am correct, not only the private key is very important, but also each key used to encrypt/decrypt every message.

If any of those are leaked, security is compromised. Therefore I am guessing that is very important that both private key and encryption keys are always protected and stored only in the end user's device.

But then I see that some IM clients allow using multiple devices to access encrypted messages.

Does this mean that the private key and the encryption keys would need to be copied to every device ? Is not this a security risk ?

Is there any protocol or cryptographic method to copy this private key and encryption keys securely to other devices ?

Thanks.

I understand that in order to have PFS you must use different keys to
  encrypt messages. So your IM client could be generating a new key for
  every message you write (or every few messages).

  This would mean that DH exchange will happen to generate a new key and
  then both IM clients should have that key so the sender can encrypt
  the message with it and the receiver can decrypt it.

  Did I understood it right so far ?

Not quite.

PFS is the property that plaintext confidentiality for passively captured ciphertexts is retained even if a long-term key is compromised.

As an example of a system without PFS, in traditional SSL/TLS configurations one might use the long-term RSA keypair (from the certificate) as a way to exchange a session key. This is called static key exchange. The problem is that if an attacker records all sessions and compromises the certificate at a later date, they may decrypt those sessions using the RSA key. This is, understandably, a problem.

TLS uses Diffie-Hellman (DH) in an ephemeral manner, known as DHE. Ephemeral, in this case, means that the keys or parameters used to exchange the key are discarded after the session is created.

Diffie-Hellman has the property that two parties can agree upon a shared secret in a context where an attacker is watching, without exposing that secret to an attacker. An incredibly simplified (mathematically incorrect, but more intuitive) description of DH would be that Alice generates a pair of values As and Ap (secret and public) and Bob generates a pair of values Bs and Bp (again, secret and public), each with certain special mathematical properties. By exchanging Ap and Bp, both Alice and Bob can calculate the same resulting secret value x. If Eve, an eavesdropper, listens in on the exchange of these values (i.e. she knows both Ap and Bp), she cannot calculate x because she does not know As and Bs (i.e. the secret parts).

As a short aside, DH on its own has a problem: an active attacker can man-in-the-middle the DH exchange and interpose their own secret values in order to compromise the connection. DH alone has no resistance to active tampering, and we generally call this kind of usage "anonymous DH" or ADH. In TLS we solve this by signing the exchanged DH values with the long-term RSA key in order to prove that they have not been modified.

Diffie-Hellman Ephemeral (DHE) works by randomly generating the DH secrets for each session, exchanging the public parts, then throwing those secrets away after x is calculated. You'll notice in the exchange between Alice and Bob above that the As and Bs parts are never transmitted, and that Eve cannot calculate x without them. Once As and Bs are discarded, nobody can recreate x. If you compromise the long-term RSA key, you cannot recover plaintexts from previously recorded sessions and ciphertexts.

  But then I see that some IM clients allow using multiple devices to
  access encrypted messages.

  Does this mean that the private key and the encryption keys would need
  to be copied to every device ? Is not this a security risk ?

  Is there any protocol or cryptographic method to copy this private key and encryption keys securely to other devices ?

Multi-party encryption is complicated and there are a bunch of different mechanisms that are involved. I personally think that Signal's double ratchet algorithm is one of the most easily understood and elegant solutions to the problem, but even that is a fairly involved system. I recommend that you read the paper as it is very well written with minimal crypto jargon.

The way these protocols generally work is that you have some sort of long-term identity key that gets exchanged between devices in some way (e.g. via QR code) when you pair them to your account. This key gives you different levels of access depending on the protocol - in the case of Signal and WhatsApp it allows that device to "join" a group chat in your name. When any party in the group sends a message, it encrypts it for each of the other parties (including each individual party sharing the same identity) so that they can decrypt it. I recommend reading this other question for a wider background on how WhatsApp (and Signal) perform group chats. One critical factor here is that the identity key is only used to sign the prekey, which is effectively a surrogate for the identity key which can be rotated periodically. This means that the long-term key itself is never used to sign bulk data, which limits its exposure significantly and allows for it to be expunged from memory after a prekey is signed.

The ratchet part of the algorithm refers to some cryptographic processes which allow for keys to be continually derived in a chain. These processes allow an individual derived key to become compromised without compromising other keys in the chain. There generally need to be multiple different key compromises of different types in order to more completely compromise the chain and decrypt prior and future messages. This results in a number of forward secrecy properties for messages.

To answer your questions more directly: the identity key is security-critical (although there are ways to recover from a compromised identity key) but it does not impact forward-secrecy directly. The public part of the identity key is published to the Signal servers, but the private part is intended to stay on the device. Exchanging the private key to a new device is done via QR code or similar (implementation specific) and is generally considered secure because it is a local physical operation.


is it possible to create a login "key" out of a USB drive? I was recently thinking about keeping my computer secure from physical access, and i decided that the safest way to keep my data under lock and key, was to do just that: Create a lock and key out of a USB drive. My idea is this: A USB drive would act as a "Key" preventing login unless it was inserted. Is this possible, and can it be done for a reasonable price? if so, how could i manage that, and what sort of programs should i look into? i am running Mac OSX Mountain Lion if it is of any consequence.

I don't think he is referring the USB-key solution as a sole authentication method, but as an addition to the normal username-password authentication.

There are two methods I can think of, in order to implement this:
1. Encrypt the entire hard drive, and put the key-file on a USB drive.
2. Leave disk unencrypted and use the USB drive for a login purpose only.

Let's review:
1. Use truecrypt or dm-crypt (or their Mac OS X equivalents) in order to encrypt the entire hard drive using a key-file and storing it on a USB drive. The obvious and major drawback: losing the USB drive will cause the loss of the entire filesystem.
2. Use solutions like pam_usb (http://pamusb.org/)

Do not forget to take in account remote login considerations!


Why is it not recommend to use permanent validity of certificate for public key As we know it is not recommended to provide permanent validity of certificate for public key. I don't know why. Could you give me some reasons ?

Just to be precise, an X.509 certificate has a non-optional end of validity date, so you cannot make a standard-compliant "permanent" certificate. However, that date can be encoded as a GeneralizedTime which can encode instants up to the end of year 9999, which is far enough in the future to be considered "forever".

Note that there is a binary equivalent to the Y2K problem, called the Year 2038 problem, so a certificate whose end-of-validity is beyond January 19th, 2038, may incur interoperability issues. Usually, Windows systems do not have any trouble with such dates (because they use 64-bit integers for their internal time representation), but application that use old libraries from the Unix world (in particular OpenSSL), and use them poorly, may have difficulty handling such a certificate. It is thus recommended, for now, to avoid setting the end-of-validity date beyond 2037.

Anyway, the official reason for having an end-of-validity date is to support revocation. When a certificate is revoked, its serial number is added to a list called the CRL, periodically published by the CA. The serial number will need to be kept as part of the CRL as long as the certificate is "valid" (with regards to its end-of-validity date). Thus, the end-of-validity is there to allow pruning old entries from CRL; if certificates were permanent, then CRL would grow indefinitely, which could be a problem since they are supposed to be generated and re-downloaded frequently.

In an ideal world, or at least a better world, we would not use CRL but OCSP. An OCSP response is like a CRL that talks about a unique certificate. In a pure-OCSP revocation system, permanent certificates would not be an issue at all.

The less-official reason of the end-of-validity date is that it works as renewal fee due date. When a commercial CA sells certificates, the CA really loves it when customers must come back buy a renewal every year.


John the Ripper on shadow file If I have a shadow file I want to crack the hashes of, will john start with the first user and go through all attempts at that, then move on to the next?

If that's the case, if the first user's hash is encrypted with sha512, but the rest are using md5, how can I tell john to not waste time on the sha512 ones and only work on the easier md5 ones? I've been looking up john examples, but can't seem to figure this out. Basically I'm looking for like a "low-hanging fruit" flag to use with john on a shadow file.

--format=md5 option I think is what you are looking for, here are some pretty decent guides on options

http://www.openwall.com/john/doc/OPTIONS.shtml

http://www.liatsisfotis.com/2012/12/crack-passwords-using-john-ripper.html


Is storing encrypted and hashed versions of the same data less secure? I have some database columns which are encrypted. Obviously there is no way to filter these by plaintext value. As the data stored in the db is ~~salted~~ combined with the IV, there is no way to recreate the cypher text.

The value in the database is created like so:

db_value = base64(json([iv, cypher, mac]))

...so without the IV, I can't create db_value. And I can't find the IV without reading db_value.

I could get around this by creating another column to store a hash of the data.

Is this a bad idea? Would keeping the data in multiple formats like this make it less secure?

So, you want to be able to quickly test if some data is stored in the encrypted database, without having to decrypt the database.

Now, if you can search this database without decrypting (without the key) then so can an attacker search the database without the key. So, yes in general this is less secure.


Does Rainbow Table Not Require Decompression? I understand that a rainbow table solves the storage problem when one attacks a password using precomputed hashes. However, since rainbow tables are essentially a compressed version of the hashes--dont they have to be decompressed before comparing with the target hashes? Isnt this decompression process expensive? How does the time used decompressing a rainbow table compare to that used in computing hashes from scratch?

Your basic premise is wrong: a rainbow table is not just a compressed list of every possible hash lookup, and you do still need to do some hashing on the fly. Instead, it's a way of exploiting the nature of hashes to avoid storing the lookups in the first place, and minimise the amount you need to re-compute.

Wikipedia has quite a detailed explanation and there is an existing question here with good answers, but the basic idea is you create a table like this:

Start with a particular password guess
Hash it
Take the hashed value as the next password guess (after applying some reproducible transform)
Hash that
Repeat steps 3 and 4 a set number of times
Store only the original guess, and the final hash. It is this that makes the rainbow table smaller than a full lookup table.

From the values you've stored, you can get back all the guesses generated at step 3. In a sense, each pair of { first guess, last hash } "compresses" the full chain of generated guesses.

But the trick is you don't need to try all the chains to reverse a hash, because if you take the hash you're attacking and start at step 2, you will eventually end up at one of the final hashes you stored (at step 6). Once you've found that, you can recreate ("decompress", if you like) just that one chain, by going from step 1 (the stored password guess) and generating all the intermediate guesses.

An important difference between this and compression is that you can make the stored table as small as you want, by making the chains longer - you'll just have to spend longer re-generating hashes to choose a chain, and to re-create the chosen chain. You could have a million chains of length ten, or ten of length one million, trading storage against CPU time.

It is of course possible to compress the resulting data using any algorithm you like. Some of these will require decompressing the entire table before searching it, others might arrange the data so that it is still searchable but takes up less space. But it would also be possible to store the entire rainbow table as, say, a sorted list on a fast SSD, and you would still have saved space over a full hash table because you are only storing the start and end of each chain, not every possible hash.


Determining strength of truncated HMAC I have data stored on a device which I must guarantee integrity, for ease of explanation the data is like numerical field representing 'credit balance available'.

The device only ever interacts with a single computer; I therefore wish to verify integrity of the balance using a HMAC: the computer reads the balance and MAC, verifies it using its private key, updates the balance and computes a new HMAC, and writes this back to the device.

The limitations: I want the hash to only be 32bits, so I will truncate it. The key can be arbitrarily long and I can use SHA1 etc.

Am I safe to assume that an attacker cannot find the secret key even though the hash is 32 bits? What if the hash was 8 bits?

In this system, the computer will block a device if it provides an invalid MAC, thus an attacker has only one attempt to provide a valid message/MAC combination.

Note: I've read this security.SE question but I am confused by the answer and the 3rd comment on the answer (by @LateralFractal), otherwise it is a similar question.

Details matter.

As @Ricky points out, showing truncated HMAC values won't help the attacker finding the secret key, compared to a similar situation where the HMAC values would not be truncated. This makes sense: the truncation only removes information.

However, the attacker is not ultimately after the secret key. What the attacker really wants is to make forgeries, i.e. compute some HMAC values that the computer will accept as its own. Finding out the secret key allows making forgeries, but the ability to make forgeries does not necessarily entail knowledge of the private key.

Fortunately, HMAC tends to behave like a PRF, so there are two known methods to make a forgery:

Perform a brute force enumeration of possible keys until the right one is found (one that matches a few known value+HMAC pairs). This attack is defeated by choosing the key is in space large enough to make the enumeration unrealistic (i.e. you generate a 128-bit key with a cryptographically strong PRNG).
Luck. The attacker sends a random sequence of bits as HMAC value and hopes that it will work. This attack is defeated by not truncating HMAC values to too small a length, and/or applying other mitigations such as allowing only one try and irrevocably rejecting devices that once showed even a single bogus HMAC value (as you do).

The "luck" attack works with probability 2-n, where n is the size (in bits) of your truncated HMAC output. I.e. with a 32-bit output, then a luck-based forgery has probability 1 in 4 billions or so to go undetected. This is the best that can be done with a 32-bit output, in all generality; that HMAC behaves as a PRF means that it is "optimal" in that respect. If you truncate to 8 bits, then the attack success probability is 1 in 256, which is probably too much for comfort. But this is your decision to make, based on your usage context.

Also (again as @Ricky points out), beware of replay attacks. A valid MAC, assuming that there was no forgery, only demonstrates to the computer that it saw and "approved" the message contents at some point -- but not that it was the last message that it saw. Old message-HMAC pairs can be sent again by a fake device. To defeat replay attacks, you must maintain some state on the computer (the computer must remember something about the device, e.g. a "message sequence number", that is part of the data over which the MAC is computed, and incremented for each message).


Account lockout policy guidelines Edit: As I am asked to clarify this question I will state it in one sentence: What is a good lockout policy for web applications, why, on what does it depend?

It is hard to find a best practice regarding account lockout policies. Windows suggests locking an account after 4 to 10 failed attempts

PCI uses the following minimum criteria:

  User accounts are temporarily locked-out after not more than six
  invalid access attempts.
  Once a user account is locked out, it
  remains locked for a minimum of 30 minutes or until a system
  administrator resets the account.

Drupal has the following defaults which are still used today:

  Drupal 7 prevents brute force attacks on accounts. It blocks login b
  y a user that has more than 5 failed login attempts (within six hours) or an IP address that has more than 50 failed login attempts (within one hour).

Does anyone have any other best practices I can add? I would like to have an open discussion on the subject and try to find one set of guidelines for a decent lockout policy that balances security, usability, denial of service.

The NIST guidelines say this:

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

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

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

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


How can I set a password for single user mode? During a Lynis audit I found this on a system that uses Fedora 28:

Checking Linux single user mode authentication    WARNING

And under results I got:

        No password set for single mode [AUTH-9308]

Rkhunter skips "Checking for hidden processes"

What more can I do to harden this system? Thank you.

To password-protect single user mode, you need to replace the single user mode shell with something like sulogin.  Here's a page that describes how to do it under the various major RHEL variants, which should cover your Fedora variant.

I'm assuming based on recentness of Fedora 28 that it looks somewhat like RHEL 7, in which case you'll want to check the ExecStart line of /usr/lib/systemd/system/rescue.service.  The link above suggests it should look like this:

ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default"

If you don't see sulogin in that line, that's your problem.

Please note that in most cases requiring a boot time password is meaningless unless you're also performing disk encryption, and that disk encryption should have a separate prompt for its password before you even get to this point.  So this setting may be redundant, depending on your system configuration, which is the sort of nuance an audit tool might miss.

As for the rkhunter issue, do you have unhide installed?  This link suggests that if it is missing, that would explain why hidden process checking is skipped.


MacOS Ransomware with EFI Lock Problem Description

Yesterday my mother called me that she got a message on her iPhone, that it was stolen (iCloud Find My Phone). She then had to enter security codes (two-factor authentication) into a textfield on her MacBook. I was not there at this time, so I can not really prove it. I think this was already a phishing window of the ransomware.

She is using my old MacBook, an early 2011, 13" with updated SSD and 16 GB RAM, with 10.10 installed.

When I arrived, the MacBook was already compromised and showed following message, after booting:

The message is in german and says:

Ihr Computer ist deaktiviert. Versuchen Sie es in 59 Minuten erneut.
(Translation: Your computer is deactivated. Try it again in 59 minutes.)

write to email: apple.help@gmx.com

apple.help@gmx.com is definitely not a valid apple mail address.

I googled for the exact same message and I did not really got any good results. The only results I found were these:

Je crois avoir été infecté par un ransomware
Phone Locked into Lost Mode

How to fix it?

My thought was that it was just a screen overlay and it should be possible to boot into another OS (live Ubuntu) to get access to the data. I wanted to find a trace of the ransomware. Maybe I could find out how it is called or what it was doing with the data.

When I tried to boot to another device, the Mac was locked with a EFI firmware protection password (the same screen with the little lock was appearing). I never set this and I really doubt that my mother did it. So it could be only the ransomware.

So I first had to reset the firmware password. Luckily I found a blog entry which describes a way where you have to change the amount of RAM sticks in your system and then reset the PRAM / NVRAM. I thought it sounds a bit like magic, but on the other way, the system could not get worse.

I removed a RAM stick, booted with CTRL+ALT+P+R and waited for three reboots.

After that it the firmware lock was gone and it was possible to boot onto a USB stick. I checked for recent file changes on the mac partition, but could not find anything. The data of the home folder was not encrypted (so maybe it was a hoax).

So I made a backup of her data and then tried to do a normal boot again. Surprisingly, the ransomware message was gone! I could just boot into the system as usual.

I run a Bitdefender scan, but nothing was found. It is really mysterious and I have no idea what really happened.

Question

So my question now is, does anybody know this problem or this kind of attack? I have no clue how the attackers could set the firmware password and where the software of the ransomware was running.

Maybe it was on an own partition but I could not find it. The MacOS seems not to be corrupted.

Update

I asked an Apple Store worker today and he did not know anything about a hack like this. But he told me that it should not be possible to reset the firmware password. Only Apple is able to do that.

Explanation
It seems that it is not a virus or a hack on your computer. The message that is shown can be set when you lock your device from iCloud (Find My Phone).
So it seems that Apple has an iCloud backdoor or something like that. Only with the password it would not be possible to login to iCloud, because of the activated two-factor authentication. So the attackers really have access to your iCloud, but not directly to your local computer.
The iCloud account of my mum is from April 2017, so it is not just an old iCloud hack.
Most likely it is because of the following iCloud hack:
Hackers: We Will Remotely Wipe iPhones Unless Apple Pays Ransom (Vice, Mar 21 2017)
Solution
If the same happened to you, you have to take your Apple device to the next Apple Store together with your receipt. The receipt proofs that you are the owner the device, so the Apple Store is able to unlock it.
For security reasons I recommend to reset your password and activate two-factor authentication.
If you have the a 2011 Macbook, the PRAM / NVRAM wipe could work for you too, but you have to do it on your own risk.


Is Server-Side Includes injection really common vulnerability? Is Server-Side Includes injection really common vulnerability? And how can I detect it - is there some way like automatic tools or some kind of fingerprint test or do I have to just play with input?

Not particularly common anymore.

One exception would be web interfaces for embedded devices as many of these just shell out to bash commands and don’t escape well if at all, but again, this is rare to see on a public facing anything these days.


Mitigating risk from electronic payments When attempting to sell a product online (for instance, on craigslist) there is a very good chance you will be the target of a social engineer; this is especially true when you are selling high-value commodities like cars or jewelry. Given the anonymous nature of the internet, it can often be hard to distinguish between legitimate buyers and social-engineers.

What steps can a person take to minimize the risk inherit in conducting high-value transactions online? Is it possible to fully eliminate the risk?

Use an escrow service.

From Wikipedia:

  Internet escrow works by placing money in the control of an independent and licensed third party in order to protect both buyer and seller in a transaction. When both parties verify the transaction has been completed per terms set, the money is released. If at any point there is a dispute between the parties in the transaction, the process moves along to dispute resolution.

Also,

  One way to avoid escrow fraud is to use a Government Agency authorised escrow company (UK),or a State licensed escrow company (US)... The validity of an online escrow company's license can be checked with the regulating authority. Usually this is accessible through their official website, and should always be checked before dealing with an escrow company to ensure it is not a look-alike or fraud.


Is it possible to intercept the payload of a secure request in plain text? Consider we run the following request:

import requests
url="https://secretsub.example.com/secretpath/post.php"
payload = {'secretmessage1' : 'foo','secretmessage2' : 'bar'}
r = requests.post(url,data=payload,verify=True)

The language (python) is just arbitrary but it can be a request on any other language (NodeJs, Java, Php...)

Notice that the url is using https, which means that the connection is secured over SSL. Assuming that I compile this program into binary (.exe), would it be possible for computer to read the payloads through a software in plain text?

I know that packet sniffing software (like WireShark), will only reveal the domain name (example.com) in plain text but not the secrepath nor the payload which will be encrypted.

If I run this code in a web browser however (assuming that it is written in Javascript), I will be able to access the payload and the secretpath in plain text inside the browser console. I assume that the browser only encrypts it only after the request is logged in its console. But if this code is run outside the browser, is there a way a for the computer host to intercept those data in plain text? (some sort of packet sniffing tools)

Generally, you are using the TLS protocol, and thus initiating a handshake with the server, agreeing upon such as cipher suites and keys to use. This is a secure protocol, as long as you can trust who you are communicating with (e.g. certificate validation).

You ask whether the host computer could intercept something. After the encryption has taken place, I'd say no.

On a side note, the host computer is performing the encryption in an allocated area of memory. If the host is compromised to the extent that you cannot trust the memory protection of that machine, or generally the context of the process, the plaintext can be retrieved prior to encryption. But it's impossible to have zero risk, so this is not necessary something that you need to consider.


How to know whether mysql connection is using SSL or TLS connection? I want to verify whether mysql remote connection is using tls/ssl connection for security purposes.
I ran status command to check initially:
mysql> status
--------------
mysql  Ver 8.0.19 for osx10.15 on x86_64 (Homebrew)

Connection id:      47
Current database:
Current user:       user@127.219.252.250
SSL:            Cipher in use is DHE-RSA-AES256-SHA
Current pager:      stdout
Using outfile:      ''
Using delimiter:    ;
Server version:     5.5.5-10.3.27-MariaDB-0+deb10u1 Debian 10
Protocol version:   10
Connection:     31.224.603.2 via TCP/IP
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    utf8mb4
Conn.  characterset:    utf8mb4
TCP port:       3306
Binary data as:     Hexadecimal
Uptime:         35 min 15 sec

Threads: 9  Questions: 222  Slow queries: 0  Opens: 33  Flush tables: 1  Open tables: 27  Queries per second avg: 0.104
--------------

Here the ssl row has mentioned a cipher but according to some people this doesn't guarantee that the connection is actually ssl encrypted.
To be 100% sure, I installed wireshark but I have never used this software before.
I just started capture with the destination set to the ip of db server.

Can this be used to make sure the connection is ssl/tls encrypted? Any help is appreciated.

It would be very, very odd to see "SSL: Cipher in use..." and then have the connection not be encrypted. (If you know of any case where this happens, please include a link.) However, it's possible that it would be less than fully secure for some reason, such as using (and trusting) a self-signed or otherwise potentially-untrustworthy certificate, or using an anonymous cipher suite, or using very weak encryption, or similar. Unfortunately, that's difficult to verify from the information given (aside from the strength of the encryption, which is the very strong AES256 cipher).
As the Wireshark screenshot shows, you're using TLS v1.1. That's not the latest, or even second-latest version - everything should be using TLS 1.2 or 1.3 these days - but at least it's not (to my knowledge) completely broken the way some older protocols are. You could look at the certificate that the server sent by viewing the relevant line in Wireshark, but that wouldn't necessarily tell you clearly whether or not the cert is trustworthy.
The simplest option might just be to look at the client command line (and options file) flags. If you used the ssl-mode=REQUIRED flag (or, for old versions, the -ssl=1  or --enable-ssl flags), then the use of SSL/TLS is forced on. Various other flags control things like what CA certificates are trusted, though it should use a reasonable list by default.


What harm could malicious PHP code cause? What harm can virus sites that contain malicious PHP code cause? What is an example of a piece of PHP code that could potentially harm your computer or steal information?

I know that most if not all client-side code cannot cause any harm, but how about the server-side code, what harm could it cause?

I was always curious as to how a website could harm your computer ...

It all comes down to the credentials that that PHP code is running with on the server.

If the apache2 process running that PHP code is running as www-root, the damage that this script can do goes to the extent of what www-root can access, which would typically mean all of the /var/www/ folder.

To fully understand this question, one needs to understand how linux works, if the web server is running under linux, to fully understand the extent of the possible damage.

If it's running under Windows, it would be the same thing, only the damage would be to the extent of what the owner of the process is able to use the machine's resources for.

Things that typically PHP viruses do are:

Use your server to send spam
Use your server to brute force other servers
Use your server's resources to join their own rig and mine crypto-currencies

Those are just a few. They can pretty much use your server to run any software.


Is this a secure method of authenticating packets? I have an client/server architecture that periodically sends very small (10 or so bytes) UDP packets back and forth, which I'd like to authenticate without a large overhead in bandwidth or processing. Note that I don't care about an adversary seeing the plaintext, only I'd like to prevent them from modifying and re-transmitting the packets.

Here is the process I'm envisioning:

User authenticates themselves with a username/password over HTTPS. Nothing out of the ordinary here.
Server replies with a success message and N bytes (maybe around 32 bytes) of cryptographically generated random data. Both the client and server remember this string of data as their common_secret.
At this point the HTTPS connection is closed and all further communication will be via small UDP packets, using this scheme for authentication:
packet = plaintext + sha2(plaintext + common_secret)
On receiving a packet, the server will calculate the same sha2 from the plaintext and its common_secret, and check that it matches the hash at the end of the packet.

An adversary will not be able to construct a valid packet without knowing common_secret. Is this a valid authentication scheme?

Vulnerabilities in your method

Your construction is most likely vulnerable to a length extension attack which allows for the modification of the message, as well as a replay attack which allows for the resending of previously send messages.

Obligatory: This is why you shouldn't roll your own. Instead, use existing solutions for the problems you want to solve.

Secure Approaches

A solution against the first issue is to use a proper HMAC. If you do need protection against replay attacks, you need to exchange nonces or similar.


Are personas used in information security? (like in UX) In the UX field, personas are used to help designers think like the future end-users.

Is this technique also used in the field of information security, i.e. to think like a hacker in order to prioritize tests?

I'm very new in information security.

Yes, in a way.

When one designs a Threat Model, one thinks about the current system, the potential goals of a "Threat Actor" (attacker or a careless user), and the currently available tools, techniques, and procedures to exploit vulnerabilities.

For instance, I work with one client that outlines all this in detailed documents and sets priorities in relation to the risk priorities of the system and business. The focus is on threats not the attackers themselves, though.

That said, there is a huge benefit to using the UX style of personas in a more traditional way to deal with the "careless user" problem. In many cases, better UX would prevent many of the user-generated security problems we face daily.


DNS queries to compromise DNS cache The transaction ID for DNS queries can take values from 1 to 65,536 and my computer pseudorandomly chooses one for each DNS request. If I sents 1,024 false replies per request, how many requests should I trigger to compromise the DNS cache with probability 99%? or as close tot hat as I can get. Thanks

I'm getting a result of .6 requests which doesn't seem right to me. Feel as though it should be around 30

your calculation seems to be simplified. According to the formula given in RFC 5452, the number of fake packets 'F' that are candidates to be accepted is given by :

P_s  =  D * R * W / ( N * P * I )

where I is the number distinct IDs available (which is 65536 in your case), P is the number of ports used, N is the number of authoritative nameservers for a domain, R is the number of packets sent per second by the attacker, W is the window of opportunity, in seconds and D is the average number of identical outstanding queries of a resolver (typically 1, see Section 5).

If D = 1 (typical value according to the RFC), W = 0.1 (typical value according to the RFC),  N =  2.5 (average value according to the RFC), P = 1 (assume only one port is used) and I = 65536 (provided in your question). Then P_s can be simplified into :

P_s =  R / 1638400

Thus, plugging in the necessary values, for P_s to be 0.99, R should be greater than 1622016 packets/s. Since we used W = 0.1 and you send 1024 false replies per request, then you need about 1622016 * 0.1 / 1024 = 15.84 attempts.

(Hope my calculation is correct)


how to embed exe file to pdf? Im trying to embed exe file to pdf for case study.

I try using metasploit exploits for this but i can only embed shellcodes with this method.

I know there is a way to embed exe file but i cant find one

Suggestions?

Thanks.

If all you are wanting to do is add an exe (or any file) to a pdf (or any file) then you can simply add your file to what is called 'slack space'. There are tools out there that do this and add many features but you can also do this by hand using a hex editor (like HxD).

To do this by hand:

open a hex editor.
open your pdf in the editor.
open the exe in the editor (in another window).
copy the exe hex values into the pdf hex values (after pdf file end).
save your new 'pdf', it will still open and operate as a pdf but your exe file will be there as well and you (or anyone) can extract the exe.

also, you may be interested in embedding javascript in a pdf. This alone is nothing new, but this can be used maliciously...


How are root CA revocations handled? Considering some CA certificates are hardcoded into operating systems, I was wondering what happens when one of these hardcoded certificates is revoked (put on a revocation list for example) because of it being compromised?

Does the operating system have a system for updating it in case it is revoked? How? And how can it be updated after it has expired?

As can be seen from Can a RootCA be revoked? there is no mechanism inside a PKI that a root CA gets removed. This means a mechanism outside the PKI is needed. This consists usually of an update of the trust store through update of the browser or the system which removes this certificate from the trust store or mark it as untrusted.

Such events happened in the past for example with DigiNotar. This case was handled by updates to the Firefox and Chrome browsers, updates of  Microsoft Windows and of iOS and Mac OS X.


Is it complicated to deploy my own CA? We want to implement a free solution to sign digitally internal documents. No legal value of this sign are requested.
We want to consider to deploy an internal CA.
Why is it always said that keeping your own CA is so much complicated? Where does that complication reside?

Deploying internally is easy. The hard part is getting all the procedures right so that it is convincingly uneasy to obtain a fake certificate. This is the condition for signatures: a signature has any value only inasmuch as people believe in it.

Of course, if your signatures are not meant to have legal value, then things are a lot simpler. But then, why would you want to sign things ? A signature is useful only through its binding property: he who signed can be held responsible for what which was signed. The whole point of a signature is to serve as a weapon against the signer. From which we can draw two conclusions:

Nobody in his right frame of mind wants to sign things. You want other people to sign things; you accept to sign things yourself only because you are pressured to do so in a specific context.
A proof is a legal weapon. If you do not want "legal value" for your signatures, then you have made them a lot less frightening, and thus a lot less useful as well.

Let's explain things with an analogy: suppose that you have a warehouse with valuable goods in it. You fear that thieves may break into it, so you want to hire armed guards. But it takes some precautions, because you do not necessarily want to give a loaded pistol to just any guy that looked good during the hiring interview; you will want some medical certificate that says that the guy is not mad, and some legal certificate that says that he is not wanted for some crime, or anything like that. A much less risky solution is to equip the guards with water pistols -- but then, thieves are unlikely to be much deterred by the prospect of being merely soaked.

Running a CA is 5% technology, 95% procedures (access control, audit, logs,...). The 95% are what makes running a CA expensive and complicated. You have to understand all that is going on (including dreary details on certificate formats such as revocation and renewals). If you do not accept to do that part of the job, then things can be very simple (a couple of scripts around OpenSSL), but then, you no longer have actual security to your signatures. You have merely sprinkled crypto all over the place, giving a feeling of security.


End to end encryption on top of HTTPS/TLS I need to create a PHP Web application which stores some user entered data. These data should only be readable to some selective users of the system (including the user who created it).The data should not be decrypted by the server administrators or other backend managers. Only the end users should be able to decrypt data.

I do know that HTTPS/TLS will securely encrypt data between client and server but here my requirement is that only some selected end users should be able to read data. I am also aware that here browser is the end points in communication. So on research I came upon the concept of End to End encryption using private/public key pairs.So my question is whether it is possible to implement this in a Web application using PHP.

You can certainly implement a system that uses end-to-end encryption and has the server portion written in PHP [1]. You'll just have to implement the crypto part as something that runs on the "ends" - that is, the browsers, so realistically you'll need to implement it in JavaScript - and your PHP code would serve this JS to the endpoints. The PHP code would also need to serve up the public keys [2] for everybody who is supposed to have access to the data being encrypted. Depending on how you're going to store the private keys, the PHP would probably store (and serve) a "wrapped" (that is, encrypted) version of those, too.

The server-side (PHP) portion of this whole project ends up being slightly more complicated than a typical web app. It needs to be able to authenticate users, which is normal, but without enabling the admins impersonate users (this is not normal) [3]. It probably needs to be able to store (and control access to) private-per-user data (the wrapped secret keys), per-user public data (the public keys), and restricted-access shared data (the actual encrypted user data). Depending on what sort of data is being stored, how much of it, whether you need to be able to adjust who has access to it after-the-fact, and whether it needs any kind of searchability, you may run into any of a host of additional complexities. Secure end-to-end systems are hard. [4]

The client-side (JS) portion of this thing is going to be where the heavy lifting occurs, crypto-wise, though. That's kind of awkward, because JS isn't great at crypto. There exist pure JS implementations of the standard crypto functions, but they tend to have problems (like being relatively slow, and potentially exposing side-channel vulnerabilities such as timing attacks). Some browsers support performing native crypto operations using data from JS, which is faster and more secure (assuming you trust the browser developer, which you kind of need to here), but it's not yet universal.

[1] You probably shouldn't. PHP is a poor choice for any highly-security-sensitive code, as it is relatively easy to make security mistakes in. Secure code in (modern, fully-patched) PHP is certainly possible, but I would recommend using a language that makes it harder to shoot your own foot off, like Java, C#, VB.NET, or perhaps Go or Python.

[2] This presents a security weakness you need to figure out a way around, because the endpoint system - the user and their web browser - have no way to tell if the public keys sent to the client (to which the data is being encrypted) are the right public keys. A malicious server admin could add their own public key to the list of keys, and then any data encrypted with that list of keys would be readable by the malicious admin. You need some way of verifying key authenticity.

[3] One tricky bit here is that, while the server should never store the user's password, the server does typically see the password, briefly, when creating the account and whenever the password is used (logging in, changing the password, etc.). A malicious server admin could modify the server to steal this password. If that password is all that is needed to log in as that user - for example, if knowing the user's password allows you to unwrap the user's private key - then the malicious admin could then decrypt the data that they aren't supposed to have access to by impersonating a legitimate user.

[4] Honestly, this sounds like a project for somebody both more experienced in information security and as a developer. It's not an easy problem, and crypto is hard to do right.


Where should a Vulnerability Disclosure Policy be published? In 2014, the New Zealand Internet Task Force released a set of guidelines for Vulnerability Disclosure:  http://www.nzitf.org.nz/pdf/NZITF_Disclosure_Guidelines_2014.pdf

Part of the recommendations for site owners is the publication of a disclosure policy, in a public area, to state the company's position in terms of reaction to security researchers.  I drafted a Vulnerability Disclosure Policy based on the New Zealand Registry Services' policy here:  https://nzrs.net.nz/about/vulnerability-disclosure-policy

My employer is in retail, and the managing director doesn't want to publish this on the website, for fear of frightening customers off our website.  As a partial solution, we agreed to insert references to the document as comments in our website's source code, as well as in the HTTP headers on our webserver.

Are these enough?  Are there any other places we should publish which won't be visible to our average visitor, but WILL be visible to those who should see this policy?

In seeking an answer to this question, I approached the team at the CROW lab (Cybersecurity Researchers of Waikato).  A representative of the Lab responded with the following:

  If someone does find a vulnerability, chances are they would be a tech
  savvy person who would have looked at the HTML or HTTP headers. I
  believe that it is enough for an average security researcher to find
  (looking at it from a technical view not legal view of course).

So, until any further information comes to light, I'm accepting that as the answer; I'll still appreciate additional answers though!


Thick Client memory encryption I came across a thick client application recently. The application temporarily stores sensitive data (like username and password) in clear text in memory and the data is flushed once the user logs out or the application is closed.

Inorder to increase the security implementation of the application is there any technique where I could encrypt the sensitive data stored in memory? so that data are encrypted whenever application memory is dumped.

Please suggest some resources for implementation.

Generally the solutions to this problem are:

Don't store sensitive data in memory (could be dificult to achieve in some cases);
Encrypt data stored in memory (raises the problem of managing/securing encryption keys);
Minimise the time sensitive data is stored in memory (i.e. scrub [overwrite] it as soon as it is used, then find a method to obtain it again if needed);

For the purpose of authentication, the password is required once to verify the stored hash, after that it won't be needed any more until the next login.

Memory based attacks are relatively complex and usually require physical access, so keep that in mind to assess your business risk.

Above all, make sure whatever is left in memory (even temporarily) or on disk that is sensitive data cannot be reused elsewhere (i.e. on another thick client) - this is where the big risk comes in. Static keys shared across multiple (all?) devices, accounts that work elsewhere, shared local passwords and local secrets, private keys, etc.


Howto seed the PRNG in OpenSSL properly? I am creating an application which runs on a mobile node with Ubuntu, which does not generate enough entropy bytes to the /dev/random, and does not always stay connected on the Internet to use typical socket entropy-gathering solutions such as EGD.

Are there any good tools for gathering the needed entropy in my situation?

Just to clarify, trying to get 1024 bytes (which seems to be the recommended value by the OpenSSL book) via /dev/random took nearly two hours...

The proper way is to use /dev/urandom, not /dev/random. There are very few cryptographic algorithm for which /dev/random is even theoretically better than /dev/urandom (this would be information-theoretic secure algorithms, not mundane things like AES or RSA). /dev/urandom produces randomness of cryptographic quality provided that it could get at some point at least 20 bytes or so of "true randomness", something which the OS took care of during installation. /dev/urandom happily extends that initial seed into megabytes of pseudo-alea which is computationally indistinguishable from true randomness (that's all you need), and it will never block.


Is it possible to run an encrypted java environment? I've seen that virtual machines in virtualbox or VMware can be encrypted so that no one on the outside can access the disk, ram or CPU cache since the entire hardware is emulated and encrypted too. I'm wondering if this is possible with a java environment.

I want to make a secure java computing environment that cannot be accessed from the outside by anyone on the same hardware. for example, a shared server. if this is possible, if so how should i set it up?

If an attacker has root access to a machine, they can read all memory, perform debug operations, reverse engineer your java bytecode, etc.  There's no practical way to prevent an attacker from obtaining a secret key that's hidden in RAM somewhere.

Ultimately, somewhere you're going to store the class files in a running JVM.  If an attacker has physical access to the machine it's running on, they can get access to your class files.


Apache - strange requests in logs I'm running webserver on Debian8 64bit (2.6.32-042stab120.16) with Apache/2.4.10.
Today in Apache access.log I found these entries:

164.52.7.132 - - [26/Jun/2017:07:16:23 -0400] "\x16\x03\x01\x01\"\x01" 400 0 "-" "-"
164.52.7.132 - - [26/Jun/2017:07:16:30 -0400] "USER test +iw test :Test Wuz Here" 400 0 "-" "-"
164.52.7.132 - - [26/Jun/2017:07:16:30 -0400] "GET / HTTP/1.1" 200 4191 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"l,

I'm aware that somebody is trying to test some vulnerabilities on my webserver. I'm concerned especially about first request from this host - what may this be, some function coded in hex or dec?

Should I do some more checks on this server?

Is this a known vulnerability? If yes, can I protect somehow from these kind of attacks?

I'm concerned especially about first request from this host - what may this be, some function coded in hex or dec?

What you see in \x16\x03\x01\x01... is just the start of a TLS 1.0 handshake, i.e. content type (0x16 = handshake) followed by TLS version (0x0301 = TLS 1.0). Looks like somebody tried to speak HTTPS on port 80 instead of 443.


Who am I really trusting? My trusted root certificates are below.
As an exercise, I want to be sure that a MITM is not changing the list.
So, can I somehow get this list signed?
In my opinion, the list could be signed by my laptop's TPM
using a key signed by my laptop's manufacturer, HP.  The final verification process is then:

copy these 3 items (the list, TPM's signature, and HP's signature) to a trusted computer
trusted computer checks the signatures to show that their keys work
trusted computer goes online to verify that the public key used for HP is trustable (ideally, trusted computer builds a certificate chain from HP to its own root, but my Googling HP or phoning HP is probably sufficient)

I'm guessing TPMs do not have this capability today, so here's a broader question:
What would you do if you suspected that your TPM has an additional "evil root certificate" which always gets hidden by an "evil fake certmgr app"?

First: the list of trusted roots is maintained by a Microsoft Root Program and is automatically updated as program participant list changes. You can disable automatic root update, see this thread: https://stackoverflow.com/a/36077658/3997611. In any case you can get a Microsoft-signed list using this link: http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab. Extract CAB and you get signed CTL. In this case, you always can compare current list with signed copy.
Next, when you are online, you are not protected much when using user account with administrative privileges. Any person with admin rights can modify this list. There is a user-scoped list of trusted roots which users can update. There is a group policy setting that locks down the user-scoped trusted root store: https://serverfault.com/a/1008039/251012


Why doesn't IPSec ESP protect the IP-Header? I understand that AH provides integrity and authentication while ESP provides encryption and authentication, but to me it looks like some IP Header Address Spoofing is still possible, no?

Why is the IP header not included in the authentication part of ESP? Was the reason to make it NAT compatible?

And can they be used combined?

Yes, when using ESP the source IP address may be modified by an attacker.  But unless this results in an amplification attack I don't really see a point in doing that. An attacker who is in the position to modify the IP addresses can also just drop traffic or passively read it (if it is not encrypted), however, will not be able to forge new packets, no matter which protocol is used.

While the two protocols may be combined (e.g. use ESP only for confidentiality and AH for integrity), the integrity functionality provided by ESP affords about the same security with less overhead (especially when using AEAD algorithms), RFC 4302 (AH):

  ESP may be used to provide the same anti-replay and similar
     integrity services, and it also provides a confidentiality
     (encryption) service.  The primary difference between the integrity
     provided by ESP and AH is the extent of the coverage.  Specifically,
     ESP does not protect any IP header fields unless those fields are
     encapsulated by ESP (e.g., via use of tunnel mode).

So if protecting parts of the outer IP header (and extension headers) is not a requirement, ESP basically provides the same functionality as AH. ESP may even be used without confidentiality, RFC 4303 (ESP):

  Integrity-only ESP is an attractive alternative to AH in many
      contexts, e.g., because it is faster to process and more amenable to
      pipelining in many implementations.


Is the UK Parliament e-petition system trustworthy? Over the last few days, I've been hearing often about the petition to (pratically) "repeat" the Brexit referendum and I noticed that it is an online petition.

I noticed that the "sign petition" form just requires name, email address, and postcode, and then you'll receive an email to confirm your signature.

Is this system secure? Can't someone just create a bot that will fill the form continuously (and confirm the email) using a different address each time? Looking at the privacy page, it also appears that it doesn't even have a captcha system, and the email verification is the only "system" to prevent bots.

Last but not least it doesn't have a system to ensure that the signer is British.

The petitions site is purely a mechanism to see whether there may be high enough numbers to support something, and if so, that something will be discussed in Parliament.

There are some checks and balances (for example 80,000 fake votes were identified and removed) but there is no need for a strong level of trust here, as nothing is decided by any of these petitions.

For the re-doing of the European Exit referendum, there are around 4 million signatories, and even with some level of fraud, the government already knows that it is something they need to discuss.

In summary - can it be trusted to the level required for this purpose? almost certainly. Can it be trusted to have no fraud? No.


Are there any security implications in creating an SSH key for the root user? I've written an install script on a server to quickly set up new sites in the /srv directory. It needs to do a git clone, and has to be run via sudo in order to have the permissions to do all the things it needs to do (create directories in /srv, create a new VirtualHost, restart Apache, etc).

The question I have is simply this: at the moment the root user has no SSH key, but I'll need one in order to git clone from BitBucket. Are there any security issues with generating one? That is, if I run ssh-keygen as root so I have public and private keys for the root user, will I be making the server less secure in any way?

Incidentally, this is a script that is already in use and has been working fine, but until now the repo I'm cloning from has been a local one, hosted on the same server. I've recently switched to hosting it remotely (on BitBucket), so I need a "deployment key" in order to git clone it.

No, having keys for your root user does not impact your security profile. It is wise though to disable root login in ssh and NOT have an authorized_keys in your /root/.ssh/ folder.

However. I got the feeling your going about this the wrong way. Personally, I would not use the root user in this manner (but a system user like www-data) and make several command and control scripts that reload Apache config for example that are specified in the sudoers list (with full specification) so that my user can simply call a script that does have the rights to do the 'special' actions needed.

This way you will have an audit log of what has happened. This limits what can be misdone by the user in case of a compromise and does not expose your complete system.

The sudoers file (and the sudo command) have an option to make them work without password entry (:nopasswd:). You can also limit the commands and calling users in the file. As a bonus you can have a separate user with limited rights to have the deployment access, further limiting potential harm.


Can I ensure that a public key derived from a private key is unique? In asymmetric cryptography, is it possible to ensure that public key derived from a given private key is unique, no matter the algorithm?

You cannot speculate on unknown algorithms.

With RSA, you can make several public keys which are all functionally equivalent, in that they all correspond to the same private keys. Namely, if the public modulus n is the product of p and q, and the public exponent is e, then e'=e+k*lcm(p-1,q-1) will be another valid public exponent for the same modulus, and corresponding to the same private key, for any integer k ("lcm" is the Least Common Multiple). This allows you to compute an infinity of distinct public keys for one private key. (But it is not recommended at all to make more than one of these public keys public: combining two such keys reveals the private key quite easily.)

If you want unicity of public key, for some notion of unicity, then you have to arrange that yourself.


Should I send login id on email? I have a very common use case where an admin is creating an account of the user and then I need to send the login id generated by my system to the user. And the user will need to set a password on the first login.

So my question here is should I send the user id on email and if yes, then what are the security risks that must need to be incorporated?

Login ID should be considered public. So feel free to send it per email.


How to "demonstrate" man-in-the-middle attack? I'm TAing a particular course on system security. A specific example is transitting the password in plain text when developing a web application (as part of a class project).

Over the years a bunch of students don't really 'care about encrypting the passwords' or avoid using SSL as a possible solution (i.e., an SHA-128/256 hash of the password is sent over the wire in case of plain text but still no SSL. So I can conduct a replay attack as a result).

I want to be able to 'demo the dangers' of the man-in-the-middle (MITM) and am not sure how to go about it. Students question if someone is really able to pull it off and are curious on the how. I thought it'd be good to 'show it to them'.

So here are the scenarios:

Same wifi connection but no control over the wifi settings (i.e. university wifi)
Same wifi where I can control whatever wifi settings I want (i.e. router etc., under my control in our lab)
Arbitrary adversary over the internet

Now, I think a 'demo' of 2 and 3 should suffice with an 'idea' of how is #3 exploited in practice (I do not intend to breed hackers. But if there is a way to demo that too it would be an icing on the cake ;)

How exactly can I demo the MITM attack and show them that I got access to their 'plain text' or 'hashed' password and gained access to the said system? Tools to use, scripts to write or a tutorial on 'how to do it' would suffice.

You may be interested in checking out this link for SSLStrip. It's a tool developed by Moxie Marlinspike for MiTM on connections to http that redirect into https. The video has some demos of ways you can use this tool but the basic idea is you target an insecure login page that redirects to a secured session, Setup an arpspoofing and configure iptables and ssl strip will log data that passes through it. We did a lab once where we set this up on a virtual network and captured passwords as they were sent. This would probably help at least situation number 2. Hope this helps.


How can I extract the hash inside an encrypted PDF file? As long as I know, the encrypted PDF files don't store the decryption password within them, but a hash asociated to this password.

When auditing security, a good attemp to break PDF files passwords is extracting this hash and bruteforcing it, for example using programs like HashCat.

What is the proper method to extract the hash inside a PDF file in order to auditing it with, say, HashCat?

Answers for John the Ripper  could be valid too, but I prefer HashCat format due to the easyness of making GPU computing work in Windows and bruteforce with OCLHashCat (the GPU version of HashCat). John the Ripper has a GPU version too, but JTR has no Windows version, at least with GPU enhancement.

UPDATE 21 Dec 2017

The script pdf2john.py doesn't exist anymore. It has been substituted by a perl version, pdf2john.pl.

Extracted from HashCat Forums, this method works for me (requires Perl):

--Download pdf2john.pl from the suite John the Ripper (OCLHashCat works with the same hash format as John the Ripper):

wget https://github.com/magnumripper/JohnTheRipper/archive/bleeding-jumbo.zip
unzip bleeding-jumbo.zip

--Use it to extract the hash from your .pdf file:

perl JohnTheRipper-bleeding-jumbo/run/pdf2john.pl MyPDF.pdf > MyPDF-Hash.txt

--Output file MyPDF-Hash.txt must be edited. Original would be something like:

MyPDF.pdf:$pdf$4*4*128*1028*1*16*652fc762fdb12c47a5f90ddd2b99b809*32*dd86d858f914809078a4a47348d32c0fc4e9c08042a10e6434b48b698de7731f*32*3c1e693526d5bc8da15b99eea6cbc6ed2c2397e23e2c39d1974fdc004c588cff:::::MyPDF.pdf

so use your preferred editor:

nano MyPDF-Hash.txt
notepad MyPDF-Hash.txt

and leave only the part inside double colons : :

$pdf$4*4*128*1028*1*16*652fc762fdb12c47a5f90ddd2b99b809*32*dd86d858f914809078a4a47348d32c0fc4e9c08042a10e6434b48b698de7731f*32*3c1e693526d5bc8da15b99eea6cbc6ed2c2397e23e2c39d1974fdc004c588cff

--Hint: you can do the extraction and the edition in one step by using sed (UnxUtils version too, if you are doing it from Windows):

perl JohnTheRipper-bleeding-jumbo/run/pdf2john.pl MyPDF.pdf | sed "s/::.*$//" | sed "s/^.*://" > MyPDF-Hash.txt

--Your MyPDF-Hash.txt file is now ready to use with OCLHashCat (or John the Ripper).

NOTES:

Tested working on CygWin (Windows).
Tested working on Kali and Ubuntu Linux.


Is JavaScript console vulnerable to XSS Assume the content of the name variable below is controlled by an attacker. Is this line of code vulnerable to XSS?

console.log(name)

When I send an injection in name variable I see its value printed by console.log as a URL encoded string, and it does not get interpreted as a script tag format. Is there a way to exploit this to XSS attack ?

No the exact code you have posted is not vulnerable to XSS.

Now if you are writing first_name to the page anywhere it could be a reflected XSS vulnerability or maybe a DOM based XSS vulnerability.  But the tiny piece code you have posted is not a vulnerability


How do I determine if an existing SSH private key is secure? For an ordinary user, how would I verify that a private key file was generated using reasonably secure algorithms? In response to things like allegedly insecure ssh-keygen defaults.

As RubberStamp points out, this is covered in detail in stronger encryption for SSH keys but to summarize:

Look at the words in the first line, and the next one or two.

 -----BEGIN RSA PRIVATE KEY-----
 Proc-Type: 4,ENCRYPTED
 DEK-Info: DES-EDE3-CBC,(hex)

 (several lines of base64)
 -----END RSA PRIVATE KEY-----

(or similarly with DSA PRIVATE KEY or EC PRIVATE KEY) is the old, bad-PBKDF format.

 -----BEGIN RSA PRIVATE KEY----- # or DSA,EC
 (base64 immediately)
 -----END RSA PRIVATE KEY----- # ditto

is the old unencrypted format, which is even worse.

 -----BEGIN OPENSSH PRIVATE KEY-----
 (several lines of base64)
 -----END OPENSSH PRIVATE KEY-----

is the OpenSSH-specific 'new' format, which is why it says OPENSSH right there. However, this format doesn't directly show whether it's encrypted or not. The easiest way is to try reading it (either for an ssh connection, or with ssh-keygen to convert or modify it) and see if it needs a password. Alternatively, you can strip the labels and decode the base64 (conveniently, openssl base64 -d does both of these!) and look at it:

$ openssl base64 -d <se200935.clr |od -c
0000000   o   p   e   n   s   s   h   -   k   e   y   -   v   1  \0  \0
0000020  \0  \0 004   n   o   n   e  \0  \0  \0 004   n   o   n   e  [snip rest]

$ openssl base64 -d <se200935.enc |od -c
0000000   o   p   e   n   s   s   h   -   k   e   y   -   v   1  \0  \0
0000020  \0  \0  \n   a   e   s   2   5   6   -   c   b   c  \0  \0  \0
0000040 006   b   c   r   y   p   t [snip rest]


What PCI self assessment questionnaire to choose? We need to fill out a PCI self assessment questionnaire, and I am wondering If we need to fill out SAQ A-EP or SAQ D.

We are an e-commerce merchant that doesnt operate trough a website, but we  receive credit card details on our API. We tokenize it and send it to third-party PCI compliant service provider. We don't store any credit card details.

The introduction to the SAQ A-EP Document (PDF) reads (emphasis mine):

Before You Begin
SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.
SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

Your servers receive cardholder data (albeit via an API rather than through an interactive web-page) and processes cardholder data (to tokenize it before forwarding to a third-party site). Therefore my reading of the above is that SAQ A-EP is not applicable.
The use of the word website in the first paragraph is, presumably, to cover "normal" websites that hand both the acquisition and processing of cardholder data to another party: for instance by opening a new window or embedding an <iframe> in their webpage (and where the contents of the window/iframe is provided by the third-party and not your servers).
While one could debate whether "website" in the first paragraph includes a non-interactive API, I think that is irrelevant1. The second paragraph does not use "website" – it talks only of "systems" and "channels" – so would unambiguously apply to your situation. Since you do process cardholder data, you cannot be an "SAQ A-EP merchant".
Therefore, of the two, the SAQ D questionnaire would apply to your situation2.

1 My strong suspicion is what really matters in the first paragraph (and this view is backed-up in the second paragraph) is the passage I highlighted, namely "that does not itself receive cardholder data". Even if your API is not considered a website, it does (or will) receive cardholder data, and therefore you would not be eligible for the (presumably less onerous) obligations of SAQ A-EP.
2 Note that the introduction of SAQ D (PDF) reads "SAQ D for Merchants applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type.". Of the two SAQs you mention, you clearly (in my mind) don't meet the criteria for SAQ A-EP. However, according to Understanding the SAQs for PCI DSS version 3 (PDF), there are a number of other types. It's conceivable (though from a quick scan of the opening page, unlikely) that you could be eligible for one of those.


Bash wildcards - Manipulate globbing to delete arbitrary files I am currently auditing a plugin and have the following situation (simplified for example purposes):

<?php

$post_id = false;
$absolute_path = "/var/www/html/wordpress/cache";
$extension = ".min.css";
$filename = $_GET['filename'];  // I have complete control over the $filename variable

$absolute_path = $absolute_path . "/{$post_id}/{$filename}-[0-9]*{$extension}";

$files = glob($absolute_path);

foreach($files as $file) {
    unlink($file);
}

?>

The point is that I want to leverage this situation to delete arbitrary files on the system, which might lead to remote code execution. The issue is that I control $filename, but something will be appended later.

glob() is a function in PHP that uses pattern matching to find files and directories. glob uses the wildcards of the system.

When you expand the $absolute_path variable, this is the result:

/var/www/html/wordpress/cache//I-HAVE-CONTROL-OVER-THIS-PART-[0-9]*.min.css

My goal is to get the following result: Have glob() return the path to wp-config.php (/var/www/html/wordpress/cache/../../wp-config.php)

In order to achieve this, I would have to somehow get glob to "ignore" everything that comes after the part I control or some other bypass. Is there any way to do this?

I already tried debugging glob() itself but I just don't know any further.

I thought about the possibility that sticking a NUL byte (\0) to the path would cause glob() to ignore the part after the NUL. That's exactly how C strings work and filenames are passed to e.g. system calls as C strings.

But that doesn't seem to happen: on my system (Debian's PHP 7.0.27), both glob() and unlink() demand a string without NUL bytes, and error out if you give one. And any other character would be valid in file names, so glob() would have no reason to drop the rest of the path.

The possible issue with NULs is mentioned with an example in the online manual, so it's possible that some older version of PHP would have been vulnerable. Null bytes related issues:

  As PHP uses the underlying C functions for filesystem related operations, it may handle null bytes in a quite unexpected way. As null bytes denote the end of a string in C, strings containing them won't be considered entirely but rather only until a null byte occurs.


S/MIME doesn't protect against a stolen password, right? We're setting up S/MIME so that we can send encrypted emails. However, I have a bit of a stupid (and maybe obvious) question...

If someone steals a password for either the sender or the receiver, wouldn't they be able to view those sent or received emails? If not, what's preventing them from doing so?

As far as I know, S/MIME doesn't use passwords, but private and public key pairs. So, the private and secret thing is user's private key. If private key is stolen, it can reveal the content.

If you want to prevent stealing privkeys you (or each user) should store them in safe place. If your privkey is stolen, you should asap revoke the certificate (with pubkey) and get new key pair.

S/MIME actually encrypts the message content with random symmetric key, which is encrypted by recipient's pubkey. Recipient then using his privkey decrypts the symmetric key and uses it for message decryption.