Is it safe to assume that a JWT is valid if the library says so?

The way to verify a JWT is to check it's algorithm, signature, expiry and issuer. Other claims can be checked too.

Signature

For RS256, the auth server will calculate a SHA256 hash of the header and payload, and sign it with it's private key. To verify the signature, the relying party again calculates the hash of the header and payload, and checks that it matches the signature decrypted with the public key.

Since the header and payload aren't encrypted, they can be tampered with, but then it won't match the signature.

Algorithm

Two serious vulnerabilities are possible when the server does not check the "alg" field [1]. This is because some JWT libraries verify the signature automatically using the algorithm provided in the header.

Firstly, if a hacker sends a JWT with the alg equal to none, the signature won't be checked.

Secondly, some faulty library implementations store the symmetric secret key and asymmetric public key in the same variable. If you've stored an RSA public key expecting an asymmetric algorithm, and a hacker sends a JWT with a symmetric signing algorithm, your server will check if the JWT was signed with the public key. Since the hacker has access to the public key, they can easily create valid JWT signatures.

Payload Claims

JWT libraries will check the current time is between the issued time iat and expiry time exp. Instead of checking the exp, some people prefer to check the current time is less than the issued time plus the maximum acceptable JWT lifetime.

The issuer iss should match the expected issuer.

Sources

[1]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries
[2]: https://auth0.com/docs/tokens/guides/validate-jwts


Protective steps to prevent files sent through WhatsApp from installing malware

Your best option is simply to keep everything as up-to-date as possible.

Your example of choice is what is known as a 0-day exploit.  Of course once the software provider learns about it and fixes it, it is no longer an zero-day, and the solution is simple: upgrade your software to the latest (protected) version.  Before the software vendor learns about the exploit, it is quite possible that nothing can be done to stop yourself from being affected.  Walking through your suggested steps:

Auto Download: Turning off auto download won't help if a weakness allows an exploit to happen regardless of whether or not an attachment was downloaded
WhatsApp settings: This in particular won't get you very far, and there usually aren't any options for things like, "Make me more secure".  For instance browsers keep javascript sandboxed as much as possible to prevent malicious javascript from installing malware just from visiting the wrong site, but weaknesses in the sandbox (random example) can allow an attacker to do what they want anyway.  In the event of such a weakness, a user who is using a vulnerable software version can't do anything to protect themselves, and by definition the software is unable to offer options to make itself safer.
Malware scanners might help after-the-fact.  It is very unlikely to detect a zero-day being exploited, but for the most part the exploit is used to install an actual payload.  If the installed payload is something that the anti-virus recognizes, it may stop the exploit from becoming dangerous.  However, if the exploit is used to install newer malware, or if it takes actions more directly (it starts spamming itself to your contacts list), then malware may be completely useless.

This is not to say that you can't do anything.  In security, defense-in-depth is key.  As a result doing things like installing malware scanners or disabling automatic downloads can help and may stop some actual exploits from happening.  However, the particular example you picked out have often been the results of attackers exploiting zero-day vulnerabilities.  When that happens, there is often nothing to be done except wait for a patch to come out from the provider and update quickly.


Is having a compromised TLD nameserver a security threat?

Could a bad actor do anything bad if they're a TLD's nameserver? If so, what are some examples?

Yes and see some examples below (I remember right now at least the following relevant cases, and will add more later if my memory finds out others).
Attacks on key actors in the chain of DNS resolution
The latest attack on some actors in DNS land was probably not just by luck targeting registrars/root/TLD nameservers operators. See:

https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-an-unprecedented-scale/
https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/
https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html
https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html

but in summary the door in the foot was:

The DNS records for the domains sa1.dnsnode.net and fork.sth.dnsnode.net also were changed from their rightful home in Sweden to the German hosting provider controlled by the attackers in December. These domains are owned by Netnod Internet Exchange, a major global DNS provider based in Sweden. Netnod also operates one of the 13 “root” name servers, a critical resource that forms the very foundation of the global DNS system.

and:

Contacted on Feb. 14 by KrebsOnSecurity, Netnod CEO Lars Michael Jogbäck confirmed that parts of Netnod’s DNS infrastructure were hijacked in late December 2018 and early January 2019 after the attackers gained access to accounts at Netnod’s domain name registrar.

The DHS even published an emergency directive on this case: https://cyber.dhs.gov/assets/report/ed-19-01.pdf
It is a clever, long running, sophisticated attack and I recommend studying it as it shows a lot of vulnerabilities in the current domain name system; Kreb's post gives 7 remediations possible at end, note that not a single one alone could have prevented the problem - the provider did use DNSSEC in fact! - and hence that most of the vulnerability still exists today - registry locking of domain names is also something not widely known yet useful.
Attacks on registry infrastructure having vulnerabilities
TLD nameservers can be sometimes hijacked just because of technical errors/bad configuration, this is one example: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html
TL;DR:
The registry used ns-a1.io as authoritative nameserver on the TLD (and other ones with the same pattern)... except that at the same time anyone was free to register this name as a domain name and hence get complete control of a part of all DNS resolution for the whole TLD!
Non-technical attacks on "stealing" the TLD
While in part subjective, .SK is a famous example.
See https://medium.com/@Oskar456/stolen-sk-domain-717e070f6735
with the core part being:

In 1995, the people operating the TLD at Comenius University started the takeover attempt by renaming their private company Softwarehouse, s. r. o. (s. r. o. stands for limited liability company) to EUnet Slovakia s. r. o., which was similar to the name of the informal group taking care of the registry. In addition, they relocated the company to a small leased office on the premises of Comenius University so they would share the postal address. Then, in 1999, they asked ICANN to do a minor adjustment of the delegation — delete “Comenius University” and add “s. r. o.” after “EUnet Slovakia.”

This was one case in my longer answer at https://superuser.com/questions/1332236/what-happens-to-country-specific-tlds-in-a-war-involving-that-country to the question "What happens to country specific TLD's in a war involving that country?" where you will find similarities and other examples.
The attempt to have a court take the whole .ir TLD as a remediation would also be a case on non-technical TLD hijack.
Specific case of ph "served" by hk
Going back to your specific case where you seem surprised that one of the .ph authoritative nameservers (remember that there is no order, so do not say "first") is ns2.cuhk.edu.hk hence under hk administration, I can not tell exactly why and how but I know this:
not all ccTLDs have big infrastructure or money to pay DNS providers to have a full reliable anycast constellation of nameservers for their TLD resolution (even if they are some doing that almost for free). Hence it was always a long standing practice of ccTLDs trying to help each other, and hence exchanging DNS services by having TLD1 give TLD2 one of its nameserver as authoritative. It helps in load balancing and at least at the beginning there was no politics involved and this was mostly solved like BGP peering requests (over a beer at a bar).
Note also sometimes it can be used for technical reasons and locality if it is believed that a significant amount of the population of users interested by the domains under the TLD lives in a specific area of the world better served by a nameserver in another "location" (network location is far different than geographic localtion). As as example have a look how .gp (Guadeloupe) uses as authoritative one nameserver from the French .fr registry (nic.fr)  and one from the European organization RIPE (which is/was providing secondary authoritative nameservers for many ccTLDs, especially smaller ones).
Now, one has to remember that when you use a domain in a ccTLD, you are under its jurisdiction. And anything can happen here. .ly is a famous example in that regard (see for example https://www.forbes.com/sites/davidewalt/2010/10/06/libya-revoking-ly-domains-that-dont-adhere-to-sharia-law/), but extrapolating you can say that .ph has a little risk in relying on an .hk domain name for its core infrastructure. It is not a technical risk right now, but still a risk.
As Håkan touched in its answer but I think it merits expansion, any owner of one such TLD nameserver can theoretically do two things:

capture the data and see queries coming at it: by virtue of the DNS protocol it would see only, on average, a share of all requests, around the same amount as any other nameservers
change the data returned and hence potentially hijack connections; this could be detected if DNSSEC is in place (which not all TLDs do)

PS: you don't need a screenshot, and you are better without.
You can do a DNS query:
$ dig ph. ns +noall +ans
ph.         12h IN NS ns2.cuhk.edu.hk.
ph.         12h IN NS ns4.apnic.net.
ph.         12h IN NS 1.ns.ph.
ph.         12h IN NS ph.communitydns.net.

or a Whois query to IANA whois server:
$ whois -h whois.iana.org ph | grep nserver:
nserver:      1.NS.PH 206.51.255.1 2620:171:805:ad2:7068:0:0:1
nserver:      NS2.CUHK.EDU.HK 137.189.6.21 2405:3000:3:6:0:0:0:15
nserver:      NS4.APNIC.NET 2001:dd8:12:0:0:0:0:53 202.12.31.53
nserver:      PH.COMMUNITYDNS.NET 194.0.1.23 2001:678:4:0:0:0:0:17


A (slightly) simplified way to think of it is:

1) You sign someone's key to say "I assert that this key belongs to the person identified".

2) You assign trust to someone's key to say "I believe this person is responsible enough to do number 1 well".

#1 is a public statement from you (your key) to the world.  #2 is a private note in your own GPG setup.

