Can OpenSSL decrypt the encrypted signature in an Amazon Alexa request to a web service? OpenSSL newbie here.

We're using OpenSSL to parse and verify the certificate and signature that Amazon's Alexa sends to external web services, following their list of requirements in the instructions here.

We're successfully extracting the public key, checking the start/end dates of the certificate, verifying that echo-api.amazon.com is the subject of the certificate, and verifying the chain of trust (by using OpenSSL command line functions).

But we're stuck at the point where the Amazon documentation says to "Use the public key extracted from the signing certificate to decrypt the encrypted signature to produce the asserted hash value."

Is this possible with OpenSSL? The openssl "rsautl -decrypt" command is only for private keys (both the documentation and our tests confirm this, and public keys are rejected, even with the -pubin option).

Alternately, is there a way to get the openssl dgst -verify to work for the Alexa signature verification?

We're testing these commands:

openssl base64 -d -in (signature_file) -out /tmp/sign.sha256
openssl dgst -sha256 -verify (pub-key_file) -signature /tmp/sign.sha256 (file)

We've used ColdFusion's getHttpRequestData().headers["Signature"] function to get the signature:

lOtMJdnw8fffdJHkiM2I6m+K0IqkMCeAWJrjoYGVtkGEBYXUOUazKh6/rpM6opxni7YMHJkA6x5/eGGmWg++VP
0+2I/TNQjR9TTu1LVKikGyi9Oskk/od/tKzEhyWJ2noyyrybqRG1bTSLjVqc1RxDLLRbDuOs12s5F6E0bL18pG
EAww6iMKr2m212wrVzJ2pehp8wVMcqlegOaXW2iFlAunWwte7E/br4vdsYiAXZRLg2uVBDvjmpeo4b9GJZbZkE
HhV+/x+KOwXCISl+Ao0BTr/pzfuF4m/oWpX1PC91hwYMSiVn9I+a+VDxKVxSVllCrffIAIc9mETVuc9U0XRA==

And the Coldfusion GetHttpRequestData().content function returns the JSON structure sent to the web service:

{
   "version":"1.0",
   "session":{
      "new":true,
      "sessionId":"SessionId.29d1522f-6ea6-4aba-b782-f41890388569",
      "application":{
         "applicationId":"amzn1.ask.skill.63fd6ac5-ed2b-4324-995c-681f96f428a6"
      },
      "attributes":{

      },
      "user":{
         "userId":"amzn1.ask.account.AHURACZZDQ43ZMUVTOQBEGB5JMWOZCFJRFYXCO26O2IZ3JRS6HYKBOOXPEM6BNWLPUM2E6EWCDC4Q2DPFHXSE3EJT4BLL4CWDNDIFASIHIV2D4AJDH7MDICIFVMHK252EBVQOGFR2TH4HNGMMTPOHI5VGQD7O4UWPZOL2FQOGRCNMVUPUI3SC2R2EH5L5V6XD7B7IF544TYJJCA"
      }
   },
   "request":{
      "type":"IntentRequest",
      "requestId":"EdwRequestId.d8e9d467-b311-4d9c-8273-9ba0b1e07613",
      "timestamp":"2017-05-11T18:49:37Z",
      "locale":"en-US",
      "intent":{
         "name":"GetRssFeedHeadlines",
         "slots":{
            "RSSFeedLabel":{
               "name":"RSSFeedLabel",
               "value":"top news"
            }
         }
      }
   }
}

Here's the public key:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnK+zBruRA1TnbgQGxE+b
4XiTTZyDkGwJ6068AGsXQmgt9lVhC8CTTC4wdR5NXosboV6/63worQCNo412csBV
jUy3H1/VEs+5Kv+AiAOUuKoBfEU8zAvHCc7GmOKUgNidcDA0MSpx3ZTMSGGbkfaL
ikRzne6nFZ6jNOnkqTtGD6SrCIYgLNArScYoPzIcXEypHFrognzrR4Ee0YcefGZy
S81Yqev/lli01dAgRvpnAty68rYTmxkNhzUSG6IIbFHIxXJKAETAkGiKJcgZpfG2
1Ok5Dk3yGrESY/ID5OnxvMxiXSnXwht8JD6bd15ui0tPDa85B0jpZLloqQZe26oR
owIDAQAB
-----END PUBLIC KEY-----

But the openssl dgst always returns a message of "Verification Failed" when we use the openssl dgst -verify with files containing the signature (trying raw and Base64-decoded) and http request body (listed above).

Any guidance would be much appreciated!

First, Amazon and you are repeating a common but wrong trope; signature is not encryption with the private key -- not even for RSA, where there is enough similarity in the mathematical underpinning that it is dangerously appealing to think this even though there are vital differences in the actual schemes and trying to interchange them leads to very bad results, and totally completely not at all for other algorithms like DSA and ECDSA. See:
Trying to understand RSA and it's terminology?
Is encrypting data with a private key dangerous?
If the public key can't be used for decrypting something encrypted by the private key, then how do digital signatures work?
Understanding digitial certifications
Digital Signature and Verification?
With GPG, can you "decrypt" a file that hasn’t been encrypted?
Why should I sign data that's already encrypted?
Is encrypting data with a private key dangerous?
Does RSA encryption always pad small amounts of data to some larger size?
Encrypt with private and decrypt with public
https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-the-same-as-signature-
https://crypto.stackexchange.com/questions/13107/symmetric-encryption-is-no-longer-necessary
https://crypto.stackexchange.com/questions/2123/rsa-encryption-with-private-key-and-decryption-with-a-public-key
https://crypto.stackexchange.com/questions/66148/digital-signature
https://crypto.stackexchange.com/questions/43894/asymmetry-between-public-key-and-private-key-
https://crypto.stackexchange.com/questions/55404/if-a-private-key-decrypts-what-its-public-key-encrypts-can-the-public-key-conve
(some of which I admit are hard to find unless you know what you are looking for).
That said, openssl rsautl can recover the signed (and padded) encoded hash from a signature using the -verify option, and the newer pkeyutl with (clearer) -verifyrecover; given your de-base64-ed signature in temp.sig and your publickey in temp.key:
$ openssl rsautl -verify -pubin -inkey temp.key <temp.sig |openssl asn1parse -inform der
    0:d=0  hl=2 l=  33 cons: SEQUENCE
    2:d=1  hl=2 l=   9 cons: SEQUENCE
    4:d=2  hl=2 l=   5 prim: OBJECT            :sha1
   11:d=2  hl=2 l=   0 prim: NULL
   13:d=1  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:AE2F2DD493F3E58F62E9F20678D9A05B86E06F8A

Observe this is a SHA-1 hash, as stated on the Amazon page you link, not SHA-256, and does match the SHA-1 hash of your data -- from edit 3 or earlier, before Anders added spaces and newlines which makes the signature fail because the entire point of digital signature is to detect and reject any change to the signed data:
 $ openssl sha1 <temp.dat
 (stdin)= ae2f2dd493f3e58f62e9f20678d9a05b86e06f8a

and thus can be verified with dgst -verify
 $ openssl sha1 <temp.dat -verify temp.key -signature temp.sig
 Verified OK


Does UNIX have a dual approval mechanism? Sudo and logging is used to keep administrators accountable. But is there a command/configuration that lets you enforce a dual approval type control such as the the "Two Person Concept"? (eg. Two authorised individuals are required to launch an nuclear weapon.)

Sudo can be set up to log actions performed by administrators but this is only a detective control. How could you implement a preventative control that enforces the appropriateness of the command being executed?

One method which I have seen used: split the password. This was for SSH access to a sensitive server: a number of SSH keys were created, and marked as "authorized" on the server. Each private key was protected with a long passphrase, and every user knew only one half of the passphrase.

That's crude but effective as long as there are not too many administrators. For N "dual control" administrators, you need N(N+1)/2 such keys (e.g. 55 keys if you have 10 administrators), which is usually acceptable. Each administrator needs only remember one "half-passphrase". The same concept can be extended to sudo by setting N(N+1)/2 specific accounts (e.g. admin Bob and admin Dave type sudo -u bob_dave thecommand and account bob_dave is part of the relevant group, or maybe is given UID 0 so as to be an alias on root).

Dual control is preventative in the following sense: the attacker must bribe two admins instead of one (which means that it will cost him twice as much in pints of Guinness).


Alternative to using Refresh Tokens? I've been learning about OAuth2, JWT tokens, and refresh tokens.

My understanding of this is:

A user logs in using their credentials.
They are given back an access token (short-lived) and a refresh token (long-lived).
Any requests to API resources uses the access token.
When the access token expires, the refresh token is used to get another one. This avoids the need for the user to re-enter their credentials, while at the same time giving a mechanism to revoke access.
Because of the way it is signed, the access token (JWT) is tamper-proof and can include any claims. Typically tokens are all signed with the same key regardless of the user, which means that you can't boot a compromised user based on access token alone without changing the key and kicking out everyone else.

Given all this, is there anything wrong with simplifying the process as follows?

Store an access token for each user in the database, along with a key used for signing (per user).
When the client sends a token to the server, it includes a header (or similar) with the user id (or a representation of it). This is so that the server can identify the user without decrypting the token first.
The server fetches the key for that user (using the provided id) and decrypts the token with it. If the user id from step 2 has been tampered with, token decryption will fail.
When an access token is compromised, it can be deleted entirely or its related secret changed.
Access tokens can thus be long-lived and there is no need for refresh tokens.

The added effort to store these access tokens in the database is about the same as for storing refresh tokens. The benefit is that the flow is simplified to one authorization mechanism rather than two.

