This is not a privilege escalation where code gets "only" executed as a higher privileged user. This issue is about execution of code inside the Linux kernel, i.e. the kernel which gets shared between all docker instances and the OS containing the docker instances. This is the highest privilege one could get and at this level one can bypass any kind of restrictions. This means that an unprivileged user which is able to execute this attack can break out of the container.


OCSP from branch office to central office

Take a look at OCSP Stapling which was created to mitigate the problem of OCSP responder being down or unavailable.

  the certificate holder (the web server) queries the OCSP server themselves at regular intervals, obtaining a signed time-stamped OCSP response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL handshake via the Certificate Status Request extension response

All major browsers and web servers support OCSP stapling.

As far having the OCSP responder check the CRL list, this is technically possible but might lead to performance issues if your CRL list gets very large. Ideally you would want your CRL list to be stored in an indexed database of some sort which can be queried efficiently by your OCSP responder.

Instead of rolling your own OCSP responder, it would be better to use a proven existing responder which can check against a an indexed database that contains your CRL list entries.


So deploying metasploit would be one option as you've mentioned however if you want a more Powershell route could look at using nishang which provides modules like powerpreter to help with pivoting on a network once you've compromised a single host.


How to exploit a misconfigured CORS policy when a per user authorization token is required?

Cross origin requests are dangerous because it makes it possible to use the session of the user to make requests as that user. This works because a cookie is sent along with the request and implicitly authenticates the user to the web application under attack.

If your application does not use cookies but instead uses a header to keep the session token in, the danger of cross origin requests is mitigated. You can still do requests to the server, but not under the session of the user.


In DoS, does every sent Spoofed IP packet have a different IP?

That depends on why the attacker is spoofing.

If they are spoofing to make it difficult to seperate their traffic from general internet traffic then it makes sense to spoof as randomly as possible.

If they are spoofing to exploit a hole in a firewall (for example a firewall that accepts all packets from addresses internal to a victim) then they would obviously choose addresses from the range they belive the firewall will allow.

If they are spoofing to perform a "reflected" attack then the spoofed source IP will be the IP of the victim.


Proving running code on a website is unchanged

In all reality no one can really prove that a system is totally secure from all attacks.  Provable security can never really be perfect because new attacks are developed regularly.  Security is a new field and we don't really know all of the ways that software can be abused. There are projects that are open source for the purpose of security and there are two major reasons to do this.

Some companies "crowed source"  their security and offer a bug bounty program.  Mozilla is one of the most successful with this model and all of their applications and infrastructure is open source.  I have found four critical vulnerabilities in their infrastructure,  and I collected $3,000 a piece for these findings.  I am happy that I was able make Mozilla safer.  Collecting these bounties where not easy,  bug bounty programs make hunting for bugs into a fierce competition.

There are also projects that make parts of their application open source such that their users can interdependently verify that the software is in fact secure.  Good examples of this is Whisper Systems (now apart of twitter) and their mobile product RedPhone.  Parts of HushMail are also Open Source for this reason.


Session Management for Private Key Passphrases in a Web Application

What you've described is very similar (almost identical) to the basics of the OpenPGP standard. It would be wise to read up on OpenPGP before attempting your own implementation of this scheme.

To answer your question posed here:

  Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would technically be able to decrypt the data without the user's Input. Remembering a passphrase hash in a Cookie is also not an option.

This is a tautology. As long as you don't maintain a ciphertext in/out paradigm for your server it will always be able to decrypt stored data at some point. The best you can do is require user input for every operation.


Change LUKS encryption key (not passphrase) without dataloss

With the cryptsetup-reencrypt tool, you can change almost all aspects of a luks encrypted device like, the volume key, cipher, or even encrypt a device that is not encrypted. In some distributions, you will have to download the cryptsetup sources and recompile with the --enable-cryptsetup-reencrypt option. If you are using a Red Hat based distribution, you will be interested in this proof-of-concept dracut module at cyptsetup sources.

Running cryptsetup-reencrypt without parameters should be enough to start a new key being generated. But be aware that any power failure or error during the process could let data unacessible forever.


What is source of bad characters exist in buffer overflows

There is no common root cause, although null byte is a common problematic character when dealing with C strings. Each vulnerability has its own buffer space and bad bytes due to the underlying code (char array size declaration f.ex), but also through the function calls that leads to the vulnerable function being called.
A payload that is transmitted over HTTP typically needs to avoid characters that influence how the HTTP request is parsed. Characters such as \r, \n, / and ? can cause the line that's being parsed to truncate prematurely and fail to overflow the buffer, or lead to a 404 error instead of calling the vulnerable function.
Characters being converted between upper and lower case is another example that will mess with shell code. There are also cases where a single byte is fine, but multiple sequential bytes are not, such as a function trimming whitespace in the payload before calling the vulnerable function.
So you can see that the overall combination of the bad bytes is a combination of the code, the call stack and the transport layer (and possibly more for second order bugs) and the bad bytes can be bad due to diverting the call stack as well as corrupting the payload.


Establishing trust between a device and a developer, TLS signal vs X.509, GnuPG (or both)

You really need both as the two achieve different things.

You achieve secure communications, which protect from interception/injection of data during comms.
You achieve confidence the 3rd party is both a trusted 3rd party and the 3rd party you think it is. (or in this case, a 3rd party which is trusted/authorised by the vendor).

The 1st one is pretty straight-forqward. The 2nd is a little more tricky and where many vendors have made mistakes. For example, the many IoT devices where they have used a GPG approach, but have made the mistake of using the same private gpg key on all devices.

Which type of solution you use for #2 will depend on your exact needs and risks. You need to balance the amount of protection required with the inherent level of complexity it introduces - there is no point having a really complex and highly secure solution if managing that solution becomes so complex that operational failure becomes more likely.

Consider what your requirements are and what the associated risks are to determine the minimum necessary protection and then look at how you will manage the solution and ensure this can be done without excessive burden.

There is no one right solution. It will depend on the risk profile you are addressing and how you structure things. For example, if you want the 3rd party developers to manage things i.e. the software is made available on developer managed web sites, then you probably want a signed certificate approach where you give an approved 3rd party a signed certificate and your device will only allow loading of apps from 3rd parties which have an appropriately signed certificate. This gives you the ability to revoke approval by revoking the certificate.

Alternatively, you could use an approach where you allow 3rd parties to submit applications to a site which you control. You would assess and approve the 3rd party apps and only make ones which you approve to be available on the site. In this case, you can probably just use a GPG based approach, which might be easier to manage.

The first approach would put greater trust in the 3rd parties, but would likely reduce administration overhead for you. The second would require less trust, but would create higher admin overheads for you because you have taken on a vetting role. It is also likely that there would be increased turn-around time i.e. from release of new/patched versions. However, it would also have the advantage of more control and increased quality, which may be important as the overall quality of your device may easily be judged by the quality of the apps it runs.

The two are not mutually exclusive either - you could do both, which may be warranted in some circumstances - again, depends on your risk profile and what levels of risk your comfortable with.


When, exactly, should old password reset tokens be deleted?

You should not reset the token when the user clicks on it, because the user might be disturbed in the process (e.g. his cat jumped on the keyboard -- mine does that on an all-too-regular basis).

(Two days ago I was using such a link -- not for password reset, but similar -- which was deactivated as soon as I clicked on it, and it turned out that the page behind it was not compatible with Chrome. So I had to request a new link, doing the whole process one more time, and I cursed them for that. When dealing with passwords, you want and need to make a cooperative ally of the user, and certainly not to make him angry.)

When the password is actually reset, all pending password reset links should be deactivated. It is simpler if you allow only one reset link at a time; if the user requests a password reset while the previous link is still valid, just send it again (possibly, reset the timeout counter). There is no need for supporting several simultaneously valid, distinct password reset links. One link at a time means an easier database design, and thus less scope for bugs.


keyUsage Extensions on a Certificate Authority

I think you're right. RFC 5280 section 4.2.1.3. Key Usage says (emphasis mine):

KeyUsage ::= BIT STRING {
       digitalSignature        (0),
       nonRepudiation          (1), -- recent editions of X.509 have
                            -- renamed this bit to contentCommitment
       keyEncipherment         (2),
       dataEncipherment        (3),
       keyAgreement            (4),
       keyCertSign             (5),
       cRLSign                 (6),
       encipherOnly            (7),
       decipherOnly            (8) }

  Bits in the KeyUsage type are used as follows:

  The digitalSignature bit is asserted when the subject public key
  is used for verifying digital signatures, *other than signatures on
  certificates (bit 5) and CRLs (bit 6)*, such as those used in an
  entity authentication service, a data origin authentication
  service, and/or an integrity service.

  ...

  However, the digitalSignature
     and/or nonRepudiation bits MAY be set in addition to the keyCertSign
     and/or cRLSign bits if the subject public key is to be used to verify
     signatures on certificates and/or CRLs as well as other objects.

My guess is that CAs want the ability to use the root key for some other kind of authentication; who knows, maybe signing logs or something? Either that or it's misconfiguration.

Full disclosure, I work for Entrust, so I'll use them as an example: the publicly-trusted Entrust Root Certificate Authority—G2 and the L1K and L1M issuing CAs do not have the digitalSignature keyUsage, so it's certainly not needed:

As for your other question:

  Should I mark the key usage extension for a CA as crticial or not ? (my guess is yes, but I don't know how to justify it)

RFC 5280 (same section) says:

  When present, conforming CAs SHOULD mark this extension as critical.

I'm not sure what happens if you mark this as non-critical, but I'm guessing some clients / verifiers will work fine, and some will have weird behaviours.


Client side encryption with sustainability as a service

Your options and your requirements do not seem to match.   If you rely on HTTPS, password strength, and server database encryption, then the admin can, in fact, access the decrypted data.   SO, if requirement 1 is actually a requirement, then this option is not viable.  If, however, requirement 1 is merely a "nice to have" then this option might work.

So, the question is:  Is requirement 1 actually a requirement?   If it is, then your only real option is client-side encryption.  For any reasonable assurance of integrity, this requires either a client-side application or browser plug-in without automatic update mechanisms.  Server-based mechanisms are simply too easy to subvert to be serious contenders.


It looks like your desktop is infected with PennyBee (aka DealPly, OfferBoulevard, SavingsBull) adware.

In theory this can usually be removed by using the Add/Remove Programs entry and the extensions/add-ons managers in Chrome and Firefox. However, if you were unknowingly infected by this (likely: via the InstallCore/OpenCandy/DownloadAdmin bundling programme run by IronSource/Injekt, part of the group as runs PennyBee et al), who knows what else has been installed? Might be worth considering a fresh install.


Can one Bypass a Web Proxy by using the Host File?

The answer is quite possibly, it depends on how the proxy is configured and the networking works.

The key to answering this question is the line about the IP address of aaa.com being accessible using telnet or nmap.  As this is the case, we can assume that traffic to the site is not being blocked completely.

For example assuming the proxy is blocking based on hostnames it sees (e.g. aaa.com) and not based on other factors (e.g. the IP address) if it doesn't see a blocked address it may not block it.

If you give aaa.com a different address using hosts (which generally takes precedence in name resolution over other mechanisms), the request will go to the web server with that alternate name.  Now the webserver may not respond as it will get a request for a host it doesn't recognise and may not respond well to that, or may redirect back to aaa.com which would cause the proxy blocking to kick in.

What we don't know from the question is whether the requests using telnet or nmap were bypassing the proxy and therefore that's why they could get to it, in that circumstance it might not work.

To provide an example, say we're trying to block www.google.com. If you put a line in /etc/hosts specifying one of www.google.com's addresses being www.flooble.com, and then make a request to www.flooble.com and intercept the request with a proxy, what you see is a request to www.flooble.com on the IP address mentioned, with no mention of www.google.com.  So if the block is purely based on the hostname, it won't kick in.

Now we know from the question that connections to the web port on that IP address are successful, so it's possible that the connection would work.

EDIT - One other factor to consider, which would be important in this case is "where does the name resolution occur".  In some cases with an explicitly configured proxy the name resolution occurs on the proxy, in which case the request wouldn't work.  In other cases with a transparent proxy (i.e. the client browser isn't aware that it's using a proxy) the name resolution would occur prior to the proxy seeing the traffic, in which case it would seem from the question that the request would work.


How could someone exploit the OS an ATM is running?

Well there's a couple of potential attack vectors which could be relevant.

First up ports.  Surprsingly some ATMs do indeed have USB ports and have been attacked via them (more info here as an example and also this CCC presentation on infecting ATMs with malware).  However you'd hope that ATMs have decent physical security to help mitigate that class of risk.

Then there's attack over the network.  One of the downsides to windows XP is that services like SMB are running and pretty much impossible to disable without making it very hard to manage the system.  You could obviously firewall off the ATMs but there still needs to be some network connectivity for management and to transmit transactions.

Now you'd hope that everyone's ATM network is physically separate and not contactable from any other network, but the idea that companies will maintain good air-gapping is not likely to hold 100% of the time in the real world (look at all the SCADA problems that people thought would not happen due to all SCADA systems being Air-gapped!)

So the answer really is that ATM software will be attacked the same ways that other Windows XP systems will be, it may be harder to carry out but not impossible.


Why make it difficult to disable MFA tokens?

What type of threat scenario does this address?

If a password dump of ServiceA leaks, and it contains the credentials for a user, and this user have an account at ServiceB protected by 2FA, nobody will be able to authenticate as him, even with the correct password. As password reuse is a common problem with credentials (the vast majority of users have few passwords and use the same passwords on every service).

  After all, an attacker who would be able to authenticate as a legitimate user would then be able to change the password and lock the legitimate user out, so what is the difference?

If the account is protected by MFA, an attacker will only be able to authenticate as the user if the MFA token was stolen too. If the attacker have the password but not the MFA, those procedures would help protect the account in the case of a password leak.

If, for example, the legitimate user lose his phone with the MFA token, or his hardware token, but knows the password, he can prove ownership of the account by supplying his ID or another details proving he is the owner, before disabling the 2FA and allowing him to login again.


Security benefit of hardware backed host keys for OpenSSH

AFAIK, your assessment is quite correct. Your physical device migrates the risk for your key to be stolen from the virtual to the physical world. So if your server is temporarily compromised you have a minimal risk that your key has been stolen. Which a huge difference!

However, it does not generally prevent the abuse of your key. So if someone hacks your server, he can sign arbitrary things with your key, just like your SSH host would do. This includes chosen plain text attacks, which enable the attacker to guess your key in less time. Therefore, it would not efficiently protect a permanently compromised system.


Do I need to worry about vulnerabilities that require administrative privileges to exploit?

Your question does not distinguish between administrative privileges, and "highest privileges possible".

Where to go when you have elevated privileges?

"Elevated privileges" are not the highest you can go. Even though you might be administrator, the operating system kernel can still deny you access to some resources or to perform some actions. Furthermore, reinstalling the operating system will wipe your access (as long as the new system is not vulnerable again).

So in short, when you have elevated privileges, you can still get kernel privileges.

Where to go when you have kernel privileges?

When you have kernel privileges, you act as the operating system. Nobody can deny you access to resources, unless they were designed not to be accessible by anyone, because there is nobody to deny you.

This might seem like the ultimate privilege escalation, but you can still go further and become the Hypervisor.

Where to go when you have hypervisor privileges?

Have a look at this chart:

On a system set up with a Type-1 Hypervisor, several operating systems can run in parallel. Even the kernel of one operating system has no access to, or is aware of, the other operating system.

However, an exploit in the hypervisor could allow you to take over the hypervisor and give you complete access to all operating systems on the machine.

So where would you go from here? If you imagine the operating system bubbles in the chart to contain a "user space" and a "kernel space", then we gradually moved down from the privileges of a normal user, to the privileges of an elevated user, to those of the kernel and now to those of the hypervisor. It would only make sense to keep moving down, which would lead to the firmware, the abstraction layer between hardware and software.

Taking over the firmware would allow you to persist your malware, even when the operating system or the hypervisor are wiped clean. The only way to go even further is to exploit the hardware directly, as is the case with some hardware bugs.


How to obtain body from RSA signed document without verifying signature?

I had to remove my answer because it was flat out wrong: the PKCS#1 v1.5 scheme for signatures used by OpenSSL is only used partially (thanks Dave for yet another insightful comment). That also means that is doesn't hash the input - but that means that it doesn't fully respect the security claims of PKCS#1 v1.5 and upwards either for that scheme. So it should really not be used that way, as it is now used as a scheme giving message recovery rather than a scheme giving signatures with appendix.

The input text is padded according to OpenSSL, and then modular exponentiation is performed using the exponent of the private key (or, more usually, the same calculation using the Chinese Remainder Theorem, but that's beside the point). If you perform modular exponentiation with the exponent of the public key they you would get back the padding and the text. However, to do that you would need the public exponent (usually set to 65537, so that's not a problem) and the modulus (which is a problem, although not as big a problem as the RSA problem itself).

So the text is indeed within the output, but you can only retrieve it if you somehow recover the public key. Earlier versions of PKCS#1 would say it is encrypted with the private key (newer versions go out of their way to explain that modular exponentiation with the private key is not encryption, even if it is the same mathematical operation that is performed). So you can then decrypt with the public key and restore the data.

Note that the RSA padding scheme used is that for signature schemes, not encryption schemes; it will always create the same result for the same message, and therefore it leaks information. So even if the public key can remain secret, RSA signature generation is not the same thing as encryption with an actual cipher (this is why AES encryption generally requires an IV).

So openssl -sign generates both a broken signature as well as broken encryption for a given message.

The solution offered was correct, kind of: if you want to have both message and signature in the same container format then you can use the openssl cms -sign options. That way you don't have to verify the signature to retrieve the plaintext.

That said, I don't see any option to output it without verification, and you need a certificate to perform the signing. Including the data (rather than creating a so called detached signature) is optional. CMS is a much higher level protocol than just RSA, so you may consider it cheating.


Securing data after laptop is lost or stolen

If you're using full disk encryption, and the laptop is stolen, the thief will have access to the data only as long as a) it has power and b) the screen lock does not come on.

Assuming you have a sophisticated thief that knows this, they would be the same as a bad actor in your organization.

  Chance is small but user may fake that laptop was stolen and use log on credentials to access data on laptop.

In other words, you want to verify the laptop was stolen and (possibly) remote wipe it when its security is questionable because the person who has the laptop has credentials to decrypt it.

There are several open source and for-pay projects that do this:

Pombo
Prey
LoJack for laptops


Protection against screenshot key loggers

A key logger can log keys, or take screenshots, only by virtue of having extensive access to the operating system, allowing the malware to do basically whatever it wishes to. As such, there cannot be a failsafe way to prevent or even detect screenshots, since the malware would perfectly be able to simply deactivate that check.

At best, you could implement a partial protection against existing key loggers, which will be efficient until keylogger authors adapt their code, which should take about one week. See this answer for some more treatment on the subject.

When hostile code runs on your machine, then it no longer is your machine. This is why payment terminals have their own screen and keyboard: to be immune to attacks on the cash register.


A relevant base of the level of trust of an app can be how much of your phone does it needs to access. Some apps require very little access and can do a lot of useful stuff. Some require only needed access, like a flashlight app needing camera access, but many also abuse wanting access to way more than they actually need. It would be illogical for a flashlight to access a lot more functions in the phone except the camera itself.
Another relevant thing is how much spam does it produce. Generally, this is a reason I don't personally trust many apps. They keep spawning pop-ups. Some keep spawning them even if they are paid versions; they just spam something different (like other info about other apps from the same company).
There is no third party guaranty for safety or privacy. If an app gets access, it can do whatever it wants with that access and it's way harder to trace that compared to a PC system, unless it is controlled strictly by another app, which usually is not the case (I find the 3rd party control apps are not advanced enough yet).
The solution for some security is an app that can limit the control of other apps. While most of them can just pass-lock access to apps, some are more advanced and require root privileges. In the case of root access, such an app should be mandatory, since on root mode the other apps can take over phone functions much more deeply and easier. This is the 3rd party way to be a little safer, but not close enough to what I would like at this point.
There is then also the problem of commodity. The more advanced an app-control app is, the more inconvenient it will be to use. You will have to find a good balance between the security part and the convenience part.
My approach to this was to install a bunch of apps on a test device, use them for a while just to see how things go, then keep only the ones that proved to be safe, proved to be reliable and did not ad-spam me. This is valid also for the control app.


Is flushing of all caches on any context switch between mutually-distrusting processes the only way to prevent cache timing attacks?

Direct answer

Did you aleady read page 11 and 12 of this document, chapter 5.1, about Prevalence of Vulnerable Systems  and 5.2: Countermeasures?

If your system is really vulnerable, then yes, you have to flush cache of sensible information before accessing suspect web pages.

But if your cryptographic tool uses non-cached memory, they are not vulnerable...

You could use NON Intel or single core CPU... or ensure no Sandy Bridge, nor Ivy Bridge and no Broadwell micro-architectures are used in your hardware.

And keep your Intel-based servers away from optimised JavaScript.

Second time reflection

For my understanding, this paper is more a proof of concept than a exploit cookbook.

I mean, if this was possible in this specific configuration, by using this method and optimised javascript, We have to keep in mind that:

Cache attack is possible.

Regardless of requirement for this demonstration.

In fact, new multi-cores processors are insufficiently protected, due
to performance challenges.

And new optimisation at libraries level could make some unattended backdoor.

This exploit is hard to reproduce, but show that if processors constructors don't care, futur could become hazardous.


What sites give the latest information on security threats especially zero day malware

Most of the information about zero-days, running malware or advanced exploits investigation (marketed as Advanced Persistent Threats) is privately owned by some commerical companies (such as Mandiant for ex.).

Apart of that, you can use the traditionnal vulnerability feeds like CERTs or CVE.
A feeds list was posted in this related question that might help you as well.

At last, I answered to that question with a small list of websites tracking malware / threats seen in the wild:

malwaredomainlist.com
malwaredb.malekal.com
exposedbotnets.com
scumware.org
malc0de.com
cybercrime-tracker.net
vxvault.siri-urz.net
nothink.org
botnet-tracker.blogspot.ch
atlas.arbor.net
marworm.com
zeustracker.abuse.ch (Zeus botnet tracker)
alienvault.com


HMAC What is secure manner to distribute shared secret between client and server?

First, HMAC is used for verifying the originator of a message and only the sender needs a secret.  It is useless for purposes of secrecy.  Second, key exchange is a hard thing.  You can do it through a side channel, but since that is hard, that is why most browsers do it for you by way of a pre-installed list of root CA certs that are installed with the browser.  This is how your browser knows to trust information coming from a particular server.

Since the server knows a secret that the client can trust, it is possible for the client to send a session key that only the server can read and then that shared secret can be used for secure communication.  That's the basis behind SSL and why SSL is used as commonly as it is since otherwise you have to do the key distribution yourself for every client.

Edit: As CodesInChaos pointed out, any kind of encryption can be used to validate the MAC is valid for the message by an authorized party.  It doesn't have to be public/private, but that doesn't really alter the fact that key-exchange is the problem as public/private is more easily dealt with in this particular case than using symmetric keys.


Is there a benefit to setting up a security key on an account that already has phone-based 2FA?

I'm assuming the security key you're referring to is a U2F security key.

U2F has several advantages over other 2FA schemes like OTP, one of the biggest improvements is to prevent the issue you point out. With most 2FA schemes a phisher could simply act as a proxy between you and the legitimate service, and obtain your password and 2FA code that way. U2F prevents this with the help of the browser.

Authentication works as follows: (somewhat simplified)

The website sends a signature request
The browser validates that the AppID in the signature request
matches the visited domain (or that the domain is a trusted
facet)
The browser forwards the signature request to the U2F device
The device uses the AppID and key handle to retrieve the private key, which it uses to sign the challenge
The signature gets sent back to the browser, and on to the website to verify it

If a MitM simply acts as a simple proxy this will fail at step 2, as the domain won't match the AppID in the signature request. If the MitM filters the signature request and modifies the AppID to match the phishing domain, it will fail at step 4, as the AppID and key handle no longer specify a valid key.

Of course, the phisher already has your password at this point so you would need to change it, but at least they can't get into your account.


Go through proxy server to Find an original IP Address

Use traceroute:

traceroute <ipaddress>

on linux.

ex:

john@john-ubuntu:~$ traceroute google.com
traceroute to google.com (173.194.46.101), 30 hops max, 60 byte packets
 1  ...
 2  ...
 3  ...
 4  ...
 5  ...
 6  ...
 7  ...
 8  74.125.49.37 (74.125.49.37)  18.659 ms 205.213.119.62 (205.213.119.62)  18.648 ms  18.605 ms
 9  209.85.254.128 (209.85.254.128)  18.595 ms 209.85.254.130 (209.85.254.130)  18.516 ms  21.724 ms
10  209.85.245.225 (209.85.245.225)  18.836 ms  18.630 ms  18.617 ms
11  ord08s13-in-f5.1e100.net (173.194.46.101)  18.246 ms  18.305 ms  18.220 ms
john@john-ubuntu:~$

install on Ubuntu:

sudo apt-get install traceroute

Fedora:

sudo yum install traceroute

Edit:

You could also just do a whois, which might be easier:

john@john-ubuntu:~$ whois google.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

...

Registry Registrant ID:
Registrant Name: Dns Admin
Registrant Organization: Google Inc.
Registrant Street: Please contact contact-admin@google.com, 1600 Amphitheatre Parkway
Registrant City: Mountain View
Registrant State/Province: CA
Registrant Postal Code: 94043
Registrant Country: US
Registrant Phone: +1.6502530000
Registrant Phone Ext:
Registrant Fax: +1.6506188571
Registrant Fax Ext:
Registrant Email: dns-admin@google.com
Registry Admin ID:
Admin Name: DNS Admin
Admin Organization: Google Inc.

  Admin Street: 1600 Amphitheatre Parkway
      Admin City: Mountain View
      Admin State/Province: CA
      Admin Postal Code: 94043
      Admin Country: US
      Admin Phone: +1.6506234000
      Admin Phone Ext:
      Admin Fax: +1.6506188571
      Admin Fax Ext:
      Admin Email: dns-admin@google.com
      ...

This should give you all the info you need!


Why forward a virtual machine with SSH to Putty

First of all, none of the steps you described are necessary to crack a wireless network. It is the way of working with the Kali Linux VM that the author in the tutorial has chosen. You could also open a terminal in Kali to execute the commands he is running via Putty. If he is using Putty for accessing other Linux machines in his daily work, it is probably the usual way of working with a Linux machine for him.

As you described, he does access the Kali Linux via SSH with Putty in his setup. There are several ways to access a network port of a VirtualBox virtual machine on your host machine.

The way he is using is NAT port forwarding. It is pretty easy to configure if you have already set up a NAT networking interface for your VM.

He is using the port 2222 because it is not possible to bind to ports below 1024 from applications that are not run by root on UNIX systems [1]. (If he is using Windows as his the host system, he could also use port 22.) But connecting to localhost on port 22 with Putty cannot work because the SSH server is forwarded to port 2222.

There other ways, too, such as using the host-only networking [2] or bridged networking feature [3]. Bridging your Kali VM is a thing you may want to avoid, as it exposes the VM to your local network. As a Kali VM has no firewall configured in the default configuration, this could be a security issue. Configuring a host-only network has no disadvantage in comparison to the port forwarding. A reason he may not do it is the higher complexity in the configuration: you need an additional adapter in your VM and on the host, and you need to find the IP address of the guest after booting.

In the updated rc.d part, he does configure the SSH server to start on boot and service ssh start to start it now.

[1] https://www.virtualbox.org/manual/ch06.html#nat-limitations
[2] https://www.virtualbox.org/manual/ch06.html#network_hostonly
[3] https://www.virtualbox.org/manual/ch06.html#network_bridged


How to know which database is behind a web application?

Let's say you've got a query like this:

$q="SELECT username, joindate FROM users WHERE username LIKE '%" . $search . "%' LIMIT 20";

Now imagine you control $search via a parameter. We would usually make it return the user passwords in the joindate field like this:

$search="' UNION SELECT username, password FROM users; -- -";

As such the query becomes:

SELECT username, joindate FROM users WHERE username LIKE '%' UNION SELECT username, password FROM users; -- - %' LIMIT 20

The part after the double-hyphen is a comment, so it's ignored, and we get all the username and password combinations appended as new records at the end of the dataset, after the legitimate records. Awesome!

But now we want to adapt this so we can find the database name, for further investigation of their database. On MySQL, we can use the DATABASE() function:

$search="' UNION SELECT DATABASE(), 1; -- -";

The use of 1 here is to pad the joindate field, which we aren't using.

On MSSQL we can do exactly the same, but with DB_NAME():

$search="' UNION SELECT DB_NAME(), 1; -- -";

Both of these tricks will append a single row to the end of the result set, containing the database name.

We can then expand this trick to use VERSION() on MySQL or @@VERSION on MSSQL, which returns the current database version. For Oracle and PL/SQL you can check for the existence of the v$version table, simply by doing a query on it and checking for an error.


Proving creation time/date of a screenshot

If you want to prove to others that you took the screenshot on a specific date and not later, you will not be able to do it yourself, you will have to rely on some common trusted third party.

For low importance issues, this can be accomplished by simply posting the image on some well known public service where the date when the image has been posted will be mentioned. Be sure to check beforehand that this service does not offer any possibility to modify the picture without altering the upload date!

For higher importance issues, you will have to contact a bailiff or a notary. By being present during the screenshot, they will be in measure to vouch the date and the conditions when it has been taken. For instance I've read about such procedure being used when someone wants to keep a proof of the existence of a security flaw still valid even once the flaw itself has been corrected. However, if you go that way I would strongly recommend to check the Law StackExchange website before engaging yourself into anything.


Single File Encryption in a Windows Environment

Your understanding is, indeed, correct.

Most probably you have a copy of that file on your system now. After you encrypt it, you'll either have to remove the unencrypted version yourself, or the encryption application will do that for you. As far as I know, there's no 100% way to delete a file and be sure that it's gone along with any evidence of its existence.

You have 3 options:

Search and destroy: Learn about all the places in which your file might have existed. This is not just about the temp directories and caches, this means down to the sector-level and effectively destroying the data by overwriting it. While plausible, I'd say it's practically impossible.
The alien approach: Encrypt the file on a different computer, copy the encrypted file to the intended storage place, then physically destroy the hard drive on the computer used for encryption. As long as you don't open the file (because once you open it, you'll run into the risk of leaking an unencrypted copy with caching, saving temporary files, accidental backup, etc...) Possible, but silly.
Full disk encryption: This is, by far, the most secure option. While, like anything in security, not 100% secure, it's your best option. I'd recommend some industry-standard application like TrueCrypt.