The two don't necessarily go together.  If you think someone makes terrible signatures (for example, doesn't check sufficiently before signing), then you may still sign their key (after all, you're not making a statement as to their reliability, just as to their identity), but you probably wouldn't want to assign trust to their key.  In other words, you believe their key belongs to them, but you don't "trust" them to make good signatures on other people's keys.

At a keysigning party, it's quite common to be able to sign someone's key (you check some ID, verify their email address works via a cookie, and so on), but yet have no idea if the person is worth trusting to sign someone else's key.  After all, in many cases, you've never even met them before.


Change settings to scan a printer with openvas

The problem seems to me that you're trying to edit a pre-made and static configuration.
You're correct that you're not supposed to change it in the .conf file.
What I'd recommend doing is:

1 Cloning the scan you want (In this case "Full and Very Deep Ultimate") by clicking the sheep icon next to it in the "Scan Configs" page.

2 Going back to the "Scan Configs" page, from the page it will take you too and editing it by clicking the wrench button.

3 Scroll to the bottom and click on the folder icon next to "Network Vulnerability Test Preferences".

4 Scroll down until you reach "Global variable settings Exclude printers from scan", and click on the wrench icon to edit.

5 Look for "Exclude printers from scan", and disable it.

Hope this helps. :)


SSL can stop MiTMs ... but on the long run, can it really?

After some time the CA will have signed a couple of thousands more
  certificates which will need to be synced and downloaded to the
  browser/app using them. What is actually stopping a MiTM from
  intercepting that?

The fact that the website's certificate is signed is what prevents a MITM.

I will prove my point with a simple example. I don't know if that's exactly how modern SSL/TLS works. But the basic idea remains the same.

Step 1, Bob's browser

Bob has a CA's public key. The CA public key is well known and never changing, therefore it's built into Bob's browser/OS.

Step 2, Alice sets up SSL/TLS

Alice wants to make her website protected. Alice creates a private/public key pair and sends the public key to the CA.
The CA bundles Alice's public key, domain name, and some other information together in a single package. Then the CA encrypts that package with the CA's own private key and sends it back to Alice.

Now Alice has a signed certificate which contains her public key, domain name, and some other info. The certificate is encrypted(signed) with the CA's private key. It can be decrypted with the well known CA public key.

This step only needs to be done once.

Step 3, Bob connects to Alice

Bob conntects to Alice's website. Alice sends Bob her signed certificate. Bob gets the signed certificate and decrypts it using the CA's public key which he already knows. Now, bob checks if the domain name inside the certificate matches the one he is connecting to. Once done, Bob is confident he has Alice's public key and no MITM can occur.

(Assuming the CA isn't evil)

Step 4, Scar tries to intercept

Bob connects to Alice's website again. Alice sends Bob her signed certificate.
This time Scar who is in control of Bob's network is listening to the communication stream. Although he can intercept and decrypt Alice's certificate using the well known CA public key, He cannot modify the certificate and re-encrypt it because Scar doesn't have the CA's private key. The best he can do is corrupt the certificate, but that would alert Bob and the connection would drop.


How can you check if a private key and certificate match in OpenSSL with ECDSA?

The equivalent data for ECDSA, or any ECC including ECDH, is the public point value and a specification of the curve used. In practice for interoperability people use one of the curves identified by a standardized OID (NIST, SECG, etc) and mostly only the two "blessed" by NSA Suite B, namely nistp256 and nistp384, although the ASN.1 formats (and openssl library) can support any(?) Weierstrass-form curve.

But the easy methods are effectively the same as in Determine if private key belongs to certificate? , to which I add some possible improvements:

Use openssl x509 -in cert -pubkey to get the field from the cert, and compare it to (all of) the public key (in the same SPKI encoding) obtained from the private key with openssl ec -in key -pubout

1A. Instead of different commands for RSA and ECC private keys, since openssl 1.0.0 in 2010 you can use the algorithm-generic openssl pkey -in key -pubout for both.
Configure an openssl-based program to (try to) use the key and "own" cert. If they don't match, openssl library will return an error which the program should display.

2A. Instead of setting-up a whole server environment, or temporarily taking-over an existing one, you can just run openssl s_server -accept X -cert cfile -key kfile where X is any port usable on your machine = not restricted and not currently bound or connected. If it starts okay (cert & key match), just control-C (or equivalent).


What is the practical approach for CIS Benchmark (Ensure permissions on all logfiles are configured)?

For the first, it depends on data. One must know its OS and applications. Some apps leak users' passwords when running in debug for example.
For the latter, if you are investigating and you don't have logs you don't have any clue what was going on. You can always send logs to a remote host if you don't want to save logs locally, sending logs to a remote node is always good choice. The next step what an attacker would do is to break into a log host and delete the traces.


Simplifying this greatly, the tokens you're looking for are going to be attached to processes created by interactive logons. If you've got a domain admin logged on interactively, you've got domain admin tokens.

I'm not familiar with how Nishang enumerates tokens, but I've had pretty good experiences with Meterpreter. Maybe give that a go?


Suspcious timing of [LAN access from remote] in router log

UPnP allows for portforwards through a NAT (your router does that), such that people from outside your NAT can connect to devices behind the NAT. This is access to the LAN from the internet, but only to a specific port on a specific client.

The thing is: such a port forward would only be created by the NAT after being configured so by a client on the LAN via UPnP. Simply disabling UPnP on the router might not do the trick here, because the forward has been requested from this machine that - as you said - came from a cold boot.

So unless you for example do file sharing or something alike that does need UPnP port forwards (and yes, game installers often are file sharing systems, the battle.net installer for example does peer to peer distribution of updates), you seem to have malware on your machine that requested the port to be opened in the first place.

This is most likely either absolutely fine and what you want (for file sharing to work, but manual port forwards would be better than UPnP) or an already infected machine trying to establish communication with an attacker. The probability that this is an attacker searching for vulnerabilities is almost zero; your sources seem to mix up things.

The IP seems to belong to Ericsson North America Managed Services, what seems to be a wireless ISP of some sort. This doesn’t narrow down the options. If would be best to

Make sure it’s not a program you run willingly, without you knowing that it’s doing this,
sniff the traffic and see what’s going on
Find out what causes the traffic and the open port.


RADIUS authentication: is it possible to get the user groups or other attributes?

The radius response is not restricted to accept or reject but can actually contain more information. For example you could use the 'Class' attribute to use as the group name. But of course the radius server needs to put the necessary information into the attribute you expect, i.e. it need to be configured to match your expectation. See also Cisco WSA : What is RADIUS CLASS attribute ? or Configure group-role mapping using Radius class attribute on Security Management Appliance (SMA).


Is lack of wildcard DNS entry a security vulnerability?

Based on the context you've provided I don't see a significant threat.

I'm assuming you're running a pretty typical internet facing web service and from that perspective the explanation your security researcher provided seems a bit muddled.

  The most common i can think of is phishing. Wildcard DNS is a handy
  feature, and phishers are apparently using it to bypass filtering.

I don't see how this is a direct threat to you seeing as presumably an attacker can't modify your DNS records. I can see how it might be a threat to your users (being a subset of internet users in general) who might be vulnerable to DNS poisoning or phishing in general, but this is far beyond your control.

  With wildcard DNS Phishers can generate any number of differing URLs
  on the fly and often evade filtering technology

Again, this is true... but only on an arbitrary domain they control, not on your domain.

  And there is no wildcard entry so attacker easily enumerate your
  secret and Public Subdomains.

I guess maybe there's some validity here if an attacker found it difficult to distinguish between a legitimate service and a fake/honeypot one. In practice you would need a lot of fake servers running fake services to make it significantly more difficult for an attacker to identify the legitimate one.

Plus, there's more effective ways of protecting public facing services besides simply obscuring them more.

There may be additional attack vectors to consider if your scenario is not what I assumed. For example if you're running an internal network with private DNS that serves records for publicly resolvable domains that someone else might control. This doesn't sound like the case though.


this is a false premise.

Firewalls work by parsing the IP's provided on there own predictable way.
The underlying protocols only use the Network Bitwise implementation of an IP address (e.a. it uses the 32 or 128 bit representation, for ipv4 and ipv6 respectively).

The underlying libraries that ping uses to make the connect translate the given representation to the expected representation by the system.

This means that there is no difference for the firewall between the IP representations

to illustrate this I ran the ping command with the address you supplied and captured the systemcalls. here is the results for the connect call on linux.

connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("8.8.8.8")}, 16) = 0

As you can see only the dotted decimal notation was used for the call.


As you correctly noticed, the risk of using plain FTP is essentially the same as using plain HTTP: it provides neither encryption nor tamper resistance. This means passwords are transmitted in clear and an attacker can sniff the passwords. And the attacker can also modify the traffic like injecting malware into downloads.
This means that plain FTP should not be used for anything were these attacks can be a problem, i.e. for most things were FTP is actually still used today.

  Is there really a risk of someone getting the code if there is no one tapped between my computer and my modem?

If you are inside a local network where you control all the software running and all the systems connected and were nobody can tap into the network (i.e. strong WiFi password or no WiFi at all, fully secured router...) then the risk of somebody attacking you insecure FTP connection inside the network is probably low. It still might be your ISP or it might be somebody at or in front of your FTP server. But even the local network might be less secure than you consider it because we live at a time of insecure routers and where even light bulbs might be a way in your network.


What if user can't answer the security question during password reset?