Storing a whitelist of access tokens in a database is a great way to perform access token revocation; if it's not in the DB, don't accept the token. However, this undermines one of the main advantages of JWTs: being able to verify tokens without having to access to a centralised DB. Usually, the short lifespan of access tokens is considered a good enough safeguard to make revocation of access tokens unnecessary. Refresh tokens can be revoked though (by disallowing a particular user from generating more access tokens).

Storing a unique key pair per user is not a great idea. They use much more storage than tokens and therefore take longer to read and write, and are time-consuming and CPU-intensive to generate. It also achieves little in the way of security.

Frequent key rotation is a better idea. Multiple signing keys can be in use simultaneously, with the key identified by either the 'kid' or 'x5t' claim in the JWT header.


The basics of cryptanalysis There are a lot of books on encryption. Is there a must read intro, something like Smashing the Stack for Fun and for profit, that more or less everyone reads?

Historically, there's no computer, let alone Python code. Encryption systems have been designed and attacked and improved since many centuries before the invention of electricity. Also, only the most basic, weakest, puniest forms of encryption can be described as "unordered data".

The really must-read introduction on cryptography and decryption is this classic text. It is free (in all meanings). French speakers may want to read this remarkable translation. This simple text is quite entertaining, extremely well written, and will plant the right ideas in the reader's mind.

Afterwards, find an introductory book. I have read that one; it is not bad. Cheap pocket editions exist, and you may find it in many libraries too. Further exploration of the subject will entail doing some maths (not very complex maths, but a lot of maths). A very good resource for that advanced stage is the Handbook of Applied Cryptography, which is quite thorough, precise, full of references, and can be downloaded for free.


How to use metasploit java exploit with custom payload? I've been testing Java metasploit exploits on my VMs for some college assignment. I tested exploit/multi/browser/java_atomicreferencearray and it works great but with one of metasploits payloads from show payloads list.

I want to set my exe located on attackers machine to run when exploit executes, but can't seem to make it work. Can anyone guide me through this.

Thanks.

You may want to
disable the payload handler
set payload to custom_exe
and
set custom::exe /custome.exe

This should get it done. You also have to keep in mind that the depending on what the exploit is doing, and how much memory space is is using, or rather how much memory space you have to execute shellcode, you may not be able to use a custom exe with this exploit.

let me know what happens.


System image that does not allow for recovery of deleted files? We are working with an contractor regarding a compromised computer. The contractor has asked for a dd dump of the drive. However, my understanding is that dd would allow the contractor to recover deleted files.

How could I produce an image that would be bootable / forensically useful, but not allow for recovery of deleted files?

An image created with the dd command would allow for recovery of deleted files.
A bit-for-bit copy (dd style) is the only way you'll get something that is likely the only forensically useful approach for law enforcement / court.

While there are ways to compact all the files on a system and copy over / update the boot record, this is not forensic. The only valid forensic approach is to copy everything exactly as it is and preserve that. You may be able to copy everything and then zero out all unallocated space (freespace wipe), but that might limit your ability to use it for anything other than trying to find out what happened. Even then it will limit your ability to discover certain types of attacks.

If your goal is to seek criminal or civil action, you have an uphill battle to show that any kind of modification to the system state is appropriate for evidence in any jurisdiction. From an expert witnesses position for the opposing side, I'd rain hell all over it. This is akin to cleaning the walls before investigating a murder scene.


Building an VM with Vagrant and connecting with ssh+2FA to protect a bitcoin wallet? I would like to try to build a Virtualbox image to use with Vagrant. This is the features:

Login with SSH + 2FA (Google Auth)
No X
No internet connection
Copy unsigned transaction, sign it and broadcast from the external host
(Possible with the use of "Synced Folders")

What worries me is:

If the image was to be stolen and the hacker could mount the image and access my wallet that way, would the solution be to encrypt something?

I really like the combination of "something I know" and "something I have", but could it work for a VM also?

Authentication is about making sure that the peer (say, a connecting client) is who they claim to be; this is the normal first step which enables authorization, i.e. the process of deciding whether the access ought to be granted or not. The important point is that such a thing makes sense only when there is a system which acts as gatekeeper for an important service, e.g. the system contains sensitive data.

A VM image, that the attacker might possibly steal a copy of, is not such a system. By definition, an attacker who steals an image of a VM can inspect it at will, booting it up, seeing its file, reading its memory, and so on. To make an analogy, imagine the VM as a city; the SSH and 2FA and whatsnot is a big fortified wall encircling the city, with sturdy doors and dozens of guards armed with swords and pikes; they will grant access only to people who know the passcode and are vouched for by a citizen. For the attacker, stealing the VM is like having some choppers and landing a few platoons of marines on the city central plaza; the efficiency of the wall and the guards against such a scenario is, at best, questionable.

So yeah, against an attacker who can read all the stored data (that's what happens with a stolen VM image) you need confidentiality, and that calls for encryption. You can actually forget this VM business and SSH; for the security you want, it totally misses the point.


Disposable mail for anonymity Initially asked in bitcoin, I wanted to know how is it supposed to be used for anonymity. I mean that I need to register wallets and buy bitcoins. For anonimity, guitedlines recommend to use disposable mail. How is that? Isn't disposable mail features public exposure of your communication and possible loss of information since I do not control the mail clean up? How can this enforce my anonymity and security? What is exact step-by-step procedure implied?

Anonymity from whom? Governments, or the average person you are making bitcoin exchanges with. These two differ widly. In the first (govs), anonymity is a bit more difficult since most people don't focus much on operational security (OPSEC) so little is thought about weaving together an alter ego. This means, most people are under the impression that they could use a proxy here, proxy there, maybe log in from Starbucks or some other coffee shop, and they're anonymous. The reality is, it all depends on what one does with this "pseudo" anonymity.

For the latter (making exchanges), where you would want to stay "pseudo" anonymous, a throwaway e-mail is sufficient. The average person is not going to get logfiles from service providers telling them who signed into a particular e-mail account, from what IP address. Even if they did, they would need to go to the ISP to figure out who the IP was allocated to. This becomes complicated.

Free mail... You get what you pay for. While I believe most e-mail service providers perform their due diligence in protecting your privacy, you need to remember they are all bound by laws. So if you intend on breaking any laws via way of bitcoin, anonymity is close to non existent without operational security.

TECHNICAL RESPONSES NOW Because my answer seems more to the tune of something which should be on a shady forum, I will talk about the technical sides of finding individuals. Using an example forensics/incident response case...

Someone registered a site, then used one of those domain proxies to hide their identity. This particular site was hosting information stolen from machines. My goal was to determine WHO owned the site, so I proceeded to go backwards using Archive.org. I viewed the site when it was created 5,6,7-10 years ago. In the 2nd year it was created, the website owner had one of those generic counters, tied to a username. From the username, I was able to piece together who owned the site. This is what I mean by operational security. Things have to be planned well thought, with an emphasis on keeping one's identity not only secret, but with attention deflected elsewhere for anonymity.


List of web session attacks and counter measures I'm writing a new website in PHP and I will be using cookies to track user session data. Before I finalize the design, I want to make sure that the site is not vulnerable to attacks. I have written a list of attack methods and came up with countermeasures for each one. Can anyone think of any more attack methods and if so also propose suitable counter measures?

A list of all attack methods I could think of:

Guess/bruteforce session cookie
Steal session cookie (e.g. if the attacker saves the session cookie to USB)
Cross-site scripting
Phishing (session fixation)
SQL injection
HTTP header injection

It should be noted that I will be using my own database to store session info - not the PHP standard session functions. When I detect an attack I will run a function called warn_and_halt() which will log the attack and inform the sysadmin, then halt the session under attack.

My countermeasures for each of the above attack types are:

Rather than using a large integer for the session ID stored in the cookie, I will generate my own random number and then hash it with something like SHA-1 to make it a little harder to guess. Of course the session ID may not be unique if created this way, so I will have to check all of the other session IDs in the database and regenerate if the newly generated session ID already exists. I am confident with this measure.
I am assuming the USB will be taken to another computer and the session cookie loaded into another browser. I will be logging the user agent (browser name) for each session. If the user agent changes during the session then I will warn_and_halt(). I have read of people using the IP address to validate the session ID, but I don't think I will be using this at all since IP addresses can change during a session for completely innocent reasons - for example if the user's router resets and negotiates a new IP with their ISP. Can anyone suggest more countermeasures here?
I will set the session cookie as HTTPonly and also check the domain of incoming cookies. There is not much of what can be done to prevent that happening on a browser in my view - the browser may choose not to comply with the HTTPonly flag - nothing I can do there! Does anyone know a better way to prevent XSS?
I envisage phishing to happen by user "bad" logging into my site, then emailing a link such as <a href='javascript:void(0);' onclick="document.cookie='sessionid=xxxx';document.location='http://mywebsite/'"> to user "oblivious". This will set a session cookie without "oblivious" knowing it. Then "oblivious" will enter their personal information and user "bad" has this info! I think most browsers will not allow the domain of the new cookie to be set as mywebsite, so "oblivious" is pretty safe. Nevertheless, I will be checking the incoming domain of each cookie to make sure it is for my website. I will definitely use cookies, rather than GET or POST to store the session ID. Also, I will counter session fixation by changing the session ID for every page visited.
SQL injection is a problem with much larger scope than stealing session IDs, but I will be countering it in general by always escaping the incoming data (including from cookies) and by filtering out any wrong characters with regex. I think I have this one pretty well covered.
I just learned about HTTP header injection. Nevertheless, it seems pretty easy to counter - just escape the incoming header fields - especially for carriage returns and validate incoming headers.

So those are all of the attacks and countermeasures I could think of (after a fair bit of reading online). If you see any that I have missed, please respond. If you see that any of my countermeasures is insufficient, please tell.

You asked: "does anyone know of a better way to prevent xss?"

The best way to prevent XSS is to educate yourself about XSS, and avoid introducing XSS vulnerabilities into your code.  Start by reading the following document:

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

(See also PHP functions for preventing XSS.)

Next, I recommend that you read about web security.  Start by reading the following introductions to web security for developers:

An excellent overview for developers -- this should be a must-read for every programmer doing web development.
Web security tutorials at Google Code University

That will help you avoid XSS.  There are many more resources on the web and on this site; take a look.

Note: The HTTPonly flag does not prevent XSS.  Also, contrary to popular belief, it provides little additional security: if your web site contains a XSS vulnerability, then it will often still be possible for an attacker to do bad things to the user.  The HTTPonly flag makes the attacker work harder, but in the end, you should assume that a sophisticated attacker will probably still get just as far.  Now I'm not arguing against HTTPonly.  The HTTPonly flag is a fine idea, if it doesn't break site functionality. But you should not rely upon it as a defense against XSS.  It is a particular porous defense.


Do I Have A Virus (and What To Do)? Background: Windows 8, not a special edition.  Windows Defender and Webroot are both installed and have been installed for over a month.  Yesterday I got a weird error that I've never seen before that Windows Defender couldn't load because "some other antivirus" was installed.  I had never seen this error before or experienced this issue and unfortunately the solutions I've searched for don't work to resolve it.

Odd behavior: I get an alert in the messaging center that suddenly virus protection is turned off - both Webroot and Windows Defender.  Now, every time I start my computer, Webroot will launch, but will be unable to scan the system (the scanner loads, but scans 0 files).  Note that this is all happening while I am not connected to the internet, which I default don't connect to the internet.  Cisco's VPN client begin loading multiple times and tries logging in; this is not set as default to load, so I have no idea why this is suddenly loading.  I uninstall the app.  Next I all of the sudden see this begin to appear in Task Manager, and after a restart see it again:

Service Host: Local System (16)
-Microsoft Account Sign-in Assistant
-Windows Management Instrumentation
-Themes
-Shell Hardware Detection
-Remote Desktop Configuration
-System Event Notification Service
-Task Scheduler
-User Profile Service
-Multimedia Class Scheduler
-Server
-IP Helper
-Group Policy Client
-Device Setup Manager
-Certificate Propagation
-Background Intelligent Transfer Service
-Application Information

Remember, I'm not connected to the internet at this point, yet my computer is acting as if I am.  In addition, it's very slow, even though I'm doing very little as far as application usage.  Note that when I terminated some of the services listed above this, like Remote Desktop Configuration (I don't recall seeing this before this week), it starts a whole new Service Host: Local System (16).

