How does a website get pass my server firewall and attempt to hotlink to my server resources?

If your access.log states that there is a connection to your Web server from localhost (127.0.0.1) then this means that some process running on the same server machine did that connection. If you are running a Web browser on the same machine, then that Web browser could be the culprit. Similarly, if your server is not the same machine as your desktop system, but you use that server as a proxy for your browser (SOCKS proxy, Web proxy, VPN...) then all your browsing activity will actually show up as connections from your server.

I suppose you are in one of the two situations described above. Now suppose that, with your Web browser, you browse a page (say, on a Web forum) which contains, in its HTML, this:

<img src="http://localhost/adm.html?adm=somehexdec&t=timestamp" />

then your browser will dutifully try to load the data at that URL, and, due to your own network configuration, the name "localhost" will be resolved from your server, and point to itself. Hence the log entries.

Now, what could be the point of such a link ? Well, it could plausibly be an attack attempt. Conceivably, there is a software system, somewhere, which technically runs as a local Web server, accepting connections from localhost only, with an "administrative" interface for connections to "/adm.html" file. If someone running such a system on his machine browses a Web page which contains the "localhost" link shown above, then his own browser will issue an administrative command to his software, command chosen by whomever put the Web page together.

Apparently you do not run such software (since your own server does not know of any "adm.html" and responds with a 404). The attack is not against you. However, this does highlight the limitations of firewall-based security in a Web context: Web pages that you browse can make your browser do connections to arbitrary other machines, including "localhost", without your consent, and since these connections come from your machine, they will likely go through your own firewall rules.

(In that case, this can be seen as an example of Cross-site request forgery, the target site being "localhost".)


How can Bitwarden claim it cannot access your passwords if the vault password is the same as the web account password?

The user password is pre-hashed with a slow password hashing function on the client side, twice, using different algorithms and/or salts. One hash is used to generate a login token (used like a password) which is sent to the server (where it gets additional hashing, and possibly also requires stuff like MFA). The other one is used as a "password-derived key" that is the first step to obtaining the master key for decrypting the database.
Typically the master key is stored on the server, alongside the user's data, in encrypted form. This encrypted master key, along with the encrypted data, is transmitted to the user upon successful authentication. A simple implementation is to encrypt the master key with the password-derived key; this encrypted master key can only be decrypted on the client (the server never sees the password-derived key). More advanced schemes involving public key cryptography are sometimes used to enable sharing select data with other users, without giving them access to your master key or any data you didn't want to share. The password-derived key is not itself used to encrypt/decrypt the data, because then if the user changed their password it would be necessary to re-encrypt everything. Instead, changing a password just requires decrypting the master key with the old password-derived key, and re-encrypting it with the new one.


If my connection to a website is unencrypted while using Tor is my IP visible?

No, your IP address will not be visible to the website, just the IP of the exit node.

The implication of the unencrypted connection is that your communications with the site can be monitored by the exit node. This could mean stealing credentials, or attempting to fingerprint you via other possibly identifying information (headers, screen resolution, font support, etc.).

They can also manipulate the traffic if they wish to, for example to deliver malware.


Using iptables to set up a killswitch for openvpn: DNS requests are blocked but they shouldn't

Run the command tcpdump port domain and then try to reach a hostname while connected to your VPN to see if the packages are actually sent to the expected DNS servers, and if you can see any response coming back in order to figure out what is going on.
If the DNS requests are sent to the wrong DNS servers, you can change your setup. Or even better, since you are already using iptables for this, you can add some iptables rules to the nat table that redirects all outgoing DNS packets addressed to any DNS server outside of your LAN to your VPN DNS servers:
*nat
# Redirect all outgoing DNS requests to a specific server (both TCP and UDP)
-A PREROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p tcp -m tcp --dport 53 -m state --state NEW -j DNAT --to-destination <DNS_SERVER_1>
-A PREROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p udp -m tcp --dport 53 -m state --state NEW -j DNAT --to-destination <DNS_SERVER_1>

(Be aware that these are rules for the nat table, so be sure to separate your filter rules from your nat rules by having your filter rules below the *filter line and your nat rules below the *nat line.)
You can also use iptables to log packages to see what are actually matched by your rules in order to troubleshoot.
Sending and receiving of UDP packets seems to be working since you are able to do traceroute which defaults to UDP mode on linux, so it seems kind of strange that DNS doesn't work.
Your last rule "-A OUTPUT -p tcp --dport 443 -j ACCEPT" seems to be accepting ALL outgoing https connections on ANY interfaces. This will also allow https requests to be sent outside of the VPN tunnel. You should probably put in the address of your VPN server in this rule.


Explain the last part of how Mitnick hacked Tsutomu Shimomura with an IP sequence attack

This file is a configuration file for some kind of antique unsecured ancestor of ssh: rsh (Remote SHell, more info including syntax example here).

This antique tool relies its security on TCP three-way handshake in order to trust that a remote host is really who it pretends to be. Due to ISN prediction, you already know this was a weak way of authentication.

Then, the same way that nowadays we can use private keys to allow password-less access to a system, in those days you could configure rsh to ease your systems remote administration by filling the list of remote hosts and users allowed to connect to you system (just hostnames, no asymetric key involved, remember? Trusting the underlying TCP protocol...).

And here, what Mitnick does is simply to put a generic mask allowing any user from any host to connect...


"global" OCSP with Apache mod_ssl / Alternative to -VAfile option Openssl

Question

What can I do to make my apache trust my self signed OCSP responder certificate ?

Answer

First, the self signed certificate must have these following properties :

KeyUsage : digitalSignature, nonRepudiation, keyEncipherment, keyCertSign
ExtendedKeyUsage : OCSPSigning
BasicConstraints : critical,CA:TRUE, pathlen:0

It must be in pem format.

Then, apply the following command to the certificate :

openssl x509 -in selfSignedCert.pem -addtrust OCSPSigning -out trusted.pem

And finally append it to the file specified in ssl.conf in Apache by SSLCACertificateFile directive


Can I concatenate multiple x509 certificates?

There is no way to combine multiple certificates into a single entity which then can be provided to the client for validation. It is also not possible to send multiple leaf certificates within the TLS handshake to the client in the hope that the client will pick the matching one.

The common way to deal with many names is instead to have many certificates and then use SNI to provide the expected one. This means that the client sends the expected domain inside the server_name extension within the TLS handshake ClientHello and the server will check this extension and provide the certificate which matches the requested name. Of course, this needs support by both client and servers. With HTTPS support for this is common in both clients and servers but for other TLS based protocols this might be different.


Principle: "Excessive" security measures make users search for ways to bypass security, thus defeating the purpose.

From my experience of implementing similar systems - and the logic we used to design them:

The idea of federated authentication is to "depend" on the identity provider to do the ground work for certain properties of the identity - so that you don't have to. If you are using Google/FB/LinkedIn or similar social media logins, this is a basic premise.
The key here is that you make sure that the identity provider's processes are indeed verifying the property (attribute) they are asserting.
So in general (i.e., unless your threat model indicates an exception) - you don't need to further verify an email address (which is among the most basic identity attributes).

** You mentioned "assuming the social account wasn't theirs": For most applications, I'd say this isn't a threat scenario that the app designer needs to cover for.
All in all, asking email to be verified again after a federated auth appears to a bit of excessive precaution hurting the security cause more than helping it.

There are several recommended password reset flows

a notable one that I remember is by Troy Hunt - here: https://www.troyhunt.com/everything-you-ever-wanted-to-know/
my favorite is by Jim Manico (OWASP / Manicode.net); the last bit of this doc (forgot password workflow) should help: http://docplayer.net/11058445-Authentication-and-session-management-jim-manico-secure-coding-instructor-www-manicode-com.html

Though it's not explicitly stated in either of the above, the need for a password reset through a registered email doesn't increase the need for additional verification at step 1.

Summary: Unless your app has a specific threat, email from a reputed identity provider's authentication flow should be sufficient without further verification.


Why aren't infinite-depth wildcard certificates allowed?

Technically, usage of wildcards is defined in RFC 2818, which does allow names like "*.*.example.com" or "foo.*.bar.*.example.com" or even "*.*.*". However, between theory and practice, there can be, let's say, practical differences (theory and practice match perfectly only in theory, not in practice). Web browsers have implemented stricter rules, because:

Implementing multi-level wildcard matching takes a good five minutes more than implementing matching of names with a single wildcard.
Browser vendors did not trust existing CA for never issuing an "*.*.com" certificate.
Developers are human beings, thus very good at not seeing what they cannot imagine, so multi-wildcard names were not implemented by people who did not realize that they were possible.

So Web browsers will apply restrictions, which RFC 6125 tries to at least document. Most RFC are pragmatist: if reality does not match specification, amend the specification, not reality. Note that browsers will also enforce extra rules, like forbidding "*.co.uk" (not all browsers use the same rules, though, and they are not documented either).

Professional CA also enter the dance with their own constraints, such as identity checking tests before issuing certificates, or simply unwillingness to issue too broad wildcard certificates: the core business of a professional CA is to sell many certificates, and wildcard certificates don't help for that. Quite the opposite, in fact. People want to buy wildcard certificates precisely to avoid buying many individual certificates.