Security questions are usually stupid and useless. They rely on information that is usually easily obtained through a quick Internet search of the target's social media accounts and is not a good way of proving identity.

  Does the system prompt them for some other secure info tied to their last order, such last 4 digits of their credit card? (If yes, what if the customer hasn't placed an order yet?)

The last 4 digits of a credit card is not secure information either. See a recent, well-known case of social engineering that exploits precisely this.

Personally, I'd just fire of a password reset email to the listed email account and be done with it. Any other steps will generally serve to annoy your customers more than protect against any real threat.


Using a special user to manage web server?

Using root as a general purpose user account is just generally unsafe. Bad things can happen too easily (I once did rm -rf ~ when I was in a root shell). So, you are correct, create a user.

Using chown, if there is only one user messing with the server data files, seems fine. The answer to this question goes into some details on how to set it up. It does a nice job discussing the security ramifications that come from making web server data files writable by the web server.


Why does Windows store Wi-Fi passwords in a reversible format?

tl;dr-  Windows is acting as a password manager, and like all password managers, it must remember the passwords it manages.  You're probably thinking of the thing where servers are supposed to store hashes instead of passwords; that strategy doesn't apply here.
@forest's answer demonstrates a major caveat – that, if we assume a wireless network will always use a specific protocol that starts by hashing the password, e.g. WPA2, then Windows could forget the original password in favor of the protocol-specific hash.

Why is it that Windows would store credentials in a reversible format? Why is it not just storing the hash of the password that it sends access points to complete the handshake and establish connection?

Windows is serving two different roles here:

Password manager:Windows can remember network passwords for you.  When it does this, it's acting as a password manager.  Like any other password manager, it must store the passwords it manages.

Client:Windows must convince the WiFi network that it knows your password.  To do this, it must know your password.

If you're concerned about Windows storing your password, it'd seem like you can just stop using its password management function.  However, you'll still need to supply Windows with a network password in order to log into a network, much like you must supply an email portal with your email password to log in.

Note:  The advice you're thinking of applies to servers, not clients.
You're probably thinking of the thing where a server shouldn't remember plaintext passwords, but rather a hash of them.  That doesn't apply here since Windows isn't the server.
You can hash the WiFi password if you like, but then the hashed password would be the new password.  This'd basically be the same thing as using a key-derivation function to generate your WiFi password.

Exception:  Protocol-specific hashes can be retained.
The above answer is written for a general-case protocol.
However, specific protocols may call for having the password hashed, such as in the popular wireless protocol, WPA2.  If we assume that the network will always use a specific protocol like WPA2 across all access points and time, then we can forget the original password if we just retain that hash.
The issue with retaining just the hash is that it's not the network password so much as the protocol-specific network password.  This is, a client that retains just the hash under one protocol would break if the network updated to WPA3, or if they went in range of an older WPA access point, etc..


I recently did a Blackberry handheld security review and used this checklist from the DoD as my source information - http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=252

This is also a useful list of resources from RIM http://docs.blackberry.com/en/admin/deliverables/7533/List_of_available_BB_AMT_tools_555278_11.jsp

This looked interesting to me as it is the commercial equivalent of the Autoberry Tool used by the US government - http://fixmo.com/products/sentinel There are no prices on the site though and I would guess it might be pricy.


How to check if my usb drives are vulnerable by BAD USB

You need to determine what flash controller your device has. Different devices may have different controllers even if they have the same manufacturer - it seems to only depend on what the factory had at the time.

One way is to disassemble the device and read the label on the controller chip

Another (non-invasive) way is to use software such as ChipGenius. This can be found via Google on a number of Russian sites. Make sure to check your copy for malware. "usbdev.ru" is one source of usb software/firmware programming files.

After you know the controller in use, you can search around to see if it is vulnerable or use / modify the manufacturer's firmware flashing tool to flash your own firmware onto it. If you succeed then the device is probably vulnerable. If afraid of "badusb" I would avoid micro-controller based memory controllers and stick to those which use single use chips.

Similar research was performed into flash memory in SD cards a while before "badusb" emerged and this CCC talk is quite interesting. It explains the reasoning behind using micro-controllers because of flash quality / economics. Much of the information applies to USB flash drives as well.


Is an 8 characters long password reset token strong enough?

all the tokens had 8 characters, all alphabetes capital and small, no numbers or special characters

This is on the edge of acceptable.

It isn't easy to compromise an account this way. In an online brute-force attempt you can typically try between 10 and 100 tries per second. A random eight character password like you describe has 53459728531456 possibilities. Brute-forcing all the possible passwords would take 16951 years. So this isn't really a feasible attack.

But it could be improved. If the token is sent in an email and the user doesn't have to type it in, there is no reason not to make it a little bit longer.

  it never changes no matter how many times i ask for password reset link

This is suspicious. Normally, a password reset token expires after some time, or after it has been used. In your case, it doesn't seem to expire at all. This means that once a token or account has been compromised, it is not possible to recover from this: the attacker can keep resetting the password if he knows the token.


What are human weaknesses at generating a password which shall be random?

Disclamer: I have no source for this. This is all based on personal experience

Since most sites today dictates a password policy where passwords must have at least one digit and one uppercase character, the structure is almost always:

One uppercase character
X lowercase characters
One or two digits at the end.

If symbols are required, they're often appended after the digit - most commonly !


Exposing ports or hide them behind proxy

This mainly depends on how you are doing the proxy.  If you are simply using mod_rewrite in Apache or Nginx to redirect from 80 to 8090 ... then there is no security gained at all.  This is the equiv of putting a sticky note on the front door of your house saying "please use the door in the back".  Anyone can read the sticky, and even if there isn't a sticky anyone could case the house and find the back door to be open (aka port scan your host).

If you need to have a web service that is only accessible by certain people one of the best ways to do it is to instead host the service on localhost or 127.0.0.1 ... this means that the port will not be accessible outside the box.  Then, in order get to the service you ssh port forward:

ssh -L 80:127.0.0.1:8090 example.com -i ~/.ssh/id_rsa

the above is how to achieve ssh port forwarding in Linux, however it is also available via tools like puTTY.

Using a ssh tunnel to access your service increases the level of security by:

encrypting the communication between client and server
protecting service behind pubkey (or password) auth used by ssh
no external port to be scanned

If you do not want to setup SSH tunnel another option is port knocking.


This is a good question. The dedicated page from OpenSSH only says:

  OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.

which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some unsubstantiated weaselling that talks of "recent discoveries". Thus, it is time for some sleuthing.

In the source code of OpenSSH-6.9p1 (Ubuntu 15.10 package), for the key generation tool ssh-keygen, I find this remarkable bit of code:

    maxbits = (type == KEY_DSA) ?
        OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
    if (*bitsp > maxbits)
            fatal("key bits exceeds maximum %d", maxbits);
    if (type == KEY_DSA && *bitsp != 1024)
            fatal("DSA keys must be 1024 bits");

The OPENSSL_DSA_MAX_MODULUS_BITS is a constant from OpenSSL's headers, that define it to 10000. So the first four lines check that the requested key size, at generation time, can actually be handled by the key generation process. However, the next two lines basically say: "regardless of the test above, if the key is DSA and the size is not 1024, niet."

These 6 lines are, in themselves, a sure sign that whoever developed that code did not completely agree with himself with regards to key sizes. This code was probably assembled incrementally and possibly by different people. The source of the "1024" can be traced to the actual DSA standard (called "DSS" as "Digital Signature Standard"), FIPS 186-4. That standard was revised several times. In its first version, DSA was mandated to use a modulus whose size was between 512 and 1024 bits (and should be a multiple of 64, presumably to simplify the task for implementers). A later version acknowledged the increases in technological power and mathematical advances, and banned any size other than 1024 bits. The modern version of FIPS 186 (the fourth revision, as of early 2016) allows the modulus to have size 1024, 2048 or 3072 bits.

It can thus be surmised that ssh-keygen refuses to use a modulus size different from 1024 bits because someone, at some point, read the then-current FIPS 186 version that mandated exactly that, and nobody bothered to update ssh-keygen when the FIPS standard was amended. Regardless of how this spectacular piece of programming schizophrenia came to be, the raw result is that most if not all SSH keys of type DSA in use today rely on a 1024-bit modulus.

The next piece of the puzzle is the Logjam attack. Logjam is basically about noticing that when a client and server agree to use weak crypto, they can be attacked. This is an attack on SSL/TLS, not SSH. However, the Logjam article does not stop at (rightfully) bashing SSL/TLS implementations for using a 512-bit modulus for DH; it also dedicates some talking space to "state-level adversaries". That part mostly says something which was already known, i.e. that breaking discrete logarithm modulo a 1024-bit modulus (something which would allow breaking both DH and DSA) is right now horrifyingly expensive, but not impossible with regards to our current knowledge of the problem and available technology (similar to breaking RSA-1024, and quite unlike breaking a 2048-bit DH or DSA, which are beyond the feasible with current Earth resources).

To receptive ears, this all sounded like "OMG we are all pirated by the NSA !" and the publicity around the Logjam issue (which is very real) trailed in its wake a substantial amount of hysteria on the subject of 1024-bit DSA keys, included when they are used in SSH.

An extra point was that using DSA requires generating, for each signature, a new random value, and the quality of the generation of that value is of paramount importance. Some implementations have failed spectacularly, leading to private key leakage (notably for some "Bitcoin wallets"). This characteristic of DSA is shared with its elliptic-curve version ECDSA. It can be fixed. But it instilled the idea that DSA signatures can be tricky to do properly (and ECDSA signatures equally, but elliptic curves are cool and nobody wants to ban them).

These parameters, taken all together, explain the ban. This can be viewed as a case of OpenSSH developers being proactive in their notion of security and are ready to force users to use strong crypto. Another way of seeing the very same sequence of decisions is that OpenSSH developers blundered badly at some point because of some poor reading of FIPS 186, and then sought to cover it in the equivalent of dumping at sea the corpse of the inconvenient husband.

Note that breaking your DSA key would allow the attacker to impersonate you, but not to decrypt recorded sessions. While it can be said that switching to an ECDSA key would be a good idea at some point (it saves a bit of bandwidth and CPU), there is no cryptanalytic urgency to do so. You will still have to do it, because otherwise you may be locked out of your servers because some packager was too zealous in the deprecation policy.


For one, an attacker with temporary access to the phone could get several OTPs and use them much later, which would defeat the point of using OTPs in the first place. Another issue could be the user requesting an OTP and then not using, later an attacker could access his messages (for example from backup) and get this active OTP.

So generally, you want to make sure the user has possession of the second factor, the mobile SIM card in this case at the time, when the login is occurring.

Another thing is, that having many active OTPs increases chances of someone guessing one of them by brute force.

There is also a practical consideration, that storing a lot of unnecessary OTPs in the database wastes space.


Your thinking is a bit weird. When browsing the Web, however you put it, a Web browser is necessarily involved, and there is little reason to believe that the browser in the iPad would be more secure than the browser in any operating system. There are even reasons to state that it would be less secure, because on the iPad you are constrained in your choices: you must use the iPad browser, and security updates are those from Apple, whether you like it or not. You can get exactly the same level of security from your Macbook by simply running a stock MacOS X with Safari, and installing updates when Apple says so (with the automatic "software update" system). Personally I find some Linux distributions more proactive in their update mechanisms, so I tend to give a bit more trust in the security of that OS.

As for Flash and Java, well, you always have the option of not installing them. On the iPad, you do not have the option of installing either; but on any other system you can just skip them. Of course, no Flash means no Flash.

A hardened Linux server is, yes, hardened. The important thing to make a system secure is not that it is minimal but that it is maintained.


By using disassocate packets.

Those packets has the source MAC of an AP and force the client to disconnect and reconnect to the AP.

By keeping sending those packets, you can keep any client away and unable to connect to this specific access point.

Edit:  A summery for people can't access links.

From a tool named Aircrack-ng

Deauthentication
Description

This attack sends disassocate packets to one or more clients which are currently associated with a particular access point. Disassociating clients can be done for a number of reasons:

Recovering a hidden ESSID. This is an ESSID which is not being broadcast. Another term for this is “cloaked”.
Capturing WPA/WPA2 handshakes by forcing clients to reauthenticate.
Generate ARP requests (Windows clients sometimes flush their ARP cache when disconnected)

Of course, this attack is totally useless if there are no associated wireless client or on fake authentications.

  Note: Some clients ignore broadcast deauthentications. If this is the case, you will need to send a deauthentication directed at the particular client.

Source: http://www.aircrack-ng.org/doku.php?id=deauthentication


Logging new network connections without TCP Wrappers

As noted in Steffen Ullrich's comment, it is possible to use iptables to do this sort of logging.

One of the techniques that come up in the search parameters Steffen provided is to log the second packet of the TCP three-way handshake in order to capture the IP addresses and ports of each accepted connection. The technique is described over on Server Fault: https://serverfault.com/questions/669488/iptables-log-established-connections.


What are the names of software vulnerabilities?

There are many different classes of vulnerabilities that affect software. A comprehensive list would be huge, but some common classes are:

Memory corruption (stack/heap buffer overflows, misused format strings, use-after-free, double-free, etc.)
Broken authentication (complete bypass, manufacturer hardcoded password, etc)
Injection (SQL/SMTP/LDAP/etc. injection, command injection, etc. Just like web.)
Race conditions (TOCTOU)
Logic errors (business logic flaws, lack of validation, etc.)
Privilege escalation
Broken/weak cryptography
Many others


How does a third party file encryption get along with OS native file encryption?

TrueCrypt
TrueCrypt creates a disk object by inserting itself as a translation layer above an existing container - typically a partition or an entire disk, sometimes a file which will therefore contain a disk image. You then format that disk created by TrueCrypt using NTFS or FAT or EXT4 or whatever you want. TrueCrypt neither knows nor cares about the files on the disk[1], it just encrypts the disk raw. Used space, free space, deleted files.. everything. It's the disk that's encrypted, and therefore any files on it are by extension also encrypted because they're in an encrypted container.

NTFS
Windows built-in encryption is based on NTFS -- the filesystem used by Windows. NTFS takes an existing disk and decides where on it to store files. It keeps track of used blocks, file names, the location of file contents, file fragmentation, all of that. It's the set of rules used to decide where on the disk a given file goes.

Built in to the NTFS spec is the idea of encryption. Key handling is done through windows, but the important point is that the encryption happens transparently when the file is stored to disk. If the file is marked as encrypted, then NTFS will transparently encrypt/decrypt the file as it's reading or writing from the disk.

Together
You can create a TrueCrypt container and format it with NTFS. In that sense, the entire filesystem will be encrypted, but Windows won't know that. All Windows sees is the disk object exposed by TrueCrypt. It doesn't know (nor does it have to know) that TrueCrypt is transparently encrypting that data before writing it to disk. But it is.

Within that NTFS filesystem in the TrueCrypt container, you an also instruct Windows to encrypt the file. It tells the NTFS filesystem that this file is encrypted, and NTFS will dutifully encrypt the file.

Now the file appears to be in plain text to the user, but actually when it's stored to disk, the filesystem is transparently encrypting it. And then again when those encrypted bits are actually written to the physical disk, TrueCrypt is getting in there and encrypting those data blocks again, so the file is encrypted, and the disk that the file is on is encrypted.

Both are done transparently, and the whole process just works. Obviously you'll need both keys to get to the actual file data. The TrueCrypt key is your TrueCrypt password, while the Windows NTFS key is typically an x.509 private key encrypted with your Windows login password.

[1]:  Not entirely accurate, but accurate enough for this discussion.


Prevent phishing attacks through abuse of Apple iOS URL scheme

Before giving any solution, it is important to remember that, if an app is being installed on a user's device, then given time and dedication, a malicious user can replicate/reverse engineer the app. That said, there are certain techniques which can be used to make the job of reverse engineering the app difficult and eventually replicating the app difficult. Some of the techniques can be:

For every request a secret value can be sent, this secret value can be a hash of concatenated strings of (password + current time + domain + a constant string) etc. Any such scheme can be created, but make sure the code is obfuscated enough so that it is hard for the attacker to break. By frequently altering this algorithm, malicious app need to also do that to keep up.
Secondly, you can include anti-debugging checks like having ptrace with PT_DENY_ATTACH call  or using sysctl approach.  But again a determined and skilled attacker can circumvent these checks. These checks can be disabled by altering the app binary. But by having frequent hash checks of the binary can make the job of attacker further difficult.
Use of SSL pinning can also protect against some script kiddies from looking at network traffic, but tools like SSL KillSwitch makes bypassing this check trivial.


Why do so many PGP public keys begin with mQINBF?

The first few bytes of the public key packets are describing, among other things, the size of the key and the version of OpenPGP used. As many people are using the same size (such as 1024-bit) and the same version of PGP, it will always give the same first characters. But, it does not mean that the key-space is smaller than expected.

For more information you may take a look at the full specification of OpenPGP messages in the RFC-4880.


The author had made the mistake of being ambiguous and confused the readers a bit. I must admit, like you, I was confused at first, until I saw the PCAP dump.

First of all, the box indeed doesn't have wget

The attacker didn't use that one echo statement, he used a series of echo statements. I counted about 107 echo statements progressively building the executable rand0-btcminer-arm. At about 50 bytes each, that's about 5350 bytes. Way more than enough to achieve a simple HTTP download.

Here's a snippet of them (highlighted in red):


Is there any security benefit in stripping only `` tags that contain code?

No, stripping <script> tags is useless because you could  still execute a javascript payload like this:

<input onmouseover=prompt(document.cookie)>

And bypassing the filter should also be quite easy, imagine what would happen if a payload like this sent:

<scr<script>ipt>

As far as what type of software they are using, well there's just not enough information to determine that. What you could do is request the robots.txt and see what this discloses.

In order to simulate / test this, you could use the following code as an example:

<?php

if (isset($_GET['q']))
{
   $var = $_GET['q'];
   $var = str_replace(array("<script>", "<script src"), "", $var);

   echo $var;
}
else
{
   echo "GET parameter 'q' is not set!";
   die();
}

?>

The solution to this problem is input validation and output encoding. Here's an OWASP resource that I recommend reading: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet


No put/delete in API, parametrized query, sanitized user input - enough for API security

No one will be able to tell if this is secure.  All I can offer is some advice on other things to consider:

path traversal - If you have any support for loading files or templates you need to consider this.  For example: verify that things like .. cannot be used to move up the file directory towards root
templates - if you are using templates, anything that comes from the client or is derived from client input that is passed to a template is a risk
string concatenation - parameterized queries are a good thing but if you are building the queries dynamically it defeats the purpose.

And of course you need to make sure your server is set up to run in production.  Specifically, Werkzeug is not considered production-ready and you need to find a more robust WSGI server.  You will probably want to run a reverse proxy such as NGINX or httpd as well.


How does my ipcamera work despite UPnP disabled on home router?

It just opens an outbound connection to the server, like a regular user would to upload to youtube or stream to twitch.


Are you saying that your permissions were 755 but are now 754 or 644? Looking at my Apache logs (Ubuntu, don't have CentOS handy), they should be 644. Was Apache restarted?

Regarding possible methods of attack (hypothetically speaking of course) -

Presuming that someone did not steal or successfully fake the certification authentication, a possible theory is that someone stole an FTP login (entirely plausible, through social engineering or sniffing the cleartext protocol somewhere along the FTP connection), and then performed privilege escalation (through a vulnerability in the FTP service, Apache (unlikely: not aware of any at the moment), some other software installed on the system, via the Linux kernel (they do exist but I presume you're well patched on that front, unless someone threw a 0-day your way, again unlikely but possible if you've data that someone really wants) or via your web application depending on how well its coded).
PHP apps are renowned for being insecurely developed and are frequently exploitable.

I'd recommend removing FTP access and replacing it with SFTP (using key authentication).


Why would a bat file that just starts a program be considered a virus?

It would be detected as a virus because it is an executable (.bat) calling a Javascript file. A recipe for a bad infection.


Trying to create a reverse bind shell from Windows to Linux

I had a firewall issue on the Kali side of things. For anyone who stumbled upon this question, I guess this is basically a guide now rather than a question.

The answer is to turn off the appropriate firewall settings on the Kali machine and everything should work fine.


What's good/bad about this custom password hashing?

Open questions:

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

Notable issues:

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


Is using Gmail and encrypted documents enough for secure email communication?

It sort of depends on what you are protecting.

Have a read of this question on what steps Google, Yahoo! and others take to protect webmail.

Also have a look at this question, giving alternate solutions on sending data. I tend to use pgp/gpg to encrypt before emailing, where possible or use a hosted secure mail (similar to the one @Paul described) for some clients.

You can secure the connection fairly well, but unless you encrypt your data before sending it, it will reside on Google's servers in the clear. This may be okay, but it may not - it all comes back to how sensitive the data in those messages are.


Prevent Session Hijacking, where an attacker steals Session ID(cookie) from the browser physically

The cookies are there to avoid authenticating via a password for each web transaction (otherwise each protected page would need to be reauthenticated every time it is accessed).

In that sense cookies are independent of the password.

They should be checked by

the browser which verifies that their validity has not expired. The server should never rely on this check for security means as the browser is controlled by the client (and can elect not to check the validity)
the server which ensures that the cookie it retrieves from the client is still valid according to its (the server's) own criteria (it should keep track of the validity of the cookies independently of a possible "validity time" within the cookie).

Therefore the fact that you changed the password does not necessarily mean that the cookie is invalid. It should be the case because the server should invalidate them on his side.
Logging out is the normal way (or rather - should be) to invalidate sessions.

There is not much more beyond that (in terms of cookies as an authentication mechanism) - they are one possible way to avoid constant reauthentication.


CSRF Token for Anti Automation for multiple requests

Generally CSRF-Token is used only when the state change request is made by user. State change means when user perform some CURD Operation on Application.

It’s not required to gives bunch of CSRF-token to every form in multistage form. But generally Programmer gives to every single form. Whether that Form is contain any state change action or not

We generally not recommended to use CSRF-token in get request because of GET request logged at multiple places (Logs, Load-Balancer etc.) so it creates risk for your Application .

Questions:

1) For Updating operation, there are multiple requests send to different modules on the Server. should the CSRF be same or different?

Ans : You  can use the same CSRF-token issue one token for each user-session. If your application is perform critical operation than you can go for one token for each form.

2) Before a response is received, the screen is allowing user to initiate one more request? what should the CSRF token be send? The assumption is that, once the CSRF token is validated, then a new token is generated and send in the response.

Ans:if your application uses the multiple token for a single form of action, then you need to validated that token in each request and in response new token will be given to the user. But generally we haven't recommended these kind of complex implementation. if it is not that much critical application

3) CSRF should be send in header or body? Should It be encrypted?

