Attack Vectors for Purely Static Website (HTML and CSS)

Let's look at the technology stack of a dynamic website:

Your code, in whatever language you chose, e.g. PHP or ASP.NET
The script engine, e.g. PHP engine or .NET CLR
The web server, e.g. Apache or IIS
System services, e.g. SSH and FTP
The operating system
If you're on a VPS, the virtualisation technology that hosts your instance, e.g. VMware.
The hardware
The network infrastructure, e.g. switches, DNS provider, etc.

Now compare that to the technology stack of a static website:

Web server
System services
Operating system
Virtualisation technology if any.
Hardware
Network infrastructure

So, you've removed the top two layers of the technology stack by going for static. It is true that a large percentage of attacks are focused at the web application code and engine, but you still have a number of attack vectors to worry about.

Off the top of my head, here are a few:

Service passwords (e.g. SSH, FTP, RDP) for the server.
Web server vulnerabilities.
Service vulnerabilities.
OS vulnerabilities.
Virtualisation software (hosting management) passwords.
Domain provider account passwords.
Network infrastructure misconfiguration.


Do we need to maintain Authentication and Authorization Logic separately?

Yes, yes, yes!

These are two different tasks.  Conflating the two incorrectly is one of the most common sources of vulnerability.

Number 2 and 4 of the OWASP top 10 this year, specifically:
https://www.owasp.org/index.php/Top_10_2017-Top_10

Authentication is "who are you" and authorization is "what can you do."

Authenticating a user does not authorize them, and being authorized is no guarantee of authentication.


If the transaction is truly offline, also called store and forward in the retail space, then there is a lot of inherent risk the business is accepting. That is why almost all in person transactions involve an online authorization, which contacts the issuing bank to verify the transaction details.

I am not aware of any way to mitigate that risk in a true offline transaction scenario.


Is it legal to find bugs on a website and report them to the website's owner?

It is legal to tell them about the bug, giving them a detailed description of the bug and how you came across it.

What is unpredictable is the company's reaction.  It could vary to something such as them sending you a reward/small gift (has happened to me), to them trying to prosecute you as a criminal (tipping them off anonymously could help with this issue).  If the bug compromises the website and it's information, make it clear that you have not used the bug in this way.

If you have the knowledge, try to make suggestions on how to fix the bug, to make it even clearer to the company that you are trying to help them out (something I did as well).

Important note: If the company refuses to recognise the vulnerability, do not seek way to exploit it and get it attention.  This will most likely result in legal action against you.


You are conflicting multiple issues, and you should start by stopping to speak about ".PEM files", the format of the file is mostly irrelevant to what follows.

ssh works with keys: keys attached to users and keys attached to servers.
When it started, it was classical asymetric cryptography, every party (servers and users) have a least one couple of private+public key and all of this is used to authenticate who connects to what.

This works well and is still probably the default most used ssh keys.

However you may hit mostly management problems (instead of technical problems) when you have too many hosts or users and you want fine grained control: each server must be configured with a specific set of user keys, and users need to know a specific set of server keys if they want to avoid the TOFU principle. You may also want more security around keys, being able to revocate access easily, etc.

So what as been added in OpenSSH (version 5.4 in 2010 for initial availability and then version 5.6 in for full support) is the possibility to use not just bare keys but X.509 certificates. X.509 certificates encapsulate a public key (where you would have the private key in a separate file) with some other metadata, such as validity dates or other constraints to use this certificate, and they are delivered by some specific Certificate Authority.

For servers, using certificates, means you basically get back the same model as today on HTTPS. Where it may be more interesting is for user keys. For example, you do not need to configure the server with the specific set of user keys allowed to connect there, you just need to configure the server to accept all certificates signed by a specific CA, that is internal and you control, with some specific constraint.
Then you can just issue to your users some certificates with the specific constraints they need to connect to the servers they need to connect to.

Netflix has an elaborate mechanism like that they talked about. Their developers have a way to automatically request new certificates, very short lived (in the order of minutes, when the SSH connection is open, it does not matter if the certificate expires during it, it stays open), so that they can connect to any host.

See this presentation of them, which may give you some ideas on why certificates may be useful: https://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production or the corresponding video: https://www.youtube.com/watch?v=JwLGsWYVjqU

They also "open-sourced" the software they need for this architecture: https://github.com/Netflix/bless


How secure is Google’s/Android’s Smart Lock functionality?

If someone was to touch and read your NFC tag with the intention of cloning it, then they can do so and fool your phone by cloning the NFC tag.  The phone relies on the tag's UID but this too can be cloned (you can get UID changeable tags from places like Alibaba).

Some specialized NFC tags & readers use certain tricks to protect against cloning using some proprietary techniques which makes them limited to that brand.


Wipe out or dissapear and start over again in internet for personal security?

I would think your "friend" could go through all his various accounts and disable them, one by one. That would probably not delete his data, but it would likely reduce his visibility by a great deal.