Another theory which failed to make it into practice is Name Constraints. With this X.509 extension, it would be possible for a CA to issue a certificate to a sub-CA, restricting that sub-CA so that it may issue server certificates only in a given domain tree. A Name Constraints extension with an "explicit subtree" of value ".example.com" would allow www.example.com and foo.bar.example.com. In that model, the owner of the example.com domain would run his own CA, restricted by its über-CA to only names in the example.com subtree. That would be fine and dandy.

Unfortunately, anything you do with X.509 certificates is completely worthless if deployed implementations (i.e. Web browsers) don't support it, and existing browsers don't support name constraints. They don't, because there is no certificate with name constraints to process (so that would be useless code), and there is no such certificate because Web browsers would not be able to process them anyway. To bootstrap things, someone must start the cycle, but browser vendors wait after professional CA, and professional CA are unwilling to support name constraints, for the same reasons as previously (which all come down to money, in the long run).


Does subject alternative name order matter for TLS certificates?

The order of subject alternative names is not important. What the client is complaining about was a change of the certificate during renegotiation inside an existing SSL session. It does not matter what the change is, i.e. it is enough that the serial number has been changed.

Apart from that it might be a bug in the client. See What means “javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation” and how to prevent it?
 where the answer points out a bug in Java7 and Java8 introduced while trying to mitigate POODLE. According to this post the bug was fixed in Java 7u85 and 8u60.


Can information somehow be secured from the host on a KVM guest?

A guest's memory is still memory, and the host sets it up by allocating it. This means the host has full access to the KVM guest's memory. You would need hardware support to secure a KVM guest from a privileged user on the host. In particular, you would need to utilize Intel SGX to create a secure trusted environment. The newer memory encryption techniques like AMD SEV or Intel's upcoming MKTME can protect against cold boot attacks or logic analyzers on the memory bus, but not a compromised host.

I do not know if KVM or its frontends (e.g. QEMU) support running guests in an SGX enclave, but I think they do not. It is very difficult to run a full guest in an enclave due to the severe limitations placed on any code executing in SGX context. Most importantly, code in the enclave cannot run as ring 0. In order to make use of this trusted execution feature, it would likely be necessary to modify both the host and guest kernels so that sensitive computation can be offloaded from the kernel into an SGX enclave.


Install a VM hypervisor on your server(s) and create a separate virtual machine for each user which runs an own webserver and database instance.
When you don't have a unique public IP address for each user, then you can point all the DNS entries to the same public IP where you run a reverse proxy which routes each request to the LAN-IP of the correct VM (side-effect: from the perspective of the users, all requests will appear to originate from the reverse proxy).
This allows the user to do whatever they want with their VM and when they totally mess it up, you just need to reset the VM. Setting CPU and RAM quotas for the VMs also prevents your users from DOSing each other through resource consumption.
Another advantage is that you can allow the users to modify their webserver configuration without any conflicts with other users. This can be useful when users have conflicting requirements regarding certain settings or software versions.


I agree with Steffen, this sounds like malvertising as the most likely cause, with a less likely option being compromise of the visited site with embedded redirects.

Running ad-blockers and script-blockers is effective against most malvertising, but can negatively affect your browsing experience.

Sometimes malvertising is targeted at only certain browsers. I used to have a site I visited regularly that suffered from frequent malvertising on the mobile version. Switching from Chrome to Opera solved that problem entirely. Ads still loaded (I wanted to support the site) but not the malicious redirects.


S/MIME certificates and "information leakage"

FWIW, I reviewed their CRL and OCSP information and a user agreement. Here's what I was able to determine.

The UA states they have the right to revoke your certificate for any number of reasons out of your control and also if you ask for revocation. Normally, they'd never revoke a cert without the owner asking, so most likely this is a low probability event. If you revoke it, it's because it was compromised and then it will be on a revocation list somewhere.

Why is revocation important?

Because this is the only case I could think of in which your cert has some public profile.

CRL - Certificate revocation list - contains a list of cert IDs, not the original certificate.

OCSP - online certificate status protocol - allows realtime queries for current cert status. However, you need the cert ID to do the query.

In neither of these cases can someone get all information embedded in the cert. So, no exposure of email address through these.

Also, it looks like they have an enterprise product for which a company can run its own sub-CA, for employees. I didn't study this product, however, it's possible that it contains a "public" database of certificates feature. Since that's the equivalent of an internal phone book for employees, it wouldn't surprise me.

Although you might want to continue questioning their policies regarding publishing of certificates in general, I couldn't find anything that looked like what you mention in your question. Publishing issued certificates is an unusual practice for any Certificate Authority.

I'd say this is one of those cases in which Wikipedia may have misleading information.


There's a lot of spam, and hacked sites are often used to distribute it

There is no site to report it to. You have to report it to the provider hosting the site. This is the only practical way which leads to a shutdown of a site.

You have to address reports directly to the Abuse Desk. Normally it is something like abuse@microsoft.com (Hotmail) or network-abuse@aol (AOL) and others. You find the addresses in the WHOIS database for the IP-range.

When you do it the report must be in the format defined in RFC 5965.

This is how I do report around 10,000 incidents per day.


Can I trust browsers not to snoop into my activities?

Is there anything stopping from web browsers snooping into our activities?

Nope, not really. That's a bit like asking

  Is there anything stopping my keyboard from recording my keystrokes?

In theory, we are interacting directly with the keyboard / web browser, which in turn talks to other components for us, and we are trusting that it is acting in our best interest.

You could do as @StackAbstraction suggests and monitor the network traffic in and out of your browser looking for suspicious exfiltration, but you're going to lose this game since there are many many sneaky ways to exfiltrate data.

Fortunately, both Firefox and Chromium ("the open-source web browser project from which Google Chrome draws its source code." -- Wikipedia) are open source. With some google-diving, you can probably find 3rd party security audits of the source code.

P.S. If you think I'm being dramatic to draw a parallel with trusting your keyboard, check out the Razor "Stats & Heatmaps" feature that they quietly snuck into their Synapse 2.0 keyboard driver in 2012. It logs all your keystrokes and uploads them to a Razor server so you can "analyze your gameplay". They removed it due to public outcry, but according to this thread they've put it back at some point.


Strange responses from an unfamiliar HTTP server

If you insist on talking HTTP through telnet, a proper HTTP server won't answer you before you're sent two consecutive line feeds, effectively ending your request:

GET / HTTP/1.0
<empty line>

If the service starts answering you before sending the empty line, it's not speaking proper HTTP, and may be something else entirely. I'd suggest using a tool like cURL to ensure proper use of protocol. Here's an example:

[root@vostok ~]# curl --dump-header - --silent http://127.0.0.1/
HTTP/1.1 404
Server: nginx
Date: Wed, 11 May 2016 07:16:15 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 11 May 2016 07:16:15 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

It may also be a HTTPS service listening on a non-standard port (like port 80, the standard HTTP port). Try the above cURL command with protocol and port explicitly specified in the URL like this: https://127.0.0.1:80/

It may not be HTTP or HTTPS at all, but some other SSL-enabled service. If you want to probe that, you could use OpenSSL to open an SSL-enabled telnet-like connection:

openssl s_client -host 127.0.0.1 -port 443

If it is indeed SSL-enabled, you'll get all sorts of information, including details about the certificate used.

Good hunting! :-)


Which forensic disk image format should be preferred?

It comes down to what you want to do with the image once you've created it. If you're going to be using Encase Forensic to dig through it, or performing lots of searches on it, you're probably better off going for E01 format, since it is optimised for those use cases. It also has built in checksumming, which is important if you are copying data over less than ideal means.

On the other hand, if you're looking to investigate the image using standard Linux tools, you can mount a raw image and operate on it without any third party tools. However, that's pretty much the only way to operate on it - which gets unwieldy with larger images.

E01 has built in compression support, when used with Encase software, but raw images can be compressed using third party software (although the amount of compression will vary massively based on the image contents). E01 files can also contain metadata, which is useful when you want to add notes to, for example, deleted files.

A good place to look for information on forensic tools and software is the Forensics Wiki - which has a list of different file formats and their pros and cons.


Does AWS KMS use HSM underneath by default?

AWS KMS FAQ states that by default HSMs are used for Customer Managed Keys (CMK). Other option is to use AWS's CloudHSM as you have mentioned in the question.

  The key material for a CMK is generated within hardware security modules (HSMs) managed by AWS KMS. You can also have the key material generated and used in an AWS CloudHSM cluster as a part of the custom key store feature in AWS KMS


Can you point out the flaws in the stated approach of adding a new device to an existing ssl certificates secured system?

You haven't given us a threat model, so I'll assume a standard corporate environment, and the value of the data being protected by this scheme is less that $1 million USD.

That scheme actually sounds fine to me. Bootstrapping device enrollment is always hard because you need some sort of device secret known to both the device and the server.

You say "app store" so I assume this is an Android / iOS device rather than an IoT device. Shame, cause with an IoT device you might be able to get it manufactured with a secret known to your database, or a default cert. Instead you're generating a secret and the length (16 string characters) is a balance of security and usability.

Some thoughts:

I hope your websocket to upload the hash is using TLS to make the hash harder to sniff (because, why not?)
Since an attacker would need to brute-force the hash and steal a username/password for an authorized account, you can get away with the secret not having a full 128 bits of entropy.
What's the largest character set you can use for the secret without causing usability issues? Probably UPPERS and numbers? Possibly UPPERS, lowers, and numbers? You'll have to exclude characters that look similar, 1/I/l, O/0, etc.
When you say "The response is symmetric encrypted with the 16 length string" how are you doing this? Are you running the 16 byte string through a key derivation function to make it into a full-sized AES-128/256 key? Is the websocket using TLS and the secret is using manual encryption inside it? Have you considered opening a new websocket at this point using TLS_PSK (pre-shared key) or PAKE (password authorized key exchange) modes?
When you say "The webserver replies back to the mobile app on the same websocket with a new certificate." Just the certificate, or also the private key? The correct way to do this would be to generate the private key on the device (ideally in the Android / iOS secure keystore if possible) and send the server a CSR in step 2, that way no private keys are ever sent over the network, period.


ZFS on LUKS2 encrypted device: LuksFormat with or without dm-integrity?

Firstly, neither LUKS nor ZFS are designed to provide plausible deniability. You can tweak and change things to hide things a bit, but it won't get past intentional scrutiny.
ZFS does checksumming, so you'd be wasting resources by using dm-integrity underneath.


Unpublished modules on npm: could an attacker take advantage of their former notoriety?

Could malicious code be pushed to NPM?

Most certainly. If a package is to become compromised (or a new one is published), installed, and used any code provided with that package could be executed. So if they run it in the node.js context for example, the attack has access to many machine level features such as the file system, system information, file execution, processes, etc. It would be as simple as putting the attackers code to be returned in the export. So as soon as they require('bad-package') the code is executed. Even worse it could be as simple as installing the module. They can specify a preinstall script in the package's manifest and run the script immediately.

Has malicious code been pushed to NPM?

Most certainly again. On 01/26/2015 a package named rimrafall was published to NPM. It's purpose was to raise awareness of the issue. The package would run a preinstall hook so immediately upon installation rm -rf /* would be executed. Rimrafall was removed within 2 hours but it can be found on Github.

Can developers keep themselves and their users safe?

As a developer the only close to reliable prevention method is version locking in your package.json to versions known to be safe. Version locking is normally practiced to ensure only a known working dependency is used and an untested dependency update doesn't break anything. But the same can be used to fend off an attackers version. As you mentioned you cannot republish a file of a particular version. By setting an exact version in your dependencies your application will only download this version. If an attacker was to gain control of the package they could only push malicious code to users of a later package. I said "close to reliable" because if an attacker was to compromise NPM's servers they could change a previous version to whatever they wish.

Additionally you can prevent a preinstall script attack by using the --ignore-scripts flag when installing. This would give you the opportunity to install but view it's code before running it. (Unless the package contains native binaries.) Prior to install you can check for such scripts by running npm show $module scripts. If you would like to leave NPM out of the mix to review the script you can download it directly at http://registry.npmjs.org/MODULENAME/-/MODULENAME-VERSION.tgz.

Does NPM prevent someone from taking over an unpublished package?

Yes and no. Once unpublished there is a hold placed on the package name to prevent immediate abuse. However it is still obtainable if you request it from NPM. In theory simple Social Engineering could bypass the vetting process and put the package name in the hands of the attacker. A message for an unpublished package is below:

  This package name is not currently in use, but was formerly occupied
  by a popular package. To avoid malicious use, npm is hanging on to the
  package name, but loosely, and we'll probably give it to you if you
  want it.

  You may adopt this package by contacting support@npmjs.com and
  requesting the name.

In Conclusion

So in closing, could an attacker take advantage of unpublished package? Yes, if the wrong person quickly took ownership nothing was in the way of them pushing a package update with their code. This would compromise anyone downloading the latest version of that package or installing/updating projects that didn't version lock their dependencies.

Edit: Keep in mind your dependencies can have dependencies. So while the dependency itself can appear safe be sure it isn't loading in an unsafe dependency of it's own.


Self-signed certificate for SSTP VPN server

Unless you include your private key or something as part of the certificate package for a trusted root CA cert that you deploy to the Windows hosts; the private key would probably compromised in some other fashion.

With that said, if it is a signing intermediate or internal CA based cert; someone who captures a signing cert could use it and perform a man-in-the-middle to do 'trusted' ssl decryption on the victim network or create 'trusted' spoofed phishing sites or other malicious browser friendly content for your users.

If your self signed cert is purely a public cert for trust authentication only; in general you should be fine as long as an attacker decides not to take it and spoof your web server.

In either scenario, if this is happening in a test/dev environment for a proof of concept-- you probably have bigger problems to worry about regarding your cyber security.

If you're really paranoid about alternative authentication; you could add requirements for the clients to have a client-side certificate that your server knows about (mutual authentication) via TLS. There's also compensating controls where maybe your network security infrastructure only allows SSTP over SSL/TLS traffic to be accessed on a specific VLAN or static IP/MAC pairing.


Is it possible to use parallelism when computing a key derivation function for a single password/key?

Most hash functions take measures to make them hard to implement on GPU's, but it is indeed also possible to take advantage of parallel execution and use that on the defender's side when verifying passwords. One algorithm that was designed to be easily parallelizable is parallel by Steve Thomas. Parallel was a finalist in the PHC and thus has gotten some review, but I could not find much information on it.

So the idea behind your algorithm is sound. The implementation looks good to me, but you may want to ask a real cryptographer before you take it in production.


Are bcrypt hashes safe enough if exposed?

We don't need a motivated attacker since security is already considered with the strongest attackers. Therefore we can say that they have all information, except the password and have a huge computing power like the Bitcoin miners that can reach ~293 SHA256 hashes per year with massive parallelization.
Now, assuming that your password has strength 256-bit then even we omit the iteration count of bcrypt and set the one bcrypt password test equal to one call of SHA256 then the attackers need around ~2163 years to search. No way! Now consider the iteration count then this number will be higher.
Now, bcrypt is very old dated to 1999. It is not a memory-hard password hashing, that is requiring some adjustable huge memory that prevents parallelization like in ASICs that BitCoin miners use. You should rather use modern password encryption function like Argon2. It is memory-hard, it can be adjusted to require threads. Also, it can have resistance to side-channel attacks that the side-channle attackers can steal the password over time. The side-channel protected version of Argon2 is Argon2i. And, It is always better to use Argon2id if you unsure about using Argon2d (data-dependent) or Argon2i (data-independent).
Side note: collisions are not related to passwords,  finding pre-images are related. In finding collision the attacker just needs to find two input values a and b such that h(a) = h(b).  In password finding, the attacker needs to find x given the password hash h that satisfies h(x|salt) = . The cost of collision finding is the square root of pre-images attacks due to the birthday paradox.


security of swoopnow integration on website

As I said in a comment - we don't do review of arbitrary third-party API's here. But given that the site claims to provide an API for easy integration of password-less logins I find it worth to take a closer look.

The problem is that there are no real technical information on this site on how this works. I've tried there small demo and found that it works be either the client send them a mail with a specific recipient and they log you once they receive this mail - or that the client provided them with an email and they send a link and after clicking on the link the user is logged in. This means probably that all what is needed is for someone to have access to your mail account - and maybe even the possibility to fake sending mails from your account (which is easy) is sufficient.  For more on this topic read
 Passwordless login over email - security considerations.

On top of that they now have your mail address and it is unclear what they will do with it. At least I did not find any kind of privacy policy on their site which maybe means that they feel free to use all the mail addresses they've received for advertisements or even resell the mail addresses. This is likely not the kind of services you want to offer to your customers.

But there are even more warning signs. If you look at the prominently featured documentation how simple an integration is you will notice that

It recommends to include a script from a third party site which you don't control. This script has essentially full control over the site in the browser, i.e. can extract information from it, change information, submit information with the origin of your site etc. See Should I be worried of tracking domains on a banking website? for more information.
It recommends to include the script as insecure http:// and not secure https://. This means that the transport of the script is not protected against man in the middle attacks which can manipulate the contents of the script and thus essentially have full control over your site display in the browser. Fortunately, if your site itself uses https:// (recommended) such insecurely included third party scripts will not work at all. But this also means that if you just follow the documentation the integration of the service will either be insecure or it will fail completely. And it gives some idea of the (missing) security mindset of the developers of this service.
But third party scripts can actually be included in a secure way. subresource integrity lets you specify the hash for the expected script. And it is actually supported by most major browsers. Of course, with subresource integrity the third party cannot just make changes to the script - but this is probably exact the thing you are trying to avoid.

Another red flags are there security claims. To cite from the FAQ part of their site:

  Is Swoop secure?
  Swoop uses state-of-the-art 2,048-bit encryption to
  authenticate your user. But what does that even mean? Well, if a
  hacker got started 13.7 billion years ago (at the start of the Big
  Bang), then he would still only be .00000213% of the way done. That’s
  how secure it is.

And this is just bullshit and playing with big numbers. The only state-of-the-art 2048 bit encryption they could mean is RSA - the others use far fewer bits (like 256) since these are sufficient.  And you only need 2048 bits with RSA since RSA is not as good as the other algorithms.

