Why does Microsoft use a digital signature catalog instead of a signature in the executable? I own a code signing certificate, so I can add digital signatures on files that contain executable code.

Microsoft seems to use a "new" way and provides most digital signatures not in the file itself but in a signature catalog (C:\Windows\System32\catroot). AFAIK, the lookup in that list is based on a hash value. Therefore, changing the file in any way - even adding another valid signature - will actually result in a removal of the Microsoft signature.

I agree that changing a Microsoft file should result in an invalid signature, but I can't see the benefit of removing a Microsoft signature when the file is signed again by someone else. Although I agree that this will rarely happen.

I see the following disadvantage: given you copy a valid Microsoft executable over to another PC which does not have the catalog (e.g. a newer catalog or older catalog), it will be displayed as unsigned, leaving it up to the one who copied the executable to proof that this is not malware.

When did Microsoft start to use catalogs any especially: why?

Catalog files have actually been around since Windows 2000/XP. They are an alternative to signing single binaries as you attach one signature to the catalog file rather than a signature to every single binary. You can use either one to the same effect, but catalog files are more efficient for a large collection of files.

Microsoft typically does not include hashes from third party binaries in their catalog files, unless they are including them as part of the OS or a Microsoft application and are willing to sign those files. The exception to this is kernel mode drivers for Windows 10 as explained in this post. It is unlikely that a third party would modify a Microsoft-signed file without having it signed again.


Is HPKP enforced on the server or in the client? I'm trying to learn about HPKP and I am trying to grasp if it is just a level of protection for user agents to mitigate MiTM attacks over HTTPS or if the server also plays a role.

Please keep in mind I am literally just learning, reading, googling about this now so the proceeding question details may use terms and concepts incorrectly. For the sake of my own education, and others that may come after me to this question with the same limited information, please feel free to alleviate my/their ignorance.

So as I currently understand it, the server delivers the relevant HPKP headers to the user agent. It is then up to the agent alone, such as a web browser, to enforce it. It does not appear that there is any validation happening on the server.

In other words, I could write a custom client that completely ignores the Pinning header details. Sure it would receive the headers, but my custom client is free to make HTTPS requests any way it sees fit (within the bounds of HTTPS protocol). Obviously I would be putting my imaginary users at risk to ignore this information.

With no server verification in place though I am completely free to just skip it and everything will proceed normally.

To summarize, HPKP seems to be a user agent bound feature, not a server bound feature along the same lines as HSTS. They are response headers that tell the agent: "Hey, please do this, but it's really up to you". If I am the author of a responsible user agent, and I care about my users security, I will make my user agent comply. Compliance however is optional.

Yes, both HSTS and HPKP are enforced by the client/user agent. All that the server does is generate response headers.

The server cannot enforce compliance because, in a MITM/interception scenario, the server might not even be involved at all to enforce the policy.


Can Professor See Open Tabs Or History? I have a professor that has online quizzes. They mentioned on the first day that they can see the other tabs open in the browser so don't try to cheat by looking up answers. Is this possible? If not easily doable, in what ways could the professor (or hacker) view your open tabs - even if it's illegal?

Not if it's your normal browser. He could see if the page in your browser has gone out of focus (e.g. if you open a new tab, click over to a new window, etc.), but that is pretty much it. One course my girlfriend had to endure in the past required her to use a dedicated browser which was a bit more invasive, but she was able to cheat using a secondary computer nonetheless.


strstr and fopen, is there a bypass? I have a binary that does this:

if (strstr(USERCONTROLLERSTRING, "..")) exit;
fopen(CurrentPath+"\\Data\\"+USERCONTROLLEDSTRING, "r");

then spits out all the content of the file. Is there any obvious vulnerability here?

Its a Windows service, it runs as SYSTEM, I'm trying to make it read sensitive files such as SAM or maybe some other vulnerability.

It only checks for ".." and it appends user provided arbitrary string to CURRENTPATH+"\\Data\\" then calls fopen

P.S. Encoding, unicode, base64, %-coding, etc won't work as it does the strstr right before fopen call after all the decoding. But that's pretty much it, no other checks are done

P.P.S. Its a Windows EXE

Windows documentation includes a section regarding Security Considerations: International Features that may be worth a read, specifically involving Unicode normalization.

To answer your question: in a vacuum, assuming the user has no access to the system other than through your program, your code is fine.
That said, if an attacker has access to certain features, such as creating symbolic links/directory junctions, then it could be possible to bypass your security check.  They would simply need to create a directory junction inside the \Data directory that points elsewhere, then access files through the junction  instead.

Additionally, keep in mind that the attacker may have control over the variable you have labeled as CurrentPath.  In Windows, you can run a program with a specified working directory even if that directory isn't the one the executable resides in.  Combined with directory junctions, if there exists any location that the attacker can create a directory junction, they can potentially exploit your program.

Lastly, it may be worth noting that NTFS has some pretty niche features.  On top of that, Windows supports multiple file and directory naming schemes.  I'm not certain if any of these are directly exploitable in this situation, but they're worth keeping in mind.


What's good/bad about this custom password hashing? For the record, this was purely for learning purposes, I've been told don't even use this for a personal website that I don't expect anyone to visit, so this post is unfortunately the last I'll see of this code. However, I've done all the things I read about and it seems decent to me (but I'm no expert), so I'm just curious as to which parts could potentially be bad enough that the recommendation to everyone is to never ever use a custom solution?Not naming anyone, but I'm pretty sure I've already done a miles better job than the free webhost that begins with a triple number haha, my plaintext password was stolen from there.

Here's the basic idea of what I did:

Salt and IVEach salt is generated by a random but not cryptographically secure function in PHP (it's better than the default random though). It is then encrypted with blowfish using a key defined in the code, and an IV defined in an actual file (which is protected by htaccess). The encrypted value is stored, so it's very easy to change the IV or salt key to invalidate all passwords. Also if the database is compromised, the salts still can't be decrypted without getting access to the file system.

HashIt uses key stretching and sha512. The amount of key stretching is defined by a modulus of a crc32 value of the password and salt, so each user has a different amount, and you can change the value to allow longer processing times. Each repeat hash uses a few hashes inside it in an attempt to keep it pretty random.

Here's the actual code I have, if you don't know PHP it's still fairly easy to see what's going on line by line:

$salt_key = 'íSgüý[Îaí²zÿCV™F÷œDDa©^fU©êm‹“.Ù   ®Kâ³ÃX}rÿ,¢\ˆÿ7L³¢QÆH’YeTsÙõŸ¥éÙí#W—c´VÆ';

function get_iv(){
    // It stores it as a file, but there's no point showing that part so here's the actual code bit
    return mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_BLOWFISH, MCRYPT_MODE_CBC), MCRYPT_RAND);
}

function generate_salt(){
    global $salt_key;
    $salt = substr(uniqid(mt_rand(), true), 0, 32);
    $key = hash('sha256', $salt_key, true);
    $iv = get_iv();
    $encrypt = mcrypt_encrypt(MCRYPT_BLOWFISH, $key, $salt, MCRYPT_MODE_CFB, $iv);
    return array($salt, $encrypt);
}

function decrypt_salt($encrypted){
    global $salt_key;
    $key = hash('sha256', $salt_key, true);
    $iv = get_iv();
    return mcrypt_decrypt(MCRYPT_BLOWFISH, $key, $encrypted, MCRYPT_MODE_CFB, $iv);
}

function hash_password($password, $salt){
    #return hash('sha512', $password.$salt, true);
    $hash = $salt;
    for($i=0; $i<(crc32($salt.$password) % 129197); $i++){
        $hash = hash('sha512', $hash.$password.$salt.hash('sha512', $salt.$hash.$password).md5($salt.md5($password.$hash)), true);
    }
    return $hash;
}

The part to check if the password is valid basically just checks the new hash against the old one so I left it out. The only drawback based on the things I've read a good algorithm should do, is it doesn't use a lot of memory.

Open questions:

Why aren't you using a cryptographically secure RNG for the salt? You're not going to be generating them so frequently as to risk depleting the system entropy pool on a modern system.
How was your salt encryption key generated?
How long is your salt_key (before you hash it)?
Why are you hashing your salt_key? That adds no security.
Why the overly-complicated nested hashing (including use of MD5, of all things) in your key-stretching loop? It puts me in mind of Moxie Marlinspike's commentary on the (broken) MS-CHAP v2 scheme (search for the string "unnecessary complexity").

Notable issues:

You do, in fact, want to use securely-random salts (and IVs). It matters how predictable the salt is; predictable salts allow attackers to pre-compute lookup tables for the predicted salts against likely passwords. Predictable IVs are probably less of a risk in this context but there's no reason not to use securely random ones.
Your key stretching iteration algorithm provides little-if-any increase in security - for each trial password, the attacker can compute the iteration count just fine, assuming they know the salt (and if they don't then they can't try to brute-force the password verifier at all) - and puts you at risk of running far fewer rounds of hashing than you intend. In particular, if the CRC is an exact multiple of 127197, the user's salt is stored as their password verifier and the password is not used at all, so any password at all will work for that user! If you get a million users, about 8 of them will have no password protection at all.
You have no method for rotating or upgrading the algorithm for password verification, at least nothing visible in what you've presented here. Hardcoded critical attributes (such as the key, the cryptographic primitives, and the way iteration count is determined) may need to change at some point in the future, at which point you would need to be able to verify a user's password under the old scheme before generating a new password verifier with the new scheme (unless you just plan to force everybody to reset their password, which is a hassle and should only be done when there's reason to expect the old ones are compromised). Therefore, you need a way to specify a password verification algorithm version, or at least need to store identifiers (probably indices) for your various currently-constant values, and look the values up based on each user's stored version identifier / index.
In the worst case, 129+k iterations of SHA-512 (never mind SHA512(SHA512(MD5(MD5)))) is going to take a long time on your server. An attacker that finds a combination of username and password for which it is so expensive to compute the verifier can just submit a bunch of requests with credentials like that (especially since, due to the reversibility of CRC, the attacker can manipulate the input to get exactly the desired checksum). That will probably cause a denial-of-service on your server. Work factors for password verification need to be high enough to slow down brute-forcing, but must not be high enough to be a way that an attacker can overload a server.


URL Rewriting vulnerability We modified our Session handling from cookie based to URL Rewriting. By doing this the session id gets transmitted as part of the URL.

Now there is a vulnerability issue, where whoever uses this URL will be able to log in into the system.

To resolve this issue we have done the following

A HTTP Session Listener has been created to maintain list of HTTP
sessions. Listener reacts on the events when session are created or
destroyed.
A Session Filter has been created to verify HTTP Session and check
    its integrity against HTTP Request attributes Session will be
    invalidated in case Request attributes (identifying the client
    origin) do not match original attributes stored with session. (to
    block the session hijack attempt)

However i think that this has a gap, when you are trying to access over a proxy etc.

Is there any other effective solution for this?

Also we cannot use third party libraries to resolve this because of the nature of the produce.

Sensitive information should never be transmitted using GET requests. The main reason is that users sometimes send links to eachother. Your system will probably fail to detect it when clients are behind a NAT router or a proxy.

If you are using sessions you might as well restart using cookies. I'm not really sure why you would need to put the session in the URL.


3DES supported in application although disabled in Windows Can users actually use the 3DES cipher to connect to a Tomcat web server, if the 3DES cipher has been disabled via registry keys in Windows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES
dword enabled 0 and dword disabled by default 1 for both client and server

Nmap scans indicates that the cipher is still available, and so does Qualys vulnerability scans:

   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

I've used the same method to disable TLS 1.0 on other Windows servers, which work fine and both Nmap and Qualys confirms.

Is it necessary to disable 3DES cipher in the web server as well, although Windows won't provide the cipher?

This is now beginning to sound like a Tomcat configuration question. Although I have no personal experience with Tomcat, some links suggest that this section of the Tomcat documentation guide looks appropriate, in particular the ciphers attribute in the configuration file conf/server.xml. From the docs:

  ciphers attribute:

  The ciphers to enable using the OpenSSL syntax. (See the OpenSSL
  documentation for the list of ciphers supported and the syntax).
  Alternatively, a comma separated list of ciphers using the standard
  OpenSSL cipher names or the standard JSSE cipher names may be used.

  When converting from OpenSSL syntax to JSSE ciphers for JSSE based
  connectors, the behaviour of the OpenSSL syntax parsing is kept
  aligned with the behaviour of the OpenSSL 1.1.0 development branch.

  Only the ciphers that are supported by the SSL implementation will be
  used.

  If not specified, a default (using the OpenSSL notation) of
  HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA will be used.

  Note that, by default, the order in which ciphers are defined is
  treated as an order of preference. See honorCipherOrder.

So you now have a way to specify what you want. Actually, you have two ways, either OpenSSL syntax or a JSSE ciphersuite list, and each has it's pros and cons.

The OpenSSL syntax provides a compact specification that allows you specify what you don't want in addition to what you do. The downside is that the terse notation makes it hard to understand just what you're getting.

The JSSE ciphersuite syntax is quite straightforward. You just explicitly list each allowable ciphersuite from this (check here for Java 11)long list, separated by commas. The downside is that as new ciphers are added over time you will have to add to this list to allow their use.


Faking and injecting cryptographic certificates Suppose as an attacker I provide a fake certificate to a user.A warning pops up on her window but she decides to continue anyways.Is my fake certificate now added in her browser's trusted certificate list? If she tries to visit my website and I provide the fake certificate again is she warned again or not? Also,how can I inject a fake certificate in a target's list of certificates so that she is not shown a warning certificate?

Is my fake certificate now added in her browser's trusted certificate list?

Yes, depending on the browser being used. It used to be that ALL browsers behaved this way. Adding a self signed certificate to the trusted certificate store.

  If she tries to visit my website and I provide the fake certificate again is she warned again or not?

In the last few years this behavior was modified to force acceptance of the non signed certificate prior to proceeding to better protect unsavy internet users from falling victim to this sort of exploit.

  Also,how can I inject a fake certificate in a target's list of certificates so that she is not shown a warning certificate?

While this area of research (using a cluster of devices to brute force and factor a collision of the random number generator leading to a private key with which to generate a weakly signed x.509 certificate) has provided fruitful results in labs, it is not common, and very computationally expensive to do.

In order for you to 'inject a fake certificate' that would evade the browsers OSCP stapling you must have a valid signed X.509 certificate from a CA (certificate authority).


Using Secure Remote Password without embedding the modulus The SRP protocol as described by the author assumes that the large safe prime modulus and generator are embedded into the client and server rather than being transmitted as part of the protocol.  However, the author suggests in this section that the protocol can be modified to allow the modulus and generator to be chosen by the server and transmitted  as part of the protocol rather than embedding them in the implementation.  I would prefer that for several reasons.

So what's confusing me is that the server is supposed to store the client's password ahead of time in the form g^H(s, P) mod n, where g and n are the generator and modulus, H is a cryptographic hash, s is a salt (also kept by the server) and P is the plaintext password.  Now in the security analysis section there is a reason given that g^H(s, P) mod n is stored rather than simply H(s, P), so that stolen database entries cannot be used.  x = H(s, P) is seen as the client's private key.  So if g and n can change from session to session, how can this possibly work without the server directly storing x?

You may want to use RFC 2945 and 5054 (description of SRP, and of how to use SRP with TLS, respectively); they are a bit more "down to the wire" than the mathematical description from the author.

When the SRP author states that the server may choose the prime n and send it to the client, he does not mean that the server may choose a new prime n for every session; the same n must be used when the user password is first chosen (and v stored by the server) and when a key is exchanged. What the SRP author means is that an authentication session can begin by the server sending a n-value to the client and telling it "we shall use this n, which is the n which we used when the password was chosen". The client needs not be sure, security-wise, that this is indeed the same n, and not another n crafted by a fake server. In that sense, the value of n needs not be hardcoded in the client.

However, if the client needs not check that the value of n is the same than used beforehand (it will have to be the same for the protocol to succeed, but a distinct n sent by a fake server will not endanger the password confidentiality), the client must still make sure that n is proper, which implies, at least, to check that n and (n-1)/2 are prime. See for instance section 3.2 of RFC 5054. The bottom-line is that, for an efficient use of SRP, you really want to use a few hardcoded n values, which both client and server know.

Possibly, you could precompute 3 or 4 sets of parameters (values of n of distinct sizes, for paranoia/efficiency trade-offs), that the server stores, and in the client you store only the hashes of those values; when a password needs to be exchanged, the server sends n and the client verifies that its hash matches one of its hardcoded hash values. Alternatively, have both client and server store the values of n, and simply use short identifiers so that both client and server use the same value. Note that if the value of n depends on the user (a given server using several values of n concurrently, and must send the "right one" for a given user), then the protocol must arrange for the user to first state his name; this is the point of the "srp" TLS extension (section 2.8.1 of RFC 5054).

You cannot have the server change n for a given user after password choice, unless the server stores the password-equivalent value x = H(s, P), and SRP was designed precisely to avoid such storage.

Note that there is no security issue whatsoever of having several distinct users on a given server or distinct servers use the same n. A single n can be fit for the whole world. RFC 5054 (appendix A) lists a few n of sizes 1024 to 8192 bits.


What are the examples of XSS (or other attacks) using "forward slash" only? In OWASP XSS cheat sheet it is written

  In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.

So the recommended escapings are

 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ' --> &#x27;
 / --> &#x2F;

What if I skipped escapings of /? What are the examples of attacker payload using just / that can trigger XSS or other attack (assuming & < > " ' are all escaped)?

In my particular scenario, we have an XSS filter in the Java servlet, which sanitizes the payload of all incoming HTTP requests (it can be argued if it's a good solution or not), and it replaces / --> &#x2F; which is a pain because / is a valid character in street names etc. One option would be to redecode &#x2F --> / but I'm wondering if there are any merits of keeping / escaped?

Edit: why I don't want to have / to be escaped:

The / is escaped before data comes to the Java code which saves stuff to DB. So, Java asks the DB to save escaped data, then when the frontend app asks Java to give us back the data, it gives back a JSON like

{something: "a &#x2F b"}

instead of

{something: "a / b"}

(well, to fix that, we could just have Java code iterate over the structure it returns and unescape it, but maybe there's no point in escaping it in the first place?)

Note that the same backend is consumed by many frontends, some of them non-HTML.
It doesn't make any sense to serve escaped HTML data as a JSON, particularly for non-HTML consumers (correct me if I'm wrong).

Moreover, in HTML app, we use Angular code like this

Hello {{name}}!

which, when given a &#x2F b, will print that string literally to the user (i.e. Angular does another round of escaping by replacing & to &amp; etc.).

To have HTML entities interpreted, I'd have to use ng-bind-html (see this plunk)

Hello !

but I expect my JSON contents to be regular text, so I don't want to use ng-bind-html as it lowers the security.

Injecting a forward slash is not a common attack vector for XSS.

The required escaping depends on the context where you're printing the output. A forward slash is used to close a tag and there is no other HTML context where it's inherently dangerous. (In Javascript this would of course be a very different story. Also, slashes are relevant in other attacks, such as directory traversals.)

  What are the examples of attacker payload using just / that can trigger XSS?

Such scenarios are rather artificial. For example, between a <title> tag all other tags are ineffective until you close the tag again. This would not trigger:

<title></title>

So if you encounter a scenario like...

<title>[userinput]</title>

...you would need a slash to be able to close the title tag yourself to achieve XSS.

The reason why the OWASP cheat sheet recommends a few more measures is to cover multiple output contexts at once. Since XSS escaping should only be employed on the final output, it doesn't hurt to escape a few more characters. (From your description it sounds like you are processing the data after XSS escaping which is not the idea.)

Example 1:

Welcome [username]!

Here, it would technically be sufficient to just escape < in the username since an attacker cannot inject new tags.

Example 2:

Your new name: <input type="text" value="[username]">

Here, it would be sufficient to escape " to avoid XSS because an attacker can never get beyond the attribute value.

Example 3:

Your website: Click me

Here, escaping " in yourlink would avoid breaking out of the attribute but you have to take additional measures to disallow XSS via pseudo links like javascript:foo(). So the standard escaping would be insufficient here.


What particular devices and processes are available to destroy hard drives, per DoD 5220.22-M? DoD 5220.22-M specifies the following methods for destruction of hard drives with classified data:

Disintegrate
Incinerate
Pulverize
Shred
Melt

I've seen shredders of the type that might be used on a hard drive, and can probably imagine what incineration is like.  But the options of "Disinitegrate", "Pulverize", and "Melt" seem... particularly fascinating.

Are there facilities that actually offer each of these as an option?  If so, how exactly is each done?

(Bonus points for YouTube links.)

There are facilities that provide this service. The facilities are often contracted in for facility-wide "shred-days." In house, the military has Defense Re-utilization and Marketing Office (DRMO.)  This office attempts to re-sell, or re-utilize equipment safe for use, or is often used in disposition.

Here's what Ive found:

Pulverizing:

Basically, this is a hammer mill that rotates. Centrifigul force pushes metal "planks" out that shmammer-the-heck out of the hard disk, until it is reduced in size enough to pass through the holes in the filter part of the chamber.

Watch hard drives being Pulverized @ YouTube

Disintegrating:

Basically, Disintegrating is shredding, but designed for use primarily on plastics such as CDs. This works in a very similar manner to a hammer mill, however it uses blades to cut/shred the items.

Watch paper, plastic, and a CD being disintegrated @ YouTube

Melting

Certain hard drives components are melted, such as the aluminum chassis, AFTER the disk has been destroyed through other means.

Watch hard drive melting @ YouTube

I hope this helps!


Is BitWarden trusted? I've been using BitWarden as my main password keeper, would like to ask if it's safe? I know that everything is not 100% safe but still want to know if they are worth it.

All my passwords are different beside some accounts password.

I know there is also keepass but can't really be annoyed to backup it each time because I also use a lot my mobile and BitWarden has a mobile application that is really helpful.

First as you said nothing is 100% safe. Having said that I think BitWarden is a trust worthy password manager for the following reasons,

They are open source. All of their products including their desktop app, mobile app, browser extension, web application & server are all open source.
The applications are developed in open too. The open source projects are not just code drops, the app is being developed in the open.
If you are using BitWarden's cloud, you need to know that they use Microsoft Azure offerings. They only use service offerings and all the security updates to the server are handled by Microsoft which they claim is better for security.Ref
If you are not satisfied with the security of BitWarden's server or have issues with MS Azure, you can host your own server. This way your data will be with you only and not stored in BitWarden's server. This is one of the biggest advantages as even if BitWarden's server gets taken down or hacked your data might be accessible and safe.
Compared to KeePass they have a well maintained open-source applications on all platforms. Some forks of KeePass are not that up to date.
They are audited by third partiesRef.


Is `/dev/urandom` secure to generate a salt on a Virtual Machine? I've read the new password_hash() function from PHP uses /dev/urandom to generate a secure salt, however this assumes some noise from device drivers.
Is possible that /dev/urandom is not so random when in example deploying a website on a Virtual machine? (in example the same image of a operative system snapshot is runned and in reality what we get is just a "hash" of system time?) I am assuming that simulating the operative system is going to be deterministic (or more deterministic than) unlikely a system running on bare metal.

EDIT:

Is /dev/urandom random enough to allow unpredictable salts to be generated on a Virtual Machine?

The salt in a password  just needs to be random enough so that its more or less evenly distributed. The salt is just used to make attacks with precomputed password hashes or rainbow tables infeasible by increasing the needed memory. Thus there is no need for a cryptographically secure random generator. This means that the implementation is secure enough in your case.


What are the security differences between a service-signed client certificate and an out-of-band shared secret? TLS allows for client certificate validation. Client certificates can be signed by the client, the service provider, or a trusted third-party CA. I'm talking about the middle option.

At a glance, it would seem to me that handing out an API key to a client would be equally (in)secure to identify that client, as when signing a CSR for that client on the service provider. The API key approach would be a LOT simpler, not having to deal with CSRs and certificate renewal etc.

Are there any differences in security between these two options?

 I have to also mention here that there is complete control over client implementation, i.e. safeguarding the API key client side is under the same level of control as the client's certificates and private key

There is a difference in a non-repudiation point of view. A shared secret is known to the server, so if something bad happens, the client can claim that he did not use the secret at that time. Specifically, any admin of the server can use the shared secret to pretend being the client.

Even if the CSR is signed by the service, the private key is still only known by the client: the service nor the admins cannot use it. So the client cannot pretend that somebody else used their certificate.

The real question is what exactly is your requirement and why you want a secure authentication of the client. Because all the logs are under full control of the server. So you can prove that you got a connection from the person who owns the private key, but it would be much harder to prove that this specific connection was used to make something.


Where are historical data for the CIS Alert Level? The CIS Alert Level is a representation of the current state of cyber(in)security, globally.

There used to be a history of the levels, with an explanation for the changes (especially the rises). I cannot find it anymore - would someone know where it is currently hosted?

Note: I am aware of the subjectiveness of this or another measurement for "cybersecurity threat". I would be glad to use others, for the sake of completeness but I am currently especially interested in the historical aspects of the changes.

It seems that this kind of information is now only available for members of MS-ISAC. If you're a U.S. SLTT government entity, you can submit for a free membership. But, if not, unfortunately there isn't any resource for alert history.

As an alternative, you can track the advisory page of MS-ISAC for last years track (~3 years) or subscribe to their newsletter.


Does the X-Permitted-Cross-Domain-Policies header have any benefit for my website if I'm not using Adobe products? OWASP says the X-Permitted-Cross-Domain-Policies security header gives web clients "permission to handle data across domains". It specifically states that Adobe's Flash Player and Acrobat PDF Reader use this header and that other web clients could possibly benefit from the header too. The reference links provided reinforce the benefit to Adobe products but don't give any other situations where this security header is beneficial.

I can't find any benefit to this header unless I'm using Flash or PDF. So in that light, does the X-Permitted-Cross-Domain-Policies header have any benefit for my website if I'm not using Adobe products?

You have it the wrong way round. Much like Access-Control-Allow-Origin the purpose is to allow other systems (in this case specifically web-hosted Flash and PDF content) to access your domain. The "remote domain" is you, the "source domain" is who we're defending against.

  When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

By default, all cross-domain requests will be blocked by Adobe's software, the same as browsers block cross-domain XMLHttpRequest.

An unwanted policy file may find its way onto your site, either by accident or malice. The purpose of adding X-Permitted-Cross-Domain-Policies in this case is to override it, so that the client still blocks unwanted requests.

Microsoft Silverlight uses a different policy file format, but it may also still use this header.

If you allow people to upload files, or are concerned about intruders using a different flaw to get files onto your server AND the content on your domain should not be accessed via other websites possibly trying to impersonate you, then yes X-Permitted-Cross-Domain-Policies will provide a security benefit. The attack is less relevant these days, as any user of modern software first needs to be tricked into allowing Flash or active PDF content.

If your website is just a regular website with nothing that requires a login to access, then you don't need it.


Searching for files on unknown/proprietary filesystem I am attempting to find any files or folders on an SD card.

Currently I've been looking at it with Foremost, but with no success. I know for certain that the file-system on the SD card is non-standard one that is not publicly available/ I believe this is causing issues with Foremost's data carving detection.

Is my only option to examine the memory its self? If so, what tool or text is best to utilize for this task?

Data carving (with something such as Foremost) works outside the file system, looking just at the data storage directly, so in some ways it is not affected by the file system. But of course it does somewhat depend on how the file system stores the data. Most common file systems commonly store data in contiguous areas and that is why file carving works and can recover whole files. It is possible for some unknown file system to scatter small data chunks all around I suppose, making it much more difficult to detect files and really really difficult to put together whole files. It's also possible for the data to be encrypted or encoded somehow by it.

Photorec works well recovering files from raw data (disregarding any file system) for many different file types based on identifiers for each file type supported). It's free and open source. There are also other good non-open source tools for that such as R-studio and ReclaiMe.

What file types are you going for? Some are easier to carve than others. Some you may even have to carve completely manually. As I said it's also possible the data is encrypted or encoded somehow if you're not finding anything with common file types. Have you looked at some of it in a hex editor? Winhex is a good one for Windows. That might be a good next step to get an idea of what is there. Otherwise you might be spinning your wheels.


Question regarding keylogger references For educational purposes I would like to learn how keyloggers have been made so far... from the simplest to most complex keyloggers. I can't seem to find a book focusing on them, most of the books I've seen go through the whole arsenal of exploitation.

The most important things about keyloggers to consider:

on what platforms (including what Windows version) do you need it to work?
should it work in stealth mode (be invisible in Task Manager etc.)?
how it should be installed on monitored system?
what information except raw keystrokes do you need to capture? eg. screenshots, window names etc.
how it should send you recorded data? online/offline, how often, how to avoid filling user's disk etc.
if it should work in stealth mode, how to prevent forensics? what actions should be taken except deleting all files? how to trigger it remotely or automatically, when suspicious activity is spotted?

After you collect answers for these questions, you can start googling for specific solutions.

In the meantime, this is the source code of simple, non-stealth keylogger working on Windows 7 and later, for the reference:

http://www.rohitab.com/discuss/topic/40755-good-keylogger/


Low level attacks on WLAN/LAN connection while connected to VPN Is it really secure to connect to a (well-secured) VPN server over an unencrypted WLAN connection (or maybe a hotel Ethernet)?

I know, that there have been questions like this - but

I'm not asking if people can read/fake the encrypted contents of the VPN connection.
I'm not asking if the traffic of all my applications will be routed through the VPN.

What I'm worried about are more low level attacks. Is it reasonable to assume (and these are really just a wild guesses) for example,

that a fake WLAN access point could send specially crafted WLAN packages that would result e.g. in a buffer overflow on my WLAN adapter, which could be used to break into my system?
that somebody on the same LAN could send low level (ICMP, ARP, ...) packages that could exploit a security vulnerability of the kernel?

Additionally, I'm worried about a possible small time window after the insecure WLAN is established, but before VPN is up and running.

Things like these...

Based on your answers, comments, and my general basic understanding of the topic, I'll try to add my own answer here (Note: More answers and comments are very welcome - correct me especially, if my assumptions are wrong.)

@symcbean puts it in a nutshell:

  VPNs only address confidentiality and integrity - not availability.

Availability can either be compromised by disrupting the network: WiFi jamming, flooding the LAN, faking IP or MAC addresses to e.g.

redirect to a different DNS (which doesn't impact confidentiality/integrity, if the VPN is fully set up, but it can impact availability before it's set up)
redirect to a different gateway (still doesn't impact confidentiality/integrity, but does impact availability)
...

But what's more important: "Availability" of the VPN can be compromised by hacking your laptop on a low level - and many sets of attacks that you're exposed to when you connect to an unprotected network will still work when you tunnel through the unprotected network with VPN. And of course, once you're hacked, availability won't be the only problem...

It's not entirely clear, how likely these attacks are (and this would be a very interesting question!), but the thing that worries me most, is that this topic is never ever mentioned by administrators when they give out VPN access. Generally, an attitude of "it's okay to connect to the most unreliable and dangerous networks in the world - as long as you're using a secure VPN setup, you're safe" has evolved, and it's hard to convince anybody, that security of the VPN is not the only concern!


OAuth 2 Implicit grant type for first party SPA - Most secure and sensible way My aim is to secure my stateless API and only allow the registered first-party clients (SPA) to consume my resources. There is not going to be any third party clients in my scenario.

I know Oauth 2 authorization with implicit grant type is recommended for public clients (in my situation, a SPA). I have read lots of things about that but I couldn't understand some points, so I'm asking for your help:

Do you think Oauth 2 with implicit grant type is the best way to accomplish this? I know password credentials grant type is not safe for SPAs, because they can not maintain the confidentiality of a client secret. So should I go with Oauth 2 with implicit grant type?
In Oauth 2, i can use the implicit grant type with auto approval, so taking the consent of users are not necessary anymore. But as i think of my SPA as a first party app, i don't want any users to redirect anywhere to login and get back to SPA page.

Do you think it is secure and sensible to enable http basic authentication for my API, so then my first party app would be able to get user credentials and add it to authorization header and sent to my Authorization server over SSL/TLS channel to authenticate and get access token?

If it is not appropriate, what do you recommend to achieve this goal?

I want also unauthenticated users to consume some resources in my SPA; should I make those resources public for any client and any user (actually I don't prefer) or expect SPA to authenticate and authorize with a dummy anonymous user to get an access token with anonymous privileges to consume public API resources.
For a Wikipedia-like website, how long should it take an access token to expire?
When it is expired, what method should I follow? There is no refresh token in OAuth 2 implicit grant type. Should I ask users to enter their credentials again (this is not user-friendly) or store their credentials in a storage and sent it to an authorization server silently to get a new access token?

In your case, I think that OAuth 2 doesn't make sense. It's designed to handle third-party clients, and the additional complexity is likely to be a distraction when you only have one single first-party client.

For user security:

No matter what you do, a web-based app is one where the user has to trust some webpage of yours with their username/password. For this reason, it seems sensible to just directly username+password authentication and skip OAuth 2, unless you have some other reason to use OAuth 2.
For publicly-visible resources, allowing access without authentication should be fine.

For securing your API to be used only by your SPA:

This is a completely different issue than user sign-in, and I'd recommend not getting sidetracked by how to acquire access tokens. For instance, many SPAs can be trivially modified/decompiled/spoofed.


Separate normal traffic Is there any tool or method to  separate normal traffic and malicious traffic from pcap? For example : if malicious traffic detected with snort i need to store those packets .only if malicious traffic .  Thanks for respond.

Instead of having Snort listen on an interface, you can give it a packet capture to read. Snort will read and analyze the packets as if they came off the wire.

See http://manual.snort.org/node8.html

This would help you understand the packets that Snort detected.


Bing bar without admin rights I know viruses uses exploits to gain admin rights to install software. My question is here at work, we have people end up with the Bing Bar installed from time to time on their machines. It is listed in the Programs and Features as an installed programs - which requires admin rights to install.

My question is, all of these users do not have admin rights. How does the Bing Bar install onto the system without admin rights? Surely Microsoft does not use an exploit does it?

As far as I know using windows installer a per-user install (in opposition to a per-machine install) doesn't require elevation. As to why user end up with it I noticed that many downloads from Microsoft try to bundle up software. They have a web popup window with the suggested bundled crap checked by default. If you click download without unchecking these items you'll be served a special installer.

Per-user Installations:
https://msdn.microsoft.com/en-us/library/aa370813(v=vs.85).aspx


Why shouldn't I put user input in HTML comments? The OWASP XSS Prevention Cheat Sheet has a list of locations where untrusted data should never be put:

 <script>...NEVER PUT UNTRUSTED DATA HERE...</script>   directly in a script

 <!--...NEVER PUT UNTRUSTED DATA HERE...-->             inside an HTML comment

 <div ...NEVER PUT UNTRUSTED DATA HERE...=test />       in an attribute name

 <NEVER PUT UNTRUSTED DATA HERE... href="/test" />   in a tag name

 <style>...NEVER PUT UNTRUSTED DATA HERE...</style>   directly in CSS

I understand why data shouldn't be put into the other 4 places, but what is the danger of putting user input into HTML comments? I would think that encoding > would be enough to prevent any attacks. Is there a way to execute JavaScript inside a HTML comment? Or a different way to exit HTML comments without >?

The relevant entries in the HTML5 Security Cheatsheet are:

Ending HTML comments with a backtick character: html5sec#133 (IE6, IE8)
Injecting XSS or with a conditional comment html5sec#115 (older IE, IE quirks mode)

Apart from that user input might be used to change this comment into a conditional comment (IE only) and thus change the DOM or block the execution of script after the comment. This could change the behavior of the page in an unintended way.


Is encrypting localStorage data more secure? I'm building an SPA app and I have to use an access token to make requests to an API. The most common way to store the JSON Web Tokens is to use localStorage, but I have always thought that was a bad idea because of XSS attacks or a user could be socially engineered to go to the console, get the token and give it away.

So I use this JavaScript library called 'secure-ls', which uses localStorage but encrypts the data. The encryption key is randomly generated for each instance of the application, so I don't store it as plain text in the code.

This is what it looks like:

private static _instance: SecureStorage = new SecureStorage({
    encryptionSecret: crypto.randomBytes(60).toString(),
});

This is what the encrypted data in the console looks like:

The plain-text data in localStorage is only available to the code. I believe this is sufficiently secure and I can't see how a hacker could get the plain-text data.

So it leaves me to wonder why more people don't use this method? Or is there some loophole I'm missing in how a hacker could get the data?

An attacker has full control over the client, and therefore has complete access to the encryption keys and methods. In short, this cannot actually protect anything from an attacker.

Normally client-side encryption at least provides a small layer of protection to slow down attackers, but protections around client-side JavaScript tend to be the easier to circumvent than similar steps in apps or desktop applications.

It is unlikely to be helpful


Chrome showing cryptography as 'obsolete' Similar to this question, Chrome is showing the connection cryptography as obsolete. Opera, IE and Firefox seem perfectly fine with the connection.

My guess would be the message authentication is using SHA1, but when I view the certificate information, the only mention of SHA1 is the Thumbprint. This appears normal for Windows systems. What exactly is 'message authentication' referring to and what do I need to change server-side to fix this?

As described in this answer and in this commit to chrome only AEAD ciphers are considered state of the art security. It looks like that your server does not use the cipher preference of the client but instead has their own preference which looks like this:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
...
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
...

This means you prefer ECDHE-RSA-AES256-SHA to ECDHE-RSA-AES128-GCM-SHA256 and thus the chosen cipher based on Chromes offer will be AES256-SHA256, because it look like Chrome does not support the SHA384 ciphers. To fix it you might change the order and put the GCM ciphers on top of the preference list.


MySql root password stored in .my.cnf Before launch of a project, I reset the server's mysql root password. The colo that is hosting project wants the server's root database password stored in the .my.cnf file, in plain text, with the permissions set to 400. I just can't see how that is good security practice, but he said that it was something that was being done commonly.

Is it secure to store a the root database password in plain text in the .my.cnf file?

Of course any password that is stored in plain text is a bad idea but the location of the file is in /etc/my.cnf so if a remote user had access to that file I think there would be more things to worry about than having your mysql password stolen. On the other hand if you are not the only one who has physical access to the system then you are still safe from others reading your file since your file permissions are 400, assuming no one escalated privileges on the system. I did some research about having your password in my.cnf file and it's true it's actually a pretty common practice.

By the way you need to make sure you don't actually edit the file thats located in the /etc/my.cnf which mysql server uses to boot up because if you do anyone can use the server with ALL privileges and ALL databases without a password. So instead create a file in your local /root directory call it my.cnf and make sure only root can read it (of course)

The easiest way to do this is to use a client section of the ~/.my.cnf file, and add the credentials inside that file.

[client]
user=root
password=somepassword

Like I said make sure the file is ONLY readable by root. –


Linking mail server with application database I have a web application running on node.js, backed by a MongoDB database which stores user data etc... I'd like to offer my users an email account, so I've set up a mail server using Postfix, dovecot, etc... My problem is that I'd like to link the two user databases. Currently I have postfix and dovecot configured to use virtual users stored in a mysql (really MariaDB) database, and this is working fine (I can access and send emails over IMAP etc...). However, I want my users to be able to use the same password for IMAP as for logging in to the web application. I'm happy to write a PHP api to create users on the mail server etc..., but my issue is how to handle passwords. As I see it, there are two options;

I can transmit the plain text passwords from my web application server to my mail server when a user signs up or changes password. This would then obviously be hashed on the mail server and stored in the mysql database, and hashed on the application server and stored in the MongoDB database. This feels somehow wrong to me - transmitting a plain text password in two hops like that.
I can transmit the hashed passwords from the application server to the mail server, and store them there without hashing again. Again, this feels pretty dodgy, as from the perspective of the mail server, it's accepting passwords and storing them in clear text.

Are there any other options to allow my users to log into both servers with the same credentials? What security issues exist with the two options I've thought of above?

There's also a 3rd option to consider: an authentication framework.
Instead of having separate user credentials for the database and mail server that need to be kept in sync, have a central authentication service that the database and mail servers defer to when a user attempts to authenticate.  There's quite a few options to choose from, but you'll probably want to start with things your applications currently support.  From what I can gather, both MongoDB and postfix support LDAP and SASL, so those would be two options to look into.

As for security issues to the methods you suggested: even if you got secure password transmission figured out, you still have to deal with synchronization.  If an error occurs at an inopportune time (e.g. a user changing their password while postfix is unavailable), you'll end up with mismatched credentials on each service.  It could be fixed, yes, but comparing the credentials on the two servers would involve transmitting at least some sensitive data.  In a more nefarious situation, consider what would happen if credentials de-synchronized when a user was banned.  They could end up retaining partial access to resources that they should have no access to at all.


How does encryption strength make a difference to an attacker Take for example I have my social security and other personal information stored as a string that I am trying to encrypt on my local drive. My first method of encrypting the string is to use a password based AES algorithm, and would then simply paste the generated cipher text into a file where I can store it and decipher it later. My second method of encrypting the string is to make up my own algorithm which is much more simple -- I take that string and apply a few easy bit shifts mixed with some random bit additions, multiplications, and rotations. Later if I need to decrypt that string, I can apply the negation of my logic to attain my decrypted string.

Now that we have a string encrypted with the popular AES algorithm, and another string encrypted with my silly algorithm, they both look equally jumbled up and complex.

Now let's assume that someone wanted to decrypt my personal information, having access to the simple text file that I stored their cipher text in. The attacker does not know what kind of an algorithm I used on the ciphered text. Which cipher text is going to be harder to decrypt? Does the algorithm that I used for this scenario actually matter and why? If this was a poor example of where encryption algorithm strength may matter, could you explain a better scenario of where it would matter more?

I'm failing to see how a complex algorithm holds up better than a weaker OR self-made closed source one, since I'm assuming that an attacker will attempt to use brute force. Since I'm assuming they would attempt brute force then I'm also assuming they have no control over how random their guesses are, (possibly)rendering algorithm strength to be useless -- i.e. since both strings are jumbled up and look random, they both appear complex.

First and foremost rolling your own crypto is almost always a bad idea see Why shouldn't we roll our own?.

Now that that requirement is out of the way lets take a look at your question. In this case you have to ask what are you protecting against. The AES encryption (assuming that it is implemented correctly and there are no side channels) will protect your data from long term high resource attacks and from simple attacks like shoulder surfing. It should not matter if it is an attack of opportunity or a targeted attack, your data is safe.

All your home grown encryption can be counted on is a form of obfuscation. Tools like frequency analysis are very powerful. Looking like both strings are messed up is not enough. Shifting all letters in the answer makes it look all messed up. However this is trivial to break. It is normally not hard to find patterns that allow for complete decryption with only a small sample. All you can count on is resistance to shoulder surfing and unskilled attacks.

It also sounds like you have implemented both the AES and your algorithm yourself. This will likely open you up to increased risk of side channel attacks (timing, shadow copies ect.).

If you want an easy method for encryption you can use a project like KeePass or 7zip to store your data (with encryption). This way you have the benefit of a time tested and possibly open source project with strong crypto. Not to say that those attributes offer complete protection, just take a look at OpenSSL.

In the end you have to evaluate your threats and ask if you are will to settle for obfuscation or if you need full protection.


Is the Common Name mandatory for digital certificates? I'm working on a project, where we use the Common Name as a certificate's basic identifier. However, importing certificates without the Common Name fails.

What's the default way to use digital certificates? Which identifier should we choose to be able to import them?

As far as X.509 is concerned, the Common Name is not mandatory. However, a number of systems will use the CN for display purposes, e.g. most "certificate manager" GUI in Windows. Therefore, it is recommended, if only for ease of sysadmin tasks, to include reasonably precise CN in certificates.

If you want to, from an application, pinpoint a specific certificate, then the good identifier to use is the "thumbprint", which really is a hash of the certificate. As long as the hash function is collision-resistant (Microsoft uses SHA-1, which is still quite robust in that respect), no two distinct certificates will exhibit the same thumbprint.

The "standard X.509" method of referencing a specific certificate is to use the pair issuerDN + serial number. Only the combination of both values is (supposedly) unique; serial numbers alone don't cut it. Mind that I am talking about the issuer's name, not the subject's; and this is the whole DN, not just the CN part of it. Moreover, it is allowed for a certificate to have an empty issuerDN provided it also contains an Issuer Alt Name extension with the complete DN. This means that properly using the issuer+serial pair can be somewhat complex. The thumbprint is easier.


SSO level of trust external identity providers I'm wondering how much I should trust our clients and their SSO implementations. We have an identity provider set up for @our-domain.com and most users of that domain have a lot of rights in our software and can access private data of our clients. We have multiple clients and we use home realm discovery by domain to redirect users to the identity provider of our client. After the users have signed in we validate the domain against a list of allowed domains for that identity provider.

We have a new client (ClientX) which also has users using a @gmail.com account and they should be redirected to their identity provider to login. Of course we don't want every gmail user to be authenticated using ClientX's identity provider so we'll me making a page https://login.our-domain.com/ClientX for that client to be automatically redirected to their identity provider. But we are unsure how many domains they can have, should we just blindly trust everything their identity provider says? When we trust all domains that also means someone could pretend to be someone else. For example the identity provider can pretend to be @our-domain.com. It is a well respected client but I think we are to blame if their security fails.

Rights are given a head of time to known users. So unknown users don't have any rights but the security risk lies in ClientX saying that a user is another known user in our system. Also, rights are based on e-mail address so that we cannot uniquely identity a user with a specific identity provider.

Couple of options we thought of:

Have a fixed list of users ClientX can authenticate.
Have a fixed list of domains ClientX can authenticate.
Change our rights system to use an identifier instead of e-mail address so that we can identity a person with an identity provider.
Just trust the client and their security system.
Other suggestions?

So I'm looking for advice on this. Seems a common enough question but I could not find anything on this. How much do you trust other identity providers? Any advice is very appreciated!

Never use the IdP-provided identifier alone; use it together with the IdP's own name. (For example, in SAML2 each IdP has its own entity ID, and I believe it's common practice to combine it with the username somehow.) So you would recognize these as two distinct users:

ClientX,user@example.com
ClientY,user@example.com

It doesn't matter much what type of identifier you use exactly (email or username or SID or GUID) – as long as it's just a text string that's 100% IdP-provided, it won't be enough.


Generate cryptographically strong pseudorandom numbers in Javascript? Is there any good way to generate cryptographically strong pseudorandom (or true random) numbers in Javascript?

The crucial requirement: if a.com's Javascript generates some random numbers, no one else should be able to predict those random numbers.  For instance, Javascript on evil.com should not be able to predict the random numbers that a.com got.

Summary of what I know about this subject.  Here's what I've been able to find, in my own research:

All browsers provide Math.random() as a library call to generate pseudorandom numbers.  Unfortunately, it does not provide crypto-quality random numbers and fails the requirement above.  On the browsers I've seen, Math.random() uses a non-cryptographic PRNG, and its internal state is shared across multiple sites.  Therefore, evil.com can call Math.random() a bunch of times, recover the internal state of the PRNG, and then infer what random numbers a.com got when it called Math.random().  Also, it uses a non-cryptographic-quality PRNG, so if a.com generates a random key and a random IV using Math.random() and then publishes the IV, it might be possible to infer the PRNG's internal state (from the IV) and then recover the key.  So, Math.random() is right out.
I found a research paper that looks at doing cryptography in Javascript.  Their code, the Stanford Javascript Crypto Library, is publicly available.  It does include a crypto-strength pseudorandom number.

However, it appears to have a hefty limitation: if I'm reading the paper correctly, it takes 10-40 seconds of user interaction with your site before the pseudorandom number gets adequately seeded.  Moreover, each site has to start over from scratch: if a.com includes the SJCL library, then it looks like a.com's script has to wait for the user to interact with the a.com site for 10-40 seconds (typically) before a.com can generate crypto-quality random numbers.  This is a pretty significant limitation.

Here's their paper:

Emily Stark, Michael Hamburg, Dan Boneh.  Fast symmetric cryptography
in Javascript.  ACSAC 2009.

The classic essay, Javascript Cryptography Considered Harmful, mentions the lack of any good way to get crypto-strength random numbers in Javascript as a major barrier to doing secure cryptography in Javascript.  The essay considers several obvious approaches and explains why they are flawed.

The bottom line is that I don't know of any reasonable solution; the options I found all seem pretty problematic.  However, it has been several years since those papers and essays were written, and I know that web technology can change rapidly.  Does anyone know of any good solution to this problem?

There is an experimental API for this: window.crypto.getRandomValues.

It's supported in

Chrome 11.0
Firefox 21
Internet Explore 11.0
Chrome with Opera skin 15.0

Opera 12 does not support this API, but its Math.Random is secure.

  Opera has not yet implemented window.crypto.getRandomValues(). However,
  our Math.Random() is using a cryptographically secure random generator.
  If used carefully (noting that it only returns 53 bits of entropy for
  each call) it is possible to use it to implement a javascript version of
  window.crypto.getRandomValues(). Just make sure to only do this in
  Opera, along with some good comments in the code.

http://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0063.html


How Secure is a Fingerprint Sensor Versus a Standard Password? According to Apple, Touch ID the probability of a fingerprint matching is 1:50000 while the probability of guessing a four digit passcode is 1:10000. Statistically speaking, this would make Touch ID five times more secure. But the answer isn't that simple. Reconstructing a fingerprint is far easier than reconstructing a passcode. Although a fingerprint is unique, you are basically walking around with the security key on you at all times. I see have a fingerprint is like have the four digits of a passcode, just not in the right order (is this the right thinking though?).

Regardless, I'm not interested in a passcode. I'm interested in a password. Software applications allows you to login to social media, online transactions, and even bank accounts. Is a 1:50000 ratio really that secure when being compared to a password, especially when looking at such sensation data? I am more interested in after the attacker has the password or fingerprint, not so much brute forcing methods. With a strong password it seems as though the odds are much greater. Although a fingerprint is unique per person, a password is unique per situation. If I have your fingerprint I have your email, you social media accounts, and your bank information. Where as a password I may only have your Facebook.

Is fingerprint scanning being rapidly growing solely on convenience or is it more secure for the typical user? Advertisement claims is more convenient and more secure. However, is this normally the case?

The fingerprint does act as the sole means of authentication for accessing the device, but not for accessing secured services or sites. It therefore does not serve the same role as a password.

Typically the fingerprint authentication is used as a second factor of authentication, the first factor being physical possession of the device on which the fingerprint sensor is hosted.  And there may be other factors too, such as the traditional password.

For example, if you have an online banking app, you will usually have to enter your user name and password first, then tell the app that you wish to turn on Touch ID.  Later, when you wish to use the app, the device will authenticate the fingerprint, then retrieve the password from password storage and submit that to the server proper, which authenticates the password.  If you don't have the device, the fingerprint is useless.  And if the device doesn't have the password, the device is useless too.

Bottom line: You can't just use the fingerprint by itself.  And no, it's not a secure as the password, unless the password is very very short.


How do security experts benefit from reverse-engineering? How can reverse engineering (RE) help a security expert?
I've participated in CTF challenges and I have seen RE as an important part of CTFs. Can anyone explain or show me a real scenario that shows how RE or cracking can help hackers break security?

What do you do in most reverse engineering challenges in CTF's

(if you're not just pulling out passwords with strings)

You analyze the logic of the program in it's normal behavior.
Analyze which computations are done on our input
Find out where 'bad boy' and 'good boy' are located
Find a way to make our input lead to our 'good boy'

What do you do when looking for security bugs?

(in a fuzzing approach)

You analyze the logic of the program in it's normal behavior
Analyze which computations are done on our input
You analyze the logic of the program when given unexpected input
Analyze the behavior and see if we can exploit the new behavior

This is just one example

Actually, just reversing the program to see which function calls it makes can be enough to find a security bug, if you see a call to the unsafe strcpy for example, you know it's worth having a look at from a security perspective.

On top of that, reversing is done to understand program logic, if you want to break a program's logic and take advantage of that ( or protect the program ), you have to know exactly how it works.

Edit after your comment:
As for how a hacker can actually use this to breach a security system;
The strcpy example above implies a buffer overflow is present, this is basically the Hello World of exploit writing.

If you want an advanced guide on what that is and how it works, you could read these articles on the corelan blog which describe how buffer overflows work and how they can be exploited.

While reading those, you'll realize an exploit writer's language is really the same as a reverse engineer's language. Which is why it is helpful to train your RE skills to become a better Exploit writer.

Malware analysis

I almost dared to leave this answer here without noting Malware Analysis.
Malware writers are becoming quite spectacular when it comes to hiding malicious activities from AV.

It's very important for AV Vendors to have people who can reverse engineer the extreme puzzles they sometimes set up in order to protect machines worldwide from sophisticated malware attacks.


OWASP Top 10? How about OWASP Top 1000? Many people are aware of the "OWASP Top 10". I'm wondering if OWASP (or any similar authority) has gone above and beyond just the top 10 most commons attacks and made a larger list (e.g. the "OWASP Top 1,000", etc.).

I'm fleshing out the requirements for my first big web app and I want to make sure I'm as prepared as I possible can be. I'd like to know where I can go to find a larger (but still manageable, not like 10s of thousands!) list of vulnerabilities I need to defend my network and applications against.

If no such "master list" exists, how would IT Sec recommend I research and secure my web app (besides hiring one of you as a consultant!)? Any "must-read" books/articles/blogs? Thanks in advance!

There is not a top 1000, because that wouldn't actually be relevant to most people. The OWASP top 10 are chosen because they are applicable across the vast majority of web applications, and are likely to be exploited if you do not secure them.

Beyond that, if you are starting from a position of already having applications and infrastructure:

Understand your assets - have a list of all your applications, platforms and versions

This can be very challenging in a large organisation, but without it, how will you know what you are vulnerable to?

Cross reference this list with the CVE database to understand the types and number of vulnerabilities which apply to your assets

The CVE database goes to the level of specific versions of applications and platforms so you can get a very tailored view of vulnerabilities you should be aware of. It also provides a rating (from 1 to 10) and a description of how the vulenrability can be exploited (eg local, remote etc)

Identify your threat actors

This could be environmental activists, terrorists, competitors, foreign governments, bored students, organised crime gangs etc.

Assess impact and likelihood based on the previous steps and prioritise remediation

You can never protect against all possible attacks, so this step is essential to help you decide where your limited budget and time will have the best return. If you can't articulate the value of a remediation project to the board you may find it difficult to get buy-in and budget.

Implement remediation activities
Rinse and Repeat - security never ends

A better position is to build a security governance framework which helps define and assure security in the development lifecycle, so this will help you build an architecture and testing plan to help reduce the likelihood of vulnerabilities getting into code in the first place - but this is a much longer discussion, and probably will see you utilising consultants :-)

tl;dr - OWASP Top 10 will give you the best initial view on what you need to do to protect yourself. After that check the CVE database for specific vulnerabilities for your code. Improving your procedures/framework/SDLC will protect you best in the long run. Proactive, rather than reactive.


Protecting Password in Code I am writing a program in Processing (which is basically java), that (amongst other things) downloads files from a FTP Server. To connect to the Server the program needs the correct FTP-password, which is currently saved as plain text in a String in the source code. The program should be given out to other people later, so I'm guessing this is not a very safe way to store the password.
What would be a good way to protect the password?

I think your effort is broken by design. You want to install a program at someone's machine that connects to an FTP server via password, but you don't want the user to know the password. No matter what you do to protect it, the user can easily intercept the network traffic comming from the program. For example, the user could set up a proxy and just dumping everything that runs through it - the password will be somewhere in this dump. Encrypting the password at the user's side and decrypting it at the server will just delay the problem - the user will just send the encrypted password.

I would rather set up an extra FTP account with an extra directory just for this user. There he cannot hurt anything, because anything he sees is generated by his own actions.

edit It's true that with FTPS the user wouldn't be able to extract the password. But who is setting up the encrypted connection in the first place? The user's machine. So the certificate is sent to the FTP server before the encryption is done, which can be intercepted again and used to decrypt the whole communication.


OTP on the same device being used to login I've seen mobile apps use two-factor authentication by sending an SMS to the mobile phone. However, if I've stolen someone's phone, where is the security advantage? I can understand it if it's used in conjunction with another medium (e.g. a website on a desktop) but if the phone itself is sent an OTP of sorts, what's the security advantage being offered?
In particular, I'm looking at Authy and wondering value it brings to a mobile app?

You are correct, this is not effective in the case of the device being stolen - you need good local authentication for that such as a long pin, password, passphrase, and potentially biometrics.

However these OTP solutions are not trying to address that threat. They are intended to prevent someone from attempting to access a service by guessing usernames and passwords, or using usernames and passwords stolen from elsewhere (e.g. through keyloggers, database dumps etc).

For example:

XYZ website is hacked and the usernames and passwords cracked and published online
I get the list and try each of the credentials against the ABC website
Often users will have used the same usernames and passwords and I will gain access to some accounts
However if my account on ABC website is linked to a mobile number and uses an SMS to authenticate then knowing my username and password doesn't allow you to compromise my ABC account unless you can also intercept the SMS


Testing security tools for non-standard protocols Many security solutions like firewalls, IPSs and Proxies are fully prepared for TCP and sometimes UDP, but what about non-standard protocol types like IGMP, CAOS, VISA and others. The whole https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers is a potential vector.

What is the best way to test those solutions for protection of evasion  over those non-standard protocols? I would take any response with a commercial product but specially any tools that I can build my own.

Sounds like a job for nmap (IP Protocol scan) or scapy. Older tools such as isic or ip6sic are in the same class, as are point-commercial solutions such as Codenomicon or Beyond Security and big players like Spirent and Ixia.

Probably my favorite tool for working with non-HTTP/TLS traffic (for those protocols, I'd use Burp Suite Professional) is Canape. Canape is a pluggable proxy, so I can record packets and frames in order to play with them. If I really wanted to hire a firm to help with testing security appliances, I'd look at Deja vu Security for their Peach Fuzzing Framework intellectual property, instructional capital, and thought leadership.


Identifying device based on the MAC address Suppose we know that MAC address A belongs to a certain device (say an iPhone 5), and MAC address B also belongs to an iPhone 5. If we have a MAC address C which is in between A and B, does this guarantee that C is an iPhone 5 or could it be any Apple product?

EDIT: Suppose they all have the same 3 byte prefix, e.g.:

A=44:2A:60:01:01:01
B=44:2A:60:21:AA:F4
C=44:2A:60:01:02:03

It could be any product, not just any Apple product.

The first 3 bytes (24 bits) of the MAC address identify the vendor of the NIC (Network Interface Card). If Apple owns the blocks 00:00:01 and 00:00:03, then MAC-address 00:00:02:00:00:01 could belong to Cisco as well as any other vendor.

And besides, almost every NIC allows changing (spoofing) the MAC-address. They are not really that reliable, especially when people know you are trying to identify devices based on their MAC-address.

Edit: In reply to your edit, yes those would all be from the same NIC vendor, given that the user has not changed his MAC-address manually.


metasploit: how to use linux/http/webmin_backdoor I am trying to gain access to a server using CVE-2019-15107 with help of metasploit. I tried to find examples of its usage, but I found none.
My machines ip is 192.168.109.133. I am connected to a vpn where I have access to the target at 192.168.208.32. At port 10000 Webmin is running with version 1.890, which is susceptible to this exploit.
I have set every required option, but it won't work, and I have no idea why.

This is the output after I exploit.

I have basically no idea what SRVHOST and SRVPORT is for. I don't know what TARGETURI is either. So if someone could explain that in more detail for me I would appreciate it.

TARGETURI is explained in the description for that option; it is the URI path to the application. If you open a web browser to the application and the base of the path is e.g. /webmin, that's what you'd use here. Or, maybe there is no prefix and you can just leave it blank.
The presence of SRVHOST and SRVPORT indicates that the target will need to reach out to a server running on your end as part of the exploit. These just set where that listener will bind, so it can probably be left as default as well. If I remember correctly, Metasploit will use the LHOST value to populate the actual address when the target connects back to this server.


How can I recover from a hacked WordPress site and prevent future attacks? I have a dedicated server running WordPress and have recently noticed that its been hacked and PHPShell a remote web server controller has been uploaded. This has let the hacker view and edit files including my database!

I have since deleted the PHPShell folder. Changed all possible passwords (database, user accounts, FTP, turn off SSH etc) and he's recently gained access again!

However I think he was originally able to upload this through Akismet plugin after checking my logs:

  xx.xxx.208.130 - - [05/Feb/2014:02:18:29 -0600] "GET /phpshell-2.4/
  HTTP/1.0" 403 1431 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64)
  AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107
  Safari/537.36"

  xx.xxx.208.130 - - [05/Feb/2014:02:17:47 -0600] "POST
  /wp/wp-content/plugins/akismet/.!31.php HTTP/1.0" 200 17503
  "https://example.com/wp/wp-content/plugins/akismet/.!31.php"
  "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
  Gecko) Chrome/32.0.1700.107 Safari/537.36" .!31.php

Going off the details above it seems he was able to upload this PHPShell through Akismet plugin. I contacted their devs and I was informed /akismet/.!31.php was not part of their original package and that the hacker could have created this as a decoy. Before I deleted the Akismet plugin and went to https://example.com/wp/wp-content/plugins/akismet/.!31.php you were able to upload and execute files to the server, through my firewall!

I HAVE to get this hacker off my server. I have run timthumb scanners and it found nothing. Where else do I start?

When compromised, the best bet is to nuke it from orbit.  Remove all files from your site, reload from a known clean image.  If you don't have a known clean image, re-install fresh and migrate over the DB records after verifying that they are valid.  Move image assets and any custom assets after careful review that they have not been compromised.

Make sure to keep your server patched and only use reputable plugins.  Make sure that your folder permissions are set correctly so that the public can not write to your wp-content folder.

It is also probably worth using the WordFence addon as an added security mechanism. While it won't catch everything, it will scan popular plugins to make sure they have not been altered.  This would likely have detected your second compromise, but it is not as sure as nuking from orbit or manual code review.  It will also help provide notification when WordPress or an Addon is out of date.


I'm a White Hat and I develop my own viruses. Should I report it when almost all scanners say the executable is safe? I develop my own viruses for 'scientific' purposes, namely to see if they pass the test of Virustotal.com. They all do, except for one or two scanners. Is this considered something you should report to Microsoft/McAfee/etc? If yes, how?

That's a pointless exercise.

Most malware scanners match on fragments of binary code (aka virus signatures), and they check MD5 hashes of known infected code against their blacklists.  Unless the virus you wrote has been deployed into the wild and is already on their blacklist, there isn't a chance they'll have your code's exact signatures on file.

The scanners that do trigger a match are most likely those using heuristics, which scan for "suspicious" behavior.  For example, very few programs legitimately need to request the OS grant them the privilege to "Act as a debugger", yet that's fairly common behavior in malware, so if they find it they'll flag it.

Reporting your custom viruses to McAfee won't help anyone - not McAfee, not the public.  If they don't identify your code as a virus, it's because their scanners don't have very effective heuristics (which they already know, and won't learn from your code among the hundreds of viruses they analyze per day.) And developing a match takes a researcher time and effort, which costs McAfee money.  There is no value to McAfee to waste money on researching a virus that nobody can get, and adding it to their blacklists, because as a white hat you won't allow it to be released.


cd-rom distro --- plus additional validation dear security experts:  we would like to create a very safe webserver.  we are in awe at the sophistication and complexity of many solutions, but they don't apply to us.  we are a small shop.

by safe, we mean a php or perl based internet-open website that limits the intrusion vulnerability with respect to remote sophisticated hacker in another country.  it does not mean protection against people stealing the computer physically.  it does not mean keeping my clients safe.

like many small shops, we don't have the manpower and attention to constantly monitor everything.  we need to do assume our server employees make mistakes all the time.  we also need to assume that we will miss security fixes, or even that we wrote sloppy code ourselves.  we need this to be simple and foolproof.  and fools we got.  well, call them unsophisticated and naive.

first, we want the internet server to boot a distro from a read-only device.  the cheapest way to do this is via CD.  the hard disk will probably be removed.  I have yet to find a modern SSD that has a true read-only switch.  (some USB flash drives have it.)  this means that there will be no root-kit installation on the root device.  when I reboot, all temporary storage will be wiped out.  I will be pristinely clean.

second, we wonder whether we can or should add more security.  on rare occasion, we need to log into the computer that is running the webserver via ssh, bash, or execute something sudo---but this is rare.  I want to install a hardware button on the computer that allows or disallows this.  I can write a linkable function or shell script that returns 0 if the button is disengaged or 1 if it is engaged.  so, I think I need to modify the code that executes ssh, bash, sudo, etc.  they just need to be wrapped to check for 0 or 1 on the button first.  or, I could modify the ext4 file system driver to let only certain programs through if the button is pressed, but this seems overkill.

I would think that if one of our fools gave a remote hacker the root account and password, but the button is off and the drive is read-only, there is even less harm that they could do.

I don't see an easy way to prevent a hacker from locating something into RAM, at least until the next reboot.

my key question now is: is there a common way to wrap a list of shell and other remote access programs to work only when my button is pressed?

advice appreciated.

regards,

/iaw

PS: and if anyone knows of an SSD with read-only switch, please let me know.

The first truth of Information Security is that there are some people you have to trust. Without that truth the whole discipline of Information Security turns into paranoid free-fall. May I suggest trusting your colleagues?

In lieu of that, the best way to protect your "attack surfaces" is to

Backup to multiple sources; some of which are write-once audit servers.
Lockdown employee access with two-factor authentication
Turn the web server into a virtual instance booted from a recoverable ghost image. Our peers at Server Fault can explain how.
Full disk encryption if you want the data unavailable if someone physically steals your server.
Install Panopticon-style video camera surveillance.


What OS's will "brick" a stolen phone; preventing their use or resale by a potential thief? You can look at this question in two ways: Prior to purchasing a used phone, I want to ensure that the IMEI is not locked and I'm able to use it fully.

Or you can be a purchaser who wants to devalue their mobile phone from theft because they are useless when transferred to another party without the original owners consent.

Example

Windows Mobile phones have a feature called "reset protection" that essentially makes stolen phones worthless as far as I can tell.

iPhones have something similar while I was testing iOS 9's "lock phone feature" that requires the original owner to type in their iCloud password in the event a phone is remotely locked, or even remotely wiped.

Is there a summary of the depth, scope, and strength of these features by OS, and hopefully a website that allows consumers to validate a phone isn't in a locked-stolen state?

I'm interested in:

iOS
Android
Windows Mobile (or whatever it's called these days)

Besides bricking, you could at least prevent further use of mobile networks by blacklisting the phone (via the IMEI) with your carrier. Your carrier can then further blacklist your phone by instructing the GSM Alliance, via their IMEI Database, to do so, so that the mobile can't connect to any networks.

This, however, as sebastian nielsen already said, does not prevent the use of the phone as a "WiFi-only" device.


"You have new mail" message I received a message from Google saying someone entered my email account.

I confirmed that there were an access from an IP in another country.

I have noticed "You have new mail" message when I open a new tab in my Terminal in OS X, I can make this message disappear if I delete /var/mail/my_user, but this morning it appeared again. I don't know if this is related with the email attack.

How can I track down this vulnerability?

"You have new mail" in a terminal is a very old Unix behaviour: the shell (the software which interprets the commands you type in the terminal) regularly checks whether the file /var/mail/username (where username is, you guess it, the name of the current user) has been modified (precisely, whether its last modification time is ulterior to its last reading time, the mark of a new but as yet unread data).

On a machine which is not an email server, reception of emails that way usually means that the email was generated locally. This is typical of cron jobs: you register some commands for regular execution, and when they get executed, their output is sent to you by email (that's purely local, the data never exited your machine).

See the contents of the file with: more /var/mail/my_user (in a Terminal window). This will give you some information as to the provenance of such emails. My guess is that they are totally unrelated with your Google story. Note also that I regularly receive (meaning several times per day) a lot of fake emails which purport an alleged security breach, and try to entice me into entering my login and password on some site which may or may not "look like" the genuine site for Google or a bank or whatever. This is common practice among attackers. Your emails might be of the same persuasion: fake emails which do not come at all from Google. Detailed inspection of the header and contents of such an email may reveal the foul play.

If unsure, reset your Gmail password (with a new, strong password); this won't make any harm.


Authorisation Request & Authorisation Grant In OAuth 2.0 I do not grasp the concept of the first steps in the OAuth process: Authorisation Request and Authorisation Grant. As far as I know:

User wants to access client by authorizing Service API
User clicks e.g "Log in with Github" and gets redirected to Service API's website
User authorizes client by clicking e.g "Authorize Client"
Service API sends client an approval of authorisation grant
Client uses authorisation grant to request token
Service API returns access token
Client uses access token to request protected resources
Service API sends back resources
Client displays resources to user

Is this process flow correct? I am particularly confused about the role of the user in requesting/granting authorisation.

The OAuth2 RFC is extensive and covers numerous use cases. Since your question is pointed towards the most common use case, that is the 'Sign in with' button, we will just talk about that.

Let's get the roles right first:

User: The owner of the resource. For instance, user owns an email amey@example.com.

Client: The application requesting information owned by the user. This is the application hosting the button 'Sign with XYZ'

Resource: The information that is being requested by the client. The client may want access to your email, your date of birth and your profile picture.

Authorization Server: The server responsible for authorizing client's request to access a user's resource.

Resource Server: The server which holds the user's resource and will transmit it to the user when presented with a valid credential.

The OAuth2 setup:
An application that wishes to access user information or resources hosted on a resource server should first register with the authorization service of the resource. The pieces of information that are necessary for this step are:

Client FQDN
Client's callback or Redirect URL

On successfully registering with the authorization service, the client receives a clientId which it will to send to the authorization server during the authentication process.

The Authentication Process:

Let's say user wants to prove to a client (say, client.com), that they are the rightful owner of the email amey@example.com.

Step 1: User clicks on "Login with example.com" on the client website. Let's call it client.com.

Step 2: This spawns the OAuth2 authentication flow. The resource server's OAuth2 URL will be called with the following paramters:

clientID
Redirect URL
state (randomly generated nonce, not mandatory as per OAuth2 but commonly used)
type (code is most commonly used, and that is the least you need to know to get started. More on this below.)
scope

The URL will look something like this:
https://example.com/oauth2?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&redirectURL=https://client.com/oauth2/callback&scope=email+profile.info&type=code

Step 3: The authorization server performs the following checks on the request before presenting an authentication dialog to the user:

The referrer header in the request correctly corresponds to the clientID as registered by the client during setup.
The redirect URL correctly corresponds to the clientID as registered.
The scope of information requested is acceptable to the authorization server. This may be based on information provided during registration or some other factors.

Step 4: The authorization server presents the user with an authentication dialog. On successful authentication, the authorization server generates a random code. Remeber, the type paramter in step 2 above? The type=code parameter tells the authorization server that the client expects a one-time authorization code for the current OAuth2 authentication request. This is not the final authorization token. Authorization codes are short lived and they provide a layer of additional security to protect the authorization token that will honored by the resource server. The code by itself will not be of any use to the an adversary.

Step 5: The Authorization Server redirects users browser to the redirect URL of client.com that was included in the first OAuth2 call in Step 2 above and attaches the code parameter along with the state parameter with the request (typically in the URL query)

The redirect URL will look something like this:
https://client.com/oauth2/callback?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&code=3b9d8826-55b5-4e0a-b441-3137c2e9f864

Step 6: When the client.com server receives this request, it makes a call to the Authorization Server and sends the authorization code received from the user's browser. The Authorization Server responds to this request with an Authorization Token which can be used to request information for a user as per the agreed scope.

Step 7: client.com's server makes a call attaching the Authorization Token to the Resource Server for fetching the user's email address. The Resource Server in turn sends a request to the Authorization Server again to verify whether the token is correct and the requested resource is within the scope of the authorization. Once authorized by the authorization server, the resource server sends the requested resource, in our case, the user's email address (amey@example.com) to client.com's server. Once, the client.com server receives this information from the resource server, it can happily conclude that the user is the rightful owner of the said email address. The server sends a cookie or any other token it uses for maintaining the client session and allows the user to use client.com's application.

Steps 6 & 7 are hidden from the user. The communication takes place directly between the client's server and the resource server. So, it can be confusing at first to imagine what is happening on the backend while you are waiting for a response from the client.

You can take a look at the below image, to get a descriptive flow of the process:

Image Attribution: https://medium.com/@darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85

Would also help to read this blog post for even better clarity.


Is there any risk in adding exceptions in the antivirus software for paths that are only writable by Administrator? Sometimes antivirus administrators don't want to add any exceptions for the antivirus software. My question is what is the risk of adding paths that whose permissions are correctly configured to allow only read/write by administrators.

In that case I think that if you already find a malware executable or file in that path you are already owned.

The risk is only one where malware is installed to said paths. This may be possible if you are using an installer which itself is benign and which asks for administrative privileges, but which installs malicious executables or libraries (for example installers that are bundled with adware). If you trust anyone who enters the administrator password to not install anything malicious, by accident or otherwise, then there should be no downside to whitelisting paths that only the admin can write to.