The problem is after a restart twice, Webroot will load, but still can't scan.  After ten minutes, it still has the scanning page loaded, but can't scan any files.  I don't know how much I can even trust Webroot, especially since the Windows messaging center will state later that Webroot is turned off (I didn't do this, so how did this happen).

Remember that I am not connecting to the internet at all while all of this is happening.  What is going on and what can I do?

UPDATE

Running netstat -ano, I get quite a few TCP connections and UDP connections (internet is disabled).  Most of these are 0.0.0.0 with various ports, like 135, 445, 27019, 49152-7.  Some have 127.0.0.1 and the remaining six have [::] and then a port.

The UDP's, which are peculiar when I run further details with netstat =a -p UDP -b show sqlbrower.exe, and SSDPSRV (svchost.exe) twice.

Short answer:

Your best option is to simply start over.  If have a backup/restore point saved where you are absolutely certain there is no malware, you can try that, but many viruses these days will disable backup/restore.  In that case, reinstall your operating system (you may want to do that anyway just to be certain).  Once that's done, get a better antivirus such as Avast! (free) or ESET (if you're willing to spend money).

Long answer:

If you want to triage the malware, the first thing you should do is double check that you are not connected to anything.  It could be possible that the malware turned on your internet connection.  Run cmd and type in netstat -ano and see if you have any established connections to foreign hosts.

The next thing you should do is download Sysinternals and Wireshark if you don't already have them. Since you aren't connected to the internet, your best bet is to probably download them on to a thumb drive on a different computer and bring them over.  You will want to format that thumb drive before you plug it into another computer though when you are done.

Once you have that, run Wireshark and look for any network activity coming to or from your computer.  Since you aren't connected, you'll probably see nothing, but it's an easy step and will put a spotlight on what the virus is doing if it works.

For details on using Sysinternals for detecting malware, watch this video: https://www.youtube.com/watch?v=80vfTA9LrBM

The video basically says to use Procexp to identify any binares that are out of place, and use Autoruns to see if any of your Registry entries have been modified to start an executable that shouldn't be there.  Use Procmon to get a step-by-step list of what all of your processes are doing (such as in your case, starting RDP).

But at the end of all of this, you will still want to remove the virus (referring to my short answer).

I hope this helps, and good luck!


How do websites protect against 2fa replay attacks? I'm imagining a scenario where an attacker can read traffic between a user and a server. The attacker grabs the user's password and the 2fa code they used. The attacker then logs in with that information before the 2fa code expires.

How is this protected against?

You can black list reuse. Simply save time (or code) of previous login, and force the user to wait until new OTP is generated. Generally TOTP tokens are updated every thirty seconds.

You can use counter based OTP; re-use will never occur as both devices increment the counter.


Can FB messenger video calls be intercepted? My friend had a video call conversation through FB messenger. Both parties used malware free Android version 4.1. One used a personal wifi (WPA2 secured) and the other used 3g globe telecom data (LTE). What is the probability that someone could sniff or intercept?  Is Facebook recording the conversation?

All the communications done over Facebook Messenger are encrypted but that does not mean that one cannot sniff the packets. One can easily sniff the packets but the bad guy won't get to know anything as everything will be encrypted (unless the encryption is broken).

As far as Facebook recording the conversation is concerned, it's a complete NO for that. Facebook only keeps the logs of the when the conversation happened, with whom and duration.

You can also read their Messenger policy for more info.


Worthy security related certifications for a software engineer I am a software engineer with an interest in expanding my knowledge in the security field.

In addition to security.stackexchange and OWASP, I am currently reading the book "The web application hacker's handbook".

My question is; based on your experience(s) what are worthy security certifications for a software engineer to pursue? (certifications where you learn a good deal and that could be  in high demand by employers in the near future).

Have you checked out SANS?  They are an excellent training and certification resource and have some software developer certifications.  Check out them out here: http://www.giac.org/certifications/software-security


Physical mechanical examples of "M-of-N" locks? Arbitrary "M-of-N" secret-sharing protocols are a well-studied topic in cryptography, and are apparently so useful that Bitcoin Script devoted a whole opcode to them.
In this blog post, I write:

Suppose we run a bank, and suppose that our bank stores all its gold in one big safe. And suppose that we have three people on our board of directors. We want to ensure that a single unscrupulous director cannot open the safe and steal all the gold. Therefore, we cut three distinct keys, and we craft the safe so that it requires two of these three keys to be inserted simultaneously, in order to open the safe.
Fans of Sean Connery might recognize this as more or less the setup to The Great Train Robbery, except for our “two out of three” requirement. I have not been able to discover any real-world mechanical analogue to the “two-out-of-three” mechanism.

So I ask you!
There is certainly an easy way to construct an "N-of-N" locking mechanism, such that you can get the safe open only when all N keys are inserted. (You just stack the locks vertically down the door, and make sure any single bolt by itself is strong enough to keep the door shut.) "2-of-2" mechanisms are used in bank safety deposit boxes.
I imagine it isn't hard to construct a "1-of-N" locking mechanism, along the lines of the Borromean rings, but I haven't found any such mechanisms patented or for sale.
I have not found any references to "M-of-N" locking mechanisms in the real world, nor can I immediately imagine how to construct one (except the brute-force method of obtaining N-choose-M different key safes, each protected by an M-of-M mechanism). Has any inventor ever designed such a physical mechanism? Does any real-world use-case exist for such a mechanism?

There are real-world multi-key locks made for this purpose. The most common have two separate cores that are internally geared to turn together, which require both keys be present and turned simultaneously.

Other designs have a single key way and require the two different keys be inserted sequentially. Here’s an explanation on using the latter: https://anemo.eu/how-do-dual-key-locks-work  This tubular lock requires each key be turned a quarter turn each. Internally, this might be done by boring a groove linking one pin’s hole to span the first quarter turn, ignored by the first key; then boring a different pin’s hole spanning the next quarter turn, which will be ignored by the second key; the rest of the pins would match. The keys would have to be used in order to unlock it, and relocked in reverse order.

Neither of these designs inherently solves the m of n problem where m < n. That can be solved with a standard industrial lock-out hasp with n physical padlocks.  Each key holder is then given a unique subset of physical keys to open one share’s worth of padlocks, using a secret sharing scheme.  Note that this approach does not scale well in the physical world, as the number of padlocks and keys grows exponentially with n.


Security benefits of Single Sign-On What are the benefits of a single sign-on implementation from the point of view of security?

From my point of view, if the account is compromised the attacker has access to any resource, so according to this, SSO is far from secure.

I can see three main benefits.

Reduce the amount of passwords users have to remember. Users are encouraged to use vastly different passwords for different sites. Managing that many different passwords can be problematic. Obviously this isn't an issue if the user uses a password manager tool but let's be realistic, how many users can you expect to do that? A SSO solution can greatly reduce the number of passwords a user has to remember, which might encourage the user to choose a much stronger password.
Provides convenience to the users. A SSO solution literally means the user has to sign on just one single time to access multiple services. This is a huge timesaver especially if a company provides multiple services. A good example of this would be Google. While this might not strictly be accurate, I have a feeling that by reducing the number of times a user has to enter his credentials, the risk of an attacker intercepting the credentials through something like a keylogger will be reduced.
Reduce the headache of assisting users with password recovery. Imagine a company running ten different services. A SSO solution can greatly reduce the amount of helpdesk manpower needed as users only need to recover a single account. Whilst not a security concern, this is a very tangible benefit to companies.

