How can I secure encryption keys in the code? I have files on the server that is encrypted with AES. I am developing iOS and Android apps to decrypt and process those files in the phone or tablet. To decrypt files on the client apps, I have to use/store the same AES keys in the app. That means I have to put my AES keys in the code so I can directly use from source or ship to client device so I can store there. Keeping/Shipping Encryption keys in the code is bad idea but I need those keys to process files.

How can I securely keep keys in my code? Or is there any other way to obtain my AES keys in the client so I can decrypt files?

You are right to be suspicious of this process. Android apps are super easy to decompile, so you should assume that any keys that are embedded in the app might as well be posted in a public blog.

Without more information on why you need to encrypt the data files it's hard to give detailed advice. A usual way to solve similar problems is to use public-key encryption. Each client app generates its own public key, and when it requests the data from the server, the server encrypts it specifically for that client, using their public key.

Unless there's details that make your problem more complex, you could probably accomplish this by using standard PGP libraries to generate client keys, and to encrypt / decrypt the files.


How does XSRF-token per request work? (Angular solution) I want to protect my application against XSRF. Although I couldn't really understand what the problem is and how my solution works, after some research I came up with a solution, which Angular uses. As far as I got, my solution requires the following steps:

Client sends a request for my SPA.
I send XSRF-token (not HTTP-only so that JS will be able to read it). I also save this XSRF-token to the users session on the server.
For every POST request I want my client to read the XSRF-token and set a X-XSRF-TOKEN header to this token.
I'll check every request by checking if the request header and the user session XSRF-token match. If they do, I'll also check JWT for authentication if I need.
After validating the XSRF-token, I'll make changes to the database. Also I'll change XSRF-token again, and send the new token to the user, and change token for the session.

But I am not sure how this helps, if I have a XSS vulnerability, since any injected JavaScript code could also do the same. I want to understand the problem and how such a solution helps.

FYI, I am also implementing JWT based authentication, using Redis for session management, on an Express server.

Is the plan good?
Your plan looks good to me. Using a CSRF-token is the standard solution to this kind of problem. But you should not feel safe just because some stranger on the internet tells you it looks good - make sure you understand what you are doing and why, otherwise your are bound to make mistakes.
(A minor point: I am not sure you need to change the token at every request.)
So why does it work?
From this old answer of mine:

The attacker fools the victim to visit http://evil.com that contains a form that automatically does a POST to http://bank.com/transfer?to=evilHacker&amount=1000000. If the victim is already logged in to her bank, the cookie with the session ID will be sent like usual by the browser and there is no way for the bank server to know that the victim did not actually intend to transfer the money. Note that this relies on the browser sending the cookie with the session ID to bank.com.
So how can a CSRF-token help? If the bank.com always checks that a random token unique to that session is present in the request, evil.com can not forge the request since the evil hacker running that site does not know what the token is.

But what about XSS?
As you say in your question, this will not help if there is an XSS vulnerability. In fact, there is no CSRF protection that will help in that case, but if you are vulnerable to XSS you have bigger problems than stolen CSRF-tokens to worry about anyway.
So the only thing to do here is to work on your XSS protection.


Is it safe to check if device is subject to Stagefright bug? Is it safe to check if device is subject to Stagefright bug, for example with:
Stagefright Detector App forAndroid by Zimperium ?
Is such (or similar test) sufficient?

Is there available any 3rd party external manual (e.g. in for of report with traces etc) or automated analysis of vulnerabilities (like Stagefright) detector software  ? If no, what could speak for or again credibility of authors of such software, to use at leat that subjective measure of trust for judgement if no analysis available?
(Please read comments below for clarificqtion)

Yes, Zimprerium was the group that discovered and reported the StageFright vulnerability (here's the original blog post).

Zimperium's Sr. Director of Platform Research and Exploitation, Joshua J. Drake (the discoverer and presenter of StageFright) is a famous Android security researcher, and a former researcher for metasploit.

While I applaud being cautious, if you can't trust their test tool then I'm not sure what you can trust.


Convenient Write Once Media to attach to a computer: A USB stick or device? What is a convenient write once media to use with a Computer, preferably via the USB interface.

I often see this use-case in several ways:

I have a server whose logs need to be on a medium that cannot later be erased or changed by an adversary to hide his tracks
There's photos or other media that need to be dumped for long term archival use without the risk of e.g. the recent "ransomware" trojans that encrypt data and then blackmail the user for money to give him the decryption key

Traditionally a CD / DVD would have catered to at least some of these use cases but now they are somewhat limiting in terms of size / usability etc.

I know SanDisk offers a MemoryVault Product with what they call their "preserve only" mode.

http://www.sandisk.com/memoryvault

But I'm not sure if this is a software protection or at the level of the hardware. What is even more confusing is that their Chronoprotect technology seems to actually allow a certain number of writes and then goes into a Read Only mode which seems weird.

Another option is this Magneto Optical Disk from HP:

http://www8.hp.com/us/en/products/storage-media/product-detail.html?oid=62378#!tab=specs

But that seems a little too specialized and possibly expensive. And I'm not sure how it is better than, say, a DVD.

The ideal combination seems a USB-stick / flash drive with write disabled internally at the controller level on the stick itself so that one doesn't have to depend on any host computer specifics to protect the data and yet the data itself is readable on any generic host / OS so long as standard USB access is allowed.

SD Cards often come with a write protect tab, but unfortunately that seems not mandatory and depends on the host controller obeying the "Read Only" suggestion. e.g. This StackExchange Question: Is the SD card write protection hard-wired or optional?

Also, a write protect tab seems iffy in some cases because it is still subject to a very likely human error. Otherwise I could use something like this USB stick: http://www.amazon.com/Kanguru-Solutions-Flash-Write-Protect-KF3WP-32G/dp/B008OGNMEI/ref=pd_sim_147_2?ie=UTF8&refRID=166NN5XXCH7FBCHNJTXW

PS. I'm assuming my adversaries are only software based. i.e. Let's ignore an adversary who might have physical access to the medium to insert into his dedicated hardware rig.

These WORM (write once read many) devices are by definition inconvenient and that's why there are very few of them and rather expensive. The expensive part is because it has to have hardware support.

You could try doing it on the same system with read-only rights for certain users and harden it with the immutable attribute. Even root cannot delete those files, but an attacker with full access can stop setting the immutable attribute for future files. But in the end, low level writes to the disk could change anything, so software can't be tamper proof.

Even forensics teams that deal with very sensitive electronic evidence use normal drives combined with other physical security measures like storing offsite and using fireproof safes. Keeping multiple copies of evidence and using hashes to prove they were not tampered with is another method they employ. This has the obvious downside that the data being protected is static.

Full disk encryption (FDE) serves the same purpose and that might give you some more flexibility. Although some FDE software offers read-only options on mounted volumes, in certain use cases the whole encrypted volume can be deleted.

My best advice is to send the data over a network to a different device.

If you care about logs, Synology offers syslog servers on their NAS devices.
Build your own NAS with FreeNAS that speaks syslog.
Get a cheap Raspberry PI and hook a hard-disk to it then sftp any files to it.
It can also be done more elegantly with network file systems.

To actually answer your USB requirement, I found a company that sells USB drives with WORM capabilities.


Can someone highlight the key difference between CRLF Injection, HTTP Response Splitting and HTTP Header Injection? I believe each one of these is closely interlinked, for instance, HTTP Response Splitting will occur in event of CRLF characters injection (%0d%0a) and this will also involve injection of HTTP headers which control the HTTP responses such as Set-Cookie & Location response headers.

CRLF Injection (CWE-93) is the general vulnerability that applies to multiples line-based protocols (HTTP, SMTP, Log file).

HTTP Response Splitting is the ability to start earlier the body section of the HTTP response. HTML injection will be possible.

HTTP Header Injection does not target the body but only the headers section of the response.


Email sent to people with my name in the from section, but not my email address I have had a couple emails sent to people who have sent me an email in the past (in my inbox, but who are not necessarily on my contact list).  They have my full name in the from section, and in the email body, but the email address they are sent from is not mine, nor do I recognize it.  The emails were not sent from my email account, but it is alarming that they are sent to emails obviously linked to my account.  And many are not related so I would not have sent an email to them all together in the past.  How could somebody have gotten these email addresses from my account?

The actual attack vector is hard to guess at because there are so many options, but some possibilities are:

A virus could have accessed your contact history or address book.
A packet sniffer watched other emails go by if they were sent over a non-secure connection.
Someone made some lucky guesses based on public information such as social media connections, work associations, common interests, etc.
Any of the above could have happened to the other email accounts which had sent/received messages to/from you.  If the association is found on either end, it would still work.

Now that it happened, you may also be wondering what to do about it.  Here is a good answer I found on just that question, but the news isn't great.


Bcrypt data type and length? I'm using the following library for hashing my password.

   string password = BCrypt.Net.BCrypt.HashPassword("stackoverflow");

The length is apparently 60 each time. My question is, I'm planning to store these passwords in my database, should I store them as char(60). If not, what's considered as a good practice?

The length of output of hashing algorithms are not depended on the input. Any input produces same length of output.

From a post in stackoverflow asked by z-boss, and answered by Bill Karwin;

  MD5 generates a 128-bit hash value. You can use CHAR(32) or BINARY(16)

  SHA-1 generates a 160-bit hash value. You can use CHAR(40) or
  BINARY(20)

  SHA-224 generates a 224-bit hash value. You can use CHAR(56) or
  BINARY(28)

  SHA-256 generates a 256-bit hash value. You can use CHAR(64) or
  BINARY(32)

  SHA-384 generates a 384-bit hash value. You can use CHAR(96) or
  BINARY(48)

  SHA-512 generates a 512-bit hash value. You can use CHAR(128) or
  BINARY(64)

  BCrypt generates an implementation-dependent 448-bit hash value. You
  might need CHAR(56), CHAR(60), CHAR(76), BINARY(56) or BINARY(60)

Full post is here: https://stackoverflow.com/questions/247304/what-data-type-to-use-for-hashed-password-field-and-what-length

In addition, do not forget to add salt to your passwords(BcryptNet handles salting automatically). Before doing your implementation , I recommend you to read the posts;

How to securely hash passwords?

https://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database


Android Application - Credentials in RAM I have been pen testing an android mobile application for security vulnerabilities.
As part of the test, I started Frida server on a mobile phone where the mobile application to be tested is installed, running, and after login (Already inserted credentials and logged in).
While being logged in the application, I dumped the application's memory using Frida (with strings), and was able to find my session token in clear-text JSON format.

I was wondering, is there any way to mitigate this vulnerability? Of course it makes sense that the session token is saved in memory, but is there a way to store it securely (E.g. not in clear text) and thus mitigate such a vulnerability?

I find this issue risky as if the mobile device is rooted, a malicious mobile application (running with sufficient permissions) can conduct the same attack locally on the mobile phone and thus extract the session token.

No, you cannot mitigate this vulnerability without a major change in hardware. If your adversary has the ability to dump memory from arbitrary processes, there is no way to store credentials confidentially. On Intel's x86 CPUs, a feature called SGX can be used to create a secure enclave that can hide data even from the kernel, but that is not a feature that you have access to on typical Android hardware.

There are only a few places where data can be stored by a process. Typically, the data can be stored in memory (e.g. on the stack or in the heap), or in process registers. A rooted device running a malicious process with sufficient permissions will be able to access all of those locations. There is no way you can hide a session token. The reason is simple: The data needs to be retrievable by your process. Any data that your process can access, a malicious process with sufficient permissions can also access.

The only solution is to not allow any malicious processes to have high privileges.


What are known domain hijacking methods? The definition of domain hijacking is: "to gain (temporarily) control a domain" which could be either through:

Stealing the legal and/or technical ownership of a domain (for example by transferring the domain to another registrar);
Gaining control of the registered name servers and pointing the domain to another endpoint;

What are known domain hijacking methods?

For example to claim an expired administrative email address and request a domain transfer at the domain registrar. Or, to use phishing techniques.

I suppose the Extensible Provisioning Protocol (EPP) is somehow related to protection against this?

Here are a few ways to hijack a domain.

Use DNS cache poisoning to redirect users to your server.
Register the domain the moment the registration gets expired (domain sniping).
You can of course just hack the server or the hosting provider if you find a vulnerability.

There are also indirect methods of hijacking a domain, such as:

Phishing with unicode characters that are similar to the original (scary stuff):

https://www.xudongz.com/blog/2017/idn-phishing/

Typesquatting: register a domain one typo away from the actual domain.
Bitsquatting, where you register a domain with 1 bit difference of the actual domain. When non-error-correcting RAM flips a bit, users might end up on your page.


TLS1.0 deprecation and PCI DSS requirements It won't be easy) As you know there are new PCI DSS requirements after 30 June which say we shouldn't use "SSL/early TLS".

But also there is the comments that merchants could save TLS 1.0 but with compensating controls:

  "For merchants using SSL/early TLS other than as allowed for POS POI terminal connections:

  1) If SSL/early TLS is being used as a security control for PCI DSS
  after the 30 June deadline, ensure compensating controls are
  implemented to mitigate the risk associated with its use and take the
  necessary steps to migrate to a secure alternative as soon as
  possible.
  2) If SSL/early TLS is present but not being used as a
  security control to meet a PCI DSS requirement, these protocols may
  remain in use. However, it is strongly recommended that they be
  migrated to a more modern encryption protocol as soon as possible."