As an example of this, consider Facebook: If you disable an account, most of what has been created using that account will become invisible (possibly deleted?), but not everything. Also, the account will still remain there, albeit invisible. If you try to rejoin later with the same e-mail address, then you will get the option of reopening the existing account instead. I would be very surprised if most other social networks and other providers of various services did not operate in similar ways; the fact is, it will be extremely difficult to ensure all your data (oh, sorry, I meant your friend's data) will really deleted.

That said, he should be able to reduce his visibility to such an extent that he will be fairly hard to find (that is, assuming your friend is not in the cross hairs of someone with a relatively high degree of competence, like Mossad, for instance).

The other part of your question is about how to initiate a new identity, and keep that separate from one's real identity. As stated by others, this has been discussed in other questions, but the following are a few pointers. (PS: I'm still learning about this stuff myself, and am not providing any guarantees. If your "friend" gets caught smuggling plutonium, or his girlfriend breaks up with him because she caught him participating in online dating because these measures turn out to be insufficiently secure, it's all on him).

First of all, use TOR. Learn how to use it properly, and follow the general guidelines, and you should be safe enough for most cases (general anonymity).
If you want improved anonymity, and to be sure that all your traffic is passing through TOR, get Tails Linux installed on a USB drive, and use that for all activities for your new identity.
Never under any circumstances let your new identity interact with any accounts or anything else that you use or have accessed previously using your "previous" (or real?) identity.
If you are really paranoid, and are worried that this is not enough, then get a separate cheap PC that you can use only for your new identity. Buy it in cash. Preferably using gloves, dark sunglasses, and a fake mustache. Only ever connect it to public networks, so it can never be linked to your address, or the address of any person or organization you may at any point have been affiliated with. Also, don't stay connected for more than a short period at a time, and keep the mustache on in public. A tinfoil hat is optional, but recommended.

Jokes aside: The real issue here is finding a balance that suits your needs. The Internet is a big place, and chances are you can "disappear in the crowd" unless someone is actively searching for you. Creating a new anonymous identity for a limited online existence is fairly easy, provided you don't actively draw attention to yourself, or have highly competent adversaries with a lot of resources. Perhaps the biggest challenge will be to find something useful to do with this new anonymous identity over an extended period of time, without interacting at any time with known friends or organizations which may give away hints to build a profile and connect the dots back to you.

Keep in mind: All kinds of usage and behavior can creates traces. A particular set of sites you visit frequently, the window size of your browser, etc. - these and other factors can be used to create a profile of your user over time. If this profile can be matched back to a similar profile for your real identity, then you may have a problem.

But then again, the odds are your friend's adversaries are not likely to be Mossad.


User authentication protected against all attack vectors

I presume you are using https with a reasonable key length, to access the login API and receive the JWT and sending the JWT is SSL sessions. If this is the case accessing the JWT from a packet capture of the (encrypted) SSL session is not going to be fast. Hence your JWT should have a sensible expiration time and be reissued on expiration.

If you are concerned that your payload is too sensitive for https I'd suggest using a private connection (eg. tunnel over VPN) prior to app connection. For public facing apps this isn't practical.


How to patch haproxy for OpenSSL vulnerability USN-2830-1

Per the Ubuntu vulnerability, running those commands is sufficient. Ubuntu is a reliable Linux distro, not known to make false claims. So you should be secure.


Is personal information secure if two VPNs are used?

No matter how many VPN/proxy you use together there is always one which communicates directly with your browser and one which communicates directly with the target server. In both cases any unencrypted data can be extracted by the VPN, i.e. username and passwords in case of plain HTTP (instead HTTPS) connections, target hostname even with HTTPS connections etc.


Would PGP/GPG have been a better choice than SSL for browsers and http servers to encrypt traffic?

The talk is not of SSL being broken, but of the "rogue government agencies" weakening the underlying crypto mechanisms to make the task of brute-forcing the keys factors of magnitude easier (such as making random number generators more predictable). These kind of attacks are not protocol-specific and can be applied to SSL and PGP in equally successful way.


Is a PCI scan required for LAN outer firewall with no open ports?

Any physical location that stores, processes or transmits credit card information needs to have its associated public IP address(es) scanned per the PCI-DSS regulations.

I have a number of sites that return back with either 'no open ports' or only port 500 (for VPN servers). This is absolutely fine.

I can't comment on using Comodo HackerGuardian - I've used a number of different external scanning utilities ASVs. None of them have errored out from not having open ports.


John The Ripper - find password when you know a part of it

You can create your own JtR rules to generate your wordlist.
Create a local john-local.conf file in your working directory, so JtR will include it, giving you the option to run rules defined therein:

~/$ cat john-local.conf
[List.Rules:myrule]
# as-is
:
# append a number
: $[0-9]
# append 2 numbers
: $[0-9]$[0-9]
# prepend a number
: ^[0-9]
# prepend 2 numbers
: ^[0-9]^[0-9]
# prepend a number and append a number
: ^[0-9]$[0-9]
# capitalize
c
# capitalize and append a number
c $[0-9]
# capitalize and append 2 numbers
c $[0-9]$[0-9]
# capitalize and prepend a number
c ^[0-9]
# capitalize and prepend 2 numbers
c ^[0-9]^[0-9]
# capitalize and prepend a number and append a number
c ^[0-9]$[0-9]
# capitalize and prepend "nothing exotic" and append a number
c ^[0-9A-Za-z#!]$[0-9]

I've added comments above the rules so you can understand the syntax. Adjust it to your needs.
Put your basic password candidates in a file (I called it wordlist):
~/$ cat wordlist
abcchji

Now, in order to apply those rules and generate your custom wordlist, call john specifying your custom ruleset in the --rules attribute:
~/$ john --wordlist=wordlist --stdout --rules:myrule >longlist
Using default input encoding: UTF-8
Press 'q' or Ctrl-C to abort, almost any other key for status
1282p 0:00:00:00 100.00% (2020-07-09 20:08) 42733p/s !Abcchji9

Depending on your rules, the wordlist will contain all corresponding combinations.
~/$ wc longlist
 1282  1282 12776 longlist

~/$ cat longlist
abcchji
abcchji0
abcchji1
abcchji2
abcchji3
abcchji4
abcchji5
... (truncated)
!Abcchji4
!Abcchji5
!Abcchji6
!Abcchji7
!Abcchji8
!Abcchji9

Finally, run JtR with the argument --wordlist=longlist against you pdf file.


Ultimately, there is no difference: both "types" of encryption will end up running some software on top of some hardware so this is mostly a marketing argument.

How an encryption stack works exactly depends, of course, from case to case and it is very important to review the details.

For instance, some hard drive will implement some encryption layer in the BIOS of their controller that will force every write done to the disk to go through that encryption layer no matter what the computer the disk is connected to supports or does. The same, however, can be achieved without any direct support from the hardware by using full disk encryption.

Both "type" of solution typically have the same performances since modern CPUs are fast enough to process the encryption/decryption streams faster than the read or write speed of even fast SSD drives (i.e. the encryption isn't the bottleneck).

Typically, all solution will offer roughly the same algorithm - frequently, AES in CBC mode using a diffuser: it's standard, royalty-free, well understood and has known security properties. The most important element to consider when looking at a disk encryption solution is the key management: how are encryption keys generated, stored, accessed and managed. This is where "software" based encryption usually shines: having access to a "richer" environment (especially so is there is some OS support or access to specialized hardware installed on the machine - like a TPM chip) which can lead to a better experience and more secure key management.


Is there any method or tool other than nmap for the detection of an OS?

There are a lot of techniques. Some of them are:

IP TTL values + TCP Window size
DHCP requests
MDNS
ARP / NDP / SEND
NetBIOS
SSH / SSL / TLS

Here is a great article about it. Don't forget to read Nmap OS Detection.


How to become a great cybersecurity professional?

I would suggest taking up entry-level or actually intermediate infosec certifications, as you do already have a degree in Cyber Security hence intermediate would seem like a good fit.

  I find that there are many many topics that I have no exposure to

As I can tell from your post that you are seeking more on knowledge than the prestige that the certifications might bring.

CompTIA Security+
Certified Ethical Hacker (CEH)
GIAC Security Essentials (GSEC)

These certifications might give you the initial foothold & exposure you need.

  I am not quite sure which one I should go for as so many jobs list so many different certs as qualifications

Do not take up certs for the purpose of getting specific jobs that lists them as requirements. The certifications I mentioned above are general-purpose certs that cover a wide range of topics and it is should not be taken as a specialization of a certain skill/topic in this field.

Gain interest in the certs you want to pursue, obtain them, then start looking for jobs that list them as prerequisites. But for now, worry about obtaining that broad skill set that you said you were originally lacking.


Wireshark decrypt and save wireless packets from command line

Is there any solution? It would even help if I could somehow generate a psk from ssid and password and save that as a text file, but there does not even seem to be a clean way to do that.

If you know how to use python, try this:

import sys
import binascii
from passlib.utils import pbkdf2

orig_stdout = sys.stdout
f = file('savefile.txt', 'w') # Specify the name and path of the output file.
sys.stdout = f

essid = 'examplessid' # Set ESSID
password = 'examplepassword' # Set password

psk = pbkdf2.pbkdf2(str.encode(password), str.encode(essid), 4096, 32)
print binascii.hexlify(psk)

sys.stdout = orig_stdout
f.close()

It will save psk to a text file. Tested in python 2.7


What does it mean when Reaver returns a PIN but no passphrase?

This usually happens if the router has the PBC (Push Button Connect) activated. The wps pin is the correct but then you can't get the password. So you'll need to push physically the button on router.

Sometimes this behavior can be because a bad signal. You can try closer to the AP.

Other times it depends of the compatibility of your chipsed and the software. For example, if you have a Ralink chipset on your wireless card, Reaver doesn't work very well. If this is your case you can use the alternative to reaver (bully).

EDIT:

Another idea... Did you tried using -N (--no-nacks) parameter?

EDIT2

I found this, maybe it can help you: https://gitlab.com/billhibadb/reaver-wps/issues/203


Your client should check response for errors regardless error source: be it proxy error, server error or TCP error.

Your should simulate web server (the way you do it depends on your favorite language and environment) and check following situations:

404, 403, 500 and other non-200 error codes. You can check status codes like "moved permanently" as well.
Junk response (not even valid HTTP, i.e. stream of random bytes)
Valid HTTP with junk inside (if you wait for json, then send .png as response body)
Interrupted response (send valid respond but disconnect client after sending 95% of it)
Timeout (accept request and make client wait for 40 seconds before answer)
Huge bomb (send 500 mb as response)
Response with logic errors (i.e. if you wait for positive integer "age" field in JSON, try sending "-9000" or "abc123" or random 500 bytes for it)

If all these cases are handled correctly, your client is ready for any proxy error, I believe.


Is it possible to detect a Telegram user by sniffing traffic?

Telegram is not a peer-to-peer network like Tor, but has central servers. Indeed, if you have full control over the network you can do all sorts of evil.
Once you get a list of known Telegram servers, you can monitor them and get a detailed record of who connected to the network at what time. You have both source and destination IPs.
Now, I assume the following may happen:

A phone is seized from an activits, giving the cops access to the subject's Telegram groups

Cops already gathered a timestamp archive of connections, now they have access to the contents of the chat. If they find content of interest, they may compare the timestamp of the picture, and the approximate byte size to the connections made that time. Eventually, they will get a short-list of people to investigate

Cops enter the chats

Pure and simple social engineering. Like Europol often does to hunt down child abusers in encrypted chats. Once they are in, they can get live information about who may be posting on certain chats.
The points is that this approach does not directly identifies an individual, but provides authorities a list of suspects short enough to proceed with more human ("classic" police) approaches


Does DNS allow third parties to register subdomains?

Short answer: No, third parties can't register a subdomain without authorization from the owner of the domain.

DNS is a hierarchical system, ordered from right to left in the hostname. Whoever has a given domain name registered controls the authoritative name servers for that domain. This means that all queries (that aren't answered from cache) for that domain or one of its subdomains will be directed to that organization's DNS servers, giving them full control over all subdomains. They can, of course, choose to delegate this control to someone else if they wish.

For example, if I were to register reirab.com, if someone queries subdomain.reirab.com (and no cache is involved,) what would happen is this:

Their DNS server would first ask the root servers for the first domain from the right, i.e. com. They would be returned a DNS NS record telling them the authoritative name server for com.

Their DNS server would then submit a request to the com authoritative name server that it discovered from the previous request for reirab.com. It would again get an NS record response telling it the authoritative nameserver for reirab.com.

Their DNS server would now submit a request to reirab.com's authoritative name server for subdomain.reirab.com. Since I would own reirab.com, I would have full control over this authoritative name server. It would either be a server that I myself own or one that is hosted by a third party on my behalf. The only subdomains that could possibly be returned (authoritatively) for this domain are the ones I myself have created records for on that authoritative name server. The only way for someone else to register a subdomain of reirab.com would then be for them to ask me to set it up for them, since I own the authoritative name server for reirab.com and all requests for its subdomains would be funneled through my server.

If I did want to delegate control of some subdomain to someone else, I would do it exactly the same way my registrar delegated control of reirab.com to me: with an NS record. By adding an NS record for subdomain.reirab.com to reirab.com's authoritative name server, I can authoritatively direct requests for subdomain.reirab.com and any of its subdomains to the name server listed in that NS record, which would be controlled by the organization to whom I delegated control of that subdomain. I could revoke this delegation at any time by removing or altering that NS record.

By the way, 'www' is not treated specially by DNS. It's just another host name in its domain's authoritative DNS server. It's only by convention that we put the host (A or AAAA) record for that organization's web server there. The A record for www.exampledomain.com and somethingelse.exampledomain.com both most likely lie on the same server: exampledomain.com's DNS server.

Note: This answer has intentionally simplified things a bit for the case of someone requesting a DNS record from the Internet. If a request for a domain comes from within the domain's organization, the request will likely be resolved directly by the organization's name servers without going up the chain to root-servers.net, the TLD's name servers, etc. In this case, a host name could potentially even resolve to something different than what it would resolve to from the Internet, if the organization so chooses.


Is my router vulnerable if WPS is enabled but WPS pin code is disabled?

If Netgear has implemented it properly, WPS Push-button-connect should be secure.  However, I have no idea whether Netgear has implemented it properly, and if they haven't, you might be insecure.

The known attack on WPS is described in this paper:

Brute forcing Wi-Fi Protected Setup, Stefan Viehböck, 2011.

For another great explanation, see also:

How The WPS Bug Came To Be, And How Ugly It Actually Is, Dan Kaminsky, 2012.

The attack described there breaks the PIN-based forms of WPS.  It is not effective against a properly implemented version of WPS Push-button-connect (PBC), because a remote attacker cannot physically push the button your router, and WPS PBC requires someone to press the button before it can proceed.

Therefore, if Netgear has implemented WPS PBC correctly, and has properly disabled all the other forms of WPS, you should hopefully be safe (fingers crossed).

(Do make sure you are running the latest version of the Netgear firmware.  The WPS attacks were only discovered less than a year ago, so versions of the firmware written before the attack was discovered are very likely to be vulnerable.)

That said, router vendors have screwed this stuff up before.  The bad track record, and the fact that it is not easy for an average user to tell whether they've finally gotten it right this time, does give some room for concern.  I think it would be understandable if this makes some security folks throw up their arms in disgust and say "oh, to heck with it, just turn off WPS, I don't trust the router vendors to get this right".

So, how much do you trust Netgear to not screw this up?


Unique Touchscreen Authentication Schemes

Some thoughts:

I would look to the Blackberry 10 lock screen for inspiration. They are already doing something very similar; as far as I've used it, you set up a number (say "9") and a point on your background image (say the center of the padlock). At login you are given a randomized grid of numbers then, by grabbing anywhere on the screen, you drag the grid of numbers so that any "9" lines up with the center of the padlock. This nicely protects against shoulder-surfing - even if they can look at the finger smudges after - since they have no idea which number you lined up with which point in the image.

Since your question has strong User Experience / User Interface vibes, you may want to also post a similar question in the User Experience Stack Exchange.


Should I make my api calls to update users contain a password or hashed auth key?

should I make the API retrieve an auth token or the users password
  before the details are updated?

NO because I am assuming that this backend app will be used mainly by the web admins/operations and why should they have access to the user's password or auth token?

Also, whoever is going to use this app must login to the system themselves
and you should log the API Calls they made.


Is it secure to mount Veracrypt without sudo password in this way

This is extremely insecure. I'm glad you asked elsewhere before running this setup yourself! I hope those 3000+ people on AskUbuntu were similarly cautious. So, why is this insecure? What can an attacker do if you put them in the group? That group will be able to elevate privileges to root. The reason is simple: VeraCrypt allows mounting an encrypted volume of arbitrary file permissions, using an arbitrary filesystem with arbitrary mount flags. Consider the following scenario:

An evil user is put in your special group, letting them run VeraCrypt as root without a password. This user wants to exploit your setup to get a root shell, allowing them to run commands other than /usr/bin/veracrypt as root. Their final goal is simple: bypass the restrictions you have in place and run arbitrary commands as root.

An encrypted volume is created, owned and writable by the evil user. It is formatted, and a bash binary is copied to the filesystem. As the volume is directly writable, the setuid bit can be set on the binary. This is normally impossible, but our attacker can modify the volume.

The evil user runs VeraCrypt as root and mounts the volume to /mnt (a normally privileged operation). They run /mnt/bash and get a root shell, from which they are able to execute any command as a privileged user. They have their root shell and can execute anything they want.

Normally, a user-mountable filesystem will have several restrictions in place. Such filesystems are typically configured by mounting with the user flag. According to the mount(8) manpage:

user

Allow an ordinary user to mount the filesystem. The name of the mounting
user is written to mtab so that he can unmount the filesystem again. This
option implies the options noexec, nosuid, and nodev (unless overridden
by subsequent options, as in the option line user,exec,dev,suid).

When a filesystem is mounted by an unprivileged user this way, despite the fact that they can create a filesystem with a setuid executable, the system will not honor the setuid bit when the filesystem is mounted. VeraCrypt has no way of knowing all this, and happily mounts the writable filesystem as root, with full support for setuid binaries. This safeguard is bypassed, and the attackers gets root, despite you only allowing one "safe" command via sudoers.
I'm sure there are other possible attacks as well. Does your filesystem have any mount flags that, on their own, can give an attacker root? Can keyfiles or new volumes be written to arbitrary locations? If so, can their contents be chosen by the user? When you bypass an important safeguard, you suddenly must rely on the designers of VeraCrypt writing the program in such a way that it protects from a threat model they never even considered. Unlike the mount program, which was designed from the start to be safe even when run as root by an unprivileged user, VeraCrypt had no such goals. The same considerations should apply to anything before you run it as root.


Using Refresh Token inside of Access Token without HTTPS

I will quote parts of the question and try to answer them.

  I previously read that Access Token must be sent with every request to
  the API but Refresh Token must be sent ONLY when the Access Token
  expires.

No, the refresh token is not supposed to be sent to the API. A refresh token is sent to the authorisation server to obtain a new access token.

  when a client sends a request to my API, the Access Token (JWT) will
  be sent to the server, if it's expired, then a new Access Token will
  be sent to them with a newly-generated refresh_token alongside with
  the HTTP Response of the requested resource (after doing some
  validation).

This defeats the whole purpose of a refresh token. The idea for a refresh token is that to keep access token lifespan shorter (to minimise the time available for reusing access token in case of a disclosure). When an access token expires, the access should be rejected outright. Also, issuing access and refresh tokens is the responsibility of the authorisation server not the resource server (your API).

If you prefer to use only a single token, you should take a look at the OAuth2 implicit flow. In this flow, only the access token is issued and you don't have to deal with a refresh token. However, this means that every time the access token expires, you need to redirect the user to the authorisation server to obtain new access token if required.

  is the conventional OAuth model must be strictly used over HTTPS? Is
  forcing HTTPS is my last resort?

Yes, you must use HTTPS. Tokens must be protected in transit as well as in rest. A leaked token means that the attacker will have access to your resource server.

I heavily recommend to read RFC 6819 that explains the OAuth 2.0 threat model and different security considerations.


How to prevent user from recovering my iPhone data?

Using the built-in wipe function is fine for casual use/reselling of a device.

Settings -> General -> Reset -> Erase All Content and Settings

However it is not necessarily proof against forensic data recovery. (It could be, but I don't know whether it is. Typically for most devices it wouldn't be).

On the other hand, if your life  - or anyone else's - is at stake, you should destroy the device, not resell it. Grind the device to dust. Heating the whole thing in a charcoal fire to a red heat should work too. (Be careful - the battery will probably explode.)

Typically, deletion involves rewriting bookkeeping data to mark portions of the disk as unused. It doesn't actually overwrite the data. To be secure you must overwrite the data or specialised software or hardware can read the data directly bypassing the bookkeeping functionality.

To achieve this you have to write data until the device is full. Depending on the filesystem it may even be more complicated than that. But for a poor-man's version, you could use the system erase function, then fill it up with files using the PC connection. Then wipe it again. You will have to do that several times to beat the wear-levelling algorithm.

This will be better than the standard system wipe, but still will not be perfect.

If you need a perfect wipe, complete destruction is the only way I would recommend.


Authorize transitive communication between applications on behalf of the user

Since (I hoped) I couldn't be the first person ever to be in this situation, I've managed to find several references on the web talking about "delegation" grant types:

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10#section-1.1
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-on-behalf-of
http://docs.identityserver.io/en/release/topics/extension_grants.html
https://auth0.com/docs/tokens/delegation

This is exactly what I was talking about in my idea. Hope this might help other people with in the same situation.


Can your internet provider monitor your data (passwords, etc?)

Was typing in my password into an HTTPS website
...
When I type in
Username123
Password123

Can the internet provider see it just like that?

Typically, no. The application-layer data you mentioned (username/password) is encrypted via Transport Layer Security (TLS) as it is passed from the application-layer to the transport layer.
In principle, only the web site to which you are sending the data can decrypt the data, because only that site has the private key associated with the public key you used to encrypt the data.
I'm putting in some caveat language like "typically" and "in principle" because there are situations where the ISP or other attacker could possible still steal this data. For example, if the ISP is performing a man-in-the-middle attack. But assuming the ISP doesn't have an signed/trusted certificate (signed certificate having a certification path leading to a one of the trusted root certification authority certificates installed on your computer) for the web site of interest your browser would (typically) alert you to the attack. And, of course, if your ISP (or other attacker) has an agent running on your local machine (or made you install their own CA certificate into your trusted CA certificate store) then all bets are off.
In principle, your ISP will only have to know the IP address of the website (network layer info) to route your data. The application-layer data (e.g., user/pass) is already encrypted via TLS at this point, so the ISP shouldn't be able to view it. However, certain other application-level data such as the domain name could still be leaked (e.g., if the certificate uses SNI) or reconstructed.


How does someone conduct a risk assessment of a B2B Integration?

You conduct a B2B integration risk assessment the same way you generally do any other risk assessment. What are the risks of connecting your enterprise system with another business' enterprise system? What do you allow them to do in your system? Do you restrict them from accessing systems they shouldn't with ACLs? Do you make sure there are no shared accounts they use to interact with your system? Do you log all of the activity they do within your network? All of the things a framework like NIST does for your entire enterprise can be pointed at that connection with the other business.


The only security threat with this product is someone stealing it.  Without a network it has no remote attack surface.  Without long term storage there is really nothing to hack.

It does have a password,  but who cares?  Probably one of the least useful password protected resources I have heard of.  It has USB host,  and so you might be able to corrupt memory with a specially crafted usb device or video files,  but again this is attack is worthless because no one cares.  This is not a strategic resource.


SSL Certificate pinning with Self Signed Certificates

I think you've misunderstood how TLS and certificate pinning works. The client will not specify which certificate the server will return (apart from using SNI extension to set the expected hostname) but the server will return exactly the certificate which should be used by the client to identify the server. The client will check in your scenario of pinning with a self-signed certificate if the sent certificate matches the expected certificate.

Sending this certificate within a full handshake (i.e. not resumed) is not optional when certificate based authentication is used, i.e. there is no way to make the server not sending the certificate (but still proof the possession of the matching private key) because the client already knows it. For more details take a look at How does SSL/TLS work.


I assume that you want identifiers which are:

unpredictable: external entities ("attackers") must not be able to guess the next identifier, even given knowledge of all previous identifiers;
unforgeable: it must not be possible, from the outside, to "get lucky" and produce a valid identifier;
unique: each generated identifier should be distinct from all previously generated identifiers.

What makes a given identifier "valid" is, ultimately, that it is registered on a the server as such. In some contexts, you might want to be able to verify validity without having to talk to a database.

There are several methods:

Use randomness. Generate a sequence of bits from a cryptographically strong PRNG. If you get enough bits (i.e. 128 bits or more), then the identifier will fulfill the properties above with overwhelming probability. Most operating systems offer an appropriate PRNG (e.g. /dev/urandom on Unix-like systems).
Use a counter and a key. Let the generating server know a secret key K, and a counter C. The key is for a block cipher such as 3DES. When you want to produce the next identifier, increment C, then encode the new C value as a block of the size needed by the block cipher, and encrypt it. For instance, 3DES uses 64-bit blocks. Thus, take the counter value (an integer in the 1 to 1000000 range), encode it as a 64-bit integer (which will thus begin by a big bunch of zeros), and encrypt that, yielding a seemingly random 64-bit value.

The second method has the advantage of allowing verification by knowing the key K, without having to check in a database: decrypt the 64-bit identifier (with K), and see if this yields an integer in the expected range (1 to 1000000). The attacker, not knowing K, will have a hard time producing an "identifier" which, when decrypted, falls into the expected range. The method with a block cipher also allows for shorter identifiers, because it guarantees uniqueness through the fact that the block cipher is a permutation.

Let's put some numbers on that. You expect about one million identifiers, which is close to 220. Your identifiers have length n bits. An attacker choosing a random identifier has probability 2-n of "guessing" the next identifier, and probability 2-(n-20) of guessing one of the valid identifiers that the server will generate throughout its life. You have to choose n depending on your constraints (you want "security", but you probably also want to keep the identifiers small).

With the random selection of identifiers, you may encounter collisions if you generate identifiers which are too small. Very roughly, since you will produce about 220 identifiers, probability of encountering a collision will be about 2-(n-39), so you will want to use n ≥ 64. With n = 64, you have probability about 1 in 30 millions that you will ever encounter one collision throughout the server lifetime: that's probably low enough risk to be tolerated.

With the encryption method, you can tolerate a much shorter n: at least 20 bits (if you just want to make the next identifier unpredictable), more if you want to prevent the attacker from producing valid identifiers (not necessarily the next one, but one of the 1 million identifiers that your server will ever produce). This method, though, has some implementation issues:

It needs a secret key to be generated, stored, kept safe, but not lost if a hard disk fails. If the server uses multiple front-ends or back-ends, then the key will have to be shared between the relevant machines.
It uses a counter. There again, counter management can be difficult, or be a bottleneck, in multi-machine architectures.
There may not be an available standard robust block cipher with the block size that you wish to use. There are theoretical ways around that but nothing standard and well-vetted yet.
It uses cryptography, which is always a slippery path. Don't invent your own crypto. If possible, don't implement your own crypto either. These things are hard.

The easy way is to use randomness. Some systems offer UUID (known in the Microsoft world as GUID). The "version 4" UUID are generated with a PRNG, containing 122 bits worth of randomness, which would be sufficient for your needs; however, there is little guarantee that any given system which produces UUID values really uses a cryptographically strong PRNG. Indeed, there is a big difference between something which ensures uniqueness between collaborating users, and a system which is unpredictable.

So use a strong PRNG explicitly, and get the bits. "128 bits" is the default all-purpose size. As was explained above, chances are that you could use less bits, e.g. as low as 64, but that requires thinking and quantifying risks; it is much simpler to just produce 128 bits and be done with it.

If you need shorter identifiers for some reason (e.g. a human user will have to type them on a smart phone...), then you may envision a system with a block cipher, but this is fraught with perils. You will have to understand thoroughly what you are doing. Thus, this is possible, but most probably expensive (thinking time is what costs the most in software development).

In all of the above I talked of bits. That's because bits are what the machine is using internally. Ultimately, you want characters: this is obtained by simply encoding the bits with an ad hoc method, e.g. Base64. With Base64, each character is worth 6 bits, so 64 bits become 11 characters (actually 12, because Base64 mandates a final size which is a multiple of 4 characters, but the last one will always be an '=' sign). With 128 bits, you get 24 characters (the last two being '=='). Other encodings are possible, e.g. hexadecimal or Ascii85. That's really up to you. Base64 has the advantage of already been implemented in most programming framework.


Log shows many hits to non existing content - hacking?

That is the background noise of the Internet: a bot scanning for commonly used admin interfaces, potentially vulnerable pages and software and well-known PHP backdoors.

In itself, this doesn't gives you any indication about the status of your server: it just tells you that a bot scanned it for common PHP entry point. It doesn't indicate if any was found, if any of the (potentially) detected entry point is exploitable, if any (potentially) vulnerable entry point was successfully exploited nor the extend of any (potential) breach.


I think that -Tfields -eframe.protocols would be the closest thing you'll get.
The output looks something like this:

eth:ip:tcp:http
eth:ip:tcp
eth:ip:tcp:http:media
eth:ip:tcp
eth:ip:udp:nbdgm:smb:browser
eth:ip:tcp
eth:arp
eth:arp
eth:ipv6:udp:http
eth:ip:udp:http

As it can be seen the information displayed will vary a bit depending on which protocol dissector gets to play. So you'll need to do some post-processing to cut the parts you don't need and/or dedup (for instance using @Mark's suggestion in the comment).


What does the Juniper backdoor actually allow an attacker to do?

As the exploit gives root access to the Juniper device, an attacker can:

Decrypt all VPN traffic to the device, thus allowing viewing of all traffic through encrypted tunnels that terminate at the Juniper box
Edit firewall rules on the box, allowing an attacker to remove rules protecting assets within the network
Alter routing tables where these are used, perhaps redirecting traffic
View logs stored on the device
Edit logs on the device to remove any trace of compromise


What's this type of leak detection method called?

I believe the term you're looking for is a "canary trap", which is a form of offensive counterintelligence.

This is similar to a suspected double-agent being given false information, which they then leak back to their handlers. This can then be used to show that the agent, being the only one told that information, was the real leak.


How to force browsers to accepte all further SSL certificates

They are designed specifically to not allow this. As you brought up yourself, that would be a massive security risk.

If you want to be able to browse your own systems without clicking "confirm security exception" a million times, add the certificates to your trust store on your computer, using the "Certificates" MMC snap-in.

This can be done even better if you create your own CA, generate the certificates for your systems from that CA, then install that CA's certificate as trusted.

If you're in a domain environment, you can even create group policies to deploy the trusted certificate settings to as many computers as you want, automatically.

This way you trust your own resources without buying certificates, and don't break your internet security.


Aren't keyfiles defeating the purpose of encryption?

If decryption only relies on the keyfile and this keyfile is readily available, there is indeed no significant security benefit in your setup.

What you can do though is store the keyfile on a removable device (e.g. a USB stick) and detach it when you are not around. That way decryption is only possible when you are present and the removable device is attached.

Storing the keyfile locally makes sense if you want to ensure that a removable device can only be decrypted on your system. You can distribute the keyfile to other systems as well if you want to use the encrypted device in different places. If you lose the removable device in transit, little harm is done, because it can only be decrypted on a system that has your keyfile.


Is making a clean install enough to remove potential malware?

It is possible for malware to persist across a re-format and re-install, if it is sufficiently ingenious and sophisticated: e.g., it can persist in the bios, in the firmware for peripherals (some hardware devices have firmware that can be updated, and thus could be updated with malicious firmware), or with a virus infecting data files on removable storage or on your backups.

However, most malware doesn't do anything quite this nasty.  Therefore, while there are no guarantees, re-formatting and re-installing should get rid of almost all malware you're likely to encounter in the wild.

Personally, I would be happy with re-formatting and re-installing.  It's probably good enough in practice.


No.
Encrypted correlations between entries require decryption, and are therefore slow. Yet, non-encrypted correlations are forbidden by requirements. It follows that you're forced to use a slow scheme.
Possibly acceptable workaround: split the logs
Use a different encrypted table for each user, with table name selected at random and stored as an encrypted profile property. In systems where encrypted tables are decrypted on-the-fly in memory for each user, this will achieve performance.
The only information leaked is the number of users, which is probably known anyway from the size of the user table, and the fact that some users may have more or less log entries than others. Observation of table sizes will allow to determine which unique identifier maps to which user, but no more.
Possibly acceptable workaround: obfuscate the correlation
Instead of a one-to-one relationship, you might consider employing a one-to-many relationship, where user N can generate any ID at random of the form NP+RAND(P-1). User N's records are all those with ID in the [ NP, (N+1)*P-1 ) range and can be retrieved with a BETWEEN clause. An attacker's inspection of the table will reveal a weak correlation between records, with on average TABLESIZE/P duplicates which will all map to the same user.


Are you denying outbound or only inbound?  My memory of linux IP tables is a bit rusty, but it sounds like your inbound is deny all while your outbound is permissive.  Basically, the most common mode is that any external system requesting in (which is what nmap checks) will be denied, but if an internal connection makes a request out, it is permitted.  It is also worth noting that ports are asymmetric.  Just because you connect to a web server on port 80 does not mean that the connection back to your computer is on port 80.  It is fairly typical for random high number ports to be used for establishing connections.  The port numbers like 80 are used to give a common point to connect to.


How to simulate DDoS attacks from the Internet?

I think you seek the use of a packet generator and a corresponding number of systems generating packets to match the load you seek. Use random valid IP addresses for the packet source addresses and you should find yourself quite annoyed when it comes time to filter.

You can do all of that without ever sending a bit across your ISP's link. If you get DDOS'd in such a way that bandwidth is maxed out rather than services, then your ISP will need to choke off the traffic prior to it reaching your link.


Does having a separate e-mail account only for security, increase security?

It is not a bad idea, but the key point here is not just having a separate e-mail but to enforce compartimentalisation of access. Here's a scenario:

you have your regular e-mail on @gmail
you have your "secure" e-mail on @hotmail (oh well..)
you check both e-mail from the same web browser
that browser is not up to date, or you stumble upon a 0-day vulnerability that compromises your system and end up with some malware installed on your machine

Surely an attacker cannot access your secure e-mail remotely; they just have to wait until you check it from your insecure browser, and capture the keyboard, or take screenshots, or what not.

As you are aware, there's no silver bullet in computer security; it's a matter of risk analysis and deciding what level of protection you want.

For example, you could (in increasing order of security/paranoia):

open the secure e-mail from a different web browser (making sure it's up to date)
...or from a different machine (physically separated)
...or limit your 'insecure' web browsing to a VM

Further alternatives include toying with virtualisation (think Qbes OS), etc.


What exactly constitutes a scanning-threat on a Cisco ASA?

TL;DR Scanning-Threat should not be thought of as a new feature, more of an enhancement to Threat-Detection.

I think these links could possibly help you, however considering you seem to have done the research you might've already come across them

Threat Detection Configuration

Threat Detection Cisco

Here is a list of what can cause a Threat-Detection trigger:

ACL Denial
Bad Packet Format
Exceeded Connection Limits
Denial of Service (DoS) Detection
Basic Firewall Check Failure
Suspicious ICMP packets Exceeded
Application Inspection Packet Failure
Interface Overload
Scanning Attack Detection
Incomplete Session Detection

A Scanning-Threat is not the same thing as Threat-Detection, you need to think of Scanning-Threat as an enhancement/addition to Threat-Detection to provide additional security capabilities. It allows you to keep track of "suspected attackers" when too many connections are created in a subnet and by default this feature is disabled.
A nice thing about Scanning-Threat is the fact that it builds a database of target IP addresses that are suspected to be an attacker. As per the Cisco documentation, below is a nice example of what Scanning-Threat can do.

When Scanning Threat Detection detects an attack, %ASA-4-733101 is
logged for the attacker and/or target IPs. If the feature is
configured to shun the attacker, %ASA-4-733102 is logged when Scanning
Threat Detection generates a shun. %ASA-4-733103 is logged when the
shun is removed. The show threat-detection scanning-threat command can
be used in order to view the entire Scanning Threat database. - Cisco Scanning Threat


With HTTPS, what information would a MitM attacker be able to glean?

In an SSL connection, the GET or POST portion is encrypted. For example: visitor: https://www.yoursite.com/shoppingcart.aspx

www.yoursite.com          visible
GET /shoppingcart.aspx    encrypted
HTTP/1.0                  encrypted

What you're thinking about is called an inference attack, where with little bits of information, an attacker can put together pieces of a puzzle. So you ask:

  If the hacker knows what the site does and what is expected to be
  downloaded or posted to it, I would guess he'd be able to work out
  roughly what the user is doing just by the data size of each https
  request/response.

This is not necessarily the case. Again, since both a GET and a POST is encrypted, it would be a worthless guessing game to an extent. Consider the following:

Example A

Site contains 1mb file called topsecret.docx
Visitor uploads a 1mb video of cats

What you will see:

Site <--> 1mb session <--> Visitor

Because the GET and POST are both encrypted, there is no way for you to determine if the user downloaded or uploaded. All you are seeing is a 1mb exchange. Any attacker would be wasting a lot of time and resources playing a guessing game however, consider a third site in the mix.

Example B

Site A contains 1mb file called topsecret.docx
Visitor does something
Visitor visits Site B
Site B now contains topsecret.docx

What you will see (of course via network sniffing):

   Visitor <--> Site A (1mb session)
   Visitor <--> Site B (1mb session)

If you could find the same documents on both sites, you could infer that visitor went to site a, downloaded a file, then visited site b where the file appeared. You could md5 it to further document proof however, you'd need to find the initial file. Otherwise visitor could have went to both sites, and uploaded or downloaded cat videos.

It would be easier for someone with the resources to pull off this kind of attack, to just outright MiTM the sites with stolen certs, sslstrip, or some other trickery versus playing a guessing game.

MODIFIED TO ANSWER Lekensteyn's comment

Lekensteyn, I added a fictitious example to illustrate a point. And it still holds true, so I will give you another example

Site A contains 2 files (File1 (1mb) and File2 (200mb)

Visitor <--> download File2 <--> SiteA

In the above, the visitor is downloading a 200mb file and upon starting he stops the session at say 1mb. Because you cannot see what he did, traffic analysis shows the session was a 1mb connection. What you will see:

Visitor <--> 1mb session <--> Site A

Would you be willing to bet your last dollar the visitor downloaded File1 based on the size? In my example, I used a crude mechanism to illustrate my answer. There was a lot I could have gotten into detail with but I choose not to for brevity


Committing encrypted passwords but not usernames

You should never be committing secrets to source code of any kind, encrypted or not. The username to authenticate into your server is probably a bit much in terms if sensitivity on its own, let alone a password even if it is encrypted. (As an aside, it sounds  like you’re storing your password insecurely - more on that below.)

I would highly recommend integrating instead with a secret storage system.

This is for a few reasons. First and foremost, source code can get lost. You can make the repo public accidentally, an attacker can get access to it while private, you can accidentally give the wrong person access, etc. - and the beauty of version control is that it’s a permanent record, so as long as a secret is in your version history once, it’s there forever.

Furthermore, humans are exceptionally bad at managing information - bad enough to need an entire highly skilled industry on simply information security - and very very prone to making mistakes. So as long as a human can touch it, and mess it up, and possibly steal it, it’s wise to build as though they will. The solution then is to reduce the number of humans who have access to the tasty treats, and the best way to do that is to automate it.

Also, you may want to reconsider how you’re protecting your passwords. Although private key encryption is strong and AES-256 is, of course, quite cryptographically secure, hashing and salting passwords is generally better practice. Aside from being more performant, you never want to be able to decrypt a password like this (because if you can do it, then the decryption key can get lost and someone else can now do it too). Salting and hashing (using a standard library like bcrypt, scrypt, PBKDF2, etc.) is better practice.

Finally, passwords are scary and this sort of thing matters. Please keep in mind this is only general information, varies by system, and might be entirely wrong if applied to your situation. So take this information with a grain of salt and skepticism and don’t make any decisions off of it.

Good luck!


In both OAuth and UMA, a protected resource is conceptual, though ultimately based on the notion of the "web resource" primitive in web architecture. The user (resource owner) is not the resource. The digital data or other "stuff" the resource owner wants to control access to is the resource.

Many OAuth deployers talk about everything at a resource server as "the protected resource" (PR), so a whole API tends to be thought of as one resource. UMA was specifically designed to enable multiple protected resources (and for each of those to be able to have different scopes as warranted), to allow for use cases such as files and folders vs. just API endpoints. So things are more flexible (and therefore complex) in UMA, out of the box.

The UMA Implementer's Guide has a section called Considerations Regarding Resource Server Permission Requests with some examples of scopes that, in passing, may suggest additional types of protected resources to you.

This section in the UMA FedAuthz spec discusses how it's the resource server's job to design protected-resource boundaries: "The resource server defines the boundaries of resources and the scopes available to each resource, and interprets how clients' resource requests map to permission requests, by virtue of being the publisher of the API being protected and using the protection API to communicate to the authorization server."

An example I deal with frequently is a consumer (or clinical) IoT device. The question that arises is: Should the whole device (basically its entire API) be one resource? Or, how should resources within it be broken down? For example, each set of "live"/streaming data coming off the device might be one resource the user will want to control. Sets of historical data already stored in the cloud might be other resources. Device functions (pan camera, turn device off/on, whatever) might be another single resource, controllable through scopes.

Some of the boundary design considerations here have to do with usability. (Perhaps similar to the process of choosing Google Apps Share button dropdown items!...)

Some background about definitions: OAuth (IETF RFC 6749) informally defines a protected resource as an access-restricted resource. UMA2 adopts OAuth terminology along with a few enhancements; its Federated Authorization spec also formally defines how to effect resource protection: "Protection of a resource at the authorization server begins on successful [resource] registration and ends on successful deregistration."

I hope this helps!


I don't think the discussion needs to be about IDS and EDR specifically. The concept you are going for is called "defense-in-depth", or the Reason Model (a.k.a. the Swiss Cheese model).

There is no perfect defense, so layering defenses helps to reduce how successful a threat is at causing loss.
And EDR and NIDS can have different scopes.

If NIDS is just on the perimeter, then you still need EDR for host-to-host threats
If EDR cannot be placed everywhere, then NIDS is required for common defense

It's not about if one is better than the other. There is no "silver bullet". It's about the threats and your risks and finding the optimal controls to counter threats and lower your risks.
So,

Is there any advantages in using a Network Intrusion Detection System,
when already having a EDR solution?

Yes. Quite simply, if the EDR solution does not lower your risks acceptably in your context.


Does port knocking increase security behind a router?

Portknocking is done with closed ports.

https://wiki.archlinux.org/index.php/Port_knocking

This means that no one can witness the sequence of ports opening up.

The port that gets opened is opened for the IP that knocked correctly.

Yes, this increases security because you limit the threat surface for scans and probes. The technique to open the port is weak in terms of security, but a closed port is a lowered threat, in general.

As for products that do this, because this is a really niche request, I doubt commercial products will offer port knocking, but custom firmware exists that will enable a router to do port knocking.


How to use Wireshark to capture HTTP data for a device on the same network as me

You should check this man page, but as far as I understand it you need to be in promiscuous mode and not monitor mode to be able to inspect the packets payload.

Monitor mode of your WiFi card will allow you to capture packets outside your SSID but I suppose at this point it's useless since you're anyway already on the same network.


HTTPS form submissions are blocked on corporate networks

Data doesn't really get lost but error messages in communication protocols might not be passed to the user by web applications or browsers.

You need to debug the problem on a lower layer. To see the actual communication between browser and web-server you can use an interception proxy such as Burp or Paros Proxy. These proxies will show even encrypted HTTP communication. You can see where the data is being sent and what is the response of the server. If no data is being communicated then the problem is on a lower layer.

Using Wireshark, you can debug TCP and SSL communication issues. This is the layer where most firewalls operate. Even firewalls that block traffic may send some data to show why a packet was blocked.

Using a less known CA should not be a problem except for very paranoid firewalls. There are many less known CAs as you can see from this map and Starfield is also issuing Extended Validation Certificates.


Is there any real protection against Google on Android phones?

One could build a custom AOSP based ROM with no google services, API's.
I have come across ROM's that do this, cannot guarantee on the completeness since I did not test it myself .


It looks like that with Chrome (but not Firefox) you also need to explicitly allow 'unsafe-hashes' since giving the hashes alone seem to apply only for script and style sections and not attributes. See 8.3. Usage of "'unsafe-hashes'". With that your CSP should look like this:

style-src 'self' 'unsafe-hashes' 'sha256-7kYG54iPGE/Vf+GFqobEwpF9bfCAVA/elCz7OiSmMl0=';

For more discussions about why Chrome decided to behave this way see this Chromium issue and this W3C issue.


How to safely extract hashes from domain controller for auditing?

For safely dumping the hashes, this Optiv reference outlines a number of methods. The most likely of which for your use case is probably to use ntdsgrab.rb to make a volume shadow copy, and then extract NTDS.dit from that shadow copy. Depending on the environment, this may or may not be more subtle than invoking the native vssadmin.exe utility.

For secure transport, as of September 2016, Metasploit's transport control lets you specify encrypted transport methods, including using -t reverse_https to use an encrypted HTTPS connection.


Unusal GET requests in my nodejs journal - has my nginx/node been hacked?

This format is used by a kind of HTTP proxy.
Unless your server is actually misconfigured or hacked to be used as a proxy (you should get rid of the browser limitation and test it out), it may have the following possibilities:

Someone is scanning a wide range of IP addresses for open proxies.
Someone is testing the availability of an open proxy once existed before you created this server and this IP address is allocated to it.
Someone who happens to know your website is testing the keyword filter (note: not the only filter) between mainland China and the rest of the world.
Someone tries to get your server blocked from a specific IP address in China by a few minutes. Usually not a big problem because it could only block the sender's own IP address (as I know). But I've heard rumors that a malicious software maker uses this method to block an overseas potential competitor (but never knew a confirmed case). In this case there must be a lot of such requests from different IP addresses in China, which may already be a kind of DDoS to make it actually working, unless your users are from a very small group that all already have the other software installed.


It's a bad idea to host a database server on your internet facing webserver.

If the underlying OS of your web/DB server, or webserver platform itself contains any vulnerabilities that can be exploited then your database will be compromised.

  I won't be broadcasting the IP address of my database because I won't
  be sending calls to it, which makes my database inaccessible to the
  outside world.

This is not true. If your web application is vulnerable to SQL Injection it doesn't matter where your DB resides on the network, it will be directly accessible and exploitable from a client on the internet.

Ideally your application would be designed around an N-Tiered Architecture with each tier residing in a different DMZ. Preferably each tier would also contain network monitoring equipment to enforce protections and alert on suspicious activity. (WAF, IPS/IDS, Database Activity Monitoring, etc)

Image from: http://en.wikipedia.org/wiki/Multitier_architecture


Homebrewed security is dangerous
The thing you are describing already well developed with a multitude of publicly audited libraries and tools available for almost every web platform. A great place to start would be with oauth2. Even a service like auth0 might work, which would essentially be the "password server".
The danger of doing this yourself is that the concept of token-based authentication has a lot of subtle pitfalls that have already been analyzed, but you are likely to make (at least) one of several obvious mistakes.


Creating multiple secure and easy to remember passwords

What exactly is the issue with a completely random password?

Auto generated passwords should be changed by your clients upon first login anyway, so there will not be an usability issue. It is not a good practice for your clients to retain the initial password, as it would have to be sent to them in a plaintext format. For that purpose - one time login tokens would be much more secure.

A password containing two dictionary words IS NOT secure. A simple dictionary attack trying out various combinations of words would easily crack your password.


A penetration tester's job is to demonstrate and document a flaw in security.

In a normal situation, a pen tester will perform reconnaissance to find some vulnerabilities, exploit those vulnerabilities to gain access, then possibly extract some small piece of data of value to prove that the system is not secure.

The piece of data is often a part of the sales pitch for the company looking to fix their problems.  It's one thing to see a vulnerability and ask the boss for $10,000 to upgrade the firewalls.  It's a different thing to say to the boss "look at these results, the tester was able to get at our credit card numbers, which is a million dollar liability lawsuit waiting to happen! Please give me $10,000 to upgrade the firewalls."

Note that this doesn't say which vulnerability the tester will exploit, and the tester might be free to try anything from a social engineering attack to a WiFi sniffer to a physical break-in.

However, pen testers generally must work within limits or boundaries.  Often this is at the request of the clients:  "Please demonstrate that you can or can't get inside our network, but we don't want you to send any phishing emails to our employees."  And the security company may have a policy of never installing certain types of malware.  (There's little reason for a pen-tester to install a botnet client or to hide his tracks behind a rootkit, for example, unless he's demonstrating the need to scan for botnets and rootkits.)

Some clients will place many limits on the tests, such as "just test the security of my application server."  These clients may be under the impression that a hacker will be thwarted by the magical firewalls they bought that will protect the app server from every conceivable form of external attack.  Or it could be that they have a different team focused on firewall defenses, and a third team working on social engineering awareness campaigns.  The client may also ask that the pen tester not exfiltrate the valuable data - knowledge of the holes themselves is enough for them.

Either way, the pen tester must carefully stay within the limits given, even when the tester can identify a more effective avenue of exploitation.  The pen tester is usually only reluctantly given a position of trust, because they're often viewed as "criminal hackers".  By carefully documenting and exposing every flaw they exploited, they gain trust through professionalism.  If a tester sees a flaw he is not authorized to explore, he should point it out, but not explore it unless he first obtains permission.

Also note the goal of the pen tester is not to "install malicious software".  The goal is to demonstrate the adequacy of the security guarding information of value (credit cards, trade secrets, marketing plans, server administration, etc.)  Malware is just one technique used by hackers.

For starters, I would recommend you read, practice, and learn what you can at home and on line.  Check out the Certified Ethical Hacker books and training available.  Try to attend local, regional, or national security conferences and events.  You may have local "white-hat" groups like OWASP that have meetings you can attend and people you can meet.  You may also have a more "gray-hat" DEFCON chapter nearby, again, these would be people you could learn from.  These are all people who might be able to help you get into the business, if they see an aptitude or skill in you.


Security risks of using MongoDB ID vs a counter in URL?

I can't think of any real security risk to exposing the mongoDB id (versus some other counter id), other than exposing creation time according to the server to the users.  Having the mongo primary key vs some other unique key (like a counter) shouldn't make a difference in terms of exposure.

Granted you should be aware, the mongo _id consists of:

  a 4-byte value representing the seconds since the Unix epoch,
  a 3-byte machine identifier,
  a 2-byte process id, and
  a 3-byte counter, starting with a random value.

and possibly you don't want to expose some of this information to your users (like creation time).

So when you have the id 56ede7f0dfdsfdsfs2a7283 (which has a non-hex digit in there s and seems to be missing a hex digit at the end -- it should be 12 bytes or 24 hex (0-9a-f) digits, so I've replaced the 's' with '0'), I can tell from 56ede7f0 that it was created at 2016-03-19T23:59:44.000Z.  (See for example: https://steveridout.github.io/mongo-object-time/ or try: ObjectId("56ede7f0dfd0fd0f20a72830").getTimestamp() in the shell).


How to find a process that is sending HTTP HEAD requests

Try to use netstat -ano
It will list all connections to a TCP/UDP ports on your machine and also the PID.
Check with one will match your proxy TCP address.

Then use process explorer from sys internals to confirm what the process is doing and get more detailed information.


Chrome and Firefox showing errors even after importing latest CA certificate for Burp Suite

You get this error because Chrome expects a subject alternative name, as correctly stated in of the sources you've checked. This problem was fixed in Burp already. From the release notes for Burp version 1.7.20.

  Burp Proxy's generated per-host SSL certificates now include the site's commonName in the subjectAlternativeName extension. Apparently fallback to the commonName was deprecated by RFC2818 (in 2000), and browsers have recently decided to implement this.

But, you are using an older version.

  I am using Chrome 61.0.3163.100 on Windows 7 32-bit with Burp Suite v1.6.

Thus, you need to use at least version 1.7.20 to have this problem fixed.


Not sure why he didn't put it as an answer, but John Downey is correct, the PCI-DSS is what you are looking for.  It is the industry standard for protection of PCI (credit card details) in transit and at rest (in storage).


Is this a self rolled hashing/obfuscation method? Can you recognize the pattern?

I highly suspect this is a self rolled, or at least very outdated method.  It is very weak by modern standards and should not be used to protect anything important.

Short passwords could be cracked with no more than 2^64 brute force attempts, which is quite possible with even a normal computer.  If both halves of the result are independent, even with fairly long passwords, 2*2^64 brute force attempts could crack it (so 2^65 attempts). There are likely further weaknesses in the algorithm that make it weaker than described here.

Another interesting point to test would be 2111111111 and see if the second part of the result remains the same.  If the second part doesn't change, this is definitely a weak algorithm.

Edit:

Seeing that the results of the 2111111111 test are the same for the second half, this is definitely a weak algorithm and should not be used to protect anything sensitive!  I have included the relevant comparison below:

  1111111111 : FIcx3a00R4evxqEuQkZZtg==
  2111111111 : GPwnH80qEACvxqEuQkZZtg==

Edit:

Another interesting test would be what Ricky Demer suggests below:

  The next thing to check is that it handles the 8-byte blocks identically.  What are the "hashes" of aaaaaaaabbbbbbbbc and bbbbbbbbaaaaaaaac?     – Ricky Demer Feb 25 at 6:44

If it handled the 8-byte blocks identically, it is even worse for even long passwords, no matter what the length.  It would require just 2^64 brute force attempts as pointed out by Neil in the comments. Once someone made a table of what each possibility calculates to, this algorithm would be practically useless.  There are probably even more weaknesses to this algorithm remaining to be discovered.

Bottom line:

I do not recommend using this algorithm regardless of the results of the last test.  We have already seen enough to know it is weak.  Something with a higher bit encryption / hash scheme, salt, long computation time etc... would be much better, and I would recommend going with one of the existing thoroughly tested methods.  Self rolled encryption / hashing has not had the benefit of extensive testing that most of the main stream methods have.


How can the Android GraphicBuffer::unflatten() vulnerability (CVE-2015-1474) be exploited remotely?

The easiest way to understand the vulnerability is to look at the diff, dig through the code, and work out how you might exploit it.

The vulnerable method's signature looks like this:

status_t GraphicBuffer::unflatten(
    void const*& buffer, size_t& size, int const*& fds, size_t& count) {

The important arguments here are void const*& buffer, which is a buffer of data for unflattening, and size_t& size, which specifies the size of the buffer.

Keep in mind that size_t is typedef unsigned int, which means it's an unsigned integer. This means it cannot represent negative values.

The method starts as follows:

// if the size of the buffer is less than 8 integers, return because it's too small
if (size < 8*sizeof(int)) return NO_MEMORY;

// cast the buffer to an integer pointer type (think "array of ints")
// remember that the size argument is NOT an int, but a size_t - therefore unsigned int.
int const* buf = static_cast<int const*>(buffer);

// check that the buffer contains the right magic number at the start
if (buf[0] != 'GBFR') return BAD_TYPE;

// populate two size_t variables - these are the ones which cause the integer overflow later!
// note that this data is supplied by the calling application, so it can control it.
const size_t numFds  = buf[8];
const size_t numInts = buf[9];

So, as you can see, there's some cursory checking to see if the buffer is the right size. It then goes on to read more data from the buffer and populate two counts (Fds and Ints). These numbers specify how many values come after the header data.

Let's carry on...

// check that the buffer is large enough to contain the number of ints specified.
// notice that 10 is the number of ints read so far (buf[9] was our last access)
// so in order to store numInts ints, the buffer needs to be 10 + numInts ints long.
const size_t sizeNeeded = (10 + numInts) * sizeof(int);
// if the buffer isn't big enough, fail
if (size < sizeNeeded) return NO_MEMORY;

// if the count argument is less than zero, fail
// this is meaningless because count is size_t, so can't be negative
size_t fdCountNeeded = 0;
if (count < fdCountNeeded) return NO_MEMORY;

if (handle) {
    // free previous handle if any
    free_handle();
}

So far so good, mostly. It's checked to see that the buffer is big enough to have the number of "Ints" that the header claims. There's a pointless check for negative counts, but that's impossible anyway. Finally it cleans up any old handle just in case, to prevent handle leaks.

Now comes the vulnerability...

// if either numFds or numInts is nonzero...
if (numFds || numInts) {
    // read a bunch of fields...
    width  = buf[1];
    height = buf[2];
    stride = buf[3];
    format = buf[4];
    usage  = buf[5];

    // native_handle_create is just a wrapper for malloc'ing a struct which
    // contains a few metadata fields and the fds/ints data.
    // the function takes two ints as its parameters, so it can take negatives.
    // the underlying code does malloc(...+((numFds+numInts)*sizeof(int)))
    // and since nothing has checked if numFds < 0, this will make a buffer
    // which is smaller than expected!
    //
    // example: if numFds is -1 and numInts is 20, the allocated data buffer
    // will be 19*sizeof(int) bytes long.
    //
    // this is potentially bad already, but it gets worse.
    native_handle* h = native_handle_create(numFds, numInts);

    // this will copy the list of file descriptors (fds) from the fds pointer
    // to the h->data pointer. the number of bytes to copy is numFds*sizeof(int).
    // it is important to note that the third argument of memcpy takes a size_t,
    // which is unsigned. numFds is a signed int, but when you multiply it with
    // sizeof(int), which is type size_t, you get a size_t, which is interpreted
    // as an UNsigned integer. as such, -1 (0xFFFFFFFF) in signed becomes
    // 4294967295 when translated over to size_t. so, it attempts to copy way
    // too much data from fds to h->data, leading to heap corruption.
    memcpy(h->data,          fds,     numFds*sizeof(int));

    // <-- CRASH HERE, HEAP IS CORRUPTED

    memcpy(h->data + numFds, &buf[10], numInts*sizeof(int));

    handle = h;
} else {
    width = height = stride = format = usage = 0;
    handle = NULL;
}

Essentially the problem is that the number of file descriptors (numFds) is read as a signed integer, but then gets converted to an unsigned integer for the memcpy, which turns a small negative into a large positive and overruns the heap buffer. This is all caused by missing checks on the values of numInts and numFds.

According to the FullDisclosure post, you can exploit it by crafting a class which derives from BufferQueue, which has access to the data that ultimately gets passed to unflatten's buffer argument.

Now, since all this vulnerable code sits inside the system_server process, which runs under the system user, corrupting its heap from a user application (i.e. an app) is a big deal. If you could overwrite a function pointer (e.g. from a callback or event) inside a struct or class that is on the heap, you could gain arbitrary code execution within system_server, thus gaining you privileges.

To answer your clarification requests...

  Firstly, where is the function native_handle_create and variable native_handle declared (as I can see their use, but neither local or global declaration).

Android Cross Reference is useful for finding this kind of thing. The function is declared in native_handle.c and the native_handle struct (not a variable - h is the pointer variable of type native_handle) is declared in native_handle.h.

  Secondly how did you determine what the actual size of the buffer should be(so to determine, whether the current size of numFds or numInts was incorrect i.e. shouldn't be -1)?

Well we know that there can't be -1 items in a list, so that's invalid. If you look at the patch diff, they've added some checks:

// compute the maximum possible number of ints that you can store in a buffer
// whose size is represented by a size_t.
const size_t maxNumber = UINT_MAX / sizeof(int);
// if numFds exceeds the max number of possible ints (e.g. if 0xFFFFFFFF is passed)
// this check will fail. the second check is the same, except it accounts for the
// fact that 10 ints in the buffer are already used for other purposes.
if (numFds >= maxNumber || numInts >= (maxNumber - 10)) {
    // clear data and fail
    width = height = stride = format = usage = 0;
    handle = NULL;
    ALOGE("unflatten: numFds or numInts is too large: %d, %d",
            numFds, numInts);
    return BAD_VALUE;
}

Later we can see even more checks...

 // originally this was set to 0, which essentially did nothing.
 size_t fdCountNeeded = numFds;
 if (count < fdCountNeeded) return NO_MEMORY;

The final check after the native_handle_create call prevents a failed allocation from causing problems - before it would just do the memcpy to h->data even if h was null, leading to a null dereference bug (DoS condition).

So these checks ensure that the input values aren't outside of bounds and therefore can't be exploited as before.

  Thirdly what does h->data mean, as I can't find declaration for a variable named data and I don't know what -> means? also what is sizeof(int)?

The -> operator is a dereference. The operand on the left is a pointer to a struct. So h->data dereferences h, which is a pointer to a struct of type native_handle (we mentioned this earlier) and accesses the data field of that struct. By comparison, if h was not a pointer but was just a plain struct, you'd do h.data instead.

The sizeof macro gives you the size of a type in bytes. So sizeof(int) will return the native int size for your compiler implementation and target platform. In most cases it should return 4 or 8 to specify a 32-bit or 64-bit integer.

  Finally I thought numFds was unsigned const size_t numFds = buf[8];, and if numFds was of type size_t I thought it shouldn't be able to hold negative numbers to begin with (unless I've missed something)?

Yes, numFds is size_t, but that just means that the raw bytes within that value are interpreted as an unsigned integer. If it contains 0xFFFFFFFF, its directly interpreted decimal value would be 4294967295. However, the problem comes when you cast a size_t to an int, at which point the raw bytes within are interpreted as a signed integer, in which case that 0xFFFFFFFF suddenly turns into -1.

  Also, I don't understand how we move from creating Heap Corruption or Array Index Out of Bounds Exception etc. to arbitrary code execution?

That's a complicated topic, but I'll give you a summary. The heap is where most of your application data goes. This means that when you're making buffers and instances of classes and various other things, most of that data is in the heap. Now, imagine you've got a class with an event - let's call it Dog, and have the event called Bark. When certain conditions arise, an instance of that class will raise the Bark event, so that other objects can react to that bark. An event is just a pointer. Other objects handle that event by assigning it a pointer to a method, i.e. a pointer to some code. So, when the Dog instance wants to raise Bark, it looks at the Bark pointer and starts executing the code there. In assembly this would look something like call [eax+0x0...].

Since the Dog instance exists in memory, on the heap, so does its Bark pointer. If you could overwrite the Bark pointer to point to some other executable memory, then caused the Dog instance to raise the event, it'd run the code at that other location. If you control the code at that location (e.g. by filling a buffer with code and using that address for your pointer) then you get arbitrary code execution.

You can exploit this by simply flooding the heap with data structures that are likely to overwrite your target data in a meaningful way. It's not always 100% reliable, but that's just how it goes sometimes.

Things get even more complicated with NX and ASLR, where you have to use pointer leaks and ret2libc/ROP to exploit it, but that's a much bigger topic.

If you want to get into exploit writing, I highly recommend Corelan's Exploit Writing Tutorials. They're a little out of date - you'll want a WinXP VM with hardware NX disabled - but it's still a strong resource.


Secure way to transfer public/secret key to second computer

Encrypt your private key with a long password and decrypt it on the target computer. Here's how:

First, export the public key:

gpg --output public-key.gpg --export {KEYID}

Then export the secret key and encrypt the result before it's written to disk:

gpg --output - --export-secret-key {KEYID} |\
gpg --armor --output secret-key.asc --symmetric --cipher-algo AES256

Use either a very long or just entirely random password for the encryption.

Then transfer the keys.asc on a FAT-formatted flash and shred them afterwards, or if you know how to destroy CDs (ENTIRELY), use a CD and then destroy it.

To import the key on the other machine, run:

gpg --no-use-agent --output - keys.asc | gpg --import

This will prompt for your password, then decrypt and import the key.

Make sure you destroy the encrypted file after running this! On a small file like a private key bruteforcing the password is fairly trivial and can be done in a matter of weeks to months depending on the hardware available to the attacker. The attacker's job is further simplified by the fact that the structure of a PGP private key is publicly known, so known-cleartext attacks can be attempted.
If the encrypted version of your private key is leaked, revoke the key and generate a new one IMMEDIATELY.

Source for the commands: http://montemazuma.wordpress.com/2010/03/01/moving-a-gpg-key-privately/


If information_schema is not allowed in MSSQL, what is another method i can use to list the tables inside a database and ultimately the columns so i can dump them without using information_schema? Thanks.

For SQL Server 2005 and up:

SELECT name FROM sys.tables
SELECT name FROM sys.objects WHERE type = 'U'
SELECT name FROM sys.all_objects WHERE type = 'U'
SELECT name FROM sys.columns
SELECT name FROM sys.all_columns
SELECT t.name, c.name FROM sys.tables t INNER JOIN sys.columns c
SELECT * FROM TableGuess1
SELECT * FROM TableGuess2
SELECT * FROM TableGuess3
SELECT * FROM TableGuess4

BACKUP DATABASE ... and collect the backup.

You can also try the information from @735tesla's MSSQL injection cheat sheet, in his comment to the question above, but be aware that's SQL 2000 syntax (which is still supported for backwards compatibility in many later versions).


How should one properly dispose of a printer or fax which is used for sensitive documents?

When I worked for the .gov, the answer was to take it apart looking for storage media (which you remove and take care of).  If it's still serviceable afterwards, then off to salvage (for sale or recycling) it goes!

I'm sure that they did something different (aka, tossed it in a shredder) for machines that held the scary stuff, I don't know.


How does RusNet block websites with so many separate ISPs?

The process of Russian Federation enforcing it's filtering of websites for access is by handing down the list of IPs that should be blocked to the Internet Providers that operate within it's borders. How exactly the providers will do that, is entirely their decision, as long as the result is that website is unavailable for access to users trying to access the said websites through ISPs located within Russian Federation.


It's highly unlikely that this is a significant component of the threat model for most error reporting systems.  It's generally going to be too hard to craft fake data that will both appear to be real data to the system, and achieve some arbitrary malicious goal to boot.  It would be a lot of work for a dubious gain.

That said, there are ways you can potentially limit the impact of bad data.  For instance, you can include software registration serial numbers with the reports.   You then throw out reports that come from invalid sources (data that contains serial numbers that aren't registered to customers) or eliminate all of the data sent with a given serial number if you're getting excessive or known bad data in reports with that serial number.

So, the risk (and impact) can be limited, but it's generally not going to be worth the effort to mitigate in the first place.


Is password generation adherent to a primitive pattern insecure?

This looks like a programmer doesn't understand what makes a password strong. Perhaps thinking: Everyone else requires lowercase, uppercase, at least 2 numbers, and at least 10 characters total.
Website admins have trained users to think about password security the wrong way. Between the way websites deny registration based on password rules and the way other websites tell users how secure ("billions of years") their password is based on a naive formula, it appears to typical users that appending a 1 in a password that doesn't otherwise contain numbers automagically makes it much more secure.
These samples look like they were generated using a similar mindset. However, it may be the case that the programmer didn't have the option to change company password policies and decided to use the easiest password for users to enter.
Especially for mobile users. Switching keyboard layouts between letters and numbers adds an extra input that can make entering passwords tedious and error prone. You could go further and generate passwords with only lowercase letters (except for the first letter being case insensitive). Reducing the character set would require making the password longer, but the longer password would still be easier to type.)
Assume that individual characters are uniformly distributed (with different character sets) and independent. You can get a conservative estimate of the password's strength by simplifying the pattern to the following rule.

Three digits (Excluding 0 and 1)
One uppercase letter (Excluding O, L, and I)
One uppercase or lowercase (Excluding O, L, and I)
Five lowercase letters (Excluding O, L, and I)

The number of possible passwords generated is then 83 * 231 * 461 * 235. About 241.6 or three trillion passwords. That's not a strong password for cryptographic key derivation and won't stand up to offline password cracking, but it's okay for rate-limited online attacks on a website that doesn't require much security.
I assume that some letters and numbers are excluded because they're easily confused. I didn't see them in the sample passwords, so I will assume they are excluded just to be on the safe side. I could have gone further and assumed other vowels weren't use (to prevent passwords contain coincidentally offensive words) but saw that vowels are used.
I noticed samples contain 1, 2, or 3 numbers, but the total length is always 10 characters. Our set of digits is smaller than the set of plausible digits and uppercase letters. I made this simplification either because I'm too lazy to compute all the different pattern variations or because I was fine underestimating numbers.
Likewise I saw a variable number of capital letters. I assumed the first was always capitalized and that the second could be lower or uppercase. I know some samples had three uppercase letters but just treated each third letter as if it were lowercase like the final 5 are.
Because of the way we simplified this pattern, we know that the actual number of possibilities is larger. The unaccounted for variations could add a few bits to the password strength. If another user wants to calculate a less conservative estimate or exact answer, then they can submit it as extra credit homework.


Is storing information in RAM more secure than on Disk?

There's a lot of nuance. Each process should only be able to access the area of memory which is assigned to it by the kernel. With file/disk access each process may be able to read files owned by their calling user, files marked as readable for the calling user's group and world-readable files.

That said, in the case of virtual memory and suspend/hibernate actions there is the possibility that the sensitive data which an application is dealing with in memory is written to disk by the system. (EDIT: It's been pointed out that newly allocated process RAM will be zeroed by the kernel in most situations, so processes which are killed are not likely to leave much remanence in RAM. It is, however, possible for a process which freed a malloc'ed variable to have leftover data swimming around in it's address space if that same process later malloc's a new variable, but that's not as relevant here. The other points still apply) Lastly, if the process which is handling the sensitive data happens to have a buffer overread vulnerability then that would allow an attacker to provide that process with a crafted input which would allow that attacker to read the current memory space of the process. Including the sensitive data...

I'd recommend keeping any sensitive data encrypted until the time at which it is needed. Normally this means keeping it encrypted on disk and decrypting it at time of use, but it may also be feasible to keep it encrypted in memory and decrypt at time of use (assuming the decrypting keys are not also stored in memory).


We cannot help you if you don't post more info about the file.

First you will need the md5 signature of that file. You can use a tiny tool called winmd5 for that.
Secondly either search that md5 sig online and try to find relevant information about the process/file or submit it to md5 malware databases such: https://isc.sans.edu/tools/hashsearch.html


Is it possible for a virus or unknown program to automatically start up a webcam

You can disable Flash access to your webcam using the Global Privacy Settings panel.

Do not use a computer account with administrative privileges. Create a regular user account that is not authorised to install software.

It is important to use an up-to-date web browser. Popular opinion is against using Microsoft Internet Explorer. Try Mozilla Firefox or Google Chrome. You can install extensions for the browsers that provide additional security, such as blocking JavaScript on a per-site basis.


Is JavaScript malware as dangerous as native viruses?

The threat a virus impose in your system is, ideally, independent of its programming language because viruses exploit vulnerabilities in operating systems, applications, APIs etc. In this sense, a Javascript virus is as dangerous as any other virus.

Also, for web applications, JavaScript is one of the main attack vectors in techniques such as cross-site scripting (XSS) and cross-site request forgery (CSRF) because it's rather easy to write for web. Cisco's Annual Security Report and OWASP Top 10 rank XSS one of the most used methods for vulnerability exploitation.

tl;dr: JavaScript is as dangerous as any other programming language.


How do CC servers communicate to botnet bots in a local network?

Usually it's not the command and control infrastructure which connects to the bots, because it can not magically know when a system gets infected. It's the botnet clients which contact the C&C infrastructure and ask for commands.

Most routers (at least in the consumer segment) are configured to blindly forward any connections from inside the network to systems outside the network. Port forwarding only needs to be configured when a service needs to be contacted from the outside.

How exactly the bots contact the C&C servers differs vastly between different botnets. They masquerade as other protocols (like HTTP), use anonymization networks like TOR and various other methods to avoid being detected easily.


Can ISP distinguish/identify devices behind NAT?

If both devices have their own connection to the VPN this can probably be detected at the ISP level. While the details vary between VPN protocols it should for example be possible to detect key exchanges with multiple inside devices in case of IPSec or OpenVPN and independent TCP connections with TLS based VPN. Even if a single device has no permanent connection to the VPN endpoint (like in case of a VPN-ish thing like SOCKS) and always creates a new TCP connection it might be possible to detect different devices with some heuristics based on OS characteristics, TCP timestamps or similar.

If instead the starting point of the VPN is not each client system but only the shared router then counting how many systems are behind the router is much harder. One might try to do a flow analysis of the VPN traffic though and deduct from the behavior (timing, packet direction, packet sizes, traffic bursts...) if this looks like a single user surfing the web or if it looks more like multiple users in parallel. The more traffic is analyzed and the longer the time frame of the captured traffic is the more accurate this result will probably be.