Apart from that it is not clear what gets encrypted here in the first place. It cannot be the mails which are sent for authentication because swoopnow has no control over how the mail gets delivered. See How (in)secure is POP/IMAP/SMTP and How secure is e-mail landscape right now?.

In summary:

they can collect and misuse the mail addresses of your customers
the documentation for integration they provide results either in an insecure integration or one which does not work
the make silly security claims instead of providing any real design information


Exchange Security - outgoing email marked as spam by recipients

Some usual reasons (not a comprehensive list):

Your mail server is an open relay, anybody on the internet can use it to send emails to any address. Spammers very quickly find these and use them to spread spam. This way your server will get blacklisted in RBLs (see below).
Your server is used to send spam by its legitimate clients due to malware on your internal client computers. Check the mail queues and see what emails go through. This will also likely result in the server getting into RBLs.
Your mail server is in a black list (RBL) for any reason. Some recipients check if the sender server is in a blacklist and will either not take emails from that server or automatically mark them as spam. You can check whether your server is blacklisted here or here or here among others.
You are sending email on behalf of other domains apart from your own (the apparent sender of the email is not your domain). You should look into things like SPF and DKIM, also here.
Your server is in a dynamic IP range, meaning your internet provider marked your IP range as dynamic. Some recipient servers either don't take emails from dynamic IP ranges or mark them as spam.


Is NAT Loopback on my router a security problem?

Most consumer grade routers don't have any prohibition against it, it just doesn't work.

Imagine the following scenario. This isn't hypothetical, just run tcpdump on your own computer and you'll see it happen right now. Captured from my Buffalo ddwrt moments ago just to verify.

Players: [Router: 10.0.0.1]  [Computer1: 10.0.0.3]  [Computer2: 10.0.0.4]
Outside IP: 99.99.99.99, forwarded to Computer2

Computer1 to Router  [10.0.0.3 -> 99.99.99.99]
Router uses DNAT to change the destination to 10.0.0.4 and pushes it back to the local network:
Router to Computer2 [10.0.0.3 -> 10.0.0.4]
Computer2 attempts to respond to the packet by sending to the source IP.
Computer2 to Computer1 [10.0.0.4 -> 10.0.0.3]
Computer1: WTF?
Computer1 was expecting a reply from 99.99.99.99, got one from 10.0.0.4 instead. Addresses don't match, connection failure, RST packet sent back.

Now, you ask, why doesn't the router SNAT the connection from Computer1 to the router's internal IP when it DNATs it to Computer2? Because the SNAT rule would make a mess of all the rest of the traffic which doesn't follow the pattern above.

SNAT really should only be used in one direction unless you're willing to put a lot of time and care into crafting and maintaining a NAT ruleset that won't bite you.

And to preempt anyone who says how about this:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.0/24 -j MASQUERADE

I would point out that this rule would affect not only to NAT-loopback traffic, but also to bridge traffic (e.g. WiFi network to Wired network), which would make a WiFi router frustratingly broken. The rule would have to be tailored to match ONLY the loopback traffic, which is slightly more tricky and probably involves marking packets. Not impossible, but not the sort of engineering and debugging that goes into most routers; and certainly fraught with peril.

Glossary:
SNAT = Source NAT (changing the source IP)
DNAT = Destination NAT (changing the destination IP)
NAT = Network Address Translation


TLS can protect against an eavesdropper which has only access to the communication channel between both parties. But it needs to be properly implemented, that is strong ciphers, proper validation of the peer etc.

It will not protect against attacks against the endpoints itself. That is it will not help you if there are bugs in the used TLS stacks (like were in most major stacks in 2014), buffer overflows or bugs in the application logic (like cross-site-scripting). If the attacker manages to compromise the endpoint in some way (s)he will be able to inject itself into the application to get access to the unencrypted data or to the encryption keys.

Thus attacks focus on compromising the implementation or the endpoint itself by subverting the methods and libraries used for encryption (like random generators), compromising the delivery chain to get access to the keys (like with sim cards) or to infect the computer during delivery already. But you don't need such advanced attacks because malware delivery by phishing or malvertising or evil maid attacks are usually enough to compromise a selected endpoint.


You should use /dev/urandom, not /dev/random. The two differences between /dev/random and /dev/urandom are (I am talking about Linux here):

/dev/random might be theoretically better in the context of an information-theoretically secure algorithm. This is the kind of algorithm which is secure against today's technology, and also tomorrow's technology, and technology used by aliens, and God's own iPad as well. Information-theoretically secure algorithm are secure against infinite computing power. Needless to say, such algorithms are pretty rare and if you were using one, you would know it. Also, this is a "might": internally, /dev/random uses conventional hash functions, so chances are that it would have weaknesses anyway if attacked with infinite power (nothing to worry about for Earth-based attackers, though).
/dev/urandom will not block, while /dev/random may do so. /dev/random maintains a counter of "how much entropy it still has" under the assumption that any bits it has produced is a lost entropy bit. Blocking induces very real issues, e.g. a server which fails to boot after an automated install because it is stalling on its SSH server key creation (yes, I have seen that). /dev/urandom uses a cryptographically strong pseudo-random number generator so it will not block, ever.

So you want to use /dev/urandom and stop to worry about this entropy business.

Now you may want to worry about entropy if you are writing the Linux installer. The trick is that /dev/urandom never blocks, ever, even when it should: /dev/urandom is secure as long as it has received enough bytes of "initial entropy" since the last boot (32 random bytes are enough). A normal Linux installation will create a random seed (from /dev/random) upon installation, and save it on the disk. Upon each reboot, the seed will be read, fed into /dev/urandom, and a new seed immediately generated (from /dev/urandom) to replace it. Thus, this guarantees that /dev/urandom will always have enough initial entropy to produce cryptographically strong alea, perfectly sufficient for any mundane cryptographic job, including password generation. The only critical point is during installation: the installer must get some entropy from /dev/random, which may block. This issue also occurs with live CD and other variants with no read-write permanent storage area. In these situations, you may want to find some source of entropy to ensure that /dev/random will be well-fed, and will not block.

The operating system itself, and more precisely the kernel, is at the right place to gather entropy from hardware event, since it handles the hardware. So there is relatively little that you can use for entropy that the kernel does not already use. One of those remaining sources is Webcam data: a webcam, even facing a blank wall, will output data with thermal noise, and since it outputs lots of data, it is a good entropy gatherer. So just grab a few frames from the webcam, hash them with a secure hash function (SHA-256), and write that into /dev/urandom. This is still big overkill.


How to allow access from just one IP in htaccess

If you allow from one IP and deny the rest (once you get the syntax correct), then only the one IP can connect.
Another computer can spoof that IP, but then all traffic would end up going to that IP and not the one trying to connect.


If you have space to store it, consider a standard data structure like a UUID4. These are generated randomly and are 128 bits, or 2^128 different possibilities.

That’s enough for your app to generate a unique reference for every gram of mass that makes up planet Earth, for every person currently alive on earth (2^128 / 2^92 / 6 billion).

Brute forcing the UUID4 space is impractical, and offers sensible security with the benefit of widespread support in programming languages and databases.

It should be noted though that using UUID4 is only as strong as its underlying random number generator, you can see a discussion on that in this question. You should take care when choosing an implementation for your project, if you are going to use UUID4 for this use case.

If you need a slightly shorter value, or something that uses can type, consider a secure random generator that provides URL safe output, such as Python’s secrets.token_*.


When does it make sense to whitelist some subdomains but not others for a given domain?

If you're concerned about malware you should note that subdomains of apple.com or google.com allow running a malware command & control (C&C). For example malware could encrypt and post your data to a discussions.apple.com post. Previously, malware has used Google Docs as C&C. This is however not very common for typical malware, thus the answer to your question depends on whether you're trying to protect against non-common, eventually targeted, malware -- if that's the case you shouldn't whitelist *.example.com.


Getting into pentesting with no experience

Anything you do to build your skills will help at this stage.  You might want to address some of the basics before trying to collect on bounties, though, or you might get frustrated.  Remember, the easy bug bounties have most likely already been collected, meaning you will need very strong skills to find what's left over.

Seek out some of the on-line classes on a wider variety of various pen testing tools, not just Metasploit.  Keep practicing on the VMs.  Learn about other security measures that might need to be defeated, such as IDP/IDS systems.

Attend local or regional security conferences; they're a great source of information, contacts in the industry, and potential clients.

Honestly assess your communication skills.  A pen tester needs to produce a clearly written report describing the vulnerabilities in such a way that the clients can understand and address them.  Ask someone else to take a look to ensure you're as clear as you think you are.

A big part of the entry-level pen tester will be their reputation.  Hiring a pen tester is a matter of trust.  If you have a criminal record or otherwise sketchy background, you may never find customers who want to hire you.  Consider getting some certifications, like Certified Ethical Hacker (CEH) and Certified Information Systems Security Professional (CISSP).  While some people like to mock certifications, don't let that stop you.  They offer something tangible to potential clients that you are at least taking this seriously, and it's those clients that will pay your salary.

Check your local area to see if you need other credentials, such as a private investigator license.  A PI license might also be helpful in standing out in a crowd of job applicants.

Consider preparing yourself for other careers in the security field as a path into pen testing.  Forensic investigation, application development security, and security architecture are all hot topics these days.


Is Bluetooth low energy (BLE) still secure?