My company has an ecommerce business and wants to save TLS 1.0 for some clients. The key question - what's the compensating controls for this case? I'm talking about usual web access from public Internet.

PS I just checked - even world ecommerce giants like Ebay and Amazon still support TLS1.0 for clients. Is it because of compensating controls?

I don't think there is fixed set of compensating controls you can use in all cases. The idea of a compensating control is that you reduce the risk somehow which you have increased by staying with TLS 1.0. I don't think it is meant to be something which magically makes TLS 1.0 safer again. Which kind of compensating controls are needed and are possible depend on your specific use case, i.e. how much the risk is increased from clients using TLS 1.0 and how you can reduce it again.

Compensating controls to reduce the risk might be for example to limit the amount of money which can be transferred by the less secure clients within a specific time or for a single API key, to add some insurance in case something goes wrong, to make the TLS 1.0 interface only accessible from a few selected IP addresses etc. Of course a compensating control could also be to add an additional encryption layer. Only, most clients which are unable to move to TLS 1.2 because they depend on some old software stack are probably not flexible enough to add some additional encryption as mitigation either.


Websocket Authentication at Opening Handshake Sufficient? Suppose TLS is used and a session ID was negotiated using standard HTTP mechanisms. With the websocket opening handshake, this session ID is also transferred in the HTTP header.

Suppose the websocket opening handshake is not performed if the session ID is not valid.

Is the security for all following websocket messages with that connection guaranteed even if no further authentication is performed for these messages?

Are there any attack scenarios here?

WebSockets work by first having an initial HTTP handshake and then establish a message-based communication. Everything is done within a single TCP connection and in case of wss:// within a single TLS connection. Authenticating this connection at the beginning (for example with sending the session cookie inside the initial HTTP handshake) is similar to only authenticating a SSH session at the beginning or only authenticating a normal HTTP/HTTPS request at the beginning and not authenticating every transmitted byte of the request again.

Of course, this single authentication at the beginning is only sufficient if the following data can not be manipulated somehow. In your example wss:// is used which uses TLS and this way protects the data against manipulation by an active man in the middle.

But if for example the attacker manages to compromise the endpoint of the connection (for example using XSS) he might be able to send his own messages over the already authenticated WebSocket. It is likely though that if an attacker can send messages within an established WebSocket he will also be able to establish new WebSockets. And if these are authenticated with a session cookie only the browser will automatically include the cookie when establishing the new WebSocket which means that it will be implicitly authenticated. So the mitigation against this would not be to authenticate every WebSocket message but instead to make sure that an attacker cannot compromise the client side of the web application using XSS or similar in the first place.


How do i validate that a PGP Public Key the user inputs is valid? we want to encrypt emails that we send to the user with his public key.
this works great, however the user can also type in a broken/invalid public key ("asdf123") and then the encryption won't work obviously.

how can i validate, that the user inputted a pgp public key with correct format?

You might want to try using pgpdump to test if the format of the public key that the user entered is valid.  See https://superuser.com/questions/696941/human-readable-dump-of-gpg-public-key for more information.


DNS in DMZ or not and mail server architecture I wonder what server I put in DMZ zone. I know the DMZ zone is for all servers or services who must be accessed from the internet, like Web Server, or mail server and sometimes DNS servers.

But I wonder two questions, for the mail server: the best secure practice is to have two servers, like front-end (webmail server who send a commands to back-end server) and back-end server who have all email in his disk?
Because, if I have just one mail server and it is in DMZ zones with a sensible data (mail, address book, user information) is not a good idea, is it?

And my second question, why must my DNS server be accessed from internet?
If I want to redirect a domain name to my server I buy a domain name from a hosting service and I redirect it on my router and in my router configuration I redirect the traffic to the server in my DMZ zone, in my ideas.

Bind has provisions for internal and external facing DNS. Just in case you want to have internal only domain names. In this way you can serve both facing queries. It also has settings that allow only trusted users from accessing it.


Can I ask GPG keyservers to name all keys signed by a particular key? Given the alleged possibility that an adversary might attempt to acquire my (OFFLINE) Secret Certification Key and Passphrase and sign other keys with it, including a key they made with my User-Identity metadata to pretend to be me:

Does GPG have a command that asks keyservers to search for and list every key signed by a particular key (fingerprint)?

E.g., Is it possible to double check that I recognize every key signed by my key, 0x1234567890123456?

Maybe this isn't possible because it would make social graphing too easy, but all help appreciated!

No, there is no such command. But you could easily fetch a dump of all keys known to the key servers and query it yourself someway. Or look at the PGP Web of Trust statistics which includes such a list and grep it. The underlying wot file could make things easier.


what is the difference between boot-sector virus and rootkits? I have read the definition for both and also read about a few examples for both the cases. I'm still not very sure what the difference is. Is the difference blurred or are there some specific characteristics that sets them apart from each other?

A rootkit works by changing the output of system actions. This could be by replacing standard commands such as ls with other tools. It can also be by modifying libraries or kernel code. Rootkits don't necessarily take advantage of an exploit, but rather the user. They may rely on another exploit to place them.

Boot sector viruses are a subset of rootkits, but the term is far older. It referred specifically to viruses that would alter to the boot sector of a hard drive to launch themselves on reboot. They have a connotation of harking from the era when MS DOS was still a substantial piece of the personal computing world. Being from simpler times, the viruses were often simpler and didn't always need booting to another OS instance to detect. Despite that, their launch early in the boot process could provide them with all the potential power that we associate with rootkits.

Even the technical difference between the terms is very muddled. It is possible that code could be considered just a rootkit, just a boot sector virus, or both. As far as colloquial speech goes, I think it is most common to refer to modern viruses that fit the definition of both as rootkits. I can't think of any notable contemporary malware that is considered to be merely a boot sector virus.