Ans:Always in the body not in cookie. There is no need to do encryption on CSRF-Token. It is nothing but a Secure random generated string for validating that the action is intended by that user or not.

For More Details

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet


Daily Virtual Machines workflow: Use for sensitive activities?

There's not much we can add to your current analysis of the pros and cons of the various arrangements you describe. You're going to have to experiment to find out where your personal comfort level is.

I would add though that if you believe it possible that e.g. airport security will try to bug your laptop, then the only safe thing is not to bring your machine through airport security. If the bad guy has physical access to the hardware, then it's not your computer any more. Also, if you believe your bank might include spyware in their application, then the only safe thing to do is to run it in it's own dedicated VM with nothing else. If the bad guy can persuade you to install something on your machine, then it's not your computer any more.

And don't forget there are other more subtle things you can do with a VM, like having single-use VMs that you throw away after use, or VMs where the disk lives on removable media that you can store separately from the machine.


Can I use RSA to encrypt an AES256 key that I put at the beginning of my AES256 encrypted file?

You are reinventing the wheel by trying to solve your problem at a low level. You are trying to combine RSA and AES encryption primitives to create something that will asymmetrically encrypt a file. What you should be doing is looking for a solution that can asymetrically encrypt a file. For example,

NaCl crypto box
GPG


Protocol/standard/software for requesting PGP signing/verification of content?