Of course, a SSO solution concentrates a lot of power on the authentication solution. One should probably spend a lot more time and effort securing that single point of failure.


Can letting anyone create Dockerfiles result in RCE? I'm about to build a web service that can be notified by Git that a push to a particular branch happened. Once this is done, the branch is checked out and docker build -t somename . happens. Is it secure or am I basically letting anyone run arbitrary commands as root on this server?

Your concern is indeed appropriate. The attacker can share system resources with his attack container as it is a Dockerfile you provide him and not just a Docker container. The build command of the Dockerfile can mount any part of the server filesystem and access any port available to the server. Not a good plan.


Are any TLS attacks practical for an attacker who can only observe traffic? A number of TLS vulnerabilities are listed by Wikipedia, including attacks with brand names such as FREAK, DROWN, CRIME, BREACH, and POODLE. My lay reading of their description makes me think these vulnerabilities are reliant on an attacker being able to either 1) influence a victim's browser's behaviour, or 2) occupy a man-in-the-middle position on the network and actively manipulate traffic.
Are there any TLS vulnerabilities which can be exploited using only passive observation of traffic, and which are practical enough to be a concern for ordinary systems administrators?
Some definitions:

By "practical" I mean not reliant on a theoretical mathematical breakthrough, or on excessive compute resources or time (say, no more than $100,000 worth of commodity x86 server could do if working on its hypothetical decryption algorithm for a year).

By "ordinary systems administrators" I mean someone working at a Fortune 500 corporation wanting to protect innocuous customer data, not a nation state agency protecting ultra-secret launch codes.

There are no practical feasible attacks for a purely passive attacker with severely limited resources (i.e. no government or similar) against currently used TLS standards (TLS 1.2 and better, but even TLS 1.0 is still sufficient).  This does not mean though that specific implementations of these standards might be a problem, for example due to bugs or deliberately weakened or backdoored random generators. Though at the moment there are no publicly known cases for such weaknesses.


Postgres password security How safe is a Postgres user's password?

When a new db user is created, is the stored password hashed and salted?

Postgres uses MD5 as algorithm with the username as "salt".

Using a salt normally prevents computation of hashes, for example in rainbow tables. Using the username as salt only partially covers this problem. It is possible to precompute hashes for common usernames, such as "root" or "postgres".

Furthermore, MD5 is one of the fastest cryptographic hashes there is. It is possible to calculate 10¹¹ MD5 hashes per second. This makes it possible to crack the passwords using a brute-force attack, i.e. trying many passwords. Modern password hashing functions are designed to be slow, so that a brute-force attack takes a long time.

In my opinion the Postgres password storage technique does not conform to modern security standards. You can mitigate this by using a long, random password and not reusing that password anywhere else.


Is there any recommended Java library for penetration testing? Does anyone have any recommendations for a good Java library which can be used for penetration testing?

I once read about a library which I think was called 'Attack lib' but I can't find it anymore.

EDIT:
This library should have easy ways to make many HTTP requests, parsing / grep'ing HTML / XML / JSON (and maybe more?).

I know Burp Suite has an interface you can code against, but this is not exactly what I'm looking for.

I'm tempted to just start writing my own library, but I'm sure there are many people who already have a library for pen testing already laying around :)

I think this is what you need: http://watij.com/. As written on their site:

  Watij (pronounced wattage) stands for Web Application Testing in Java. Watij is a Java API created to allow for the automation of web applications. Inspired by the simplicity of Watir and enhanced by the power of Java, Watij automates functional testing of web applications through real web browsers.

Hope that helps.


SVC service page on production I am testing web service on production.
There is a standard SVC web page available like the example below (another randomly selected webpage, just for example). Is it ok to have this page available on the production environment?

The Web Services Definition Language (WSDL) provides all details necessary for binding to the service and is considered an information disclosure finding when the target of a pen test. While the following is dated, they still hold true today.

The following was taken from a Black Hat Europe 2007.

  WSDL Enumeration

  As with any other web application attack, the first step in formulating an attack on a web service is discovery and fingerprinting of the service deployment. The information gathered at this first stage is crucial to identifying possible entry points and carrying out an attack that is directed at the heart of the web service.

  Luckily for today's hackers, web services are often deployed with what many refer to as a 'blueprint for attack'. The WSDL file is a web services deployment descriptor that outlines not only the functionality provided by the web service, but also the expected syntax, the input and output points, and the location to access the service. In other words, the web service is announcing to the world its location, the methods it provides and assumptions it is making regarding its input points -- a goldmine for anyone with malicious intent.

  Source: Web Services Vulnerabilities by Nishchal Bhalla and Sahba Kazerooni (published February 15, 2007)

This snippet was taken from OWASP Europe Conference, Leuven, Belgium, May 30-31, 2006.

  WSDL and Access Scanning

  A WSDL document contains information pertaining to the Web service such as available operations, the content of the messages each of these operations accept and return, and the endpoints that are available to invoke the operations. Securing a Web service should rely on cryptographic measures to fully protect information rather than obscurity (security by obscurity should be avoided), because the information that a WSDL provides can expose certain architectural aspects about the Web service that could make it easier for an unauthorized user to mount an attack.

  For example, attackers can determine valid request formats by examining the schemas and message descriptions in the WSDL that can contain operations such as getItemByTitle, getItemById, placeOrder, getPendingOrders, etc. Knowing this information, the attacker may be able to guess other possibly hidden operations such as updateItem, and perhaps use this information to place items on sale and then place orders using newly discounted prices. In fact, it is easy for a developer to introduce such vulnerabilities to
  a Web service since WSDLs are mostly generated automatically and contain a full description of the available operations. Developers may later comment out the operation section to hide it the service, but leave related information such as the message descriptions and schema types of these operations intact.

  Source: Securing Web Services by Rix Groenboom and Rami Jaamour (published May 30-31, 2006)

The only thing I would add is that public and private services should be handled differently.

Public Service - If the WSDL describes only publicly accessible content and the service is publicly accessible, there's no risk having it remain public.
Private Service - A service requiring authentication/authorization of any kind should have it's WSDL protected in a similar manner.


How do I compare the safety of a compiled program with optimization flag? I would like to know how I can know which is the safest compilation line, that is:
Having several compilation lines in, for example, GCC, how do I know which one is more secure? Hardening would be a good solution? What do you recommend?
Does the compilation optimizations flags affect security?

Compiler options can influence the security of the resulting program in several different ways. Generally speaking, optimization can hurt security. However, this is not a reason to always turn off optimizations! For example, if your encryption code is so slow that users disable the encryption feature and send data around in cleartext, that makes security worse.
Undefined behavior
Low-level languages such as C and C++ have a lot of areas with undefined behavior. "Undefined behavior" means that anything can happen, and compilers take advantage of this to optimize code.
There a strong disconnect between the way typical developers see code and the way compilers see code. Often, what looks like an obvious optimization to a developer is hard for a compiler to detect, while compilers may perform optimizations that seem to the developer like it's exploiting a loophole.
A classic example is that optimizing compilers will eliminate redundant checks. Sounds good, right?
if (config == NULL) return ERROR_BAD_CONFIGURATION;
… // code that doesn't modify config
if (config != NULL) x = config->value;

An optimizing compiler is likely to compile that last line as if it had read x = config->value since it knows that config cannot be null at this point. Now consider this:
int *p = &config->value;
if (config == NULL) return ERROR_BAD_CONFIGURATION;
…
x = *p;

config->value promises that config is non-null at this point. Therefore the check config == NULL below is redundant and an optimizing compiler is likely to remove it. So, if config is null at runtime, x gets set to a value that's read from an invalid address, leading to a crash or worse. This is an example where an optimizing compiler makes incorrect code insecure, whereas a non-optimizing compiler would let the program get away with being incorrect.
Turning off optimization usually leads to fewer such surprising effects, but it is not a guarantee. The fix for such "optimization-induced bugs" is to write correct code in the first place, rather than hope that the compiler will figure out the intent of the programmer.
Undefined behavior is not limited to low-level languages. In particular, regardless of the language, concurrency inherently has some undefined behavior, because the order in which things happen is not determined. Race conditions can happen in any language (even without built-in support for concurrency, it can happen via communication between programs). Compiler options usually have little influence there.
Side channels
Some vulnerabilities exploit direct ways of accessing information, for example a missing permission check or a buffer overread. Other vulnerabilities are due to indirect ways of accessing information: side channels. A common side channel is timing, including the timing of indirect events.
For example, on a typical high-end system such as a personal computer or smartphone, the operating system protects programs from accessing each others' memory. However a program may still be able to deduce information from the way other programs behave. In particular, by measuring the timing of memory accesses, an attacker program can deduce which cache lines a victim program is accessing, and this provides information about which addresses the victim accesses in memory. For example, the easy and fast way to implement the popular cryptographic algorithm AES uses look-up tables; if the attacker knows which row of the table the victim is accessing, that can allow the attacker to reconstruct the key.
Programs can be written in a defensive way to avoid leaking information in such ways. This is sometimes difficult when optimizing compilers turn code without obvious leaks into executable code that does have leaks, because the compiler has determined that the program would be faster that way. In this case, an optimizing compiler can make even correct code insecure.
Compiler bugs
Compiler bugs are uncommon, much less common than bugs in some random application. Any decent developer knows that if the program doesn't work, a bug in their own code is much, much, much more likely than a compiler bug. Nonetheless, compiler bugs can happen. The higher the optimization level, the higher the risk of bugs. Most code doesn't benefit from the highest optimization levels anyway: usually -O or -O2 is a good compromise between performance and risk.
Safety features
Some safety features are partly under the control of the compiler. There, the obvious thing to look for is whether these safety features are enabled. These safety features generally don't help to defend against vulnerabilities, but they can make exploits harder. They often don't make exploits completely impossible, but they can make a difference between taking 5 minutes and 5 weeks to craft an exploit, and that can give the developer the time to develop and deploy a patch.
For example, many compilers can generate stack canaries. Stack canaries detect when a buffer overflow happens on the stack and halt the program. To exploit a stack buffer overflow, the attacker needs to limit the size of the overflow so that the canary isn't overwritten or arrange for the correct value to be written in the canary's place, neither of which are always possible or easy.