Potential FileVault problems in my setup After FBI vs. Apple, I have a few questions about the security of my data. Here's my setup:

AppleID is connected to local account
I don't remember exactly, but I think I have selected option "Allow user to reset the password using Apple ID."
FileVault Enabled(note: It was enabled half month after the first setup, where I enabled the option above)
"Wake for WiFi Access" is enabled
"Find my Mac" enabled

What could determined law enforcement do if they confiscate my MacBook:

while it is in sleep
locked, but user is logged in
powered off

What law enforcement can do, depends, yes, on the state of your computer, and on how many good computer scientists they know and how politely they ask for help.  Please keep in mind that encryption can be broken using brute-force methods, and there are some really powerful computers out there that can break weak encryption schemes.  Of course law enforcement getting access to those powerful computers and the computational expertise required to break the encryption is quite a feat of political savvy.  Such a method would probably involve computer science research, so I will answer the question with methods that already exist in the public domain (i.e., methods that are readily accessible to law enforcement).

While the laptop is in sleep

A determined person could try an exploit that attempts to use lan-scanning events to gain access to the OS.  Most of these successful exploits use the wireless card.  Some of these exploits yield significant access, and sometimes root access, depending on the operating system.  These exploits do work on Mac OS X.

Since you have the ability to reset your password using the AppleID, a politically savvy professional could convince Apple to give up your AppleID or enter it to gain access to the OS.

There are USB trojans that yield root access on Mac OS.  A determined professional could use one of these trojans to gain access to your data.

There may be iPhone/iTunes vulnerabilities which can be used to gain access.
While the laptop is locked, but the user logged in

Remember that they encryption key for the hard-drive is on your computer, somewhere that it can be access very early in the boot process.  This key should be accessible by rebooting the machine in a different OS that can read the boot portion of the hard disk.  It is possible that with some OS-specific expertise, the key can be located, and subjected to a brute-force password hack.  Such a effort would very likely be successful, and it would only require a small cluster of computers to do this quickly.
While the laptop is powered off

If the computer can be booted, then this offers very little more protection over the other states.  Did you set a bios password or boot password?  If so, then the determined professional would have to brute-force those passwords.  Then they could employ any of the techniques listed above.

On the other hand, the easiest thing that law enforcement can do is deprive you access to your data forever.  With this encryption scheme it is very easy to destroy the contents of the hard disk by destroying the encryption key.  I assumed above that your main concern was someone accessing your data.

Please keep in mind that the techniques mentioned here have a lifetime.  These things work until the vulnerabilities are repaired.  These methods are current as of late last year, 2015.


What are the security implications of allowing unlimited size cookies? Our application firewall blocks requests if it detects a cookie is present with a value greater than 1024 characters in size.

Are there any exploits involving large cookies?

i.e. How much more secure is restricting cookie size to 1024 rather than say 2048 characters.

What are the security implications of allowing unlimited (browser maximum) size cookies?

It seems likely that the restriction is more about disallowing something which seems likely to be malicious than a specific threat, however there are some potential risks I could think of with large cookies.

Denial of Service.  Assuming that the application processes the cookies, then a very large cookie value could cause the application to do excessive processing, leading to an app. DoS
Attempt to exploit an overrun condition.  If the application had some kind of buffer overrrun condition in cookie handling code then a large cookie could trigger that.

All that said the short answer is it depends on the application behind the WAF, and assuming it doesn't have flaws in coookie handling code, I don't see any particular reason to set a hard limit of 1024 chars for a cookie value.


Are cars with keyless proximity-based entry protected against range extenders? Some cars unlock whenever the key fob is within a certain distance.

Do such systems generally guarantee the maximum distance in a secure fashion (namely, by requiring the fob to respond within a certain time, thus relying on the speed of light for security), or do they simply work on the basis that a weak enough radio signal won't travel very far?

In other words, are any such systems susceptible to an attack utilising a device that relays and amplifies the signals between the car and a reasonably far away key fob?

I suppose this fall backs to active RFID type of communication issues and, maybe 1-2 years ago, I read an article on the subject (sadly I do not remember the reference now). Researchers tried to authenticate under the following condition:

The victim bearing the genuine RFID token was in some crowded public place (subway, ...),
Attacker A goes near the victim (no need to steal the token), he bears an RFID tranceiver linked to a mobile phone,
Attacker B is near the door to open, having also a mobile phone and an RFID tranceiver.

Here is a quick representation of the communication path established between the RFID token and the RFID lock:

Genuine RFID token <--> RFID tranceiver <--> Mobile phone A <--> Mobile phone B <--> RFID tranceiver <--> RFID lock

Thanks to this system, the researchers manage to extend the RFID range to unlimited. However, the issue they encountered was, as you mentioned, timing issue making this attack practically not doable with current technology (ie. up to 3.5G), however they emitted some worries on the subject with technology evolution which would fatally come up with this timing issue.

So, to answer your question, technically the attack is doable, but not practical yet. However, if I were to wear such a key and would have such safety concern, we see more and more faraday pouches designed to prevent such issue (some are even integrated to bags and jacket pockets, a discussion on the subject is here).


What previously-unknown Wifi access points will devices automatically connect to? I was reading an article on an iOS8 SSL exploit on The Register when one quote caught my eye:

  “Anyone can take any router and create a Wi-Fi hotspot that forces you to connect to their network, and then manipulate the traffic to cause apps and the operating system to crash,”

Emphasis mine. This is reiterated in the slides (PDF warning!) on pages 20-22. It mentions that it wouldn't be possible unless you can force the user to connect to WiFi but immediately says that's possible to circumvent with "Karma attacks" and "WifiGate", bypassing any user interaction.

Even before the DoS exploit, the idea of an attacker manipulating a device onto their network is terrifying.

Could somebody explain how these work, if they only apply to iOS and either way, how somebody might mitigate against them?

The good news is that your device will never connect by itself to previously-unknown access point.

The bad news is that the concept of "previously-unknown" may not be as obvious as expected.

Basically, you device will recognize and connect to an access point thanks to two things:

The SSID, the "name" of the network,
The pre-shared key, the password securing the network and ensuring, among other things, that the access point is who it pretends to be.

(For completeness the device can also check the access point MAC address, but I think this is rarely the case by defult, most probably to not interfere with Wifi networks using several access point to cover a larger area).

However, on public networks, there is by definition no pre-shared keys. Therefore, the only thing the device can use to recognize the access point will be the SID.

In other words, if your device has been allowed to connect to some genuine public wifi (which usually bear very frequent or obvious names), then it will try to "connect back" automatically as soon as any other access point broadcast the same SSID, even if this time the access point could be everything but genuine...


At what point is password complexity "safe enough" Obviously the best passwords will be highly complex randomly generated passwords stored in a password vault. For the average user though, this might be a slight overkill.

Assuming that the average user is not nearly interesting enough for a targeted attack by a competent attacker, at what point does a password become safe enough from the most likely attack scenario, a dictionary or bruteforce attack against a large compromised password hash database targeting the low-hanging fruit.

What is the minimum level of entropy that should be met, taking into consideration that the user has no control over the type of hashing applied on the password?

Security is all about balance.  There is no "perfect" answer and no "perfect" security.  You can always make things more secure, but security has a cost, typically usability.  Making good security decisions is based on making a determination about what is important to your needs, what is acceptable risk, what is necessary usability and then setting your security policies based on those needs.

For a site like Wikipedia, password security doesn't really matter since anyone could make an account and modify the same content.  There isn't (for the most part) any difference in privilege or restriction, so there isn't a big reason to want to break a password and the risk is minimal.

When dealing with banking information, then clearly the risk is much higher and the level of restriction the password grants access to is higher, so the complexity should be higher.  Similarly, anything that has the ability to cause loss of life will generally have even higher security still.


Are there standard protocols for user authentication over JWT? I would like to learn more about protocols using a JWT as a Token.

I'm aware of OIDC but I can't find any other well defined and robust protocols for user authentication using JWTs.

Sure, I can use a simple REST endpoint providing a JWT in exchange of valid credentials, but where can I find an RFC about that ?

Great question, and probably one that doesn't have a satisfying answer.

The JWT format is specified in rfc7519, but as far as I know it's kinda like HTTP: the standard headers are defined, but how you use them in your app is up to you.

For example, should your JWT contain only an expiry date, a sessionID, and a signature? Maybe that's ok if you have a strong server-side session mechanism. But if you're totally stateless then you probably need to carry more data in the JWT. Should it contain a userID? Should it contain group or access control info? Should it include info about how the user logged in - which portal, or which authentication method? Is any of this info sensitive enough that the the JWT should be encrypted so that the user can't see it? Is your web app designed such that all services that consume the JWT are able to share an AES private key to decrypt it?

TL;DR: I'm not aware of any RFCs or frameworks that tell you exactly what data should be carried in your JWT, but I'm also not sure this is really possible since the questions around what data you need to carry in the JWT depend heavily on the architecture of your app.


Is L and P the same for OAEP in CMS In RFC 4055 Additional Algorithms the application of PKCS#1 2.1 RSAES-OAEP (RFC 3446) for key transport is described.

The (key transport) parameters of RSAES-OAEP in this RFC define a hash function, a parameterized mask generation function as well as the p source function.

However I cannot find a definite definition of this P parameter. Its characteristics (by default an empty string, alternate values for each encryption, input to RSAES-OEAP) suggest that this is the same parameter as called L in RFC 3447. This is also enforced by the security reflection, which defines the hash beeing applied to encoding parameter P (which is done to the L label).