Assuming you are using forms one could add accept=multipart/signed,application/pgp as an attribute of the appropriate input element.  I don't think there is anything out there that would actually do anything with this information but it is a standards compliant way of expressing that you want signed data submitted.

As far as security issues go I think as long as whatever does the signing makes it clear to the user what they are signing and gets their consent it should be fine.


How safe are encrypted files error-wise?

That depends entirely on the cryptographic algorithm used.  One of Claude Shannon's maxims was that errors should not propagate.  In the case of AES in CBC mode, a single bit error will propagate to two blocks.

Modern cryptosystems are likely to use a digest or other message integrity mechanism to detect tampering, so that in case of an error in the encrypted data, the entire ciphertext will be rejected on the basis that a mismatched digest suggests tampering.

Modern computing hardware is so robust that it probably doesn't make sense to worry much about errors.  if error correction is an important consideration, then data should have error-correcting codes added before encryption.  In that way, errors in the decrypted data can be corrected.  However, if decrypted data is accepted despite a non-matching digest, then tampering can no longer be detected.

Edit: Now that I think about it a {ahem} bit, a bit error in encrypted data is no more likely than a bit error in plaintext.  If you accept that a single-bit error renders an entire physical block of the disk unreadable, then a bit error in encrypted data the propagates to the next 128-bit block (AES, CBC) will also result in loss of a single 512-byte disk block 31 out of 32 times, and at most two physical disk blocks in the 1/32 case that's left.  Unless I've missed something in the probabilities, for 512-byte physical blocks, a bit-error in encryption corrupts one block 97% of the time and two blocks the remaining 3% of the time.

If you also accept that a single unreadable physical block means the file is effectively destroyed, then there's no error-rate penalty for encryption.

In any case, one defends against unreadable ciphertext in the same way one defends against unreadable plaintext: RAID and backup copies of files, being physically careful of disk drives, etc.


What are the security challenges encountered with attribute exchange?

At the end of the day the client (usually a browser) still needs a token to maintain a session (usually with a cookie variable).   If the attacker gets this token,  by XSS or OWASP A9 then they can access the same resources.  CSRF is also a concern.

Now this is assuming that these authentication providers are totally immune from attack.  If a flaw exists in one of these services,  you are also in trouble.   SQL Injection,  Phishing, Insecure backups,  lack of brute force protection are just a few concerns.

oauzz is an oauth fuzzer,  which can uncover serious flaws in an oauth implementation.


Would you go with SSD or Disk Hard Drive?

Summary thoughts:

Bad: SSD model that has a lousy secure erase mechanism.
Good: Any standard HDD; SSD model that is known to be good.
Best: SSD or HDD with hardware encryption. Any medium when using full disk encryption.

Detail:

Some background answers from other questions that will help out:

SSD (Flash Memory) security when data is encrypted in place

How can files be deleted in a HIPAA-compliant way?

I think the only security difference between SSD and HDD technology comes when you discuss repurposing a drive. If you're in an environment where storage is repurposed, you need to make sure that the SSD drive you select can be reliably cleared. There are many models that don't do that properly. See SSDs prove difficult to securely erase for some info on it.


Why do Chrome and OpenSSL disagree over signature algorithm?

Why do Chrome and openssl disagree over signature algorithm?

Because they get different certificates. The reason for this is that Chrome uses Server Name Indication (SNI) whileopenssl s_client does not, at least not by default.

If you look close not only the signature algorithm is different but also the subject of the certificate:

$ openssl s_client -connect winkel.vpro.nl:443 | openssl x509 -text
...
Subject: ... CN=_default_.omroep.nl/emailAddress=beheer@omroep.nl
...
Signature Algorithm: sha1WithRSAEncryption