How did Wanna Cry get past Antivirus Programs For those who had windows computers when the WannaCry virus hit, how exactly did the virus bypass antivirus programs. I have tried to read some papers about this, but I don't understand how exactly that windows hole helped the virus evade antivirus software. Is this just a matter of people not having antivirus software, or did this virus somehow evade that?

Antivirus software usually detect malware threats in two ways:

signature-based detection
heuristic detection

Antivirus software products did not have a virus definition or signature for WannaCry since it had not been seen before (previously undetected threat) being a newly created malware. So it escaped all signature based detection.

Heuristic detection relies upon observing active execution of a binary. For example, if an antivirus observes a virus scanning for and modifying or appending executables on a system, it would flag the binary as possible malware or suspicious. The way WannaCry works is by accessing specific crypto libraries on Windows (for the process of generating keys and subsequent encryption) and then scanning for common document file types such as DOCX, XLSX, JPG etc to encrypt. The antivirus heuristics engine fails to detect this as a typical malware infection. They will possibly add heuristic capabilities to stop ransomware as it is executing by observing its behavior some time in the near future. For example: https://www.wired.com/story/shieldfs-ransomware-protection-tool/

Also, as you mentioned, it is possible that a lot of users who got hit were not using a properly updated and effective Antivirus solution. If they were big on updating software, they would have updated their Windows OS and had a patch for MS17-010 Eternal Blue vulnerability.


Web service HMAC authentication/anti-replay I am creating a web service, which handles various requests from web clients. The client and server share a big secret key S, and when one part wants to send data, it calculates the token as follows:

T = HMAC(HTTP body || Request Timestamp, S)

So when a part receives http request it recalculates T from the http body, and the timestamp from the Date http header field, and compares it, with the HMAC digest it received. If the digests are equal AND the time offset of the timestamp and the time the request was received is lower than a specified threshold grant the request. Else deny it.

Is this secure? Assuming that the attacker cannot forge the Date header since it is protected from the HMAC, plus the time limit offset(for replay protection), i think it is ok.

Assuming, that the above protocol has no flaws, how long should i set, the valid threshold offset? Say for example 5 seconds is ok?

If you do your protocol over plain HTTP, then attackers meddling with the communication may drop, duplicate or reorder requests, within your time frame. They may also send to the client (respectively the server) some of its own requests as if they were responses from the server -- depending on your protocol, this may or may not be a problem, but it could be devastating.

You can lower the validity range of requests and responses by rejecting time stamps which are off by too much an amount, but this requires that client and server are properly synchronized, something which cannot be guaranteed on a general basis (many computers "out there" are off by several minutes, even hours, even years in some cases). So you cannot make the timestamp validity range sufficiently low to ensure decent security. To sum up, your protocol cannot be really resistant against replay attacks and variants, when played over an unprotected transport medium like plain HTTP. You can do some mitigations, to some extent, but at the cost of usability issues (because of a possible lack of clock synchronization).

The solution is then: use SSL (aka HTTPS in a Web context). SSL will give you all the replay protection you may wish for; it also brings encryption. With SSL, your homemade HMAC become redundant and you could simply forget them altogether.


Can you store sensitive app config vars in the environment and be PCI compliant? Note: this is a cross post from my question on SO. Feel free to keep the one in the more relevant location and close the other.

We have a rails app which will be deployed on torquebox/jboss. (This in a way does not matter too much for the question as it would apply to any Web app, not just a Rails one.) It retrieves certain app-level sensitive configuration variables from the environment, such as ENV['DATABASE_URL'] (which includes the auth credentials so it looks like drivername://user:pass@host:port/dbname) and ENV['PEPPER'] when it starts up, to do essential processes like connecting to the database. The variables are not encrypted at this time. In essence the use of the environment to hold these variables follows the 12-factor app Heroku playbook.

There are in a way two questions here:

Is it PCI compliant to store such variables unencrypted in the environment at all?
The environment variables need not come from the OS shell (the normal place where they would live). They could equally be set in jboss or torquebox if that would be any more secure eg against an attack like shellshock. Which ENV variable store should be used?

I am aware that there are alternatives, such as encrypting with DPAPI (but that is Windows only), using Java key stores (but that is limited to client certificate based authentication AFAIK, not plain old passwords), but they are more of a pain to use, and the use of environment variables seems so widely recommended even by PaaS providers themselves that I am wondering if we actually need to go the extra mile.

The DB URL (other than username and password) and Pepper aren't sensitive values.  You may not want to advertise them, but you should assume they are known anyway.  If your security is dependent on them being secure, then you are almost certainly not PCI compliant.  Any "security" that that secrecy provides is just security by obscurity.

The DB should be inaccessible other than from your web servers and your pepper only exists to make hashing more difficult.  I don't see why these particular values being accessible to the environment would be a problem since they aren't secret anyway.

The main possible problem would be that your DB credentials are kind of flying in the wind, but there isn't really too much a way around having to store it somewhere.  You should try to restrict the access to the configuration data including the username and password for the DB as much as possible, but unless you go pretty elaborate, it has to be in a file somewhere.  Make it as inaccessible as possible and make sure that only the systems that need access to the DB server have access and your risk is limited.

I'll let someone else speak up on the username and password specifically though as it has been a little while since I last had to deal with PCI-DSS and I don't particularly trust my memory or have time to look up the specifics at the moment.


How to safely mirror network traffic for audit reasons? We have an internet connection that we need to audit:

INTERNET ->> ROUTER ->> CLIENTS

our idea would be to put a (enough big) HUB before the router (router, that logs in via pppoe to the ISP) and on that HUB put an OpenBSD* machine too:

INTERNET ->> HUB ->> ROUTER ->> CLIENTS

*I want to run a:

tcpdump -i em0 -w out.pcap

on the OpenBSD machine (em0 is the interface plugged in to the HUB, -no IP address needed for that interface?). I choosed OpenBSD since it has a history regarding security, so if there is an attacker, it wont go in via tcpdump, since tcpdump could have vulnerabilities, and it listens on the interface.

My question: is this the perfect solution? (no, I don't trust proprietary HW that can do "port mirroring")

UPDATE: We don't want to put an iptables rule in the router to send all traffic to a logserver.

In theory your solution should work just fine at a basic level with a caveat. You'll need to find a hub that works at the speed of your Internet connection or greater.  Depending on the speed of your Internet connection that might be tricky, especially has hubs are getting harder to find.

I guess a question is why you don't trust dedicated port mirroring hardware, as that would be the standard way of doing this.  Either setting a port on a switch to be mirrored, or using a network tap


gpg key size of 4096 and "the future is ECC" My boss wants to sign our binary. I need to tell him how he can create the signing key.

Most if not all sites I have seen about signing binaries say "use gpg".

OK, so gpg per default has 2048. Their FAQ https://www.gnupg.org/faq/gnupg-faq.html#sec-11-4 has several arguments why 3072 or even 4096 does not offer higher security but "costs a lot" (I assume they refer to computing resources).

Does this still apply 2020? Can I safely recommend to my boss to use 2048 key size?

What puzzles me even more though, is that on their FAQ they say:

  Probably not. The future is elliptical-curve cryptography, which will
  bring a level of safety comparable to RSA-16384. Every minute we spend
  arguing about whether we should change the defaults to RSA-3072 or
  more is one minute the shift to ECC is delayed. Frankly, we think ECC
  is a really good idea and we’d like to see it deployed as soon as
  humanly possible.

Is it possible to use ECC for signing binaries? Are there any tutorials for that? Or is the current state-of-the-art to still use gpg with 2048 key size?

Does this still apply 2020? Can I safely recommend to my boss to use 2048 key size?

This would be to a certain extent a matter of opinion and as such likely not suitable for discussion on StackExchange. For any practical purposes one should be safe with 2048-bit RSA for years to come. However, the cost of using 4096-bit RSA won't be practically noticeable when used for signing binaries.

ECC seem to offer more strength in smaller keys as well as faster computation for both signing and verification.  Bitcoin employs ECDSA with 256-bit keys, for example.

  Is it possible to use ECC for signing binaries? Are there any tutorials for that?

Currently, at least as of GPG v2.1, ECC key pairs are possible to be created in GPG. To check the version of GPG in your system and list available algorithms you can call gpg2 --version. If you can see ECDSA or EDDSA, you can also generate ECC key pairs using gpg2 --full-gen-key --expert and selecting the appropriate algorithm. As to differences between the two, see this question.


nmap host up but reason = no-response I have a strange situation.
My scanning machine is on networkA and target is on networkB.
Those networks are managed by IP pools in cisco ASA.

When I nmap the target with -Pn -sS --reason, I get as results the following:

Host is up ; port is filtered ; reason = no-response

What doesn't make sense is Host is up. It should not be there since there is no routing between those pools.

What do you think of that?

The -Pn option means "skip host discovery and treat every host as up." When the -Pn option (formerly spelled -PN or -P0) is used, every target address will show "Host is up." Since you added --reason, you should also see a reason for the "up" determination: "received user-set." This means the reason the target was determined to be up is that you, the user, told Nmap to consider it up.


Why would the browser present the certificate for an unknown outside site? The first time each day that I attempt click on the 'Mail' link from the Yahoo home page, my browser (Seamonkey) throws up a dialog with the title 'Secure connection failed'.

The content in the dialog reads -

ak1s.abmr.net:443 uses an invalid security certificate
This certificate is only valid for search.dnsadvantage.com

Error code: ssl_error_bad_cert_domain

(if somebody could guide me, I'll attach the certificate from dnsadvantage here)

I have no idea why dnsadvantage.com is entering the picture ... instead of going to the target URL https://login.yahoo.com/config/login_verify2?.intl=us&.src=ym

After I cancel the dialog, the page continues to load but now shows the certificate for Yahoo.

I'm concerned somebody may be trying to retrieve the credentials for yahoo.

Why does the browser present the certificate from dnsadvantage.com instead of yahoo.com?

The deal is that dnsadvantage.com is being used as at least one of your name servers and ak1s.abmr.net had a failed dns lookup (oops).  dnsadvantage provides free DNS lookups in exchange for doing a MITM attack for domains that it cannot find.  The page that it serves for these failed lookups is search.dnsadvantage.com and it displays google ads.

So try going some domain that doesn't exist like dsjfiohefoehf.com,  and you should see a dnsadvantage advertisement. If you don't,  then only one of your DNS lookup servers is from dnsadvantage,  so you might only see an ad on ~1/3rd of failed dns lookups.


Should I use different browsers for surfing and logging into accounts? I use web in different ways, i.e.:
a) to log into my accounts (email, google, social, forums, etc.);
b) for downloading softwares;
c) for surfing trusted websites;
d) for surfing websites which I don't know whether they are safe or not;
I do the b), c) and d) with Chrome and added add-ons to block scripts, advertisement and trackers. I cannot use Sandoxie anymore because of compatibility troubles.
Since Chrome is not sandboxed and my safety is only relying on add-ons, should I still use a different browser for logging into my accounts or it doesn't matter?
In other terms: as far as a virus attacks me through an untrusted website, will my credentials be more protected if they are not saved on the same browser?