So my question, why does RFC 4055 not use the cleaner L parameter name (less conflicts with RSA's p) and is there any formal link of the both I have missed? (RFC5652 CMS does not seem to talk about the details of key transport encryption).

PKCS1 v2.0 in 1998 (rfc2437) called it P for encoding parameters; PKCS1 v2.1 in 2003 (rfc3447) changed it to L for label, but the ASN.1 had already been published and implemented using names like pSourceAlgorithm id-pSpecified pSpecifiedEmpty and it would have been disruptive to change that. This is noted in the description of pSourceAlgorithm in A.2.1

Although rfc4055 was published after 2.1 in 2005, since it is Standards Track work on it would probably have started earlier, apparently by enough to pick up the old terminology. It does reference 3447, but updating references is usually among the final steps done by the RFC editor. OTOH 2437 and 3447 are only Informational copies of documents from (then) RSALabs and could have moved faster because they didn't need consensus.


Does it make any difference of the order Hashing and Encrypting in terms of security? I am implementing a password vault program with java. I have programmed a triple DES for encryption and a SHA256 for hashing.

My question is would it make any difference if I first hash the raw data (password) and then encrypt it, or first encrypt the data (password) then hash the encrypted data. I am mostly concerned about, would it make any serious differences between them in terms of security.

Thanks

You don't want a hash; you want a MAC.

The scientific answer: you apply the MAC after encryption, not before. It is known as "encrypt-then-MAC" and it has a lot of benefits over doing things in reverse (aka "MAC-then-encrypt") or in parallel ("MAC-and-encrypt"). See this question for details.

The moral answer: don't do it. It is hard to make these things securely. You don't know enough to do it. Even people with a PhD in cryptography consider that they don't know enough to do it. When such a thing must be done, a cryptographer produces a tentative design and submits it to his peers, who scramble and try to break it for several years. Only survivors are deemed "apparently secure".

The practical answer: there are nice encryption modes which combine encryption and MAC for you; these schemes have survived the onslaught of enraged cryptographers. See GCM and EAX.


How are CVSS scores used in security risk management products? From CVSS v2 complete guide :

"Security (Risk) Management: Security Risk Management firms use CVSS scores as input to calculating an organization's risk or threat level. These firms use sophisticated applications that often integrate with an organization's network topology, vulnerability data, and asset database to provide their customers with a more informed perspective of their risk level."

My precise question is: How are CVSS Scores used in calculating org's risk ?  CVSS Scores are calculated per exploit, curious how they are extrapolated for entire org's risk level? Imagine we inventory every application, host etc in the network, we perform thorough scans of Nessus or Qualys etc. and then we have CVSS scores of known exploits. But how are they stitched together to show the risk posture of entire network?

Any references or pointers would be of great help.

First of all, there are three different metrics to calculate the global CVSS score. These are: Base Metrics, Temporal Metrics and Environmental Metrics.
Temporal Metrics and Environmental Metrics are optional and these are calculated using the Base ones as an input value. To have a better overview of these metrics and their equation, take a look of this picture:

(source: first.org)

Generally, the base and temporal metrics are specified by vulnerability bulletin analysts, security product vendors, or application vendors because they typically have better information about the characteristics of a vulnerability than do users. The environmental metrics, however, are specified by users because they are best able to assess the potential impact of a vulnerability within their own environments.

That means that the user must provide the environmental metrics whereas a vulnerability scanner might provide the others.
As far as I know, Nessus includes just the Base and the Temporal Scores. Thus, Nessus is not able to get the value of the Environmental metrics. The environmental metrics depends on the organization's necessities.
Otherwise, if you want to calculate the CVSS score using the Environmental Metrics, you can not use an automatized vulnerability scanner as Nessus. You would need to assess the system and decide the threat that the organization is capable to bear.
In order to calculate the global CVSS score, you can mix the results of a Nessus scan with the assess of the system.
There is available a CVSS v2 calculator
In addition, it looks as if Qualys works in a similar way. The scanner provides the Base and the Temporal Score, moreover the user provides the Environmental metrics.

The CVSS Environmental Metric group captures the characteristics of a vulnerability that are associated with the user's IT environment.

More information of Qualys and CVSS

I suppose that the global CVSS Score should take the worst situation possible.


How do you compare risks from your websites, physical perimeter, staff etc In assigning budget rationally - ie proportionally to the risk in a particular area, how can you calculate the relative risks?

I can think of examples where clients of mine have secured their websites very well, but have no security on their front door and no vetting of contractors - this seems crazy but usually boils down to the fact they have had no way to compare risks.

Answers can be quantitative or qualitative, but I'm just interested in how this is done in organisations you know.

I'm sure there's many processes - the general term to search for is 'risk analysis' or 'risk assessment'.  The process I'm most familiar with is what's advocated by NIST.

Generally, the NIST process :

what is your system - what counts as part of your system and not part of your system
what are your threats?  what groups or people, what are they after, what are their resources?
what are your vulnerabilities? what can be exploited by one of these threats?
what do you have protecting your vulnerabilities already?  How effective is it?
how likely is it that your vulnerability will be exploited by a threat, despite your controls.
what is the impact if the vulnerability is exploited?  how much will you loose?  Both in assets, or the ability to make future money, or damage to reputation
combine likelihood and impact - if both are high - this is your MUST DO list.  If both are low, you have candidates for things to defer.
investigate new protections - balance the cost of the protection vs. the cost of vulnerability exploitation to see if it's worth it to pay the money.

Put together a plan for what protections you'll spend money on now.  Keep in mind there's other options beyond stopping the exploit - for example, and insurance policy to prevent losses.


Blind SQL injection: Can you execute a hex string as part of the query? Sorry in advance if this is a noobish question, but I can't seem to find the right phrasing to get the answer on google or here--I'm pretty new to SQL and am working on a SQLi challenge that is a blind injection.  The page returns no information unless you either run a query successfully or use quotation marks in a pattern that I haven't been able to identify, in which case it says "you can't do that". It is silent if you cause any sort of error with your input.  As a result I haven't been able to figure out what the backend is, what varient of SQL is being used, what the database name is or what the table names are.

The statement being run must be something like "SELECT * FROM table WHERE title='". The site will allow me to dump all the entries of the table it's querying from by injecting something' OR '1' = '1. I know there's another table in the database containing information that I need to get at (a flag), but if I try something like something' UNION SELECT * FROM users WHERE '1' = '1, it returns "you can't do that". Even after a lot of fooling around with it I haven't been able to figure out on what criteria it filters quotes--the UNION statement I tried has the same amount of quote characters as the OR '1' = '1 statement that DOES run, and adding superfluous quotation marks that don't change the meaning of the query (adding random open and close quotes, putting a single quote in a comment in the middle of the query) sometimes triggers the "you can't do that" and sometimes does not.  I haven't been able to identify a pattern.

My question is this: Is there a way that I can fool it into thinking I'm using the right number/pattern of quotes, such as a pattern that I already know works, but also include a hex-encoded UNION statement that would be run as part of the query? I've been trying things like something' OR '1' = '1 CONVERT(varbinary(max), <hex code for ' UNION SELECT * FROM users WHERE '1' = '1>) but not getting any results.  Since the injection is blind I can't tell if I'm doing something that's a syntax error (does that CONVERT statement actually turn the hexcode into ascii that would then be executed as part of the query?) or if my logic is off.  If somebody could let me know if what I'm doing makes sense and/or point me in the right direction that would be greatly appreciated.

Thanks!

For a UNION to succeed, both SELECTs need to select the same number (and possibly compatible data types) of columns.

So your first task would be to identify the number of columns in your initial SELECT. You can do this with the ORDER BY clause by specifying the numeric position of the column to be sorted by:

' ORDER BY 1,'

This would end up the the query as follows:

SELECT * FROM table WHERE title='' ORDER BY 1,''

A non-existing column position would result in an error. So just increment the number until you get an error (or false response).

Then you can construct your second SELECT with that exact number of columns and UNION it with the first one. Depending on the DBMS and column types, you may need to fiddle a little bit around with the column types of the second SELECT to find compatible types.


Point domain to IP address on Cobalt Strike On Cobalt Strike how do I point a domain (in this case a subdomain) to the IP address to create a listener?

Do you mean you have a listener running on your cobalt strike server and want your payload to connect to it via a domain name? In that case you need to modify your DNS record to point to the IP address. Go to your domain name registrar (where you bought the domain) and add an "A" record which ties your subdomain to that IP address. If you Google it your registrar will almost certainly have instructions on how to do it.


What are the FEDRAMP "complementary controls"? Quoting the FedRAMP official FAQ:

  FedRAMP requirements include additional controls above the standard NIST baseline controls in NIST SP 800-53 Revision 4. These additional controls address the unique elements of cloud computing to ensure all federal data is secure in cloud environments.

However when I download the list of controls via the Official Fedramp Website (see this for "HIGH", and similar links for the other levels), I get what looks like the NIST 800-53 controls. Depending on the FedRAMP impact level, a subset of the NIST controls are selected.

So, what are those "additional controls above the NIST baseline"? I can’t find those on the web.

What FedRAMP calls "complementary controls" are simply the classic NIST "security control enhancements" selected for FedRAMP, and that are available in the usual NIST templates.

It was just a vocabulary issue..


Password verification scheme (used in eg. MS Office) - more secure than just a hash? Usual password verification schemes stores a salted password hash and the salt. If the hash is good and computational costly, it is considered secure.

However an alternate version (used in Microsoft Office and probably other places) generates N random bytes (eg 16 bytes) and a M byte hash of the N bytes (say an additional 16 bytes), concatenates them and encrypts the concatenated N+M bytes using some encryption algorithm and a key derived from the password.

To verify the password, the N+M bytes are decrypted, the first N bytes are hashed and compared to decrypted M bytes. If they match, the password is considered verified.

To my untrained eyes, the introduction of  random data (of sufficient length) makes this system secure against any table look up scheme even if the hash is weak. It only seems to depend on the strength of the encryption and the key length.

Am I wrong? Where?

This scheme is ok, but it's basically just a variant of a salted hash. These are generally considered old practice. Furthermore, this scheme is more complicated (more surface area for potential bugs) and relies upon multiple cryptographic algorithms being unbroken.

Modern good practice is that passwords should be stored using a slow key derivation algorithm such as PBKDF2 or bcrypt. These ensure that lookup tables are infeasible, and that cracking all but the weakest and most common passwords is extremely expensive.

I wrote an answer a while back explaining a bit of the history of password hashing and why we now use slow KDFs.


Communicate through gpg I need to frequently communicate with a server in the manner do stuff related to x or send me info of x

My thoughts are to directly put the task I want to be executed into the package I want to send, add some SALT and encrypt it using a monthly changing public gpg key. Since every user will have a public and private key, too, the package will be signed by them. This blob will be used client-side.

The server does the same but with it's key to sign and the public key of the specific user to encrypt.

Everything is sent through simple HTTP, though HTTPS would be possible, too. But is it worth it for that particular protocol? Can this even be a safe protocol? What vulnerabilities does it have? Is it considerably fast? What else should I use if any answer to the previous questions implies a highly insecure way of communicating?

If you're using simple HTTP for communication then TLS would be the easier route.  While you think you might have thought everything through it's better to use an established protocol for the following reasons:

It's already supported by most browsers, operating systems, and devices.
The infrastructure is already in place, with lots of examples for configuration.
Already tested.  Faults in its security have been detected and fixed.
Regular updates

The other concern for using just straight GPG is performance.  Bignum operations take significantly longer to perform.  Having to do these large calculations for every message you send to the server could be taxing.

Checkout How Does SSL/TLS PKI work? for more information on why/how the web uses Certificate Authorities.


Linux 'add_interrupt_randomness' implementation - low entropy contribution by cycles and jiffies? Currently I'm analyzing the process of entropy generation of a Linux 64-bit kernel during system startup (for educational purpose). The system is hosted as/on a (64 bit) virtual machine (Xen domU). For a deep analysis, I'm tracking the state of relevant input parameters i.e. how those are processed. In function add_interrupt_randomness I found some code whose intention is not clear to me: The handling of cycles (value provided by CPU cycles counter) and now (jiffies). Both are unsigned 64 bit values, and processed as following:

c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
j_high = (sizeof(now) > 4) ? now >> 32 : 0;
fast_pool->pool[0] ^= cycles ^ j_high ^ irq;

So c_high/j_high (__u32) are assigned with the upper 32 bit of cycles/now and then assigned (after XOR) to the fast entropy pool.
Hence a maximum variation of the values provided by c_high and j_high should be desirable?. But since c_high and j_high are based on cycles and now/jiffies, ,which are purely incremented variables, there is very little/no variation in the upper 32-bits as the traced values reveal:

Values in call no. 1 of add_interrupt_randomness:

cycles:0xFFFEA432A6C2CB89
c_high:0xFFFEA432
now_jiffies:0x00000000FFFEDB0A
j_high:0x00000000

Values in call no. 4265* of add_interrupt_randomness:

cycles:0xFFFEA43FBA85B313
c_high:0xFFFEA43F
now_jiffies:0x00000000FFFEE80C
j_high:0x00000000

*(startup is completed at this point)

During the system start add_interrupt_randomness is called 4265 times. The value of j_high is constantly 0x00000000, the value of c_high
increments from 0xFFFEA432 to 0xFFFEA43F.
So my question is: why are the upper 32 bits processed instead of the lower, which would provide more randomness?

If interested: this is the complete definition of add_interrupt_randomness:

void add_interrupt_randomness(int irq, int irq_flags)
{
    struct entropy_store    *r;
    struct fast_pool    *fast_pool = this_cpu_ptr(&irq_randomness);
    struct pt_regs      *regs = get_irq_regs();
    unsigned long       now = jiffies;
    cycles_t        cycles = random_get_entropy();
    __u32           c_high, j_high;
    __u64           ip;
    unsigned long       seed;
    int         credit = 0;

    if (cycles == 0)
        cycles = get_reg(fast_pool, regs);
    c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
    j_high = (sizeof(now) > 4) ? now >> 32 : 0;
    fast_pool->pool[0] ^= cycles ^ j_high ^ irq;
    fast_pool->pool[1] ^= now ^ c_high;
    ip = regs ? instruction_pointer(regs) : _RET_IP_;
    fast_pool->pool[2] ^= ip;
    fast_pool->pool[3] ^= (sizeof(ip) > 4) ? ip >> 32 :
        get_reg(fast_pool, regs);

    fast_mix(fast_pool);
    add_interrupt_bench(cycles);

    if (!crng_ready()) {
        if ((fast_pool->count >= 64) &&
            crng_fast_load((char *) fast_pool->pool,
                   sizeof(fast_pool->pool))) {
            fast_pool->count = 0;
            fast_pool->last = now;
        }
        return;
    }

    if ((fast_pool->count < 64) &&
        !time_after(now, fast_pool->last + HZ))
        return;

    r = &input_pool;
    if (!spin_trylock(&r->lock))
        return;

    fast_pool->last = now;
    __mix_pool_bytes(r, &fast_pool->pool, sizeof(fast_pool->pool));

    /*
     * If we have architectural seed generator, produce a seed and
     * add it to the pool.  For the sake of paranoia don't let the
     * architectural seed generator dominate the input from the
     * interrupt noise.
     */
    if (arch_get_random_seed_long(&seed)) {
        __mix_pool_bytes(r, &seed, sizeof(seed));
        credit = 1;
    }
    spin_unlock(&r->lock);

    fast_pool->count = 0;

    /* award one bit for the contents of the fast pool */
    credit_entropy_bits(r, credit + 1);
}

from: https://elixir.bootlin.com/linux/v4.15.6/source/drivers/char/random.c#L1118

They are both processed.
Both cycles and now are mixed into the fast pool in their entirety. See the relevant lines:
fast_pool->pool[0] ^= cycles ^ j_high ^ irq;
fast_pool->pool[1] ^= now ^ c_high;

In order to distribute randomness a bit, the number of CPU cycles* that have occurred since boot are mixed with the high bits of the number of jiffies, and the number of jiffies are mixed in with the high bits of the number of cycles. Even when this is happening, the full number of cycles and jiffies are inserted into the fast pool with the XOR operation. There is no c_low and j_low, but the bits are added.
The fast pool is defined in the random driver as:
struct fast_pool {
    __u32           pool[4];
    unsigned long   last;
    unsigned short  reg_idx;
    unsigned char   count;
};

The fast pool contains an array of four 32-bit values. The cycle counter, stored as cycles_t, may be a 64-bit value as it is defined as an unsigned long, so writing just the cycle counter to one of the pool elements will discard the high bits. This is not ideal, so the high bits are obtained separately and put in their own 32-bit integer which is then added to the pool on its own, in effect preserving the entire 64-bit value despite only being able to mix in 32-bits at a time. As you can see with the following two lines, if the two values already fit in a single 32-bit integer, the (non-existent) high 32 bits are set to 0:
c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
j_high = (sizeof(now) > 4) ? now >> 32 : 0;

The process is thus:

If the variables are larger than 32 bits, save a copy of the high bits, otherwise set the copy to 0.
Mix in the variables with the fast pool, discarding the high bits during integer conversion.
Mix in the saved high bits, in effect "folding" the low and high bits into a single 32-bit integer.

* On some architectures, such as certain versions of MIPS, the cycle counter may not be available.


SUID Scripts vulnerability In this article, it says that this C-shell script:

#!/bin/csh -b
set user = $1
passwd $user

With these permissions:

-rwsr-x---   1 root     helpdesk

Is vulnerable because one can manipulate env variables, like:

env TERM='`cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh`' change-pass

But I really don't see what the TERM env var has to see with all this. Do you have any explanation?

This is a design flaw in csh, allowing the evaluation of backtick escape in the contents of environment variable.

Overall, the assumption is generally made that controlling the environment of a shell should not lead to execution of arbitrary code.

Breaking this assumption creates dozens of attack vectors for remote code execution, from CGI scripts to malicious DHCP replies to mail forwarding.

When this behaviour was accidentally triggerable for bash, we called it Shellshock and made a huge fuss about it.


How difficult is it to direct an email into a gmail recipient's spam folder? I assume gmail recognizes patterns somehow, but I have no idea how it's done.

What is the easiest way to have an email flagged as spam and directed to the recipient's spam folder? And how confident could the sender be that the email was successfully sent to the spam folder?

If I recall correctly Gmail supports GTUBE, a test string which will always make the spam filter mark a mail as spam. So including

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

In a message body Could do the trick. I don’t use gmail myself so I can’t verify this, but if it is supported it’s one way to guarantee that a mail is marked as spam.


Proxy Non-HTTPS logins through EC2 I've been thinking a lot about password security these days, and have been becoming more and more hesitant to use services that have login forms that are not on HTTPS.  As I was researching security, I played around with Cain & Abel on my local network to see how easy it really would be to run a man-in-the-middle attack on sites that don't use HTTPS.  Unfortunately, it's pretty dang easy.

So I've been trying to think up ways to get around this.  It's unrealistic to expect myself - and certainly the rest of the security-ignorant world - to simply stop using services that don't use HTTPS.  There's too many of them that don't.

The plan that I'm most interested in right now utilizes a proxy system on an EC2 instance to do logins remotely, and then pass back the secured session/cookies.  Essentially, the flow would look like this:

User send username/password and domain cookies over SSL to an EC2 instance.
EC2 instance uses cookies to imitate the user's session, and submits a login request.
EC2 instance returns any new cookies to the user, as well as any redirects that may have been requested by the login server
User sets cookies per the EC2 response, and either refreshes (if no redirects), or redirects to the specified URL.

The security here relies on the fact that EC2 instances are distributed and anonymous, making them fairly secure against man-in-the-middle attacks.  Certainly there is still a possibility, but in my mind this vastly decreases the risks of sending passwords to non-SSL sites.

Are there any security holes here that I'm not seeing?  Is there a real security benefit from doing logins this way?

I find rather dubious the idea that EC2 instances being "distributed and anonymous" makes them "fairly secure against man-in-the-middle attacks". This may make the task harder for your arch-enemy who is after you specifically, but it won't make much of a difference against an attacker who just want to harvest passwords in a quite impersonal way.

The only tangible benefit I see is that it would strengthen your near-field link -- typically, against some bad guy using the same Wireless hotspot than you. However, it would be both simpler and more thorough to use your external system (the EC2 nodes) as a generic proxy for all your Web traffic: this is very simple to do with ssh (setup a SOCKS proxy with ssh -D, and configure your browser to use it; PuTTY can also do it). You could also install an HTTP proxy which you contact through HTTPS. Or, even more thorough, tunnel all your traffic through a VPN (see OpenVPN).

Such proxying will not protect you against wide-scale attacks (e.g. MitM enacted through DNS poisoning) but it will give you some protection against low-powered stalkers who perform their villainous felonies only locally. At least it won't harm.

(And Amazon will quite like your scheme, too.)


How should API keys be generated? I want to make sure requests can't be forged and sent on to my server. In order to do this I need to generate an API key per user on my system. The purpose of the key will be to sign requests on the client side & validate them on the server.

The question is, what are API keys generally made up of? Are they just a cryptographically secure random number (similar to a password salt)? Or is there some logic behind them e.g. should they be made up of data specific to the user.

In my system each user already has a unique ID (GUID) which isn't publically exposed, could I use this as my "key" or should an API key differ from a users ID?

It depends on how much you want to separate roles.

Basic system: your "signature" is a MAC. The "API key" is a secret value with is shared between the server and the user. Normal MAC algorithms like HMAC can use arbitrary sequences of bits as key, so a key is easily generated by using /dev/urandom (Linux, *BSD, MacOS X), calling CryptGenRandom() (Win32) or using java.security.SecureRandom (Java).

Enhanced system: your signature is a true digital signature. This makes sense if you want to separate the key generator (who can produce keys which will be accepted by the server) from the server itself (who validates the incoming signatures). Keys for signature algorithms are mathematical objects with a lot of internal structure, and each algorithm implies a specific key generation algorithm. Use a library which already implements the needed bits (e.g. OpenSSL).

Either way, there is more to it than just key generation and signatures. For instance, you probably want to avoid replay attacks: an ill-intentioned third party spies on the network, and records a valid request signed by a regular user. Later on, the attacker sends the request again, complete with its signature, so as to replicate the effect. To avoid replay attacks, you must add some sort of external protocols, and these things are hard to do (it is not hard to define a protocol; it is very hard to define a secure protocol). Therefore, the smart thing to do is reusing an existing, well-vetted protocol, which, in practice, means SSL/TLS.

With SSL, the "basic system" is reduced to sending the API key in a header at the beginning of the conversation (that's exactly what happens with password authentication on HTTPS Web sites). The "enhanced system" is then "SSL with a client certificate".


Where does the responsibility lie for a XSS vulnerability I am an avid user of Workflowy (online outliner/note taking tool) and I installed the Chrome extension 'Workflowy for Coders', which formats the text within notes.

I discovered that one of my notes triggered a Javascript XSS (because it was a sample of XSS (<script>document.location="http://google.com";</script>) ). The vulnerability stopped when I disabled the extension.

I sent notes, both to Workflowy and to the extension creator, but I'm curious, who is technically responsible? Workflowy, the extension creator, or Chrome? I could not think of a clear answer to that question.

If there is no clear answer, there might be wider implications for web developers.

The fault is almost certainly that of the Workflowy extension.  It is the extension developer's responsibility to ensure their extensions are secure, and avoid introducing mistakes like XSS vulnerabilities into their extensions.

XSS vulnerabilities are common in browser extensions.  It is easy for extension developers to screw up and introduce a XSS vulnerability, and extension developers often aren't focused primarily on security and may not be very aware of security issues, so security vulnerabilities in browser extensions are common.

Actually, Chrome is at the forefront of developing mitigations against these kinds of vulnerabilities.  While the responsibility is ultimately with the extension developer, Chrome recently introduced powerful mitigations that make XSS vulnerabilities in new extensions less likely.  These mitigations rely upon restricting extensions, using a Content Security Policy, in a way that helps prevent XSS vulnerabilities.

For backwards compatibility reasons, the new restrictions only apply to new extensions.  It will take some time for these new defenses to be phased in fully.  That said, this is a great development.  It will really help protect users.  I hope that other browsers follow suit.

For more on this topic, here is a recent research paper on this subject:

An Evaluation of the Google Chrome Extension Security Architecture.  Nicholas Carlini, Adrienne Porter Felt, and David Wagner.  Usenix Security 2012.

Some sample findings from the paper:

An analysis of 100 randomly selected Chrome extensions found that 40% of Chrome extensions had at least one security vulnerability.
The same analysis also found that Chrome's new defenses should eliminate 94% of the most serious vulnerabilities.

See also a blog post summarizing the paper's findings, and another follow-up.


When should a password cipher be used and when should a normal password be used? I came across this article discussion how to make a password secure by adding your own "encryption" scheme to a selected word and create you password.

For example, if my cipher was to add four zeros, switch every word in the alphabet with it's reverse letter, and attach with my favorite number.

Examples

Google = 0000tlltov7
Stack = 0000hzxp7
etc...

The idea here is to simply remember the cipher, not the password. The clear text comes from the name of the website/company(Apple, Microsoft, Google)... but is this a better way than creating passwords?

Sure, every password is unique and extremely difficult to brute-force, but the the scheme exposes it all. If an attacker were to find out my scheme, they would know all of my passwords. When is it better to use password ciphers? When is it better to use normal passwords?

It seems unlikely this hasn't been asked here before, but I couldn't find a good duplicate.

Password managers, when combined with long, randomly-generated passwords, operate on an approach I like to call "put all your eggs in one basket, and guard that basket really really well".  The length and randomness of the passwords protect against brute force and dictionary attacks, and the randomness also prevents password-sharing attacks where one site stores your password insecurely.  The primary attack vector, of course, is an attacker gaining access to your password manager database, at which point they gain access to every account of yours.

If you can remember all of these long, randomly-generated passwords, then there is no database to breach, and you're better off.  However, most people can't do this.

As an alternative, you can use an algorithm to reproducibly generate a password on-demand for a site (a number of options are described in What is your way to create good passwords that can actually be remembered?).  These retain the benefit of not having a breachable database.  The question, then, is to whether or not the benefit of avoiding the database of passwords outweighs the downsides of moving from randomly generated passwords to a reproducible scheme.

If the scheme is obvious upon looking at a plaintext (e.g. siteName + accountName), then one breach at an insecure site opens up your entire set of accounts to any attacker who happens to look at your password.  This is obviously pretty awful from a security perspective.  Most schemes aren't that obvious, but you're betting on the attacker to not be able to reverse-engineer it - whether that's a good bet or not is up for debate, and depends on your specific scheme as well.  It's worth noting that the chances of successful reverse engineering go drastically up as an attacker gains access to plaintext passwords from multiple sites.

Another issue with reproducible password schemes is that they don't provide an easy way to change your password for a site - they are reproducible, and to generate a new password, you would need to integrate an additional piece of information (some sort of "round"), which you then need to either store or memorize.

Both password manager use and reproducible password schemes are security downgrades from the ideal password memorization option.  They are also both much better than what most people do, which is to use the same insecure password across many accounts.  Which one is "better" depends a lot on the specifics of your password manager and the scheme you're comparing it against, and which attacks you're worried about.


What is the role of RSA in ECDHE-RSA? I have read some textbooks and not found a convincing explanation.

In the cipher suite ECDHE-RSA-AES128-GCM-SHA256, what is the role of RSA in the first part (ECDHE-RSA)? This part of the cipher suite indicates the key exchange algorithm, right? That is what ECDHE is used for: key exchange, so why do we need RSA?

Are both algorithms used to exchange the keys? I’m a bit confused about that.

Obviously, it is not necessary to explain ECDHE or RSA separately. I just want an explanation of how they work in this context.

ECDHE by itself is worthless against an active attacker -- there's no way to tie the received ECDH key to the site you're trying to visit, so an attacker could just send their own ECDH key. This is because ECDHE is ephemeral, meaning that the server's ECDH key isn't in its certificate. So, the server signs its ECDH key using RSA, with the RSA public key being the thing in the server's certificate.


Revoke a certificate without index.txt I generate self-signed client certificates for a little Apache server hosted under my stairs. The script below was hacked together for this purpose - note it uses the 'mini-CA' x509 method, therefore recording nothing in an index.txt.

Now I need to revoke one such client certificate, which entails generating a CRL and adding it to Apache. CRL generation seems to require an index.txt however:

root@myserver:~# openssl ca -cert "ssl_ca/ca.crt" -keyfile "ssl_ca/ca.key" -revoke "ssl_badguy/badguy.p12"
./demoCA/index.txt: No such file or directory
unable to open './demoCA/index.txt'

Is there a 'standalone' CRL generation command, as per cert creation? I don't care about persistence of CAs or respecting proper SSL 'theory' (otherwise there'd be no self-signing for a start). Originally I just wanted to secure and control access to my server; now I just want to revoke some of that access.

When called as per ./clientcert.sh certname, the following script makes a new directory /root/ssl_certname/ with all the bumf (including PKCS12).

#! /bin/bash

echo 'When it asks for a key password (3 times), recommend you use the new key name'
echo 'When it asks for cert details, use "." (blank) for all, EXCEPT CN, which should'
echo 'also be the key name. All other passwords ("Export" etc.) are blank'

clientname="$1"
newdir="/root/ssl_$1"
caloc="/root/ssl_ca"
cert="$newdir/$1"

if [ -d "$newdir" ]; then
    echo "$newdir already exists!"
else
    mkdir "$newdir"
    cd "$caloc"

    openssl genrsa -des3 -out "$cert.key" 2048
    openssl rsa -in "$cert.key" -out "$cert.key.insecure"
    mv "$cert.key" "$cert.key.secure"
    mv "$cert.key.insecure" "$cert.key"

    openssl req -new -key "$cert.key" -out "$cert.csr"

    openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in "$cert.csr" -out "$cert.crt"

    openssl pkcs12 -export -clcerts -in "$cert.crt" -inkey "$cert.key" -out "$cert.p12"
fi

EDIT: Technically doesn't solve the issue, but I've achieved the same thing by adding the following to my default-ssl vhost:

# Block badguy client cert
Rewritecond %{SSL:SSL_CLIENT_S_DN_CN} =badguy
RewriteRule (.*) /blocked [QSA,R,L]

- where /blocked doesn't actually exist (I guess I could put a holding page there).

First off, let's be clear: the client certificates are not self-signed. They are signed by a CA, and that CA's certificate is self-signed. This is important, because a self-signed certificate cannot be revoked at all, by definition: revocation is an information coming from the issuing CA; a self-signed certificate is its own CA.
A second important point is that a CRL is a list of revoked certificates so far. So if you revoke one certificate, then you have a CRL which designates that certificate; if you then revoke another one, then your next CRL must designate both certificates. If the next CRL only talks about the second certificate, then it "unrevokes" the first one. For revocation, Apache has no memory, or rather, the CRL is Apache's memory. Apache will use the latest CRL as the exclusive source of revocation information for all certificates.
This means that you really need to maintain a list of revoked certificates on the CA. The openssl command-line tool can maintain such a list for you: that's the index.txt file, as maintained by the openssl ca command-line option. If you don't use it, then you will have to maintain the information yourself, which is, at best, cumbersome. If you want to handle revocation at all, then the simplest way is to use the index.txt and let OpenSSL manage it.
Now if you have already done it, then it is of course possible to sign a CRL with the CA private key using the library, programmatically; but there is no command-line tool for that. This is said so in the documentation:

BUGS
Ideally it should be possible to create a CRL using appropriate options and files too.

And also there:

RESTRICTIONS
The text database index file is a critical part of the process and if corrupted it can be difficult to fix. It is theoretically possible to rebuild the index file from all the issued certificates and a current CRL: however there is no option to do this.

To produce a CRL with some code, I suggest that you have a look in the OpenSSL source code, in the apps/ca.c file; search for "X509_CRL_new". The functions are not well documented... But, I insist, if you begin to revoke certificates then you must maintain a list of all certificates revoked so far (at least the serial numbers, preferably with the revocation date for each of them), and this basically means making your own equivalent of the index.txt file of openssl ca.


Sqlmap, update query and risk param I was reading about the 'risk' param for sqlmap, and the docs contain information, that risk 3 level can update tables. What does it mean? As far as I understand, this can happen either in the app update injection or if the app's logic updates some table.
Am I right? Or it is possible somehow to update tables accidentally even in select query while using sqlmap?
Thanks.

Let's say there's an injection possibility on an action that results in the deletion of a single result.

DELETE FROM users WHERE userId=1;

A risk level of 1 or 2 is likely to result in a single user being deleted.

Risk level 3 uses OR which can end up effecting many more rows than intended.

DELETE FROM users WHERE userId=1 OR 1=1;

It's not that risk 1 & 2 don't have the possibility of deleting or updating database records, rather their impact is likely limited in scope; while risk 3 is more likely to destroy (or make your presence known by disruption) an application before you can effectively exploit it.


Any scenario for using both, OpenID Connect and OAuth 2.0? Since OpenID Connect builds on OAuth 2.0, I am assuming that everything that is possible with OAuth 2.0 is also possible with OpenID Connect.

In particular, say that my website stores some information that belongs to the user and implements OpenID Connect to authenticate users. When the user is authenticating through another website, that website can use the same OpenID Connect flow to obtain authorization from the user to give it access to that user's information on my website.

Is that statement correct? Could there be any scenario where I would need to implement OAuth 2.0 independently of OpenID Connect?

Short answer is that it is undefined. If you want a library that supports both, ensure it explicitly states it supports both OAuth 2 and OIDC.

If you were to draw a Venn diagram, OAuth 2 and OIDC intersect each other but OAuth 2 also defines some flows that OIDC does not extend, and OIDC adds a flow that is not in OAuth 2.

OAuth 2 flows:

Authorization Code Grant
Implicit Grant
Resource Owner Password Credentials Grant
Client Credentials Grant

OIDC flows:

Authorization Code Grant
Implicit Grant
Hybrid

The OIDC specification explicitly extends OAuth 2's authorization code and implicit flows, but says nothing about the others. Therefore a given OIDC implementation may fully or partially or not support the remaining OAuth 2 flows. By partially I mean, it only returns the access token as per OAuth 2, but not ID token.

So why doesn't OIDC explicitly cover all OAuth 2 flows? Here's what I think:

Resource Owner Password Credentials Grant. This flow defeats the security features introduced by OAuth 2's authorization code grant. From a security perspective, stay away from this flow.
Client Credentials Grant. One example of this scenario is service to service communication, which could be solved with PKI - does not need ID token introduced by OIDC.


Encrypted code file (.vbs) hides all my files and shows .lnk files I am using Windows XP Professional and what happens is that when I try to connect any gadget like a pen drive or a mobile through USB, all my data gets hidden and it shows a 1 kb file which is a .lnk file and if I try to find the target of that .lnk file it shows:

C:\WINDOWS\system32\cmd.exe /c start qfstynchuh.vbs&start explorer USB&exit

Where USB is my file name.

I tried doing research in regarding this and I got one idea of showing hidden files using CMD by changing to F:/ and typing this code

attrib -s -h USB

It successfully worked but again the files got hidden.
I have the qfstynchuh.vbs file but when I open it with CMD it shows around 10000 lines of encrypted words. I can't paste this code here so the real code is in this link: http://hackinginjections.blogspot.nl/2014/08/qfstynchuhvbs.html

I also tried deleting that file but again it appears and I tried changing and deleting all those codes and again saving it but nothing happens. If it comes to the anti-virus then it is not detecting and by the way if it detects it move this to chest and saves there. I am using Avast anti-virus.

Please help as all my pen drives are getting infected and it is also infecting my friends' PCs who are using Windows 7.

Your computer has been infected with H-Worm by Houdini.

The VBS file on your computer consists of two parts; first, the actual malware, encoded as Base64 as said by user2867314; second, the code to Base64-decode the malware.

Step by step:

The first line is a comment.
The next line calls the function deCrypt with the Base-64 encoded malware and assigns the return value to a variable with the name Safa7_22:

Safa7_22 = deCrypt("(…)")

The third line executes the value of the variable Safa7_22 as VBScript:

EXECUTE (Safa7_22)

Line 4-6 contain a function named deCrypt that, when called, calls another function named decodeBase64 with the data passed as the first argument to the deCrypt function and returns  the value returned by the decodeBase64 function. It is redundant, as the malware author could just have called the function decodeBase64 directly at line two. Since VBScript first makes all functions in a script available before it starts with the execution of the other code, it is available at line two.
Line 7-49 contain a function to decode Base64, apparently copied from here.

The malware is encoded to hamper detection by AntiVirus solutions.

Here is the original malware with the correct syntax highlighting: http://pastebin.com/ne1fnwKx

And here is the the decoded malware: http://pastebin.com/7qS5rEEQ

At the top at the decoded malware is the configuration: it is configured to communicate with its C&C at al-ahlii17.no-ip.org.

Right now, this subdomain points to a server at 101.61.156.113, a server hosted by an ISP in Mumbai, India.

It will use port 1155 and is configured to hide both folders and files and replace them with shortcuts.

When the malware is base64-decoded and executed, it performs the following actions.

It first calls the function instance. This function checks if the computer already has a flag in the Windows registry. If not, it will store the following:

a. If the script is in the root directory of a drive, it will set store the value "true" and the current date.
b. If the script is not in the root directory of a drive, it will set store the value "true" and the current date.
After that, the function instance calls another function, upstart. This function creates a key in the Windows registry under HKEY_CURRENT_USER\software\microsoft\windows\currentversion\run\ to ensure the script is started each time when you're logging in to your account if you weren't logged  in yet. It also copies itself to the Startup folder.
Then, this function ends and the function instance resumes execution. It checks if it is already installed at the configured install location and, if so, starts WScript in Batch mode with the script's name and exits.
It then uses the OpenTextFile function to try top open a copy of the script at the install location. If opening fails, the script is already executing, meaning there is no need to reinstall it. Thus, if there is an error, it quits.
The function instance has now stopped execution, and the scripting engine resumes at line 42, where it encounters the following instruction:

while true

This is the beginning of an infinite loop, meaning the script will stay running until it breaks out of the loop (or the script is terminated).
After that, it calls the function install. This function first calls the upstart function, described above, again. After that, it will do the following for each drive:

If configured so, it hides files and / or folders and replaces them with a shortcut that will first execute the malware and then open the original file / folder using Windows Explorer.

Then, it will send an HTTP POST request request to the C&C server. It can perform various actions: downloading and executing arbitrary programs, updating itself, executing CMD commands, kill processes, send information about the drive and running processes to the attacker and more. It also contains an action to uninstall itself. All of this happens over an unencrypted (HTTP) connection.
Once it has executed the attackers commands, if there were any, it will halt execution for a specified amount of time (in this case, 5 seconds). Then, it encounters the instruction wend, after which it will start over at the beginning of the while loop (see point 5).

How to remove:

Terminate wscript.exe using Task Manager or Process Explorer.
Show hidden folders if you haven't done so already.
Remove any malicious .lnk files left behind by the script.
Delete the script's entry under HKEY_CURRENT_USER\software\microsoft\windows\currentversion\run\. It will be the script's name without .vbs.
Remove the script from the windows startup folder.
Clean the other registry keys left behind by the script as well if you want.
Remove the script file from the root of each portable disk drive and the install directory (%temp%).
Make the hidden files and folders visible again.
Malware almost never comes alone. Run a full system scan with an antivirus and a second opinion scanner (such as MalwareBytes and HitmanPro). Also, consider a full reinstall of your system.


How do we estimate the time taken to crack a hash using brute force techniques A German hacker famously managed to brute force crack a 160 bit SHA1 hash with passwords between 1 to 6 digits in 49 minutes.
Now keeping everything constant (hardware, cracking technique - here brute-force, password length etc.) let's say it takes 1 hour to crack a SHA2-256 bit algorithm (the time taken is just an example, I know that's not the case currently) then how do we estimate the time taken to crack the SHA-512 hash or the SHA2-384 or SHA2-224 hashes?