I found the answer. It's insecure. Both classic and LE are affected by KNOB attack and the session key can be downgraded. See  https://francozappa.github.io/publication/knob-ble/
So, make sure to use another extra TLS layer ...


I'd say it does not matter. There's two kinds of attacks today:

Automated attacks.

These will of course not even bother about personal details; they look for extremely weak passwords or known security vulnerabilities.
Patching your OS and using secure passwords will probably protect you against automated attacks.

Targeted attacks.

These may care about who the user is. But if an attacker that is targeting you are able to see your device name, e.g. is on the local network, you've probably lost already.

I would focus on knowing what services are running on the computer, and disable unneeded services, and add a firewall to block incoming traffic. Patch the OS and applications, and keep good passwords.

Tracking a laptop to a person is a fairly easy thing to do if you have network access. Note when they come to work, and look for new devices within that time span. Three-four days should be enough to identify me.

The name will not normally be visible outside the LAN you're connected to.


What are the methods to crack WPA and WPA2?

Cracking WPA/WPA2 can be done pretty quickly using the aircrack-ng suite which conveniently come packaged with the Backtrack penetration testing live operating system. Take note that you will need a wireless card that has a compatible chipset.

There are plenty of articles on the internet on cracking WPA/WPA2 key but I've personally found that Youtube videos are the easiest to follow.


A generic way to test available outbound ports, independent of the location of the port filter (e.g. local host-based firewall, perimeter firewall), is exactly what you proposed - trying to connect to an external system, that is listening on all available ports.

You do not have to re-invent a mechanism for the target system of the connection attempts, because such a system is readily available: PortQuiz

If you do already have limited shell access, you can write a short bash-script (or whatever scripting language you have available), that tries to connect to PortQuiz and outputs all successful attempts.

You can also try more complex approaches like DNS tunneling to setup your communication channel, but I wouldn't consider this in scope of your question.


How does DNS over TLS prevent your ISP from seeing the websites you visit?

It doesn't. DNS over TLS is not designed to keep your privacy from ISP. Like HTTP,  DNS is vulnerable to MITM. DNS over TLS provides the same level of security as HTTPS.

As DNS over TLS is encrypted, your ISP can't see the domains you query for but they don't have to. TLS uses Server Name Indication, a TLS extension which appears on the outside of HTTP host header. SNI field contains the domain name of the server you want to talk to. Once you visit that site, your ISP can see that unless you use a VPN.

Cloudfare has recently released support support for encrypted SNI(ESNI) for the websites that are hosted by Cloudfare. This actually prevents your ISP from seeing the site you visit provided you are also using DNS over TLS. But for ESNI to work browsers have to natively support it. Mozilla landed support for ESNI in Firefox Nightly, so you can now browse Cloudflare websites without leaking the plaintext SNI TLS extension to on-path observers ISPs, coffee-shop owners, firewalls.


Which factors should I consider for devices that accept handwritten digital signatures?

I don't think there are going to be any guarantees.  If there is not previous case law on topic, then I would expect this to come down to an assessment of credibility, based upon the testimony of the people involved, possibly testimony from expert witnesses, and the rest of the circumstances surrounding the court case.

Keep in mind that the legal process doesn't treat signatures as absolute ironclad guarantees; they consider them as part of the totality of the evidence.

If you want to think about how to ensure this will stand up in court, I would have two suggestions.  First, talk to a lawyer.  (Legal advice is not our strength on this site.)  This is the most important advice I can give you: talk to a legal expert.

Second, I would suggest thinking about this from an adversarial perspective.  Imagine you were an expert witness hired to demolish the credibility of the signature in court.  What would you be your line of attack?  What would you say, to try to convince a judge or jury that the signature doesn't prove anything?  Then, think about what processes or mechanisms you can put in place to make those arguments less compelling.  Note that complex technical mechanisms that are hard to explain to a jury are not likely to be an effective rebuttal; you need to look for something that will be persuasive in a courtroom, which is not necessarily the same thing as what mechanism will be most effective from a technical perspective.

My guess is that, for a low-value transaction, you probably don't need any crypto.  If you've captured a signature that appears to match how Alice signs her name, that's probably going to be good enough for a low-value transaction.  Conversely, for a high-value transaction, I'm skeptical about whether these devices are going to be persuasive in court, no matter how much fancy crypto you've thrown into them.  We have decades of familiarity and experience with wet ink signatures on paper, and we understand their failure modes a lot better than we do digital signature pads.  Look at UK's chip-and-pin, for instance; it has suffered from multiple serious security flaws (found primarily by security folks at Cambridge), even though their scheme has lots of fairly reasonable crypto that was designed and intended to stop such attacks.


Process Explorer, part of the SysInternals suite, is indeed a Windows only tool. It is largely intended to replace the standard Windows task manager. As such it gives very detailed information about the running processes, and all the various and sundry statistics that one should expect. One line I heard used to describe it was, "Finally, an actual top for Windows!"

That being said, it is not a virus detection tool. It does, however, give a knowledgeable admin or analyst the information they need to understand what is running on a system. Using this information one can start looking into specific processes to determine whether or not they should be running, and if an application is doing something it is not supposed to be doing. In this manner it is possible to find viruses and other malware running but it is not a virus detection in and of itself.

One should always keep in mind, however, that a good rootkit can still fool these types of detections. If the virus has access to the Windows kernel, then it can forge all of the information that is presented to Process Explorer. In doing so you will only see what the virus wants you to see.


Is it okay to only use username/password to secure an admin page for moderating a website?

I think it is fine to have a web facing panel as long as:

Its not guessable, for example, www.example.com/admin. U don't want notorious users to attempt brute-forcing for two reasons:

Incase the brute-force succeeds.
If u have an account lockout policy in place, which you should, u don't want to be locked out by notorious users.

Use strong passwords which are not going to be standard dictionary passwords.
Use out-of-band authentication along with the regular authentication system. This prevents brute-force as well as account-lockouts.
Restrict the admin-panel to specific ip addresses such as ur internal subnet address and only accessible through VPN, this should give u one extra layer of protection.
More on this at: https://stackoverflow.com/a/2851584/4399898.
And HTTPS should be the standard, if the cookie doesn't have the secure flag and HTTP-only property set and the admin browses to a page after logging in and not signing out and this page contains a malicious injected script, a là XSS, it can lead to the cookie being stolen and probably the authentication being effectively rendered useless along with CSRF bypass attacks etc. So, IMO, HTTPS should be implemented throughout the application.
If there are multiple admins and the authentication system has a SQL db backend, use parameterised queries.

Thats all i can think of right now. The link i posted with my fourth point should give u more information.


This used to be a common usage in the old time when clients did trust neither web sites nor web browser for their security and privacy and consistently refused javascript and cookies. As HTTP is a non connected protocol, the session must use some piece of data to pass the session id between the client and the server. That means the if you cannot use cookies for GET requests, you are just left with an URL parameter. That was implemented in many web applications as session through URL rewriting.

It is now seldom used, because browsing most site while disabling cookies is simply impossible. So users have been educated to consistently allow cookies in their browsers.

On a security point of view, passing the session id in the URL is not worse than passing it in a cookie: if someone (except for the user itself) can intercept the URL, he can as well intercept the cookie. And session fixation is not easier with URL than with cookies: it is the problem of the server than should invalidate old session ids, and create a new one after a successful authentication. Logs is not a problem either: a session id make sense only for the duration of the session and is not a long term sensitive information. The only place that could cause problems is cross site requests of redirections. In that case, the REFERER header could contain the session id. So a well designed application using URL rewriting for its sessions, should consistently store the client IP in the session server side, and control that the session ID and client IP match.

TL/DR: That usage is known as session through URL rewriting. It is now seldom used because session through cookies are much more common. The problem is not security because the security of an URL parameter is not different than the one of a cookie, but that extra parameter is displayed in the browser bar, and can intrigate a user, or require removal for storing an clean URL as a bookmark.


How can I trace the IP address of person in chat?

Set up a web server and send them a link to something on it. Once they click the link, their IP address will be logged in your web server's access logs.

You could also host an image on said web server and trick a user into loading it through a third party's website. Some social networking sites allow you to upload snippets of HTML including image tags.

Note, when I say "their IP address" I am referring to whatever the address is after any NAT and proxying.


Theoretical - Is it possible for an attacker to leave an irreversible software artifact?

If we are talking about any theoretical possibilities (outside of basic, that would be purged during BIOS and OS wipe):
 - Attacker can change firmware of the hardware. Most lucrative would be network adapter and storage device, but others might be targeted as well.

Cannot think of anything else, if we are restricting ourselves to software artifacts only. If we extend this to hardware (we assume attacker got physical access to the device, right?), possibilities are limitless. It all just depends on our paranoia (i.e. is it government/military?).


Depending on your threat model you could add enclosures, alarms, CCTV, access controls to the room, a security guard etc... but without knowing what you want to do it is hard to say where to stop.

I would certainly consider securing the Pi itself - a locked metal container, securely fixed to the wall/device will make any attack harder/noisier/more obvious. Adding an alarm will also improve this.

If you can find an enclosure which incorporates a secure keypad (ie one that is hard to break and is tamper evident) that will help you prevent an attack.