If you instead use SNI by using the -servername argument you get the same certificate you got with Chrome:

$ openssl s_client -connect winkel.vpro.nl:443 -servername winkel.vpro.nl | \
     openssl x509 -text
...
Subject: C=NL, ST=Noord-Holland, L=Hilversum, O=VPRO, OU=ICT, CN=*.vpro.nl
...
Signature Algorithm: sha256WithRSAEncryption


What precisely about Zoom is not secure?

Early Zoom use did not properly limit access with passwords and was subject to Zoom Bombing, uninvited people joining the meetings. Zoom also mislead with statements about E2E encryption when in fact it was no such thing, as a result it got a lot of negative press.
Conversely the open source product Jitsi emphasized security.
In both cases, it's all in the details.
Recently Zoom has enabled E2E encryption capabilities, comparable to Jitsi.
True E2E encryption was limited to direct one-to-one person connections  for Zoom, and all the others as well, because trying to manage dozens or hundreds of individual encryption keys and cross connects is a nightmare.
[Correction]
Apparently Zoom does now offer multiuser E2E encryption. According to their support page:

How does Zoom provide end-to-end encryption? Zoom’s E2EE offering uses
public key cryptography. In short, the keys for each Zoom meeting are
generated by participants’ machines, not by Zoom’s servers. Encrypted
data relayed through Zoom’s servers is indecipherable by Zoom, since
Zoom’s servers do not have the necessary decryption key. This key
management strategy is similar to that used by most end-to-end
encrypted messaging platforms today.

Non-E2E Multiperson meetings for Zoom and everyone else is performed by connecting to a central management server that handles all the cross connects. Encryption is User-to-Server, but everything on the server is decrypted.
The security issue is, who controls the server and where is it?
Plain old default just use Zoom runs on servers controlled by Zoom throughout the world. I've seen Zoom servers in Australia handling meetings in the U.S.. Zoom, like all the others, offers the capability to run your own servers for greater control and security, but user and meeting metadata are still managed in the Zoom public cloud.
Other products, like Jitsi, allow complete secure isolation if set up that way. I believe WebEx supports an isolated setup as well, but I'm not positive. Of course, many of the other products are often used in a more convenient but insecure fashion as well.
Specific to the APP, the one issue I found was:
Zoom iOS App sends data to Facebook

As people work and socialize from home, video conferencing software
Zoom has exploded in popularity. What the company and its privacy
policy don't make clear is that the iOS version of the Zoom app is
sending some analytics data to Facebook, even if Zoom users don't have
a Facebook account, according to a Motherboard analysis of the app.


Is there any reason to include the remote ip when using reCaptcha?

Because there could be a DNS/hosts reroute in place to allow the captcha to be parsed differently by a malicious user

One possible scenario is farming cheap labour to manually solve captchas and then submit them back with the form. Since the recaptcha only will serve the image once this is the lazy way to farm this out. ( redirect the requested image to elsewhere ).

If the IP address which requests the image is different to the IP address that requests the page then this would indicate this style of attack.


Avast malware-gen popups on mac when going onto google chrome website

It seems like you are not the only one. Other people have reported similar or identical problems.
It appears that an update issued today has fixed this problem.

Please try to update your install of Avast and see if it fixes the issue.

EDIT : DO NOT RUN A FULL SYSTEM SCAN! PEOPLE HAVE REPORTED IT HAS CORRUPTED THEIR SYSTEMS!


Securing information on password attempts

You're on a hostile device (a user's computer), so have to assume that they can manipulate your code. Therefore, you can't limit in that way: you can ensure that the passwords used are long enough to withstand brute force attempts (e.g. a SHA-256 hash would mean that an attacker would need to try millions of attempts per second in order to be sure of decrypting the data within the lifetime of the universe, assuming perfect implementation of encryption), you can attempt to detect multiple attempts, or you can try and obfuscate the number of tries, but there will always be ways for an attacker to bypass these.

For example, if an attacker ran your software in a VM, they could restore to a snapshot taken before a password attempt when your restriction kicked in.

In order to defeat that, you'd need to control the decryption layer, on a device you control - potentially an internet based service, which returns either decrypted data, or a failure message. You can't just return the correct password, since that would imply that there is some local element where a password can be entered. You can't confirm the password as being correct, for the same reason.

An alternative to an internet based service would be a hardware device which is plugged into the computer of the user, and which acts in the same way: upon a correct password, it returns the encrypted data, else it increments a failure counter and rejects further attempts when this reaches a specific level. This device would need to be tamper-proof - it's no good if you can open it up and read the memory directly. This is essentially the method Apple use with the iPhone, where the separate device is built into the phone, but with very limited interaction with the rest of the system.


Ransomware/Virus/Malware - modern protection(s)

Anti-Virus never offers 100% protection
This statistic claims that AV software is able to stop about 25% of all attacks. That can be seen as a positive thing (25% less stuff I have to worry about) or a negative thing (75% still going through).
Common sense, however, is 99% effective. Not opening e-mail attachments from strangers, downloading shady files from shady sites, etc. reduces the risk of compromise drastically.
Behavior Analysis isn't 100% perfect either
There is a set of actions that AV software classifies as "malicious", and a set of actions users would like to do in order to do their job. Unfortunately, these two overlap a little, and so AV software has the task at determining how strict to be.
Too strict, and users will complain that AV software is preventing them from doing their job - which then results in the AV software either being tuned to being less strict, or the AV software being removed entirely.
Too permissive, and malware can disguise itself as a user doing user tasks, as is described in the GitHub repository you linked to.
The idea of Behavior Analysis isn't to offer 100% protection, but to complement matching of known malware. This is already implemented in top-of-the-line AV software. In other words, even with Behavior Analysis, the success rate is only 25%.
Protections against Malware
There are many approaches, and they're usually together. Generally, you want to prevent malware from getting to your devices, rather than trying to stop it once it's already there. In order to do that, known infection vectors are either prevented or made more difficult.
One way that malware can infect a machine is through exploiting known vulnerabilities in the software and operating system. The solution for that is centralized patch management, meaning that the OS and software is always kept up-to-date and known vulnerabilities are patched as soon as possible.
Another way for malware to infect a machine is via phishing. Phishing can be countered by awareness campaigns, as well as spam filters. For example, an e-Mail prefixed with !!! THIS EMAIL ORIGINATES FROM OUTSIDE YOUR ORGANIZATION !!! is more likely to cause alarm when it's supposedly coming from your CFO on a Friday afternoon.
Of course, there are many other infection vectors, but this should give you an overview.


The impact of 'hacking insurance' on the information security industry

If you have a car insurance you will pay more if you have a more expensive car. Also young and inexperienced drivers will pay more because the risk with them is higher.

The same is with such hacking insurance: this price depends on what needs to be covered and how much the risk of hacking is. The risk of hacking or at least the costs associated with a hack can be reduced by using established security strategies, i.e. backups, training, firewalls, breach detection, audits .... Thus if you invest more for security you pay less for the insurance. In fact most insurances will probably do not offer you a hacking insurance at all if you do not already have adequate security measures in place because in this case the risk would simply be to incalculable. And they will reduce payment in case of hacking attacks if you failed to keep your security up-to-date.

This means that  I consider such insurances will be a good thing which will help to improve the security.


This depends on the platform.

As a general case, you should consider using the OpenSSL bindings to use OpenSSL's RAND_* API. Do make sure to seed it correctly. Not reading the OpenSSL documentation will cause a security compromise on virtually all operating systems due to improper RNG seed. Even “big ones” have been bitten by this.

On Unix-like operating systems including BSD, the Hurd and Mac OS X, you should read from /dev/arandom (if it exists), or /dev/urandom (if it exists), or /dev/random (only if none of the other two exist). If none of these ① exist and ② are character devices, stop with an error to prevent compromise. You really do not want to “invent” an RNG/seeding scheme yourself!

On Windows® systems… first consider if you really want to do this. This is already a potential security compromise. Then, read from /dev/urandom if it exists (Cygwin), or use the CryptGenRandom API. I'm not sure there are Python bindings for it, but it's not hard to do in C, and can be made into a compiled Python module. Maybe with FFI…

When using OpenSSL, do consider to set RANDFILE to keep a seed across program invocations, especially on Windows®. Consider preseeding this from known good entropy. Maybe mixing stuff from random.org, randomnumbers.info or fourmilab.ch's Hotbits service (but, again, do not only take from there, as it's transmitted over the network). Be aware that the RANDFILE is not handled properly by OpenSSL by default: instead of read+RAND_add+write+close on program start, it's normally read at program start and written only at program end; this is better but only if your program (and all other programs using it) is not running more than one instance at any given time.

Do not use any of those:

Process ID
Time
Mouse position
Screen content
Content of “uninitialised” memory – it is often not uninitialised (even malloc() results, which the C library may not initialise, is initialised by the OS for the sole reason to clear what was in there before (e.g. from another process), and the simplest way to clear it is to zero it out), and if it is, this is normally Undefined Behaviour, which may lead to all sorts of mayhem