The hash type is also an example, an other way of asking this question is if it takes 1 hour to crack a hash of 128 bits, how do we arrive at a formula to estimate time to crack the same hash type but of a different bit strength, everything else staying constant?

For hashes with no attacks beyond brute force, cracking time is:

keyspace / hashrate

A six-digits-or-less password has a keyspace of 1,111,111 possible values, so a hashrate of 377 hashes per second is sufficient to crack it.  Now, for a modern computer, that's exceptionally slow (the sort of hash rate you might expect from an Apple II), and wouldn't be worthy of note.  The article is actually about passwords of 1 to 6 characters: assuming alphanumerics, that's 6.2*10^10 possible values for a more impressive 21 Mhash/sec; if it's bytes, that's 93 Ghash/sec.

SHA-512, SHA2-384, and SHA-224 aren't much slower to compute than SHA1 or SHA-256, so if you can brute-force a SHA1-hashed password in an hour, you can brute-force it in about an hour if one of the other SHA hashes is used instead.  This is why passwords should be hashed using an inherently slow algorithm such as bcrypt.


Securing a Web application using HSTS Background

I am developing a Web application using ASP.Net MVC. I deployed the application in IIS(V8) and now doing the Web app hardening process. I configured the SSL in IIS and the Web app is functioning using SSL only(using secured cookies etc..).