Sealing ports can help, but if an attacker gets into the enclosure, they could access the traces on the PCB so while it has some deterrent value, I wouldn't recommend it.


How to determine if a VPN provider respects data confidentiality?

Short answer: You can't.

Before you buy any service you should take a look at their Privacy Policy. For instance Hide My Ass:

  What data we collect: We will store the stamp and IP address when
  you connect and disconnect to our VPN service, the amount data
  transmitted (up- and download) during your session together with the
  IP address of the individual VPN servers used by you . We do not store
  details of, or monitor the websites you connect to when using our VPN
  service.

  Why we need this data: We do this so that we can monitor the performance of our Site, for example it enables us to sort server nodes by the number of users connected, to limit your account to one concurrent IP address per VPN connection (to prevent shared accounts), resource analytics (to carry out usage analysis for administrative purposes) and to prevent abuse and fraud. This data is stored on our system for between 2 and 3 months unless we are required, for legal reasons or under exceptional circumstances (including our own investigations of fraud or abuse), to retain this data for an extended period.

You have plenty more services but who can guarantee that they won't sell your data?

The scope of the answer is much larger (legal side, technical side, etc...). I hope someone can develop a better answer for you.


Can Fiddler decrypt HTTPS traffic when using elliptic curves + client cert authetication?

Fiddler captures HTTPS traffic by generating on-the-fly a fake certificate for the intended server, thereby running a complete Man-in-the-Middle attack. This requires that the client is configured to accept the Fiddler-controlled CA as a trusted CA, as described in the documentation.

This kind of interception breaks client certificates. When there is a client certificate in SSL/TLS, the client technically signs (during the handshake) what amounts to a hash of all received and sent handshake messages so far; the signature computed by the client will then cover (among other things) the server's certificate as seen from the client, i.e. the fake one generated by Fiddler, not the genuine server's certificate. Therefore, the client signature will not match the handshake messages that the server saw.