You could:

enforce strong passwords on the site
install client side certificates
specify a connection timeout on the VPN
implement two-factor authentication on CRM access

For remote use, you'll need to install a certificate from a recognised Certificate Authority and enforce connectivity over TLS.


Anyone observing the exchange can just trivially calculate K!

K = (K xor R1) xor (K xor R1 xor R2) xor (K xor R2)

This are exactly the three messages which are sent in your protocol...


Why don't Twitter and Facebook enforce password complexity during sign up?

Facebook and Twitter have very...specific, controversial security postures. They serve a broad market and the security space does not always appreciate everything they do. My recommendation for an app you're building might be not to follow Facebook and Twitter's examples in terms of security.

For resources, I recommend looking to OWASP first. If you're not familiar with OWASP, they're a collection of application security methods and best practices, giving visibility on the whole lifecycle - from conception and design through to pentesting. They lead the appsec industry and speak with a huge amount of (well-earned) authority.

All that being said, definitely checkout OWASP's information on password strength controls. If you're looking for help with password strength implementation, hopefully that should sort you out. (And while you're there, have a look at the OWASP top 10 for other helpful tips when it comes to building your app.)

Great question by the way. Good luck with the app!


The sugCls.handleContent method code is here starting on line 1263:
https://github.com/liigo/html-parser/blob/master/test/testfiles/sohu.com.html

You can see that it does some interesting slicing and dicing to extract parts of the string it is passed. To de-obfuscate, one would need to follow each step manually, run the command in its intended context and hook the output (e.g. to a console), or extract the relevant bits of the handleContent method and write an equivalent method.

Unfortunately, the purpose of obfuscation is to make sure that the code will not make sense to a human interpreter. By nature, de-obfuscation is a very difficult process, and there are hundreds of techniques and tools one might apply (often to no avail!).


Are SHA-2 certificates considered obsolete, or current?

"SHA-2" is the traditional codename for a family of six functions that includes SHA-256 and SHA-512. These functions are considered completely fine and current and non-obsolete.

There is a newer family of functions called SHA-3, but it has been formally defined only very recently, and nobody really supports them yet. Moreover, SHA-3 is not formally defined as a replacement for SHA-2, but as an alternative.

All the current fuss is about an older function called "SHA-1", not "SHA-2" (and most of the panic is greatly exaggerated).


You are right that it doesn't really provide more security.

Except usability problems and increased complexity, I'm not sure what it brings. For example, if you change the session_id and invalidate the previous session_id on every request, your user won't be able to use many tabs in his browser.

Also, as you stated it doesn't stop an attacker to get in there first and use the session_id before the real user.

Is it acceptable to not change the session_id?

Yes, while the user is logged in there is no reason to change it.

So, then, how long should the user stay logged in?

It always depends on the security your application need. For example, stackoverflow doesn't reset my session if I don't log in for a week. It doesn't reset it even if I close my browser. On the contrary, my bank website will close my session if I'm inactive for like 10 minutes or if I close my browser tab.

Leaving a session open increase the risk that it can be stolen. If it's crucial to keep the session safe then change it often. The idea here is to define rules about when you need to change it and to balance security and usability.

Note : The session_id security is pretty similar to CSRF token. Here's a similar question : Why refresh CSRF token per form request?


What's the best way to secure the responses in a single page web app after logout?

Encrypt the content using a session key while in transit. Decrypt the content in-memory using a variable.
At logout, explicity clear the variables containing keys and decrypted information. Also explicity clear any variables containing authentication information and any information that was used to generate the session key.
The session key can be generated out of authentication information like hash of username/password and other information accessible to both client and server, but NOT someone watching the decrypted network traffic inside a SSL session (which the developer Tools do). Also beware of "pass-the-hash" attacks on the authentication scheme - eg if you hash username/password on client side, beware that someone might find the password hash inside developer Tools and then send the hash itself to login - without knowing the password.

A suggestion is following:

1: User logs in with username and password.

2: Application sends Username, H(Username, H(Password, T), T) where H() is a hash function and T is a timestamp. Read more in 3 how the timestamp is constructed.

3: Server checks that the record is valid. This is accomplished by having T to be a timestamp that has a granularity of 1/2 of the expected validity time. This is generated by cutting off bits from a standard unix epoch timestamp. Eg, if you want validity of 5-10 minutes, remove the last 8 bits from the timestamp. At validation, check if the hash match with T=current_timestamp, T=current_timestamp-1 or T=current_timestamp+1 to compensate for a client Clock that is slightly off. This gives a validity of 256-768 seconds, which is roughtly 4-12 minutes.

4: Application now generates a session key, using H(Username,Password,T,Static salt). Save session key in variable. (this ensures session can be used for longer than 4-12 minutes). NOTE: You CANNOT use a timestamp to expire a session, you HAVE to clear the variables if you want to expire the session due to inactivity. Remember that variables are accessible to a malicious indivual if not cleared - timestamp is only used to expire a used password hash so it cannot be reused.

5: The server script generates a session key in the same way, ensuring to use only the T that was found out to be correct during validation at 3.

6: Use the session key to encrypt information in the JSON structures.

7: at logout, delete session key, username, password, H(Password, T), and H(Username, H(Password, T), T) and also any information that was transferred during session. This is accomplished by simply setting the variable to nothing, eg key = "";

The above login scheme makes Everything secure both against pass-the-hash attacks and also secures information in-transit using a unique session key. Also session keys from a Another session cannot be used to decrypt previous sessions.

This ensures information is encrypted when its visible in developer Tools. Its not possible to gain the values of variables in developer Tools after they have been cleared, ensuring no access to data.

If the computers are in a controlled segment, which they should be if you developing a Health record application that is accessed by doctors, you SHOULD disable all debug/developer functions via a Group policy. But that is hard to do if the application is accessed by patients.


Bidirectional encrypted server to server communication using TLS

You can simply create a unique certificate signed by a purpose specific CA and force both machines to only accept certificates from that CA. It would be the Apache equivalent of

SSLCACertificateFile /your/CA/folder/ca.crt
SSLVerifyClient require
SSLVerifyDepth 1

This approach is scalable, as you can include a third machine in the future in your "security ring" to contact any of the existing machines. Only those with a signed certificate from your CA will be accepted into your ring.


Can software keyboard add security to decrypting FDE'd Drive

Most “keyloggers” are in fact general spyware that detect many things other than key presses and are not at all fazed by on-screen keyboards. But such a keylogger would be software running in the operating system. It's possible to store malware in the computer's firmware, but that's a rather advanced threat; while malware in the firmware of many peripherals can access the RAM, figuring out what the software is doing from outside the OS is difficult. This being said, once someone has written the software, anyone can run it, so it's easy to spread software attacks.

So relying on an on-screen keyboard does reduce the risk of a keylogger attack when running an OS you control on hardware that you don't fully trust. It doesn't eliminate it, however. Using hardware that you don't trust also has the problem that you can't know that it's really executing your program. It would certainly be possible to write spyware that analyzes the OS on your drive a bit and invisibly injects itself into it.

If you really don't trust the hardware, don't use it, period.

If you kind-of trust the hardware, then you can reduce but not eliminate the risk by reducing the hardware attack surface. Eliminating the keyboard is an advantage in at least one situation: in a cybercafé-type environment, when you trust the administrator of the machines but you fear that someone will perform a discreet modification such as inserting a hardware keylogger into the keyboard. Still, once the software for the attack has been packaged, it's easy to insert a piece of hardware that's actually a USB hub with the attacker's hypervisor, causing your OS to run inside the attacker's hypervisor and thus exposed to the attacker's spyware. You're just requiring the attacker to be a bit more sophisticated.

Once again, the only way to have confidence in a computer is to trust its hardware. If you don't trust the hardware, you can't trust any software that runs on it.


Role of the chosen ciphersuite in an SSL/TLS connection

So from what I understand it generally works like this:

Client connects to the server

For HTTPS yes. For other applications it varies; some make a new connection and some reuse an existing connection.

Client tells server about their supported protocol (e.g. TLS 1.2) AND the cipher suite (e.g. ECDHE-RSA-AES128-GCM-SHA256)

Ciphersuites plural, and quite a few other things in extensions, both shown in the article you link. (Which highlights SNI as relevant to the IIS/http.sys logic being described.)

Server answers and agrees on a protocol and cipher suite they both support (e.g. TLS 1.2 & ECDHE-RSA-AES128-GCM-SHA256), as well as the servers certificate (also containing their public key)

The certificate contains the static (long-term) public key, and as ISMSDEV said is accompanied by any intermediate aka chain certs, and optionally the root cert. The article doesn't clearly state, but does show in the network trace, that the certificate(s) are actually a separate message but possibly in the same SSL/TLS record and almost always in the same TCP frames. For ephemeral keyexchange, as in the ciphersuite you specified but not the one in the article, the server's ephemeral key (with parameter(s) and signature much as ISMSDEV said) is in a separate message ServerKeyExchange; then optionally another message to 'Request' a client certificate, again not clearly stated and this time not shown; then a ServerHelloDone message, not described at all but shown.

--- now from here on they communicate based on the chosen protocol and the role of the cipher suite becomes important ---

The protocol version/format and key-exchange have already affected the server messages above. The symmetric cipher and possibly hash don't have effect yet.

The client verifies the server's certificate against known certificate authorities and extracts the server's public key for the key exchange

Verifies the certificate chain, extracts the longterm (certified) key and also extracts and verifies the ephemeral key if used, which it is in the ciphersuite you specified.

Now the cipher suite's key exchange kicks in (in this case ECDHE-RSA), which uses the server's public key - the result is the pre-master secret (as depicted in the diagram below)

Key-exchange has already started, with the server messages above; it is now completed using the client's key. The diagram you copy shows an arrow from client to server with (encrypted) pre-master secret because it is for a ciphersuite using RSA key-exchange, but you specified a ciphersuite using ECDHE-RSA key-exchange and for that the client's ephemeral publickey is sent (in clear) instead and the ECDH algorithm is used, independently at both peers, to derive the pre-master secret.
In addition if client certificate (aka client authentication) was requested, the client may send its own cert chain and its signature on a transcript through the client's key exchange message, (both) as separate messages, as described in the article but not shown.

With the pre-master secret, both the cipher and the hashing algorithm are then used (in this case AES128-GCM and SHA256) for the message encryption and digests.

Not yet.

The key exchange is repeated, encrypted with the cipher, using the pre-shared secret and verified with the hashing algorithm. The result is the master secret

Nothing is repeated, and nothing directly uses the pre-master secret. Instead the pre-master secret is used with the 'random' (nonce) values from the Hello messages in an algorithm called the PRF (Pseudo-Random Function) to derive the master secret, and then the master secret is similarly used to derive several session keys. As the article says:

[the server] performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
(bullet) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity [....]

Note the plural in 'session keys'. For some ciphersuites in TLS1.2, including the one you specified, the hash in the ciphersuite affects the PRF. For other ciphersuites, and all lower protocol versions, it does not. See What's the hash for in ECDHE-RSA-AES-GCM-SHA? .

The master secret is used with the cipher and hashing algorithm, to encrypt any further communication.

Each endpoint sends a message ChangeCipherSpec to 'activate' the ciphersuite and then a message Finished, which is the first encrypted (and MACed) message. As the article says:

The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key. It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.

Nothing directly uses the master key. Symmetric (data) encryption uses two of the session keys (one for each direction). For ciphersuites that use HMAC for integrity (as in the article), it uses the hash algorithm from the ciphersuite (and two more session keys), but you specified a ciphersuite which uses GCM mode, which as ISMSDEV said provides its own authentication (not using any hash).


My Virgin Media account password is visible in plaintext to call center staff. What do I do?

Generally, reuse of passwords across different sites is a bad idea for this reason; you never know whether they are taking measures to secure your password from view of staff or hackers who might grab the database.    Of course, once one of these sites is compromised, hackers will try the same password combination for other common accounts like Facebook, PayPal, etc etc.

I recommend using LastPass, KeePass or another password manager to generate a new, random password for every site you login to and then save it.  Sure, having all your eggs in the LastPass basket might seem like a security risk, but at least they are more trustworthy to use best practices and secure your data.  This is evidenced by the recent hack of LastPass, which because they had been salting/hashing their passwords so well, I haven't bothered to change my master password because the risk of compromise is so small.

I think using random passwords and saving them in a manager like LastPass is a MUCH better practice than memorizing and reusing passwords on different sites.  It also has the advantage of being easier/quicker to login as well, and reduces risk when you create logins on sites that you don't trust.


in such a way that only the user can access it.

It makes no sense to encrypt the data the server have to operate (unless you are exploiting malleability). Fully homomorphic cryptosystems are infeasible now and not so well studied, so it is infeasible to protect user's data from a privileged party.

So let's suppose you try to mitigate offline attack, when an adversary obtains a dump of server db with user's data in it and tries to decrypt it without knowledge of user's passwords. The adversary is unable to modify the code running on the server and unable to monitor the data the server gets/gives from/to another users.

You use SHA-256 of the data having poor entropy, which means it is easy to make a dictionary brute-force. So my first advice is to replace SHA-256 with some KDF (hash functions intentionally made resistant to brute-force at cost of running time and memory), for example the Halting KDF, and have personal salt for every user.

Changing passwords is not a problem because you are able to re-encrypt the data.


Can someone be connected to a router but not be in the DHCP table of a router

Someone can definitely be connected to your router without showing up in your DHCP lease table. Anybody who has given themselves a static IP address will not show up in your DHCP table.

In order to do this, someone would need to know some basic things like

What the gateway IP address is
The subnet mask
an available IP address that would not cause a conflict with another device on the network.

This could easily be done by connecting via DHCP, then statically setting your IP address to the same settings the DHCP server gave. Now in that instance, the DHCP lease would still show up in the table until it expired, but once the lease expired that device could exist on your network and not show up in your DHCP server. They would need to have physical access to the inside of your network to make this happen. This could be a wireless connection, or physically plugging into a switch  or router.

Now with that said, I highly doubt that the issues your experiencing are caused by a rogue actor on your network sucking up all your bandwidth. In your post you say that the statistics the router gives the upload / download speed are not what you would expect. I'm going to assume you know that you're not always going to be downloading or uploading at peak speeds. In addition if you did have a rogue device sucking up your bandwidth, this would be shown in your router statistics (this is a generalization, but I assume you can see realtime transmission statistics based on what you've said in your post).

The long answer to your short question is that if you are not receiving speeds that you would expect (run something like Speedtest.net to confirm your upload / download speeds) then this is likely an ISP issue. This commonly happens in instances where the signal is not strong enough, or perhaps there is an MTU issue. Contact your ISP and they will walk you through troubleshooting.


How to analyze server crash dump after recent patch update?

What you are asking for how to do crash dump analysis for determining the source of crash. There are number of techniques though i describe the basic one.

First you need to install Windows Debugger (WinDbg.exe) which is installed with windows software development kit.
Second part is to configure WinDbg with Microsoft symbol server.


Does client have to send the CA chain along with the client certificate after ServerHello?

You are responsible for sending enough of the chain for the server to connect your certificate to a trusted root.

For TLS 1.2 this is discussed in RFC 5246.  Client certificates are defined in §7.4.6, which (among other things) states:

  Client certificates are sent using the Certificate structure defined
  in Section 7.4.2.

And if you look in §7.4.2 it describes the Certificate structure as including the certificate_list (emphasis mine):

  This is a sequence (chain) of certificates.  The sender's certificate
  MUST come first in the list.  Each following certificate MUST directly
  certify the one preceding it.  Because certificate validation requires
  that root keys be distributed independently, the self-signed
  certificate that specifies the root certificate authority MAY be
  omitted from the chain, under the assumption that the remote end must
  already possess it in order to validate it in any case.

In short, the server is expected to have the trusted root, but not required or expected to have any intermediate certificates that may be required.  The client is required to provide them if it wants verification to proceed smoothly and reliably.  (And the same is true for the certificates the server sends to the client).


Storing two copies of data, encrypted in different ways

An attacker now has the advantage to be able to choose which crypto system he wants to break. It's enough to find a weakness or implementation error in either one. As for you this adds the responsibility for keeping two systems equally safe.

If we assume that you do that correctly, I can't see any significant advantage for an attacker...


Can you cut up frames/packets and combine them anonymously?

Yes, you can mask the source IP

Nothing stops you from writing a false source IP address, just like nothing stops you from changing the "From" field on a letter. In fact, IP packets and letters are remarkably similar.

  What happens if I change the source address?

The answer is quite simple: You will not get a response. The IP address in the source address will get a response. This technique is used in some DDoS attacks to mask the origin of the attack, or to cause the server to reply to the server you actually want to attack.

  Can this be stopped?

Yes, in a remarkably simple way. Imagine you live in New York and go to a local post office, wishing to send a letter to France. As the sender's address, you state "The White House, Washington DC". It's very likely that an attentive postal worker will reject your package (and possibly notify authorities, but that's beside the point).

How could the postal worker know it was fake? Because the postal worker knows which "Source Addresses" are legitimate - namely those from New York. Any source address outside of that will be rejected. Network Ingress Filtering is a technique that works the same way.

ISPs know the range of addresses they hand out (e.g. 203.0.113.0/24, so 203.0.113.1 to 203.0.113.254), so any IP packet coming from that network with a source address in this range will be accepted, and the rest rejected.

About the other questions

  Can you chop up an IP packet and send it from multiple IP addresses?

Yes, this is actually done regularly by routers all over the world. It's how the internet is designed to work. It also doesn't give you any kind of anonymity, because the Internet Protocol wasn't designed to be anonymous.

For further reading, Wikipedia has an excellent article describing IP Fragmentation.

  Does this somehow relate to the Tor network?

No.


Security risks of allowing customer to use his own domain for a hosted SaaS application

No, if the application is used solely by the customer, or any third party trust the application because they trust your customer. (not you)

For example: A administration panel, a web site that is under the customer's solely Control, a shopping page for customers etc.

Yes, if the application provides value to a third-party, and this third-party should not need to trust the customer.
For example if a user select to trust this SaaS application without implication of which customer it is.
Another example is a credit card entry form by a PCI DSS compliant aquirer. If the aquirer allows the customer to set his own domain on the CC form, then the customer's DNS server must be protected on the PCI DSS level, since if this are modified, the domain can be aimed on a CC collecting malicious site.

One example of this is that you provide antivirus scanning, and then you sell this "without brand name" to a customer, which can put his own name on the antivirus solution.
If the customer trust this solution because the Engine come from you, then your customer can turn malicious and aim the SaaS domain on a malicious site at any time.


How to (programmaticaly or by other means) encrypt or protect customer data

One standard method used for something like this is application layer encryption.

Your project consists of a web tier (Django) and a database tier (PostgreSQL).  If you implement your encryption in Django, then you can write encrypted blobs to the PostgreSQL data store.  This is not, by the way, "client side encryption" as described in the article you link to.

The advantage of this method is that you separate the encrypted data from the keys.  An attacker who is able to dump tables out of your database can get at the encrypted data, but not the keys.  An attacker who is able to compromise your application and extract the key still needs to get the data to use the key on.

The disadvantage of this method is that the encrypted data can't be searched or manipulated purely at the database level.  If it's passwords, that's fine; you're not going to be SELECTing all the passwords with certain criteria, you'll usually just pull one and compare it.  But for other sorts of data that can be onerous.

Update to address comment below in proper length:

Yes, if the attacker compromises the application, it is possible for them to compromise the key, and possibly even to leverage the application's database access to take advantage of the key.  So why is this better?

First of all, it removes some common single-vector touchdown attacks.  If the web app suffers from SQL injection, for example, an attacker can usually extract full tables from the database.  But they can't extract the key from the application in the same way, and will then need another separate successful attack to achieve their goal.

The attacker can wait for something interesting - but if they compromise the app, they can probably intercept inputs and compromise info as it comes in before it's sent to the database; access to the key is irrelevant at that point.  And that requires a long-term compromise and patience, which is less of a concern unless you're a target in the APT space.

Compensating controls can be put in place to limit the impact of application layer compromise.  For example, if the application only has access to certain stored procedures, and not the ability to execute arbitrary SQL against the database, then even if the attacker compromises the application and gets the key they may not be able to leverage it to get bulk data.  Any iteration to get data piecemeal is much more likely to get caught by logging, alerting, or SQL monitoring tools.

And, while less common, the separate storage of the key prevents backup attacks which gain access to database backup files.

There is no perfect security, but defense in depth is a proven method to improve security.  Separating the encryption key from the encrypted data in a multi-tier application is an excellent contribution to defense in depth.


What unique fingerprinting information can an iOS 10 app collect?

As always there is basic system info available similar to what any web page can access: IP address, HTTP headers, etc. Many of these are low entropy or can be changed by the user through various means, but it may be possible to combine enough for a reasonable identification. Or for reasonable enough correlation for cross-device tracking.

You have answered your own question.

You can be fingerprinted merely through access via a web browser. Given an install on an ios device has in-practice all the capability of a web browser, and more on-top. Look at canvas detection etc.
https://browserleaks.com/ is a good example of some basic methods.

Advanced techniques just gather a crapload of data and feed it into AI, the big players, like in most aspects now, don't bother looking into factors too much in-depth, they just hire some maths wizards & let them train AI to do the rest.

If I can run Javascript & HTML, as in a browser, it is possible to fingerprint you to near 100% accuracy - your only mitigation would be pointless as it would take so much effort the cost of doing so would outweigh any benefits - In most cases, those whom attempt to avoid fingerprinting only make themselves more unique/distinguishable.

  In general, what remaining device fingerprinting privacy/security vulnerabilities still exist as of iOS 10, particularly those that have no user controls or actions that can thwart them?

*All those that exist in any web browser. I agree with you that the app/web design should be much more permission-oriented & opt-in. I.e, assign each app as specific permissions as I want to. However, you can never prevent fingerprinting. Fingerprinting is merely a correlation.
Let me summarise the headache for you:
You do everything to mitigate web tracking techniques.
However, the NSA/GCHQ has intercepts all global traffic. They can identify requests chained via proxy or VPN and can correlate them to fingerprint you merely by your connection latency.

Hence: you decide to increase or randomize connection latency.
With a small tweak, GCHQ/NSA/whoever else can now identify you (via global taps) by identifying unusual/unique latencies on requests and receive connections (enabled via global taps on all comms).

I realize the example I give is complex and not to do with ios. But you ask an extremely broad question, and to give you an answer:
You can be tracked, no matter what measures you take. Including on IOS 10. As discussed already, given I have basic web page capabilities I am already capable, let alone the other features all IOS versions offer.

Just to keep you busy, here's another one:
You block your location, cool.
The app requires an internet connection to work (you want to use it as you have installed the app, so you obviously have no other choice than to permit wifi/internet connection).
Gotcha, I now have your location via your wifi/network information thank's to Google's mapping data.

Have fun...


How safe are the passwords suggested by Apple keychain?

I believe that answering this question based on the mere complexity of the password generated may miss the mark.   While it appears the passwords generated by Safari/OSX Keychain are quite complex and would be virtually impossible to crack with technology available today, this only helps in defeating brute force attacks.

Much more commonly, passwords are discovered through:

Malware/Keyloggers

This OSX keychain access should make it harder for malware and certainly keyloggers (since you're not typing anything) to obtain passwords.

Password re-use

Reuse of same password on multiple sites means taht if one site is compromised/experiences a breach, hackers will try this username/password combination on other sites.

So, that said, using unique passwords for each site and a password manager like Safari/Keychain increases your security significantly.   This security enhancement goes far beyond the simple complexity of passwords, because by using a password manager you're engaging in a best practice that helps defeat numerous types of attacks to get your password.


How a risk assessment impacts information security policy?

Risk assessment should not affect information security policies.  Policy should be a statement of goals/objectives, and should normally not change.  Policy should define the limits of risk management.

Multiple different organizations provide different risk assessment/risk analysis methodologies, but I think those are too detailed for your question (I'm not sure if you're asking about ATO, C&A, ISCM, RMF, etc.).  If I understand the question correctly, the answer is that Risk Assessment & risk analysis are intended to start a constructive suggestion about the response to the risk.  When you complete a technical assessment:

There are generally more findings than there are resources to fix findings. Risk assessment prioritizes resources against risks - if you have $N dollars and 10x$N problems, it makes sense to spend the first $ on high probability, high impact problems, and defer solutions on low probability/low impact problems. Technical findings may reveal that you don't have a fence around your facility, leaving you vulnerable to physical infiltration; that is not a problem if you are a ship at sea.
Many of the findings are the result of the instant when the technical assessment was conducted.  Risk Assessment can discuss the urgency of the problem.  If my patch half life is 7 days, then at any instant technical assessment will find that I have unpatched machines.  Risk assessment allows me to compare the cost of an emergency configuration control board against the fact that those patches should be resolved within 7-10 days.
Many findings are unresolvable.  I worked on one assessment that found a flaw in network devices that would have required tens of millions to fix - we would have had to replace relatively shelf standard network devices (that could be administered by normal network admins), with specialized network devices that required specialized training and exclusive support.   The unit cost was high, the support costs were higher and the number of units were in the low thousands. Replacing shelf standard equipment with custom crafted equipment is very expensive. There was an alternate solution that could be done using maintenance spares, and the resulting environment was actually more secure than the custom equipment.
Sometimes the technical finding is not the problem; the underlying procedures/governance is the problem.  I've managed a number of assessments where the technical problems mount up because the relevant manager hasn't bothered to ask for the money to solve the underlying problem.  Risk assessment is the framework for the discussion that begins, "If you ask for $X now, you'll get it next year, but if you wait for the incident to happen, it will cost you 100$X. Here is how to do it..."*
Sometimes the finding is not worth the effort.  It doesn't make sense to implement two factor authentication on a SCADA control panel.  If it costs thousands of dollars to stop processing, log out of the system, log back into the system and start processing again at the end of every shift, there are other ways to ensure accountability.

Technical assessment compares an abstract ivory tower set of principles to a system that is in place to perform a mission function.

Risk Assessment is the start of a dialogue, "How do we accomplish our mission with our resources in our environment, knowing that we have these vulnerabilities?".


How do I configure Symantec AV to permit pentesting tools without compromising my organization's network and my host computer?

If you're doing true penetration testing then the goal is to see what your blue team can and cannot detect or prevent.
So you don't want to disable anything. Your pen tester must be skilled enough to find ways to bypass your security controls on his own.

It almost sounds though like your confusing a penetration test with vulnerability management. If you are just trying to scan for vulnerabilities, that is not a penetration test. Vulnerability scanners would be run from dedicated scanning systems that have the scanning tools whitelisted and allowed to execute.


Is it possible to exploit XSS by replacing image data for img tag

There're some exploits in old browsers, e.g. Opera10 allows to execute Javascript for SVG fonts in .svg files (https://html5sec.org/#43):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg onload="alert(1)" xmlns="http://www.w3.org/2000/svg">
<defs></defs>
</svg>


From the beginning SPF test has compared the envelope sender against the published DNS record. This article is wrong claiming that this has been changed.

SPF is simply designed against forged senders, not forged headers. DKIM is designed to protect the headers and the body against forging and tampering. The From: header is always signed, other headers being optional.

DKIM can only protect mail that has been signed, but it doesn't provide a mechanism to prove that an unsigned message should have been signed. DMARC alignment can enforce DKIM by telling the receiver how they should handle unsigned messages.

SPF and DKIM protects your email domain against different threats. The only efficient solution against email spoofing is to use SPF+DKIM+DMARC together in a combination that allows all your own email scenarios and restricts everything else.

To answer the new question after the modification:

You need SPF record to match the envelope sender. Your SPF record doesn't need to match the sender in the From: header as it's never tested against the SPF record.
You should also implement DKIM+DMARC. This protects the From: header.
With all three set, a 3rd party email server can send email on your behalf using your domain in the From: header, if they have a matching DKIM signature. The envelope sender must match the SPF record: it can be their own domain, or you can add their servers to your SPF record to allow using your domain. Both are equally good, as the receiver only sees the From: header, and it's validated by DKIM.


Effectiveness of Secure Boot on kernel-mode rootkit detection

Secure Boot consists of several components working together ( https://technet.microsoft.com/en-us/windows/dn168167.aspx was my source for how the different components work). Because it works vertically (from the bootloader up) the security of the kernel-mode protection the requires that the lower levels work flawlessly.

Secure Boot

When the PC is turned on the UEFI Bios finds the bootloader. The Bios will only run the bootloader if the bootloader is signed using a trusted certificate or the user has approved the bootloader's digital signature. This prevents and modified/unofficial bootloaders, theoretically stopping bootkits. However this only works if the security is implemented correctly. A little Googling finds several reports of methods that allow a program to bypass the Secure Boot.

http://www.pcworld.com/article/2337180/new-attack-methods-can-brick-systems-defeat-secure-boot-researchers-say.html
http://www.pcworld.com/article/2045793/researchers-demo-exploits-that-bypass-windows-8-secure-boot.html
http://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html
http://www.intelsecurity.com/resources/pr-bios-secure-boot-attacks-uncovered.pdf

I will leave the evaluation of these articles as a exercise to the reader. In addition there seem to be articles that reference bugs in the UEFI implementation of several motherboards. If we assume that these exploits exist then all further Secure Boot steps are compromised, including the Kernel mode root-kit protection.

Trusted Boot

The bootloader then verifies the digital signature of the kernel. Then the kernel verifies the Windows start process. This includes the kernel drivers, the startup files and the ELAM system. If any of these files are corrupted then the computer automatically tries to repair/replace them. If this fails the computer refuses to boot. However this assumes that the bootloader was secured. If that step was compromised then this one could be bypassed as well.

Early Launch Anti-Malware (ELAM)

ELAM starts antivirus software before non-Microsoft boot drivers are loaded. Once ELAM is started it scans drivers as they load. This theoretically prevents malware infected drivers from hiding themselves from the Anti-Virus software, which is normally  not loaded until after boot. ELAM can load either a Microsoft (Windows Defender, Endpoint ect.) or a non-Microsoft anti-malware driver. If a driver contains malware or is not trusted then ELAM will prevent it from loading. This is secure to the point that you trust the anti-virus software to detect driver exploits and malware, which is not guaranteed with new exploits.

Measured Boot

Measured Boot does not prevent exploits, instead it helps in their detection. Using Measured Boot Windows sends logs about the boot process to a secure server. This includes hashes of the boot files allowing any changes to be detected. In order for this to work you need to a. have a secure server setup and b. actively monitor the boot logs.

These potential issues do not mean that Secure Boot does not work. I found very few references to functioning rootkits or bootkits for UEFI systems in the wild. In addition the Microsoft Security Intelligence Reports 18 or 19 (https://www.microsoft.com/security/sir/default.aspx) do not report any rootkits or bootkits. Of course they also make no claims in the reports that Secure Boot fixed these issues.


Protecting against GCHQ port scans: How does TCP stealth work?

The difference is that SPA has a separate authentication step taking place over a UDP port before the SSH port is opened. In TCP Stealth, authentication is performed inside the SYN packet that initiates a connection with the protected service.

An advantage of TCP Stealth is that it does not need to keep track of which ports are "opened". It only needs to keep track of state like a normal TCP stack does.
Another advantage is that no application need to be installed on client systems when this goes widespread. It will simply be built-in to all computers. So upon connecting to a resource, you could tell your operating system to embed a password in the SYN packet.
A third advantage, since an out-of-band authentication step is not performed, a NAT router could easily add authentication data to specific SYN packets to perform network-to-network authentication (like it was a VPN tunnel between the routers but without the encryption).  This would provide access to a specific service to all computers behind a specific NAT router. The same thing with SPA would either require 2 connection attempts or a long waiting period to connect.


How can the sybil attack be used on a P2P system that implements DHT?

In a reputation based P2P network, an entity gains more resources or priority by having a higher reputation. Consider for example this site, Stack Exchange:
Suppose you could write a simple script that generates hundreds of new accounts in a minute, and generates proper questions for those accounts. You could have your bot accounts vote on each other's questions and answers and soon enough you'll be able to downvote anything to oblivion, control which questions are more visible, ...etc

As for Bittorrent, it doesn't implement any sort of shared reputation, but here's how it works:
if you generate enough identities, eventually, you should make it into everyone's DHT routing tables, and a bit later you'll have a sizable fraction of the total vote.
By replying with invalid info you can now pollute the network enough to introduce delays and outages. You could make it likely that anyone ends up with, say, 80% sybils, and now those sybils can give downloaders invalid file contents for certain torrents, effectively censoring them.

Source:
Liang Wang; Kangasharju, J., "Real-world sybil attacks in BitTorrent mainline DHT," Global Communications Conference (GLOBECOM), 2012 IEEE , vol., no., pp.826,832, 3-7 Dec. 2012


When is Veracrypt an acceptable solution?

You should use LUKS2 with authenticated encryption.
You can format a device for this by running:

cryptsetup luksFormat --type luks2 $dev --cipher chacha20-random --integrity poly1305

You specified that data integrity is a requirement. In that case, you should not go with VeraCrypt, as it does not provide full integrity. It uses a mode of operation called XTS which is not great on its own. It is also malleable, which means someone can modify the plaintext by modifying the ciphertext without knowing the key. However, they are limited to only randomizing 16-byte chunks of data. That is, modifying a single bit in the ciphertext results in 16 bytes of plaintext being randomized without VeraCrypt noticing. When you use LUKS2 with authenticated encryption, this issue is mitigated and integrity is protected.

Now, does VeraCrypt have any use-cases that LUKS does not? Sure. VeraCrypt is easier to get working under Windows than LUKS, but the biggest benefit is plausible deniability. If you are in a situation where you have an external encrypted drive and someone is demanding that you disclose the password, you can claim that the drive was wiped and does not contain encrypted data if you use VeraCrypt. If you use LUKS, this will not be possible as it contains a header specifying that it is LUKS. VeraCrypt also has the additional benefit of supporting hidden volumes, which can be useful in certain repressive regimes.

Note that plausible deniability and hidden volumes may not work effectively on solid state media.


Ingress RFC1918 spoofing: How to handle it?

Not really, yes, and no.  ISPs tend not to filter traffic that way for a couple of reasons:

The first is practical.  Equipment designed to process high packet volumes has evolved to the point where a lot of the routing decisions are made in hardware.  Imposing ACLs diverts that traffic to be handled in software, which doesn't route packets nearly as quickly, adding to the amount of equipment required to route the same volume.  This is really a problem of evaluating threat before acting on it. The level of traffic containing spoofed 1918 addresses would have to be sufficient to have detrimental effects on other parts of the network before an ISP could make a business case for implementing ACLs and investing in more equipment.  When that equipment is a router chassis populated with cards that cost six figures each, the bar is set relatively high.

The second is legal.  The product sold by most ISPs to most business customers is plain, vanilla packet transit.  Once the ISP starts filtering customer traffic, it runs the risk of being held liable for not having filtered traffic that a customer deems damaging.  Most contracts explicitly indemnify the ISP from it, and at that point there's no point in adding filtering, putting the onus entirely on the customer.  That's why managed, firewalled connections are more expensive than the regular flavor:  it costs more to provide and carries more liability.

Your options are to drop the traffic at your ingress or, in the event you're seeing large amounts of it, take it up with the originating AS's abuse team.


When you're not sure if something is legal, it's best to not do it. We aren't lawyers, you shouldn't trust our analysis if what is and isn't legal.  Even if it was in a grey area there's a good chance it could be a pain while the legal system sorted it out.

The CFAA is likely the law you would run afowl of.

You can report fraud and crime to the FBI

Don't take the law into your own hands. There a chance you will do more harm than good.


Cetificate Pinning. How do we handle the situation where a website is visited for the first time?

The way that trust on first touch is handled for pinning is by the use of Pre-load lists, where the certificate to pin against is loaded into the client software at distribution.

You can see more information about what domains Firefox has preloaded here

Revocation with pinning is an interesting topic.  What I've seen suggested is that you pin two keys, one that your using live and a backup one that you keep offline.  That way if you need to revoke your main certificate you have a spare one to use.

Without that if you revoke your certificate you could be in a spot of bother depending on your customer base.


Are OpenSSH vs OpenSSL public key format names mismatched?

A little step:

$ ssh-keygen -y -e -m PKCS8 -f /home/wolf/.ssh/id_rsa | openssl asn1parse
    0:d=0  hl=4 l= 290 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 271 prim: BIT STRING

$ openssl rsa -in /home/wolf/.ssh/id_rsa -pubout -outform PEM | openssl asn1parse
writing RSA key
    0:d=0  hl=4 l= 290 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 271 prim: BIT STRING

$ ssh-keygen -y -e -m PEM -f /home/wolf/.ssh/id_rsa | openssl asn1parse
    0:d=0  hl=4 l= 266 cons: SEQUENCE
    4:d=1  hl=4 l= 257 prim: INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim: INTEGER           :010001

$ openssl rsa -in /home/wolf/.ssh/id_rsa -RSAPublicKey_out -outform PEM | openssl asn1parse
writing RSA key
    0:d=0  hl=4 l= 266 cons: SEQUENCE
    4:d=1  hl=4 l= 257 prim: INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim: INTEGER           :010001

$ ssh-keygen -y -e -m PKCS8 -f /home/wolf/.ssh/id_rsa | tail -n +2 | head -n -1 | base64 -d | openssl asn1parse -inform DER -i -strparse 19
    0:d=0  hl=4 l= 266 cons:  SEQUENCE
    4:d=1  hl=4 l= 257 prim:  INTEGER           :DEE24467850E0F877429474448807D2000B30E889BE6CA3BA8561B69D925F1C0AFA9A536A7EE95D077D5E5D6D3BA90C4C5E3B547B6872AD3F795816A54A7170EEB3454351424FD751EFA9A07F277C9F4987FCC94F9C06658D95567DD2A9E99AAF130BD86481AD34DA84DB1E91F1954043137E53816BA9AF49962E0BAC4B51FECBA45F4C20FC66F6AAAB910C576FD9AED5AE03BD77A2B9D51662DCF1725FEAD7263F29F170E8953FA3CE9C3E4B7A062F840C3273104946C266DC06AFAB2EF03DD8ABFCA0EF0B25AD9D07CFC9DADB35284FF6C0C9B73AD8E744B575AA833737DA8B1415615811E5FE95E6FA144B91A05B240DF20A29D12FD29AA9FF0A2E90F4973
  265:d=1  hl=2 l=   3 prim:  INTEGER           :010001

The openssl man page calls one the PEM format and the other the RSAPublicKey format.

What ssh-keygen calls PKCS8 and openssl rsa calls PEM is a wrapper around what ssh-keygen calls PEM, that adds an ASN.1 OID for "rsaEncryption". The last example parses the DER bitstring that starts at offset 19 to convince ourselves that it's the same exact data.

The format is described in PKCS#1.

PKCS#8 is here, and talks about storing private keys, not public keys.

I can't help answering what is the more correct name for each of the two formats, though I would call them by the ASCII string in the header.

I like the format that encodes the fact that it's an RSA public key inside of it, and so does not require externally encoding it (like the "ssh-rsa" prefix used in ~/.ssh/authorized_keys), though it is a little bigger. Using a self describing format, a program can learn to read ECDSA and EdDSA keys without inventing a new way to specify that the data is a public key but not an RSA public key.


PGP: How is it possible for me to read a sent mail, encrypted by me with the recipient's public key?

In the normal Thunderbird configuration, the emails are stored the way you send them, so if you send an encrypted email, it's also encrypted in your sent folder. (Note: there may be a way to configure Thunderbird or Enigmail differently, I don't know much about their configuration possibilities.)

Enigmail has an “Encrypt to self” preference (in the Sending tab; extensions.enigmail.encryptToSelf), which is on by default. With this preference turned on, all the emails you encrypt are encrypted for you (with the key configured in the applicable per-identity settings). Unless you've configured Thunderbird in an unusual way, this is what you're observing.

The underlying OpenPGP/GnuPG implementation can be configured for this as well, with the encrypt-to option in gpg.conf.


To prove that you own a domain you have multiple methods, being the most common to add a CNAME or TXT record to your DNS, or if it's for a web server, you have the possibility to upload a temporary file (like Let's Encrypt does with the webroot plugin).

Prove that you own an IP is a little more complicated and eventually would need some signed confirmation by your ISP. You can't use file upload because it's not a 1:1 relation. For example, if you have your site in a shared hosting, the IP would be the same for many customer and you just own a VirtualHost in that IP.


Google and yahoo: what criteria do they use to qualify a "new device"?

The true answer is only going to be known by Google and Yahoo!, respectively, but we can guess.

In order to determine if you've logged in from a device before, the service provider would either need to store a unique identifier on a device, or do some sort of fingerprinting.  As far as storing a unique identifier goes, the simplest way to do this would be to write a cookie using the browser.   If they are doing some sort of finger printing, there are a couple of datapoints they could use:

IP Address
Browser's User Agent String
Other types of browser fingerprints (too many to list.)

Browser fingerprinting is a vast subject, and there are too many possible options to list here, and it's likely that they use a combination of them to determine a unique fingerprint.  As far tools go, I am not aware of any simple commands which can give you all of the possible options.  It would be a matter of examining the HTTP Requests, and seeing what information is sent to the server.


Obtaining Access

To begin a dark web is a network (often encrypted) which overlays the Internet but requires specialised software to access it. The Tor client, supplied within the Tor browser bundle, will connect to the Tor network and direct traffic through a triplet of nodes: entryNode --> relayNode --> exitNode. All three nodes will encrypt data transmitted with their public keys in the order:

(entryNodePublicKey(relayNodePublicKey(exitNodePublicKey(data)))

Unless you have spyware loaded onto the host computers for the "important individuals" you will only see the entryNode IP address and encrypted traffic. Using this IP address you could confirm it belongs to the Tor network, as an induction node or guard node.

Because Tor is implemented for political activists, whistleblowers, oppressed dissidents, etc... it has built-in tools for censorship circumvention, OBFS4 bridges are among a few common methods, but another is using meek bridges. Meek bridges take advantage of AWS and Azure for domain fronting, this will make the Tor entryNode when performing DPI appear as an HTTPS amazon.com or microsoft.com connection; normal traffic. This method is deployed to circumvent the Great Firewall of China.

Equally other methods to conceal the entryNode connection include, but are not limited to:

OpenVPN using AES encryption: most modern VPNs
Proxy: HTTP, HTTPS, and SOCKS
RDP (or any other remote access protocol, preferably encrypted)

The RDP idea will involve connecting to a remote computer and be using that to access the dark web, with or without the protection of VPN(s) or proxy(s).

Mentioning about circumventing censorship has relevance, as Vault 7 disclosures outlined CIA malware would use data centers as botnets and would prefer performing any connections over HTTPS (with modern ciphers) on port 443. This would draw much less attention to connection logs when reviewed by a SysAdmin.

With this information in mind, now we should consider without tremendous detail, the metadata and "noise" the attacker made when obtaining the confidential information. Questions include:

Did they leave logs and metadata concerning the breach?
Did they use someone else's access to access the confidential information, or use a zero day exploit?
Do IP address logs belong to residential IP address(s) or recognised anonymising networks.

We have now built knowledge of when the confidential information was stolen. So, now we can see if the attacker had vulnerabilities within their OpSec that we can use to deanonymise them.

Selling the Information

This would be your second (and last) opportunity to identify the attacker. This also may not be possible, as it involves tracing the payment method, which could also employ money laundering.

This confidential information is now an asset to the attack. Presuming their goal is to profit from the attack, we will sell the information onto a buyer. A dark web marketplace would be a good start. Although, they could have been hired by a wealthy group to perform the attack. So, the information will be sold via either method:

Dark web marketplace
Closed auction (private)

The timing for selling this information would depend on the nature of the breach. Intellectual property with patents would not need a critical sell window, while a database of password hashes should be sold ASAP before the passwords are changed.

Payment would be your opportunity to trace the attacker. Payment could cover several forms:

Dead drop bank account(s)
PayPal
Credit/Debit card(s)
Cryptocurrencies

I cannot elaborate much further here, as money laundering is its own topic, and can be very broad. I can state that, the more judiciaries the IP addresses and payment cover, the more cumbersome and less likely you are to identify the attacker.


Would a RansomWhere application be possible for Windows too?

Already done - it's currently in beta.

Have a look at: Malwarebytes Anti Ransomware Beta.

Former times it was called CryptoMonitor developed by EasySync Solutions, owned by Nathan Scott. Nathan was recently hired to bring up the Anti Ransomware tool for Malwarebytes.


Yep. Open wireless networks are entirely unencrypted; anyone can see all the data you send (even if they aren't connected to the network).