I did some security tests and one test I did was trying to intercept the SSL traffic using a proxy. I used BurpSuite for this test and did install the Burp's certificate in my browser.

I can easily inspect all HTTPS traffic using the Burp tool. I know this is possible only if we install the interceptor's certificate in the client browser. Otherwise it will give the broken SSL notification.

Problem

My problem is how we can prevent any interceptor analysing the HTTPS traffic even if someone installs the interceptor's certificate in the client browser?

Resolution

I heard that if we implement HSTS (HTTP Strict Transport Security) we can resolve this issue.

Question

Does implementing the HSTS solving the problem I have? If so, what is the most effective way of implementing it (Do we need to implement it in the application level or in the Hosting (IIS) level) ?

If the HSTS not solving this problem, what are the other alternatives we have to secure this scenario?

Being able to intercept SSL traffic with an imported root certificate is not considered a weakness of the web application. It's a browser design decision to allow the import of custom local trust anchors.

  Does implementing the HSTS solving the problem I have?

No. A HTTP Strict Transport Security header just enforces HTTPS. HSTS doesn't care which certificate you use as long as it's valid. That is, with HSTS you won't be able to select "Add an exception" for an invalid certificate anymore. But when a certificate is trusted by an imported CA (like the Burp root certificate), HSTS doesn't make a difference.

  My problem is how we can prevent any interceptor analysing the HTTPS traffic even if someone installs the interceptor's certificate in the client browser?