Malware needs to be dropped to your host to scrape the saved passwords, it can't be done by the malicious website itself.

Unless the malware (say, dropped by an exploit kit) targets only a particular browser, all the popular browsers are vulnerable because all the saved passwords are stored somewhere on your computer. I think in general saving passwords on a separate browser does slightly increase the security but there are better ways to protect these credentials (e.g. password managers and protection against exploit kits).

If your concern is saving the credentials in the browser maybe you should take a look in how different browsers manage saved passwords and choose a browser according to that:
http://raidersec.blogspot.se/2013/06/how-browsers-store-your-passwords-and.html
http://www.pcworld.com/article/261259/can_you_trust_your_browser_with_your_passwords_.html
(Please note these links are a bit old and some information might be outdated)


How can I test if a DNS Server is vulnerable to zone transfers with its IP? How can I check if a DNS Server (let's say a DNS Server inside a private network) is vulnerable to zone transfer attacks when I only have its IP?
I do not have any domain names. I see all these tools like dig, dnsenum, fierce and so on using a domain as a parameter and I do not know which domain I should use as a parameter when the only thing I have is the DNS server IP.

First of all, if you are inside the local network that shouldn't be hard to figure out a domain. If you are connected with DHCP have a look at the DNS suffix(es) registered for the connection. It could be something like the company name + .com.
A tool like nslookup can help you too. Request the PTR lookup for the IP address, or use dig -x. You should get a fully qualified host name in return, then you have a domain name.
One way to investigate further is to use a sniffer like Wireshark or tcpdump and sniff the traffic going from and to the server, and you'll quickly find out what DNS requests are sent to that name server.
What you need to know is that the name server may be authoritative for several zones. And each zone may have a different configuration. Thus it is possible that the name server will honor zone transfer requests for some zones and not for others. So you should test them one by one.
Another important point to keep in mind is the IP address of the client. A local IP address may very well be trusted for that purpose whereas a non-local address would not.
Generally speaking, nowadays most name servers are configured not to allow zone transfers to outside entities. But again, local addresses may enjoy more permissive ACLs.
Also, it is not rare for corporations to use a local domain like .local or a subdomain connected to the active directory, or have a split horizon setup.


What is OSINT (open source intelligence)? I know about threat intelligence services. I've also read definitions of OSINT but I can't get a tangible feeling of what it actually is.

What are some examples of OSINT services (apart from blacklisted IPs and malware C2s)?
How is OSINT different from threat intelligence services? (Is it just the source of data that is different?)
What types of services go under the OSINT title?

Open Source Intelligence is the operation of gathering information about target, from publicly available sources. You don't use anything illegal, you don't get into contact with target so you don't leave trace. In short, you don't do anything to alert the target.

When harmless/unimportant looking publicly available informations about target systematically collected and gathered together, it becomes harmful, especially in social engineering attacks.

Examples of resources for OSINT:

Internet Service Registration – The global registration and
maintenance of IP address information
DNS: Local and
global registration and maintenance of host naming
Search Engines:
The specialist retrieval of distributed material relating to an
organisation or their employees
Email Systems: The information
contained within each email delivery process
Naming Conventions: The
way an organisation encodes or categorises the services their online
hosts provide
Website Analysis: The information intentionally made
public, that may pose a risk to security

Examples of tools for OSINT:

Google Dorks: Sophisticated Google searches, shortly.
Shodan: Search engine for inter-connected devices
EXIF-Viewers: Sometimes you can find very useful information inside photographs
Metagoofil: Info gathering tool for extracting metadata from public sources.

And many others...


Is there a security benefit in knowing if my iPhone is jailbroken? There is an app for the iPhone supposedly detects if your smartphone has a jailbreak installed. Is there a security benefit in knowing whether your phone has a jailbreak or not?

YES! It can tell you if someone has jailbroken your phone and gained control/ability to spy on you.
This app detects the real sources of jail breaking just in case it's hidden.
If you jail broke your iPhone, then good for you you did it right. If not... something else insidious is going on. See this answer on Apple SE for more information, but basically the application tries to detect things you can only do if jailbroken. It then notifies you if you are jailbroken or not. This can be useful for finding out if someone jailbroke your phone for nefarious reasons.
The real reason someone has to jailbreak YOUR iPhone is to spy on you. This gives them access to normally locked parts of your phone, the ability to copy text from your phone to their monitoring services, to hide their activity, and many other bad things.
If your iPhone is jailbroken and you did not do it, you have a compromised phone, however this could be due to company contracts! If it's a work phone this could be for making sure you aren't leaking company secrets through your phone, to prevent access to certain websites and services they don't want running on your phone, and many other legitimate reasons for them.
If it's not a work phone, but your personal phone it could be because your providers(whoever gave you the phone) is spying on you.
If it's your personal phone and you bought it you've been compromised big time and should start changing credentials from a secure terminal for all remote accounts and get a different phone.
To get rid of the jailbreak you can reinstall from iTunes to a factory image, which will overwrite the entire phone. This is a destructive process, but ensures the jailbreak is gone.


Added security risks that come with 3-tier software architecture Are there any added security risks that come with using a 3-tier architecture such as MVC in a software project?

I got asked this today, and my gut reaction was "I don't see why there would be." After some consideration, I decided that I don't actually know the answer. I took a look at another question, but it didn't really have any useful information.

Ideas?

My gut feeling is that the MVC model, or, for that matter, any cleanly defined model, tends to decrease security risks. Although things are not that clear.

From a very general point of view, security issues are a special kind of bug, on the implementation or on the structure (possibly the specification). Knowledge dilution is a huge risk factor: bugs happen more often when there are more people involved in the project. To keep the whole thing secure, there must be someone, at some point, with a transverse view of the project, who can think architecturally and grasp the interactions between all the modules; this becomes harder when the project size grows. To say things in plain words, for a secure Linux kernel, you need a Linus Torvalds: one head who receives all the information.

Any clean model which defines the roles and tasks of sub-modules in a clear way, such as the MVC architecture, will help that one-thinking-head a lot. It makes it possible to maintain the necessary project-wide security thinking framework, when the project becomes huge. On the other hand, the MVC model encourages throwing more developers at a project, which mechanically increases security risks, so MVC is a mixed blessing.

As a basic rule, the smaller the project, the more secure it can get. The Lone Wolf Developer model will get you more secure applications, and probably will deliver them faster, but with less features.


CSRF token not bound to session in Spring application We're developing a Spring appication with Spring Security. After doing some pen testing, one of the test results was a vulnerability:

  Cross-Site Request Forgery Token is not bound to user context.

We started to play around a little with tokens in private browsing and such, where we were sure the sessions were all separate and we noticed that the application accepts tokens from any one of these sessions, i.e. we can take a token in one session and simply manipulate another sesson's hidden inputs to use this token, without any complaints from Spring when we submit the form.

This seems to me to be a security vulnerability because (for example), upon finding out that user X is using our app, someone running evil site example.com can also use our app and take their CSRF-Token from his/her session, set up a form on evil site example.com that posts to our app, and lure user X to this form.

I have a hard time believing that I've stumbled upon some unknown security vulnerability in Spring/Spring Security, so what am I missing? Am I misunderstanding CSRF? Is my attack vector not a realistic attack vector?

In terms of security configurations, we've mostly used this part of the Spring Security Documentation to get CSRF configured.

So, we've solved it. Spring Security sets the CSRF-Token as a cookie, which evil site example.com can't access because sites can't access cookies that aren't from their domain. Upon submission of forms, there is a hidden input field that has the token and is submitted as well. Spring compares the token in the cookie to the token in the submitted hidden input. If they match, everything is good, otherwise 403 is returned. Since evil site example.com, can't access the token in the cookie, forms submitted from evil site example.com can't have the correct CSRF token in the hidden input (I think DNS spoofing could give them access to the token in the cookie, but then we have a man in the middle attack as well as CSRF)

The problem with our tests above was, that we were changing both tokens: the one in the hidden input as well as the one in the cookie, which, as mentioned above, an attacker can't do, so our attack vector was indeed unrealistic.

Additionally, because of this, Spring Security doesn't need to explicitly bind the token in the cookie to a session because it knows that only our domain, i.e. our App, can change the token (actually I think there is a concept of "session cookies" too, but that didn't come up here), meaning that as long as you're changing the tokens in both the cookie and the hidden input to a valid UUID, the tokens will match on the server side and Spring Security won't care. We even went so far as to use UUIDs for the tokens that weren't generated by Spring Security, meaning Spring Security didn't have them in their tokenRepository and Spring Security still didn't care. This surprised us a little at first, but I guess since the token in the cookie really can't be accessed by the attacker, Spring Security only cares if they match.