It is true that these are (some of the) input sources used by the OS and/or OpenSSL for their RNG implementations. But these people know (more or less, but a bit more than you) what they are doing, and, far more importantly, they are not the only sources. They are all not secrets, and an attacker can experiment with them. More importantly, their value range is not great. Also, do not write any “keyboard input” code (values and timing) yourself. The OS handles keypress-to-entropy conversion itself, normally. Just ask the OS for good entropy, and error out if there isn't any.

Do not use the system's hardware random number generator as only source! They can be compromised. Also, it may not even exist, or access be prohibited (think virtual machines).

Mixing any of these into a pool is good – but then again, the OS will do a much better job at that than your user-space application.


Why do some sites block pasting into username or password input fields?

In my opinion, I don't think it's a net win.  Those restrictions always frustrate me.

(I'm hoping someone here will post details about how to defuse or work around them.  Maybe a tweak to Firefox's user_prefs.js?  An extension?)

Presumably the reason why sites disable the password manager is because they're worried that Alice might sit down in front of Bob's browser and log into the web site as Bob, maybe purchasing something on Bob's tab.  This is particularly an issue for roommates, family members, etc. who live together with each other.  (See also "friendly fraud".)  A related risk is that Bob might actually purchase something, but then claim that Alice did it to get out of paying for it.  Presumably, the sites hope that by disabling the password manager, Bob will be forced to type in his password anew every time; Alice won't know the password and won't be able to type it in.

However, these restrictions come at a significant cost.  They make the website less usable and more annoying for users.  They also drive users to either select poor passwords (which may be more susceptible to password-guessing attacks) or to write down their passwords (potentially enabling roommates and family members to learn the password, leaving everyone back where we started).  For users who do trust everyone else who has physical access to their computer, these restrictions strictly decrease security.

Personally, I suspect most sites should be reluctant to employ such measures.  Odds are that you will annoy your users more than you will help them.  But you will be in a better position to make an informed decision.

If you do decide to employ such restrictions, you might consider providing users a way to opt out if they do not share their computer with others.  Perhaps this may only be of interest to power users, so I don't know if it's worth your time, but you could consider it.


Is it secure to use HttpSessionState.Session to store Identifying Information

Objects stored in a HttpSessionState session are stored on the server-side.  They can only be accessed by your application code, not by the client (the browser) or the user using the browser like a client-side storage mechanism (like cookies) might allow.

So, there is no direct way for a user to tamper with or modify the value of session objects.   The only way a malicious user can abuse session state would be to steal an entire sesssion, which is known as a session hijacking attack, or force a victim user to use a specific session, which is known as a session fixation attack.  This is accomplished by taking the value of a cookie that is sent to the browser that identifies the session a user is associated with, so that it can be accessed on subsequent requests.   If a malicious user can steal another user's session cookie/id or force another use to use the attackers previously established session id, (often relying on separate cross-site-scripting attacks to accomplish) the attacker than then either impersonate the victim, or get the victim to perform an action on the attacker's behalf.

Even in these cases, however, the attacker is limited to the transfer of the session in its entirety.  He or she still has no control over the values of the properties stored server-side for the session.


Retrieve, from a failed wifi hotspot connection attempt, the password posted

If you could do that easily, consider that you will be able to get easily the correct password.

TL;DR: no it isn't possible.

There are attacks where an user may compromise the password from a wifi hotspot, but mostly these are possible because we get large amounts of encrypted packages (this is a simplification, obviously you also need a bug in the implementation of the security mechanism).

Consider that when trying to access with an invalid password you only have one package so the only way to exploit it would be brute force.

In fact, it seems harder to get an specific erroneous password than the good one.


Can I use the same password for my Computer, Mobile and Password Manager?

Consider that the password of your vault (password manager) is not stored anywhere (only in your head) if you are using a strong zero knowledge vault.
If you are using it also as the session password of your Windows computer and your mobile phone, then it is stored in their memory as a hash.
The difference is not huge because, for both, an offline bruteforce attack is the main threat against your password. Indeed, most of the time your vault define a random crypto key, use it to cipher your passwords and protect this key using your password. So the attacker needs to try many passwords to invert the key protection and check if the result key correctly decipher the passwords database.
It is a bit harder than just trying to reverse the hash of a Windows computer.
In order to not increase the risk by reusing the password for your computer and your mobile, I would advise you to enable the encryption of your PC and your mobile.
This way, an attacker cannot access to the active sessions where you are logged (GMail, bank and so one) by directly reading the disk.
But remember that there are more chances that an attacker get a physical access to your mobile or PC (if you lost it, if it is stolen, ...) than to your vault (he should find a vulnerability to dump the database)


Can the blocking of JavaScript and the disabled loading of embedded attachments make an HTML email relatively secure?

Check when that document you quoted was written, this is because the use of JavaScript in HTML emails is disabled. Even if it were enabled, almost all email clients (apart from very, very old ones) have the feature of JavaScript auto-run disabled.

As to the loading of embedded images, yes their HTML code can open malicious links when loaded, hence why most email clients disable the feature, instead giving you a choice to load them every time you open the email.

So, because JavaScript doesn't actually serve any advantage (did I mention emails with JS often get sent to spam?), you might as well leave it disabled in case of the slim chance that your email client let's a malicious piece of code slip. For the embedded attachments, again you should disable the auto-load of them, and instead let you manually load them.

So activate the option but leave "deactivate embedded attachments and JavaScript" turned on.


Sending sensitive information via self destructing link in an email

I think that onetimesecret.com it's a very useful service, and it fits your needs.
Of course, you should share the onetimesecret password by a different channel in order to increase the security and avoid the case of compromising the sensitive information if someone has access to the email account.
I have dealt with these situations before and, depending on the context, I have used several tools (and also a combination of them):

You can use a cloud storage (like dropbox or google drive), to store a 7zip protected file with the sensitive information.
FTP server inside your company (You should read about Pure-ftpd in *nix)

I agree with Philipp, encrypting Emails is always the most secure alternative. But it is not always easy to implement this.

An easy way to address your concern and perform encryption, it is by creating an email account in Hushmail.com. The service allows you to set a password at the moment of sending the email (it is even easier than opening onetimesecret). But remember, you must always share the encryption key by a different channel.


Looking for Wepawet-like open source alternative

If you're familiar with JSUnpack, it's a brilliant tool which has been made for the deobfuscation and detection of malicious javascript files.

It is open source, and available here: https://code.google.com/p/jsunpack-n/

Additionally, on top of javascript, it can scan the following file types:

PDF files - samples/sample-pdf.file
Packet Captures - samples/sample-http-exploit.pcap
HTML files
SWF files


As you noted, the main three are:

Something you know
Something you have
Something you are

I'd argue that there are others:

Something you can do, e.g. accurately reproducing a signature.
Something you exhibit, e.g. a particular personality trait, or even neurological behaviour that could be read by an fMRI. These are not strictly "are" features, as they're more fluid.
Someone you know, e.g. authentication by chain of trust.
Somewhere you are (or have access to), e.g. locking a session to an IP, or sending a confirmation pin to your address. This one is a bit tenuous in terms of being called an authentication factor, but it's still useful to note.


What are the actions of Locky on the source files which lead to encrypting?

What happens when Locky fails to encrypt a file?
Locky "fails" the encryption when it cannot reach one of the C&C server. It tries to receive the private key which is located on the C&C server.
Locky cannot fail encryption once it has the private key, unless all the Locky-processes will be canceled while it's encrypting. This means that there is a big chance that a file could become corrupted.

What happens to a file after its content have been (successfully or not) encrypted?
The content of an encrypted file will be all scrambled. This size of the file will be different and the entropy will also be higher.
The content of a failed encrypted file will be probably the same. Except it can be that the content will be smaller than the original content of the unencrypted file. And once you decrypt it with the private key, the file will be most likely be corrupted.


For what is an ICMP tunnel useful and how does ist work?

In general, tunneling one protocol under another is done because there are networking devices in between that only can handle or allow specific protocols.