If the documentation is to be believed, then Fiddler can fix that, but this requires Fiddler to recompute the client signature. This works only if Fiddler has access to the client's private key. The ".cer" file is not sufficient; the private key is needed. The documentation is a bit unclear; my guess is that Fiddler uses the ".cer" file to know what client certificate to use, then will look for that certificate and private key within the local user's certificate store (which would be why Fiddler's documentation says that you should first import the certificate "as a .pfx file", i.e. with its corresponding private key, and then just export the ".cer" file). In any case, without access to the client private key, Fiddler will not be able to masquerade as the true client when talking to the server.

Now Fiddler could also have a limitation with regards to EC certificates; that I don't know. From what I explain above, Fiddler must run as a TLS client when talking to the genuine server, so if there is a client EC certificate, then Fiddler's code must support it, meaning that Fiddler must be able to generate an ECDSA signature.

From the documentation we see that the private key remains within the entrails of the client machine (a Windows system). Thus, any signature generation will need to go through the cryptographic API offered by Windows. Windows has two completely distinct API: CryptoAPI and CNG. CryptoAPI is the old one; CNG was introduced with Windows Vista and 2008. From the point of view of an application (e.g. Fiddler), a private key stored and managed with CNG can be used only with specific function calls; an application that knows only CryptoAPI cannot use a CNG-stored private key.

Unfortunately, CryptoAPI has no support for elliptic curve. An EC-based key can be used only through CNG. Moreover, Fiddler is said to be written in .NET, and .NET's cryptographic API relies on CryptoAPI only (you can use CNG but you have to do it with explicit invocations of the native DLL ncrypt.dll and bcrypt.dll). Therefore, I find it quite plausible that Fiddler uses only CryptoAPI and, thus, may support only RSA and DSA keys for client certificates, not EC keys.


Traditionally an ATA disk password will not enable encryption for data at rest on the disk. BIOS factory reset will not reset what is known as the ATA User password. The ATA Master and User passwords are stored on the disk drive's physical firmware.

The drive can be unlocked using a (factory-installed) Master password (which generally only becomes relevant when the User password is set) or using the User password.

For some fun background reading on the the use of ATA passwords and disk drives refer to the T13 Working Group ATA Command Set (search the PDF for password).

There are several tools and techniques available to obtain the Master password depending on drive type.

I have not had to workaround a Seagate drive, but the general order involves feeding a manufacturer specific script (available on forums) to a tool like MHDD or Victoria to dump data located in the drive's firmware which contains the Master or User password, parse and translate (with your brain) the output with a hex editor to yield the Master or User password, and then use MHDD or Victoria to unlock the drive with the password.

There are many posts on hddguru forums outlining the process for various manufacturers and drives.


How someone would routinely email out a Google Doc

Most likely, the attacker has embedded a script in the document or in another document in the same account. Check all of the documents for embedded scripts and make sure there are no stand-alone scripts either.

Also make sure that none of the files have been shared with an external user id.

Then make sure the user turns on 2-factor authentication on their account. Although this can be a bit of a pain, the added security is well worth it when you can loose so much if you loose control of your account.


How to use attack trees and attack graphs

Yup, you've got the idea.  Your last paragraph beginning "However what I understand..." captures the idea well.  That's about right.

Attack trees are one possible tool that to assist with what is sometimes known as "architectural risk analysis" (Microsoft calls this "threat modelling"; two names, same idea).  The idea of architectural risk analysis is to identify potential security risks in a software system, based upon the design and architectural features of the system.  This can be helpful to identify security risks, brainstorm defenses and mitigations, or pinpoint areas of the code that should be examined more closely for vulnerabilities.  Attacks trees can be helpful to systematize the process of thinking through the space of possible attacks that someone might try against your system.

There is no way to automatically generate attack trees for a complex system.  Attack trees do not eliminate the need for domain knowledge about the system and about computer security.  You still have to understand the system, understand the kind of attacks you might face, and think through the potential risks.

The biggest limitation of attack trees is that they can be enormous.  Building a complete attack tree is very labor-intensive, and it seems unlikely in most situations that this effort is the best possible use of an expert's time.  This is probably why attack trees aren't very widely used.  Most work on architectural risk analysis and threat modelling tries to provide ways to identify the highest-risk possible attacks.  See, e.g., STRIDE and other techniques to try to focus in quickly on the most significant risk factors.

Anyway, I think you've understood the basic gist of it.  What precisely is your question?


Encrypt and decrypt large files with RSA, is it possible?

RSA is way too low level for users and most application programmers, never implement an encryption scheme using RSA yourself. There are way too many pitfalls that will render your encryption to become useless when using plain RSA.

Instead, just use something like GnuPG (which uses OpenPGP format):

gpg --output encrypted.gpg --encrypt --recipient avigaga plain.txt

and to decrypt:

gpg --output plain2.txt --decrypt encrypted.gpg

There are also GUI tools for all major operating systems if you do this often and if that's your preference.

OpenPGP uses RSA and AES, but it has combined them in a secure way, so you don't have to combine them yourself, and so you avoid the pitfalls of trying to combine them in insecure ways.


Edit: October 3, 2015 An article in IT World for September 29, 2015 reveals the existence of, but doesn't describe fully, two serious flaws in the Windows driver that TrueCrypt installed.  It isn't clear from the article whether those flaws compromise the crypto or the underlying Windows OS, or both.  It also isn't clear whether that driver is installed only for full-disk encryption or at any time a TrueCrypt volume is in use.

Original answer below:

Older versions of Truecrypt are as safe as they ever were.  Unhappily, the safety of older versions has not been conclusively demonstrated, I think.  A code audit by others, of which phase one is complete, did not find any problems that significantly weaken the crypto algorithms, and I really doubt anyone, even the NSA, can crack AES unless there's a back door that hasn't been found.  (That's a back door in Truecrypt; I'm relatively sure that AES itself is safe.)

That said, I am still trusting an older install of Truecrypt.  For you to use Truecrypt, you'd have to put your hands on an old copy of the software.  There is what purports to be a copy of Truecrypt 7.1 on Github.  The Open Crypto Audit Project says it is verified, and I have no reason to doubt that.

There is also an open source successor, VeraCrypt, which I have not tried.


AES-CTR-256 is only available since OpenSSL v1.0.1. It's possible to view the encoding ciphers by issueing the following command

openssl enc help

It will show all the available encoding ciphers. To check the current version of OpenSSL run the following command

openssl version

Note that the 0.9.8, 1.0.0 and 1.0.1 branches have been maintained in parallel. OpenSSL 0.9.8zc might be newer than 1.0.1e, so focus on the version instead of the date.

Some applications (i.e. Ruby) don't use the openssl executable, but link to libssl instead and inherit the abilities of the library. Upgrading OpenSSL to a newer version doesn't help much in that case. If the application uses dynamic linking, then it might suffice to upgrade libssl to a newer version. If it's linked statically, then the entire application needs to be recompiled with a newer libssl (or you might check if there is a newer version).

Ruby programmer's can check which OpenSSL version is installed by issueing the following command

ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'


How to demo Skype-decryption using FOSS tools?

After reading this post you provided, they only seem to be doing MITM and re-signing the certificates that Skype is using during the transmission (something really common when we use HTTP/S proxies), but in this case, for other TCP traffic that is not HTTP.

TCPcatcher may help you, more specifically, this tutorial (as a guidance, but applying for Skype ports/protocol): http://www.tcpcatcher.org/monitoring_IMAPS.php

Also, take a look at this thread, where they discuss about doing SSL MITM for all kind of TCP traffic: https://security.stackexchange.com/a/33376

Hope it helps.


Is it possible to decrypt symmetric key encryption without the key?

To decrypt the message, you have to know more than the key; you must also know the encryption scheme, encryption mode, initialization vector, etc. None of this is supposed to be secret; the key and the plaintext message are the only two secrets in most symmetric-key cryptography (and as was stated in the comments, due to protocol requirements and other formatting inherent in most data, the plaintext is not entirely secret).

Those two secrets are enough: according to the Wikipedia docs for AES, the most successful brute-force attack against any symmetric algorithm was against a 64-bit RC5 implementation, which basically required a "white-hat" botnet run by the nonprofit Distributed.net to provide sufficient CPU time to try all of the 18,446,744,073,709,551,616 possible keys in the 64-bit keyspace (that's 18.4 quadrillion keys; putting that in context, the estimated total economic output of the human race in recorded history is only about 2.4 quadrillion US dollars). Using about 2,700 "willing" computers in the botnet, it took five years to crack the cipher. And most of the common symmetric algorithms nowadays (Rijndael/AES, Blowfish/Twofish, Serpent, Triple-DES) use keys at least twice that long, producing a keyspace of approximately 3.4x1038 (340 undecillion) possibilities. The feasibility of a brute-force quickly becomes infeasible; given one more size doubling to a 256-bit key (which is used in some schemes), assuming we could, starting right now, build a Dyson's sphere around our Sun and trap every photon of the plane of the ecliptic (our planet's own orbit) with perfect efficiency, and then build a computer at the electron level with perfect thermal efficiency powered by this Dyson's sphere and set it to try brute-forcing the key, the Sun would go dark before the computer finished trying every key (the Sun would fail at somewhere around 2218 keys).

Even if the cipher they used were vulnerable, most known cryptanalytic attacks against ciphers that aren't completely broken require what's known as a "known-plaintext" or "chosen-plaintext" attack, where you as the attacker can see or even choose the plaintext messages to be fed into the cipher. Most of these attacks still only reduce the complexity of breaking the cipher by a small number of powers of two; for instance, a 64-bit cipher, which would require 2^64 tries to brute-force, might be crackable if you could see, perhaps, 2^44 64-bit blocks being fed into the algorithm using the same key, and see the ciphertext output. Technically, that's an "attack" because it is more efficient than a brute-force. But, it requires you to feed 128 terabytes of data through the algorithm, without knowing the key (which probably means you're feeding it through the one actual machine performing the encryption for someone else, which would eventually arouse suspicion).

In summary, with one ciphertext, no plaintext, and no key, you stand no chance.

Virtually all successful hackers nowadays find the weakest link in the chain (the human, the unsecured computer that human is using, or the flawed implementation of the encryption algorithm on the computer the human is using), and exploit that instead, through keyloggers, social engineering, etc.

So, should this game ever commence for real, I would suggest discretely installing a program on the computer your friend will use to generate the key and encrypt the plaintext, which will transmit the plaintext and/or key to you as it is typed in by your friend. MUCH easier, and faster, than breaking the cipher. Or, if the key is based on an ASCII string, you could kidnap your friend, lock him in your basement, and use some sort of painful but non-damaging interrogation technique until he gives it up.


"Security Power Tools" (O'Reilly Media, 2007) has a chapter on Scapy.

"Python for Unix and Linux System Administration" (O'Reilly Media, 2008) also has a short section on Scapy

Both of those books are available on Safari Books Online and Amazon.

But, it looks like the various online documentation sources are the best bet:

Scapy Documentation - This is from the authors.
The very unofficial dummies guide to Scapy


Hardening Javascript in respect to Javascript Malware/Ransomeware like Ransome32

The most important thing to consider here is that this type of JavaScript malware does not run in a browser. It runs in a special runtime called NW.js which gives powerful NodeJS API's not found in a browser.

While NW.js shares many technologies with the Chromium browser, it is not a browser but a type of native wrapper for making desktop apps, and this type of malware would not run in a traditional browser which would never create the necessary API's for things like direct, un-prompted filesystem access. Therefore, browsers (and presumably Adobe Reader, even with a not-so-great track record) are already immune by design.

On the flip side, the main advantage to NW.js is that it makes these powerful API's available to JavaScript powered applications. This means that you can make desktop applications with traditional desktop application capabilities. The only way to limit this functionality would be to take away these advantages and cripple the wrapper completely.

In short, this isn't a new security risk. Running any desktop application carries the same risk, be it written in C++, JavaScript, etc. The only think new is that JavaScript has evolved to be the interpreted language of choice for many new things, and is now a common language outside a browser.

In fact, your link says it uses a self-extracting RAR file which means the user must run a .exe file. That .exe could be anything.

On a side note, we have actually already seen pure JavaScript malware for Windows targeting the Windows Script Host because .js files are executable on Windows by default (!). Normally these are just used to bypass malware filters and download more executable payloads when run.


malware - How to listen to and close malicious ports?

First of all, you should check that your firewall is enabled in Windows. Make sure it doesn't have any weird exceptions listed in it. Secondly, install and run antivirus scanner(s) for the entire system. You can run 'netstat -aon' from command prompt to see all "listening" ports. Also check from task manager if you have any weird processes running with SYSTEM privileges, even something benign sounding like "notepad.exe".
Although, if the perp has infected you with a rootkit, everything may look just normal and you cannot find anything suspicious using above methods. In that case you could only use traffic monitoring and analysis to detect any anomalies in it.


We have implemented Managed Preferences using MacOS Server and Open Directory to address this point for general users. The key problem is that this cannot block users with local admin access. Nothing can. The only real answer is your users should not have local admin privs for their day-to-day work, especially on a mobile device, if they want live by the letter of the PCI-DSS standard.

Yes, an sysadmin is a sysadmin and she should have the access rights to do her job. The standard implies that this just should not be done from a mobile device. We always challenge the developer or user that claims "I need admin access to run X software." Almost always, they don't. The software supplier is often lazy and just suggest root access to make it easy for them. They don't really care about your security practices. With proper analysis of least required privs, you can have non-root users do all they need without sysadmin access.

This gets a bit off your direct question, but we are pursuing card info tokenization with our payment gateway so we won't have the PCI requirement. Another option is to segregate your mobile device network access so one could be an admin on their local but just not have access to card processing systems. Finally, we've also built server-based VMs or Terminal Services hosts that provide the access needed and not have sysadmin access on the users local host.

Hope that helps.


It is safe to buy a domain if I get this message in Firefox?

"Connection partially encrypted" means that some parts of the page you see came outside of the SSL tunnel; most probably, the main page was served over HTTPS but contains links to inline images with plain HTTP URL. This is not really dangerous per se, but still kind of sloppy. It does not speak well for their ability to manage security issues.

When you write your credit card number in a Web page, the data will be sent to whatever URL was set in the form as "submit action". This can be seen in the page source. On a general basis, if you send some rather sensitive information (your credit card number) to somebody, then you are trusting that person to apply some care in the handling of said information. Since the warning you got demonstrates a low level of competence of the site manager in the matter of security, I would say that giving them your credit card number may not be the best idea ever.


Why does Firefox no longer recognise certificates issued by Multicert / Camerfirma?

It appears that Camerfirma was revoked from Mozilla Firefox 88:

As many of you have pointed out, there do not appear to be remediation
actions that Camerfirma can take at this time to sufficiently reduce
the risk of continuing to keep the Websites trust bit enabled for the
Camerfirma root certificates. Note that Camerfirma has indicated to us
that they are exiting the TLS certificate business.
...
...we intend to turn off the Websites trust bit for the following root
certificates in our upcoming batch of changes to Mozilla’s root store,
which is expected to happen in Firefox 88

The "..." elision above contains a number of their reasons why, which have a lot in common with the list of poor security practices you've already provided.
Chrome 90 will take the same action.


The process of judging the security of information stored in a password database is done with the assumption that an adversary (hacker) not only knows which cipher/encryption method you are using, but also that he has stolen a copy of your password database. Knowing those things, the hacker wishes to discover password so he can pretend to be a valid user.

In the problem described, the we assume the hacker has stolen the database and can see the values of both S and Y for every user contained in the database. The difference between the two methods is in what the value of Y consists of.

In method 1, [password] is combined with [salt] and then that value is block-cypher encrypted with key [password].

In method 2, [salt] is combined with [password] and then that value is block-cypher encrypted with key [salt].

The fact that the password and salt are mixed in different ways in the two examples is irrelevant; the critical fact you should notice is what key was used to create Y.

In method 1 the key used for encryption is password. The hacker doesn't know what the password is, since it has been encrypted before storing it inside Y in the database. In method 2 the key used for encryption is S. The hacker knows what S is, since it's right there in the database.

If method 2 is used, the hacker can decrypt Y immediately to discover password using the keyword S. If method 1 is used, he will have to break the encryption of Y without knowing the encryption key [password]. So method 1 is a more secure way of building a password database.


Encrypt User specific Information without a password

Protecting from someone getting the database contents is easy: Use a key (password) know to your application to encrypt the db records (a single key common to all users). That way, if someone stole just the db, the encrypted values would be without the key that is stored locally in the app node.

If the user would always be using the same browser, I would recommend to simply store the per-user "password" in a cookie¹ However, you may not be able to rely on that, and with such setup a user on a new browser would need to authenticate again producing new API keys (you will define if that's considered acceptable or not).

If the only thing you know is the identity, I think that you have no other course than using that for the encryption. I'm not familiar with the way Auth0 works, but it must be giving you some kind of user identifier (eg. an internal id or an email address) that is validated.

In that case you could eg. search the relevant database entry by looking for a record with the primary key being HMAC("foo", ), and decrypt the parameters with HMAC("bar", ), "foo" and "bar" being different secrets kept by your Heroku application.

Thus, only when knowing a user-id can the record be found and the secrets decrypted. This is not specially secure if someone got hold of both the database and the App², could try different identities, as emails are generally public (eg. I would begin by trying your email address). But still that requires testing users that could be there (from email lists gained from elsewhere, bruteforcing possible emails...).

¹ actually, localStorage / indexedDB would probably fit better.

² only one of them would not allow them to access any contents


How safe I am without antivirus on Windows 7 with restricted security policy enabled?

In depth defense recommends that you put multiple defense lines to protect your system against as much attack vectors as possible. What you describe sounds good because you try hard to control what will be executed on your system.

But IMHO, antiviruses are specialized pieces of software that research downloads and file systems for known signatures, independantly of the way they would be later triggered, and that later control again at execution time. IMHO this a complementary to your security measures, because I cannot find that in what you describe.

So I cannot really say what is the risk of not running an anti virus. I really depends too much of your usage of the system and of internet data. But as antivirus could do controls different from what you already have, my advice would be to use one free antivirus (Avira or Avast have good reputation) in addition to your other security measures.


Fresh Graduate Going into Penetration Testing

A Little Background
Penetration testing probably feels like the sexiest part of security, but it is also a very small part. It's also exceptionally broad. The term "penetration test" is often used as an umbrella to mean any one of the following:

Vulnerability Assessment
Security Assessment
Security Audit
Penetration Test
Social Engineering

It could be argued that exploit development is actually outside the scope of the term, even though in some engagements custom exploit development may be performed.
Just so we're on the same page, let's do a very brief description of what I mean by each of those.
Vulnerability Assessment
This would be the real world version of peaking in windows and rattling doorknobs. In this type of engagement the tester will be given, or attempt to determine, the architecture and analyse it for weaknesses. We'll look to see what services are running, what versions of the software those are, attempt to figure out how things are configured and connected together, how the services are used, and what security protections may be in place.
Taking all that information we'll identify potential weaknesses and report on them. This may include findings relating to out of date software versions, weak configurations (such as using HTTP when they should use HTTPS), no of insufficiently restrictive firewalls, etc.
The idea here is to look for problems and report on them, not to actually break into systems.
Security Assessment
In most cases a security assessment is a complete vulnerability assessment followed up with a policy and procedure review. This will allow the assessor to judge, not only if the procedures are in line with policy, but also whether the business unit's workflow needs tightening up. This is important because a technical vulnerability assessment won't reveal whether or not sensitive files are routinely stored in unlocked file cabinets in the main lobby, or discarded in the normal trash.
Security Audit
Audits can be very similar to an assessment, with one major difference. An audit is a strict formal test against a pre-determined standard or set of standards. An assessment may use standards as guidelines, an assessment report will include anything the assessor feels may be a weakness. An audit, however, is restricted to testing ONLY THAT WHICH IS DEFINED IN THE STANDARD. The intent here is that an audit is very formal, repeatable, and predictable.
Some audit reports may include additional, or informational, findings very reminiscent of an assessment. There should not, however, be many of those. They should not be binding, and they should be used to inform compliance against the tested standard.
Penetration Testing
This is effectively a more thorough form of a Vulnerability Assessment. Once the tester has identified weaknesses they will then attempt to exploit those weaknesses. This has two major advantages:

It helps determine whether the findings in the assessment are false positives, such as the case of a software version that should be vulnerable but contains backported security patches.
It tests the vulnerabilities against mitigating controls.

It is one thing to have a finding that the company's ERP solution is a year behind on patches, it is another to demonstrate that being behind on patches allowed an attacker to retrieve payroll information.
Unlike a security assessment a penetration test will not usually involve a policy/procedure review.
Social Engineering
During a social engineering engagement your team will attempt to con or infiltrate the organization to ex-filtrate information. This is where you get into the types of things you'll often see in spy shows or movies like Sneakers. You'll probably do some dumpster diving, attempt to create (or steal) badges, talk your way past security, pose as the CEO and attempt to convince the help desk to change your password, etc. This may or may not be included as part of a penetration test.
What All This Means To You
In the end, all of these things require specific skills. Some of them are technical, some of them are personal, some of them are organizational. Your best bet to break into the assessment/penetration field is to start somewhere else. It is generally the case that the best way to know how to break something is to first know how to make it work.
The people I've talked to, or read about, who do the best got their start as developers, systems administrators, network administrators, or something similar. Let's not forget that at the end of the day you're not breaking into a server for fun. You're figuring out how something breaks in order to tell the client what they need to do to fix it. If your report can't include recommendations on locking down the TNS listener then it doesn't really matter whether you accessed the database.
Reporting a hack (or potential hack) with no recommendations just simply not useful to the client. As such you would be doing a disservice to the client, and as such it would make your employer look bad.
So as counter-intuitive as it may seem, you really should start somewhere else. Keep your eye on the ball, though. You may be able to get a job in Security Operations, that is acting as a firewall administrator, or a systems administrator for security appliances. That would certainly help jumpstart a move into assessments or incident response.


nmap - how can I input a target to nmap from a file with the netmask attached?

You need to use the -iL argument to nmap to specify the file it is reading, then it will properly expand any CIDR addresses in that file, as shown:

$ cat file.txt
192.168.0.1/24
$ nmap -sT -Pn -p 22 -iL file.txt

Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-09 13:00 EST
Nmap scan report for 192.168.0.0
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap scan report for 192.168.0.1
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

...

Nmap scan report for 192.168.0.254
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap scan report for 192.168.0.255
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 256 IP addresses (256 hosts up) scanned in 63.20 seconds


What are some of the benign use cases of injecting bytes into another process and creating remote thread?

Well the problem with this approach is that the injection happens
using the WinAPI which is also used by native windows applications.
A very common chain that has been out there in the wild for a while now
is the following one:

OpenProcess -> VirtualAllocEx -> WriteProcessMemory -> CreateRemoteThread

and variants. If you notice all of the above functions are part of the WinAPI.
Now let's study what exactly each of these functions do. From the MSDN docs:

  OpenProcess: Opens an existing local process object. The access to the process object. This access right is checked against the security descriptor for the process.

So this is a simple function that justs allows an application to get a handle and interact
with another process if it has the appropriate rights. This is very common to happen on windows
for various applications.

  VirtualAllocEx: Reserves, commits, or changes the state of a region of memory within the virtual address space of a specified process. The function initializes the memory it allocates to zero.

So again this function can be used to allocate some memory space which is useful
if e.g. someone wants to make a custom memory manager for an application. Even malloc
which is used a lot in C/C++ programming in its core uses VirtualAllocEx and variants.

  WriteProcessMemory: Writes data to an area of memory in a specified process. The entire area to be written to must be accessible or the operation fails.

Well, what is the point of allocating space if you can't write to it (if you have the
appropriate privileges/rights of course).

  CreateRemoteThread: Creates a thread that runs in the virtual address space of another process.

Creating threads is useful for many reasons. In this case - it is just a way we can execute the process we already have a handle for, using OpenProcess from above.

In addition a variant of the above routine is also used for DLL injection/hooking which is used e.g. by software debuggers.

So as you can see this technique is often used to inject malicious code but it is also used by built-in applications. For this reason there are other techniques (e.g. code signature etc...) to prevent malware infection/injection. The bad news is that unfortunately there are also ways to bypass some of these techniques.


What are the vulnerabilities of reusing passwords for generation of keys and encrypted files?

The password (passphrase) you mention is used to symmetrically encrypt your private asymmetric key. You use the private key (not your password) to decrypt/sign your messages, this process is not affected by your password.

In case that the attacker obtains all your encrypted private keys she won't have much chance either, even if you used the same password in many cases, modern ciphers are designed to prevent that and much stronger attacks:

https://en.wikipedia.org/wiki/Attack_model


Key management scheme in PHP that is compliant with NIST SP 800-57

NIST SP 800-57 is a long and very general standard, applying primarily to details such as key purpose, length, lifetime, and other details that are typically independent of the application in use. Perhaps you should review that standards documentation, identify the requirements relevant to the your application, and narrow your question to reflect the specific requirements that your application needs to implement.

Note that finding an application written specifically to implement key and password management best practices doesn't make a whole heap of sense, since key and password management needs to be integrated into the application that actually uses the passwords and keys, rather than a stand-alone solution. So it's unclear what an application specifically for enforcing key lifetime, length, etc., would actually do, and how it would fit into your general workflow.

Also key management practices are as much about configuration, usage, and deployment of your application as they are about the code itself, and probably significantly more so.