Remove CA from trusted CAs list while trusting it older certifications Lets say that some certificate authority changed her security policy and we don't trust her new certifications.

Is there any convenient way for an organization to remove this certificate authority from  his trusted CAs list, yet still keep track and trust it older valid certifications that were issued ?

Usual software handling certificates (e.g. Web browsers) don't validate in the past; when they consider a certificate (e.g. for a SSL server), they want to know if the certificate contents are trustworthy now. The "certificate stores" as managed by operating systems relate to this model. A "trust anchor" (aka "root CA") is either trusted, or not trusted. There is no notion of "it was trusted".

Validation in the past makes sense only in the presence of time stamps: a document is signed, and a time stamp is applied on the signature (or on the encoding of the document and its signature). The time stamp is to be verified at the current date (so the TSA certificate must be valid now), but then the signature itself, and the signer's certificate, can be validated at the time stamp date. This allows for verifying signatures even long after the relevant certificates have expired, although it requires that additional objects like CRL or OCSP responses are timestamped as well; additional time stamps may have to be applied at regular intervals. There are some emerging standards for such a process, e.g. PAdES (with the "long term" format) or ERS (which deals only with the time stamps part, but does it well).

In any case, such usages need a notion of time ranges attached to trust anchors. There are ongoing efforts (especially in the EU) for defining a standard format for that (called TSL) (the EU tries real hard not to say that this is a list of "good root CA", but everybody understands it that way). Validity dates are attached to each root CA in this list.

Some software which does validation in the past may use the OS "trusted root CA" certificate store directly. Indeed, a "trust anchor" is, nominally, the combination of a name (an X.500 Distinguished Name) and a public key (see RFC 5280, section 6.1.1, item (d)). However, it is widespread practice to use certificates as an encoding format for root CA. Such a certificate will include the name and public key, but also other fields, in particular two dates for a validity range. Therefore, some applications will use the root CA dates as indicative of the time range during which the root CA was indeed to be trusted.

In that context, what you are looking after is doable. Indeed, it suffices to modify the dates in the root CA "certificate". First export it as "raw DER" (not PEM / Base64). Then open some binary editor and change the dates in it; they use either UTCTime or GeneralizedTime, so their internal representation is based on ASCII. UTCTime uses the YYMMDDhhmmss format (two digits for the year, two for the month, and so on); with GeneralizedTime, things are similar except that there are four digits for the year (and there can be milliseconds). Just change the year, month and day fields to fit your needs. Once the certificate has been modified, import it back into your trust store and remove the original one. And voilà! you have your root CA with modified dates.

Of course, modifying the certificate contents that way breaks the signature which has been applied on the certificate. But this is a root CA: it uses the encoding format of a certificate as a convenience, but this is not a "real" certificate. The signature is there because the certificate format has a non-optional slot for a signature, but nothing actually verifies that signature. Indeed, the certificate is often self-signed. Therefore, breaking the signature should have no importance.

I repeat, though, that these dates matter only in the context of some software which does "validation in the past", so all of this depends on what such software actually does: root CA certificates in the OS trust store embed validity dates (and you can modify them "manually", as described above), but software which does past validation does not necessarily use these dates to manage the root CA certificates. It may well use another source, e.g. a TSL.


Is there anything preventing the NSA from becoming a root CA? There are now tons of Certification Authorities (CAs) that are trusted by default in major OS's, many of which are unrecognizable without online lookup or reference.

While there have been attempts by the NSA and others to "hack" or otherwise exploit root certicate authorities; is there anything preventing the NSA from becoming a Root CA itself?

It certainly has the resources and expertise, and could "suggest" to major OS vendors to add its Root CA to the default trust store list (which is large enough that it may not be noticed by anyone..?)

If it is feasible, what would the implications be? Could they essentially Man-in-the-Middle attack most HTTPS connections without a warning? (Perhaps not Dragnet-type interception, but close?) Or create a fake commercial root CA as obviously people would be suspicious if it had NSA plastered all over it?

It is already done:

It is the FPKI root CA, under explicit and full control of the US government. Windows already trusts it by default.

Before you flip out and begin to delete root CA certificates, burn your computer's motherboard, or drink a gallon of vodka, think about what it means. It means that the US government could technically emit a fake certificate for any SSL site that you are browsing -- but with a certificate chain that would point back to the US government. That is the point of having a "trusted CA" in the client: so that the client may validate a certificate chain. Therefore, such a forged site would hardly be a discreet way to eavesdrop on communications. All it would take would be a single user clicking on the padlock icon, reviewing the certificate chain, notice the FPKI root, and mock Obama on Twitter.

Pushing your own root CA in the "trusted store" of your victims is not an adequate way to spy on people without them noticing. Although it is a government agency, the NSA as a whole is usually not that stupid.


Crypto Browser add-on What are the known limitations with browser addon/extensions that do in browser encryption vs a native implementation in the browser. The addon would expose cryptographic primitives for use in JavaScript.

The browser addon would act as an interim solution to "The web cryptographic API" under development by the W3C.

Browser add-ons are browser-specific, so any answer to your question can only be very general.

Some browsers allow for plugins as any piece of native code, which can, of course, do anything that native code can do. For these, the add-on could provide all the functionality you can wish for. Other browsers primarily enforce Javascript-based add-on logic, so whatever the add-on does, it must do within the constraints of that programming language. Javascript is not good at computing-intensive tasks, and cryptography is such a task. The add-on would be bad, for instance, at decrypting a video file or anything similarly bulky.

Note that when the browser allows for add-ons with native code, the native code will depend on the OS and CPU architecture. This is known to be a source of severe headaches for developers. Javascript-based add-ons are much more portable, but pay for it through much reduced performance and also greater isolation from the local machine.

The biggest problem with a browser add-on is that not everybody has it. If people must install an add-on to use your Web site, then this no longer is a Web site; the whole point of a Web site is that everybody can use it without any prior installation. An add-on is useful only when it provides optional client-side functionality (so your site code cannot rely on its presence), or when everybody already has it (in which case it no longer is an add-on, but a "native feature").

The two "add-ons" which got close to being sufficiently prevalent to be considered as "always there" are Flash and Java, but both are still restrictive (an iPad, for instance, has neither). It would be quite improbable for your add-on to achieve an even similar level of success. This means that whatever reasons which would make doing your browser-side cryptography in a Java applet a bad idea, also apply to the scenario of using a crypto add-on (and Java, at least, has the muscle and existing code base which allows for powerful cryptography).


What if the attacker tamper the IV used in the block cipher CBC mode? I am a newbie to block cipher and when learning the CBC mode, I start to understand that an IV is being used in this mode and also will be transferred to the message receiver.

So here is my question, what if the IV is tampered? CBC mode can help to protect the integrity, but the IV is not encrypted, right?

AES-CBC only insures confidentiality, not integrity or authenticity.

If you look at the image down below, you can see how the Cipher Block Chaining Mode works for AES:

Source: Wikimedia Commons

For now, let's ignore all the other blocks of data, padding, etc., and just focus on the first block of data. The ciphertext is decrypted with the key, and then XOR'd with the IV.

Since the attacker can freely modify the IV, the changes to the IV are directly, bit-for-bit, reflected in the decrypted text. This property is called Malleability. In fact, all the blocks are malleable, since you can modify any block of choice and it'll be XOR'd into the result of the next block. Yes, you will "lose" one block, but depending on how the data is structured, that may be okay.

Isn't this really dangerous?

Yes, which is why AES-CBC must be used in combination with a primitive that guarantees integrity and authenticity. That means, if either the IV or the Ciphertext are modified, the decryption will fail.

Or, you can use Authenticated Encryption, such as AES-GCM, which will do all of this for you.


How does the Random Hardware Access function work on a smartphone? Certain smartphones and laptops, one of which my Windows 10 Phone and Laptop (Windows 10, redstone 1 update) have a function called "Random Hardware Access" under the WiFi settings.

The settings has the following explanation for this function:

  Use Random Hardware Addresses to make it harder for people to track your location when you connect to different WiFi networks. This setting applies to new connections.

From the explanation, we could assume the phone (or laptop) utilizes it's WiFi antenna or MAC address to spoof info.

But the question is still there, How exactly does Random Hardware Access work? Does it use random MAC addresses? does it lie when asked for location or fake the WiFi Antenna's broadcast range?

And how effective would it be? would it indeed, for example, protect my privacy by making it harder for free-wifi spot's tracking functions?

This feature randomly changes the MAC address reported by the phone. Nothing else. The MAC address is available to the Wi-Fi network but also, potentially, to software running on the device. E.g. a browser.

MAC addresses are actually in two parts. The first part tells you what manufacturer the device (strictly speaking the manufacturer of the network component of the device) is from. The second part is unique to each network device.