If routers or firewalls allow (don't drop) and don't record (don't log) the full ICMP packet, then just looking at the protocol shows pings or something happening. This causes the covert comms channel to be overlooked.

The proxy server would be needed to form the tunneled traffic into a form that the real desired server could understand. Otherwise the webserver itself would have to directly accept ICMP/TCP traffic.

Target >> ICMP Tunnel with HTTP >> Proxy that unwraps the tunneled HTTP >> HTTP Traffic >> Server


How to implement a digital signature for 21 CFR Part 11 for non repudiation

Note that the problem is more of a legal than technical/implementation issue. Your links above to the FDA regulations and the other stackoverflow question How to achieve non-repudiation? emphasizes the legal aspect of it as well.

That means you will need to ensure compliance to laws of each country (e.g. ESIGN Act in the US). What is interesting about ESIGN is that it preserves the right of a person to NOT use electronic signatures. Might I suggest using a service such as https://www.docusign.com/ instead - see its section on legality.


Simple exploit leads to wrong EIP and EBP

You just discover that GCC perform alignments on local variables (stack). An paper that could give you an idea of this concept is the following one: Optimal Stack Slot Assignment in GCC


So, here in Europe, ATMs have been Pin&Chipped for at least since the mid 90's. So there's no question.

Other than that:

Just insert a credit card (stolen, yours) and try to get money?
Stand next to the ATM and observe people withdraw money?
find the type label and get the user manual online?

Also, although admittedly small in-shop ATMs are far more common in the US, and thus are offline / non-chip ones, you could probably compile a list of those which have and those models which don't have that feauture. I'm not a skimmer, but common sense tells me that there's a list with pictures somewhere on the internet.


Does salting your own password improve security?

What you are talking about is not a salt, it's just a pattern, and one that is highly predictable. Say, for example that your password on Amazon is p@ssw0rd123amazon and your password on Google is p@ssw0rd123google and your password on some small e-commerce site is p@ssw0rd123*sitename*.

If someone hacks the e-commerce site and posts all the passwords on the internet they are out there for anyone to see. It wouldn't take a genius to recognize your pattern and figure out the password you are using for Amazon and Google as well.

Password patterns never work out that well and not as secure as you'd think. You are better off getting a password manager to generate strong passwords and save them for you, then you don't even have to think about your passwords.


What do malware authors using android root exploits go after?

Mobile malware is after the same thing as regular malware it's just on a different platform.

We use our phones to do everything from email, banking, social media, etc.  Security tokens are stored in these devices for all kinds of different applications, and possibly web-sites.  The average user doesn't take mobile security seriously.  Try 3333 or 6666 on a friend's iPhone some time.

Access to email can give more than enough information to start taking over accounts, and could lead to identity theft.  Even if they're not after your identity they can still just be the annoying malicious malware.  Ransom-ware is becoming popular on Android.  Maybe they just want to spam a bunch of ads through your apps.

Nowadays you need to treat your phone like you would your laptop/desktop because they've now become equivalent.


Why does windows defender scan my computer multiple times

On this Microsoft help page there is an explanation how to schedule tasks. Windows Defender should not scan more often than it is scheduled to scan.

It reads:

  Search for and open Schedule tasks.
  In the left pane, expand Task Scheduler Library > Microsoft > Windows, and then scroll down and select the Windows Defender folder.
  In the top center pane, double-click Windows Defender Scheduled Scan.
  In the Windows Defender Scheduled Scan Properties (Local Computer) window, select the Triggers tab, go to the bottom of the window, and then select New.
  Specify how often you want scans to run and when you’d like them to
  start.

You should also be able to check how often Windows Defender is scheduled to run now.


Can admin see my password when I enter it?

No, you can't protect yourself against a privileged user. Any piece of software you can install to protect you could be uninstalled or deactivated by the privileged user

That's why is told that when a computer is compromised and the attacker gets root access (Or is possible that he did) you just don't control that computer anymore

If you don't trust the computer administrator or whoever has access to an administrator account then you shouldn't store any data that you don't want them to access


Is IP spoofing still a threat in the Internet?

Yes there is some statistical data about that: http://spoofer.cmand.org/summary.php

// Quoting the referenced Pages FAQ:

  Actually, our measurements clearly show that spoofing is still
  prevalent among approximately 25% of the autonomous systems and
  netblocks we survey. More importantly, a single entry point for
  spoofed traffic provides attackers a means to send spoofed traffic to
  the entire Internet. ISPs can employ filtering [RFC2827] to ensure
  their outbound traffic is not spoofed. But there is currently no way
  to ensure that inbound traffic is legitimate as long as there exist
  entry points for spoofed traffic. uRPF [RFC3704] does not work, and is
  not used, in the core of the network where routing asymmetry renders
  it useless.


Which things can facebook access like contacts etc

Yes, that, and a lot more if you use their mobile app. Also, they are not alone on harvesting everything; always read the app permissions list before installing an app, and consider whether you are willing to share your data with the app maker...


Where are the HTTPS session resumption tickets/sessionIds stored on the client?

What the client actually stores is the set of security parameters, the most important part of which being the master secret: this is the secret value shared with the server, obtained from a previous handshake. The session ID or session ticket is just a value used to reference that master secret(*).

The master secret is very sensitive (knowing it allows decrypting all the data in the session...) so the client is supposed to be extra careful with it. In practice, the client stores it in RAM only; you won't find it in any file, and it disappears when the client process is terminated (process termination, in the case of Web browsers, mostly equates with closing all browser windows). Session ID and tickets are stored along with the master secret, in the same emplacement, since they do not make sense without that master secret.

(In modern Web browsers, there are usually several process, but they talk to each other, so, for this discussion, they can be considered together as "the browser process".)

On the server side, RAM-based storage is also common, but some servers allow storage in a database or in some other mechanism so that the master secret may be shared between several front-ends. This is needed for some kinds of load balancing mechanisms. Of course, writing the master secret on any physical medium is a potential source of leak, so this kind of game shall be done only with great care.

(*) Well, the session ticket is something a bit more complex than that, but the gist of the idea remains valid: for the client, the master secret is outside of the session ticket.


Denial of Service, as its name suggests, is any event which causes service to be denied, either to users or administrators, or any other entity which relies upon the system.

This can include anything from synfloods to smashing the server with a sledgehammer. As such, yes, your example would be considered a denial of service.


How does proxylist sites discover new proxy?

Usually, these sites have admins or people that work for the site. I know a person that works for these kind of sites and he said he uses a proxy scraper like ProxyFire and other ones.


Stealing Facebook HTTPS cookies with captive portal

If you visit HTTPS sites and get redirected without any warnings then the problem is that your browser doesn't correctly validate certificates - a good browser would display a warning as the captive portal's certificate does not contain the domain you wanted to visit in its common name field.

A possible vulnerability would be if you visit the site over HTTP, but there are solutions to mitigate this such as the Secure Flag on cookies that tell the browser not to send this cookie over HTTP - and HSTS which makes the browser automatically convert your HTTP requests to the site into HTTPS requests, in addition to preventing you from bypassing the certificate error if an HTTPS connection can't be made.


How do you keep someone from changing hidden values in an HTML form?

You don't. User can change whatever they want to. A hidden field is not different from a common field from the browser or server perspective.

If you want to store secret data the user will need, store them server-side on a session. It's the fastest way.


Multipurpose security token a security vulnerability?

The sort of problem I can foresee with this is that it's vulnerable to the following sort of attack:

Attacker causes your system to send a password reset email to the user.  Such an email contains a valid security token plus some context, for example:

Telling the user what this is about;
Instructions for the user how to complete with the action;
URLs for the user to click on to complete the action.

Attacker intercepts this email and adulterates it to keep the security token, but alters the context to their advantage.
User receives the forged email, acts on the adulterated context, and thus unwittingly carries out some action that the attacker intended them to do.

Whether this is a realistic or fruitful attack very much depends on the details of your system.  In any case, binding the tokens to the actions that they're supposed to perform removes this sort of risk.


User-to-user encryption in addition to SSL for mobile phones?

By encrypting machine-to-machine, you (sort of) protect the data in transit, but user-to-user encryption protects the data in transit, from parts of the machine (further up the stack), as well as protecting it in storage. An additional benefit to user-level encryption is better control over the encryption process, in case you do not have control over the SSL process at any point.

The question becomes, "who are you protecting the data from?"

The Pidgin chat client, for instance, can be configured to use user-level encryption, and gains the benefits I outlined.


Secure access to a Microsoft Access Database

If you don't have details of the existing system, using a VPN is likely to be the simplest route. This way you can not only use the required level of authentication (depending on your country this may vary, but accessing patient data usually requires strong authentication, logging etc) but also mean you don't need to alter the existing application.

VNC or Hamachi can be very useful to make it simple for the doctor, but from a security perspective it's the tunnel/VPN that you communicate through which you want to concentrate on.


Are the malware signatures used by AVs primarily created by human analysts or by automated means?

Disclosure: I'm working for an anti-malware vendor.

First, there is no anti-malware vendor which operates exclusively on signatures. Even free ClamAV is using more than signatures. So I'll address this question as related to "automated detection measures".

Several vendors I worked for in past use automated means to create malware detection rules. According to hearsay, this also seem to be the case at all other major security vendors.

The reason for that is the sheer volume of new malware. AV-TEST Institute, a reputable independent testing organization, states: "Every day, the AV-TEST Institute registers over 350,000 new malicious programs (malware) and potentially unwanted applications (PUA)." While those numbers include all malware, including polymorphic and metamorphic, the number of new detection rules needed in a day generally exceeds the number of minutes in a day. Thus for most vendors it is fully automated task.

Human effort however is still used to:

Create generic detectors - the rules which can detect polymorphic/metamorphic/obfuscated/encrypted content. A "dumb" signature cannot detect those, so there are different code pieces doing that.
Create proactive detectors. Those are targeting certain traits in malware which are unlikely to change fast enough (such as certain hardcoded strings, certain way functions are called, some unique libraries used). Using those as a base, it is possible to proactively detect new malware from the same author/group before it is even released.
Creating the disinfection routines. Those cannot be generated automatically, code needs to be written, tested and so on.

Of course maintaining the automatic detection systems is also where lots of effort goes.


programs or methods to review Internet browser applications for security

This very much depends on what you mean by "security review".  From the comments I guess this was handled by a general sys admin rather than a specialist in the past, so it's perhaps likely that what you need is just a relatively high-level review.

The sorts of things you could check for relatively easily before sending out an update would be

Malware.  Ensure that there's no known malware in the downloaded software.  Either by running your in-house A-V software against it, or perhaps using a tool like Virus Total to check against multiple engines.
Checksums. Ensure that the downloaded software matches the checksums provided by the vendor, to indicate that it has not been modified in transit.  For firefox these can be found here