You can't. If you locally import a trusted root certificate, a website can't instruct your browser to reject it anyways.

Note that there is also the HTTP Public Key Pinning (HPKP) header that a server can send to enforce a particular certificate chain. (This might be the concept you're after, rather than HSTS.) But even this header doesn't overrule local trusted root certificates. (E.g. Google, Facebook and Github all still load through the Burp proxy despite sending HPKP headers that would theoretically reject the Burp CA.)

From "What HPKP is but isn't":

  HPKP does not protect against local attacks, such as malware intercepting traffic. As long as the malware has the ability to get a root certificate installed on your machine, there’s nothing HPKP can do.

This is also explained in the Chromium Security FAQ:

  Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

So there is no common way to achieve what you want - are you sure you really need to block local root certificates? If a user installs the Burp certificate into their browser to intercept SSL traffic they made a conscious choice after all. Here's how the Chromium FAQ justifies that behavior:

  We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should.


Load balancer and two machines - how many SSL certificates do I need? We have a load balancer facing the Internet.

It's balancing load towards two systems behind it in the back-end running apache.

How many SSL certificates do I need to buy?
- One for the load-balancer only
- One for the load-balancer and for each server instance one (3 certs)+
- Only for the server instances (2 certs)
- The certificates can be re-used

Also, can I re-use the server certificate as a client certificate to make calls to other backends from the apache servers?

The point of a load-balancer is that all your servers appear to the client as one. So no matter where you handle the TLS (on the load-balancer or on the application servers), you will only need one certificate to ensure that no web browsers will show any HTTPS warnings.

When clients communicate only with the load-balancer (which handles TLS) and you control the network between the load-balancer and the backend servers, there is little reason to encrypt that connection too. But when you do not trust the network and want to use encryption between load-balancer and backend servers, you can use self-signed certificates for that. When you put the certificate on the servers yourself, you know they are trustworthy. So paying a 3rd party to sign them would be pretty superfluous.


Did I participate in the recent DDoS attacks on Dyn's DNS service? It was reported that the recent large scale DDoS attack affecting multiple websites in the US was done by hacking 10s of millions of devices and using them for the attack.

How can one in general know if ones devices were hacked and used in the/an attack?

Knowing after the fact can be a bit difficult if you are not actively monitoring your network traffic.  But there are some things you can do now to determine if you were at risk of being a participant and to mitigate against future participation.

As has been mentioned in a number of places, if your WAN router/bridge/cablemodem/firewall has uPnP turned on, you've definitely opened up your local network to risk.  You should turn this off.

For your various devices, if you've left the default administrator password set, you've left yourself open.  Change this.

Make sure the firmware on your devices is up to date and expect further updates to come out in the near future.

If you have devices that don't need to communicate on the Internet to "call home," then block them from doing such things; don't give them a default route, add firewall rules, etc.

By most accounts, CCTV (e.g. web cams) were the primary devices infected and utilized.  If you have such a device and a list of know offenders can be found here (https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/), you might consider taking some action.


Best appraoch to test inhouse firewall effectiveness We have Fortigate 100D that has antivirus profiles enabled like SMPT, POP3 and IMAP.
How one could make sure that the antivirus is working as expected ?
For instance it seems that Fortigate has already  signature for "Locky" malware but one of our PC was infected.
So what are best appraoch to test inhouse firewall effectiveness ?

Testing if the detection is configured properly can be done by using the EICAR test virus. This virus is harmless by itself but every malware detection should be able to detect it even if it has no current signatures.

Of course this will only tell you if the firewall is properly setup at all. It gives you no information about the effectiveness of the protection, i.e. how good it protects against existing malware and how fast it will catch up with new malware. No firewall is able to offer you full protection no matter what they claim because they need to catch up with new strains of malware too. To find out how fast the vendor reacts to new attacks you can not believe marketing claims but you have to ask others who've used the products or independent researchers.

Apart from that the analysis in such firewalls (UTM, NGFW...) can often be easily bypassed. Small modifications of the traffic are usually enough to make such firewalls blind. In case of web traffic you can verify marketing claims by using my HTTP evader test site with you browser (see these details for how it works). And while I don't have a similar automated analysis tool for SMTP, POP, IMAP etc yet I've did similar research for mails which also shows easy ways for bypassing analysis.