So any unfriendly network can track "you" in the form of the hardware address of your device. As this normally doesn't change, there is a potential for interconnected networks to track your device anywhere. Unscrupulous operators including advertising networks can grab the MAC address into a super-cookie too allowing even wider tracking of where you have been and what you have done.

By randomising the MAC address, all of this is at least made a lot harder if not impossible.


What are the best practices in a manufacturing/production facility for data retention? My scenario: A production facility that uses data sets provided by customer(s) to produce personalized goods in bulk.  Data sets can range from 100,000 to 2,000,000 names and addresses in the US.  This isn’t PCI and doesn’t fall under HIPPA or Sarbanes-Oxley Act.

In a job shop environment, how long is too long to keep data lists provided by customers?  Project Managers would love to keep “everything” indefinitely to refer to.  Network admins would like data sets scrubbed once a project has shipped.

I’d like to have a solid balance.  What are some of the best practices in this area and sources that you refer to for setting policy?

Never hold anything for longer than you absolutely need it. Your factors in how long that is can include:

legal requirements
financial reporting requirements
regulatory requirements
contractural requirements
legitimate business reasons

I think that the US as a 10-year requirement for financial reporting (it's been a while so I might be wrong).

Your contracts might require longer periods in order to satisfy your obligations.

Yes, there are many who want data "indefinitely", but then they have to define a legitimate reason for it (and that reason will have to stand up to outside scrutiny).

Privacy regulations, in general, have the understanding that personal data must be destroyed when no longer needed. And they have a dim view of "we might find a need later".

Here's your rule of thumb: "personal data is a toxic asset". It holds more financial liability than benefit. You tend to only keep it because you are forced to. But after you no longer need it, and as the benefit shrinks over time, you are just left with a liability.


Long term HDD storage solution I have some HDDs which are encrypted to what I think is a decent standard.

I want to lock these away in a remote storage facility, but am a little worried about EMP/Magnetic stuff from wiping the HDDs.

I will be backing up the HDDs, but wanted to know if there is cheap easy way to protect the HDDs from EMP/Magnets from wiping the information on them?

You are asking the wrong question. EMP and "magnetic stuff" is not your true concern.

First, "EMP/magnetic stuff" will not wipe your harddisks, unless something really unexpected happens, such as a nuclear bomb going off in the stratosphere (and that will likely destroy the circuits, but not likely wipe the platters), or you putting the harddisk onto an induction cooking plate, or similar things. In which case you have more serious stuff to worry about anyway.

Even placing a harddisk in immediate proximity of a strong permanent magnet for several hours (I've actually done that by accident!) doesn't seem to affect it in any significant way, although I wouldn't know what the effects might be if you put your harddisk between two layers of neodymium magnets for 5-10 years.

A "storage facility", such as a shoebox on a table placed in an otherwise empty, closed garage, provides enough protection against any "magnetic stuff" that might reasonably occur.

The actual problem: Harddisks are not made for long-term storage, and they are definitively not made with zero failure rates. You should reasonably not expect a harddisk to store your data reliable for longer than 5 years. Yes, there exist harddisks from the mid-1980s that still work today (I own one of these), but that's anecdotical and meaningless since they have practically nothing in common with present-day devices.

Typical rates of failure (numbers vary, depending on whom you ask) are around 5% per year within the first two years and around 10% per year thereafter.
Typical unrecoverable sector failure rates on consumer drives are specified as 1 in 1014 bits, server-grade disks having 1015 instead. Those are lower bounds as specified by the manufacturer (and no guarantee of failure), but still.
With a typical present-day disk having around 1013 bits, this means that if you fill such a drive to its full capacity, there is roughly a 50% chance that at least one sector may be unrecoverable.

There exist better media for long-term storage. M-Disc promises 1,000 years of lifetime, and while those 1,000 years are almost certainly a false promise, you probably won't live to tell a difference. If they live 50 years, that's mighty fine. You need an extra powerful writer to burn them, but every normal DVD player can read them.
Since earlier this year, these exist in blu-ray format, which should give enough capacity to hold your most important stuff "forever". Verify the disc after burning, and better burn two of them to be sure, put them into a wooden box inside a rockwool bed inside a steel box (to protect against the casual storage facility fire), and keep that box locked in your storage facility, door closed. Best put a shrink-wrapped DVD reader in there too, just in case they don't make them any more in 50 years.
Unless a nuclear bomb explodes or you fail to pay the rent for your storage room, your data will live longer than you.


Anti-Phishing Campaign Objective At every office I have worked, links and files, both internal and external, are shared in emails.

Is the objective of an anti-phishing campaign that users  never click on blind, or otherwise unknown, links?  pdfs?  Any file or link?

What is the expected recipient behavior?  What should the average person do?

The objective really depends on what trade-off between efficiency/productivity and security you're willing to make.

Stopping general phising (the mass mail, badly written, generic kind) is't impossible, and can be achieved without too much sacrifice, through proper employee training. Highly targeted, professional grade phising though, is incredibly hard to stop, as it may appear to be from (or be from) legitimate email accounts, be well written and highly relevant to the person receiving it. I would say stopping this kind of attack is near impossible for any organization that relies on interaction with the outside world.

There have been some examples of these attacks recently (against people who most likely do have employee training):

http://www.canberratimes.com.au/it-pro/security-it/hackers-breach-reserve-bank-20130311-2fv8i.html
http://www.h-online.com/security/news/item/Highly-specialised-MiniDuke-malware-targets-decision-makers-1813304.html

Of course training employees to exhibit "proper" behavior requires the proper internal organization to support it. There's not much point in telling employees not to do something that will actually be required of them (for example clicking links to change their user details, etc).

The average person can first of all be highly critical of any email received.

Does the email use properly constructed English?
Is this email something you asked for or were expecting?
Would an email purporting to be from paypal or your bank ask you to follow a link to wallyswatersking.com/wp-content/acdasdc.php? Note that links that appear to go to certain places may not (can often be detected by hovering the mouse over the link, or by examining the source code of the email).
If an email has an attachment, is it from someone you know? If not, it's probably a very bad idea to open it.

Technical solutions to mitigate these problems might include

Up to date AV (although this will likely not be effective in targeted attacks).
Application sandboxing.
Using an email provider that actively works against phishing and spam (like Google or Microsoft).

More on phishing here

http://www.onguardonline.gov/phishing
http://www.microsoft.com/security/online-privacy/phishing-symptoms.aspx


Shared Global Blacklist Trust Issue Some vendors like Palo Alto Networks make appliances that will sync blacklists across all of their client base when one of their clients gets attacked. So after the first guy gets attacked, all of the others in the same "good guy" alliance are protected.

My question is: How would Palo Alto know who to trust? What if one of their clients, or anyone who could find a way to talk to their web service tries to blacklist Google? How do you establish the kind of trust in the clients needed for a shared global blacklist?

Usually it's a mix of black and white listing to avoid that specific problem. Occasionally mistakes are made but they are usually resolved very quickly.

I can't speak for any particular vendor but there are a lot of good free threat intelligence feeds that many organizations contribute to to minimize accidental blocking of valid addresses.The way any specific vendor handles the trust rating and what to publish is likely different from vendor to vendor but generally they've all been working through those issues for a few years and gotten good at it.

Another aspect is the trust rating of any given IP is the network it's from. Large ranges of IP's can be attributed to specific owners via their BGP AS numbers. This helps incident responders contact the owner of an IP and it also helps people know if this is an IP run by a risky small ISP known for hosting lots of malware vs. a very reputable organization like a hospital that may have an infected host.

Likewise there are lots of lists for known Good hosts (top Alexa websites) and known Bad/Malicious hosts (Russian Business Network type hosts).

You may want to look into these lists as well

https://zeltser.com/malicious-ip-blocklists/

It's a lot of work to create these feeds but they are very valuable tools to block/slow-down attackers.


Did information technology had a increase or decrease in security with the introduction of automatic update features? For obvious reasons we teach users

  Always update... updates are good... never forget updates, et cetera!

Apart from the danger of malicious advertisements that make use of that showing users that they need to "update", I want this question to focus on the automatic update features in software specifically.

A lot of applications have introduced automatic update features, where users basically don't have to do anything anymore, in order to get their software completely renewed or patched or fully stuffed with (undesirable) new features. As a security professional my first feeling about that would be "Great, this makes the world a bit safer" especially because you take away the human interaction which often causes failure due to laziness, forgetting to update, forgetting to even check for updates or whatever "human" reason that causes lack of updating and start to patch known vulnerabilities automatically.

People get tons of different mobile app updates, operating system updates and desktop application updates. Doesn't all this updating increase the security risk by possibly introducing vulnerabilities in high tempo on a massive scale?

So, on the one side you have the extreme of no auto-updaters at all, on the other hand you have a scenario wherein mostly everything gets automatically updated. I consider the downside of auto-updaters that they can rapidly introduce new vulnerabilities.

I'd be interesting to see some kind of statistical analysis that shows a possibility of both scenarios.

Auto-updates greatly improved security by fixing any non zero-day vulnerabilities.

Most vulnerabilities only become known to the general public after a patch for it is released. Years ago, when auto-updates were not the norm, black-hat hackers used to reverse-engineer any security updates, found out what vulnerabilities they fixed, wrote exploits for it and distributed them to target users which didn't bother to install the update. That gave us epidemics like Win32.Sasser which propagated through a vulnerability which was already patched when the worm appeared, but many people didn't have the patch installed.

But nowadays, the release of a security update means that in a few hours nobody will be vulnerable anymore. That's simply not enough time to create an exploit and distribute it.

The high patch frequency also means that people who look for zero-day vulnerabilities (which means: finding vulnerabilities on your own before the developers do) are aiming for a moving target. A vulnerability might get fixed even while they are still working at their exploit (sometimes even unintentionally).