XSS prevention through Content Security Policy

Yes, CSP goes a long way to defending against XSS.  If you do a Google search on "Content Security Policy XSS" the first few links explain how and why.

If you're having trouble using Google, here are some good links to help explain how CSP defends against XSS:

An Introduction to Content Security Policy from Mike West
An Introduction to Content Security Policy from David Müller
Using Content Security Policy to Prevent Cross-Site Scripting (XSS) - SendSafely.com explains how they use CSP on their site.
The promises of Content Security Policy to secure the web

The CSP policy is enforced by the browser.  Therefore, assuming you have set a proper CSP policy, and assuming your browser doesn't have bugs, there is no way to bypass CSP.  That's one of the attractions of CSP.

Note that some browsers (e.g., IE10 and earlier versions of IE, if I recall correctly) don't support CSP.

Be warned that CSP is not a silver bullet:

CSP does not stop DOM-based XSS (also known as client-side XSS) if you enable 'unsafe-eval' in your CSP policy.  To prevent DOM-based XSS, you must write your Javascript carefully to avoid introducing such vulnerabilities.
CSP stops most forms of script injection, but it does not stop markup injection: see, e.g., Postcards from the post-XSS world as well as the HTML form injection attack from Section III-A of Self-Exfiltration: The Dangers of Browser-Enforced Information Flow Control
 (Chen et al, W2SP 2012).  So, you still will want to avoid introducing injection bugs into your code.

See also A few things beyond the scope of Content Security Policy for more discussion of some problems that CSP doesn't solve.


Are Google Chrome Extensions vulnerable?

Ok, so we came up with conclusion that this is not vulnerability
Although we have a way how to access IFRAME contents with $("selector").contents();
and although we can really point IFRAMEs to chrome-extension:// protocol

The point is, we cannot use this in Google Chrome only (till now)
Thanks to Google Chrome Javascript security implementation, we have to respect

Same Origin Policy (SOP)
described here: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_DOM_access

We cannot access DOM content loaded from other origin in the same session

Attack possibilities

It's still possible vulnerability, but with need of disabling SOP on google chrome
can be done like this:

chromium-browser --disable-web-security

but it is quite difficult to do it from within web browser ;-)

taken from here: https://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy


Can you get virus just by visiting a website in Chrome?

Short answer: Yes, you can get a virus just by visiting a site in Chrome or any other browser, with no user-interaction needed (video demonstration). Even with Chrome you are not 100% secure - and you probably never will be with any browser, but Chrome is getting pretty close to it and the security research community seems to agree that at this time, it is the most secure browser you can use.

Long answer:
Chrome, at this time, is the most secure browser that exists in windows, because of the sandboxing techniques it uses which add up to the security.
A good description of this sandbox is here: http://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html although a bit dated. A more recent and technical one is here: http://dev.chromium.org/developers/design-documents/sandbox

The general idea is that a malicious website will have to use two separate exploits to achieve code execution on your pc: The first one exploiting the browser, the second exploiting the sanbox. This has been proven a very hard thing to do - it has not be done ever.

Your question comes at a nice timing: A week ago the security research firm VUPEN claimed that it broke chrome sandbox and published the following announcement: http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php
If you watch the video, you will see that no user interaction was necessary besides visiting the malicious URL, and a sample application popped up out of nowhere (it could be virus instead).
The attack description proved to be wrong (but that does not matter much to simple users): The sandbox itself was not breached. It turned out that VUPEN exploited a bug in Adobe Flash Player, which is a plugin almost everybody has installed - and this plugin was not sandboxed. The answer of Google is that they are moving and developing fast so that this plugin will be sandboxed eventually in the next versions.

To sum it up: As you could see in the video, you can never be 100% sure that you are safe, so be careful, don't open links you don't know where they go or don't trust the sites.

Sidenote: NSA recently published a document indicating "Best Practices" for user security on the internet: Among those is the recommendation to use a browser that has a sandbox.

Here is the report: http://www.nsa.gov/ia/_files/factsheets/Best_Practices_Datasheets.pdf

Another sidenote: Internet Explorer 9 is advertised as having a sandbox, but security researchers agree that it is not properly implemented and have demonstrated successful attacks against it.

And a third one: The incognito window has nothing to do with virus protection, but can be useful in certain classes of attacks where cookie stealing or similar is the target because it separates browser instances and isolates information available.

Finally, there are technologies that offer better protection, like sandboxie and running browsers in virtual machines.


How to protect REST JWT authentication from accepting calls from browser?

It sounds like what you are trying to do is to identify the software being used to access your API. The way I look at this, it is independent of user authentication. User authentication tells you who is using your API, you are interested in what is being used to access your API.

The fundamental problem you face is that you can't trust 100% the code that is running on the client. You have no control over it and a malicious user can modify it or reverse engineer it or as you suggested use something like Postman to send synthetic requests.

You have a number of options of how to proceed:

Remove the problem

It may be that you can re-architect your app and server so that you no longer care what is being used to access your API. It is difficult to trust code that you don't control so if possible it is good to move as much of the functionality to the server.

User-Agent String

A basic method of attempting to identify the source of a request is to look at the user-agent string that is included in the headers of the requests coming to your API. You could filter out requests coming from things that are not your android app. The problem is that it is just a header and is really straightforward to fake. So it doesn't do much in practice.

API Key (and Secret)

Another thing that you could do would be to use an API key. This is an identifier that you use to let your server know that the client accessing it is genuine. To prevent it being stolen by just observing the connection with a proxy, you have to use TLS which encrypts the connection between the the client and server so third parties can't easily eavesdrop. You may still be vulnerable to a man-in-the-middle attack though (look at pinning if this is a concern).

You can enhance this scheme by combining or replacing your key with a secret that you store in the app and never transmit. Instead you sign the traffic you send to the API using an HMAC. If anyone alters the message you send, the signature will not match and you can reject the request. Because your app is the only thing with the secret, another app will not be able to access your API.

This holds true as long as your secret remains hidden, but if you have released your app into the wild, someone malicious can still potentially get access to the app and try to look inside it to retrieve the secret. How hard this is depends on how hard you hide it. You can obfuscate your secret or embed it in native code but a sufficiently motivated individual will probably be able to find it given enough time.

In conclusion

None of the options for identifying the source of an API call are perfect, people will rightly tell you that they can all be cracked. The decision you have to make is how important is whatever you have behind your API and how much do you want to protect it. Only you can can answer that one.

I work at a place that does this sort of stuff and one of my colleagues has just started writing a series of articles that go into a bit more detail about mobile API security. If you want some more detail it might be of interest.


Trying to land a shell on a remote service

Try to get as much information about the remote machine as you can and match it on your test instance.  The remote machine is probably running a slightly different version of the OS such as a different release or patch level or sometimes even language pack that could throw off the addresses.  There could also be a difference of 32bit vs 64 bit.  Using a return address thats inside the application's own code/data section can help with that as well.

If your test instance matches the target's software perfectly, then if you had to disable ASLR on the test instance manually then theres a good chance its enabled on the target.

Also, try using a large NOP sled (string of 0x90 or no-operation instructions) so that you don't have to have the exact memory address.  You could be off by some number of bytes but as long as you land in the sled you'll hit the shellcode.

Good luck!


I believe that in this context yoroshiku can be rendered as the hope of a long and productive presence on Security.StackExchange :-). So, Welcome!

You are partially correct in your understanding of the collision problem; the risk exists, but if the algorithm has a "flat" enough output, the risk is essentially the same whatever the number of rounds.

The "security" that is increased by incrementing the number of rounds is the assurance that anyone attempting to generate large numbers of hashes (e.g. for a brute force attack) will require a suitably unlikely amount of computing power.

Let's say SHA-512 with 10,000 rounds costs ten times what SHA-512 with 1,000 rounds costs. Then, enumerating 10K round hashes for whatever purpose will take ten times as long than with 1K round hashes.

Usually, in most applications the "happy day scenario" involves only one call to the hash function (e.g. you're hashing the password supplied by the user). So we can use a high round number, and still allow the user to experience a negligible delay.

  The way i see, you can both cause a collision with too long plain texts or with too many applications of the same hashing function

Yes, but you're only comparing calls with the same number of rounds. Say that for example 10K-round hash of "foo" is abcdef, and 1K-round hash of "bar" is too abcdef. This is a collision of sorts.

But when the system is run, it will not use the hash result at every round; it will wait until it has completed the 10Kth round before returning the hash. It will never even know that a "collision" was generated at round 1,000.


Are services like "LastPass" less secure, as they have all my passwords protected by a single password?

That's why you need to make sure you change that password regularly and make it incredible strong. (I try to surpass 128 bits)

If you don't use password managers and need to insert a lot of different passwords, you might end up re-using passwords, which is even worse. I personally always recommend to use password managers once you have to remember a lot of passwords.

Personal opinion: However I don't really like LastPass because it's web-based. Call me paranoia/conservative about it, I prefer to use a KeePass database (which is encrypted) offline or synced with Dropbox.


The ICMP packets coming back were in response to your host sending out UDP packets to other hosts who don't have port 2054 open.  It was not a smurf of any sort, unless someone remotely compelled your PC to send out those packets.  Regardless, it would take a lot more than a few dozen small packets on the local subnet to noticeably slow your connectivity.  The culprit to your speed issue lies elsewhere.  Also, try to find out why your PC is sending UDP packets to port 2054 on a large number of hosts.


Will uploading a picture from my computer to a site let that site locate my computer or compromise my security?

Yes an No.
In order to upload an image, or just browse the site in general, you need to connect to the server. That means you send some data there, and they send you a response. In order to be able to send you a response, they need to know your IP address. This isn't a security flaw, this is just how the internet works.
However, most servers don't interact with you any more than answering your requests. Your IP will probably be logged somewhere on tge server, compressed and stored on some archive server, never to be looked at again.
What about file uploads?
Generally, uploading files to a server is way more dangerous to the server than it is to you. In fact, I can't think of a single way to compromise a host by allowing them to upload a file to a server. Of course, that doesn't mean there are no ways, it just means that it isn't a common thing.
So, what now?
Running on Windows 7 is risky, and it gets riskier every day. Microsoft will no longer patch any vulnerabilities, so any possible way to hack your computer that is found tomorrow (or has already been found) will be exploitable forever.
In other words, move to an OS that actively receives security patches. Now!


How safe is it to decompress untrusted files

Just looking at the CVE's for unzip you will find several possible code executions, modifying the permissions of existing files, overwriting arbitrary files outside the current directory....

The CVE list for unrar is shorter but includes also code execution.

  What steps can be taken to minimize the threat while extracting the file's contents?

Any kind of privilege separation and sandboxing, i.e. virtual machines, chroot environment or containers, ...  And of course have the latest patches.

There is actually nothing special about unzip and unrar - you should take the same care with any kind of potentially malicious files (which includes at least everything with suspicious origin).


Ethical Hacking: Cracking my personal wireless network

I believe the question has been already answered here, but I'll post mine as well.

From experience, it might be the following:

You're not close enough to the router, there is a chance that you'll not capture the handshake if the client is too close to the AP and the monitor mode device is relatively far.
A hardware issue, your network device is old and not compatible, so it can't capture packets from another protocols. For example if your device running 802.11g and the network is 802.11n

Solution: First, try to capture the handshake from different physical positions, if it doesn't work, try another WiFi device.


How can I protect myself against DNS leaks?

You can solve the problem in 2 ways:

DNS Resolver on VPN

You can install a DNS forwarder on your VPN server (if you have control of the server where it runs), set it to only forward queries coming from the VPN interface and configure your computer to use it.
Forwarding gateway

You must use two systems: one will act as the router, and route every single connection through the VPN, and the second will use the first as the default gateway.

This is the way Whonix Linux works, so even if the remote site uses WebRTC to find your local address, it will only get the useless local network address (192.168.0.x).

The first method is easier to implement and easier to maintain. The second one is more secure, as it routes everything using the VPN connection.


What are the physical security features that prevent the cryptographic data on a SIM card being read?

SIM cards are just smart cards, so apart from pointing to the generic definition of Tamper Resistant, I'm not sure much can be said in general.

Looking up the manufacturer specs may provide additional info. For example, Gemalto (a specialist in hardware crypto chips) manufacturers a large number of the world's SIM cards. Their marketing page says this:

  With a microprocessor base, SIM cards are similar to a mini-computer with its own operating system, storage and built-in security features. When configured with up-to-date cryptography, as recommended by NIST, BSI, ANSSI, etc., SIM cards provide a level of security that is state-of-the-art.

That's all kinda vacuous and fluffy, bet it's reasonable to assume that SIM chips will contain similar security technologies to Gemalto's FIPS 140-2 certified products.

This excellent answer by @ThomasPornin is also relevant:

https://security.stackexchange.com/a/31051/61443


Let's start with that Nessus and Openvas are not DAST tools.

Burp is a very good option, you might go with, OWASP ZAP is similar, but it is 100% free.
Than there are other vendors like Rapid7 Insight AppSec (not InsightVM/Nexpose), Tenable Web Application Security (not Nessus), Synopsis, etc., a simple search on Google will give you a bunch of results with vendors.

All of the major vendors can hold a session active whilst doing the scan, that's one of the basics. I would suggest looking at the report quality, ability to integrate and ease of use.


Will the ISP know what sites I visit if I use a VPN?

In short, No!

They see the IP of the VPN service and probably log it, and all your traffic including URL's IPs to your sites are encrypted. But if the VPN service is not encrypted, then the ISP could in theory can see all your traffic.

However, if you are using a split tunneling mode, then the ISP can see your DNS queries and surfing traffic.

Read more about VPN, and be sure what mode you are using.


How to catch people creating many accounts on the same website using very unique credentials?

All you can do is make it more costlier to perform such kind of activities but it could end up in negative effects on genuine buyers. For example one who owns 51% of hash power in any of the crypto-currency could rule the crypto-currency.  But the cost of owning 51% of hash power is very expensive. Likewise make your system more expensive for buyers, if you have implemented the mechanisms posted in your questions like unique phone number verification, email address verification and so on it is sufficient.

If you are requesting way too much of personal information then complexity of creating buyer accounts will increase. New buyers will not give way too much of their personal information in your site.

The best way to solve this problem is by implementing "Payment verification" on the buyer side. That is to verify their credit/debit cards. This will prevent the fraudsters creating more and more fake accounts. Implementing Payment verification is easy for you and for the buyer. The stress of requiring so much of personal info is on the bank and fraudsters cannot easily request 100s of credit cards from the bank.


Browser cache, cookies, active logins and other data

It really depends more on the services you are accessing than on your local system.  If you are not storing passwords, not using persistent logins and the services you are accessing are following good security, then any session cookies on your system should only be good from your current connection and should be useless to a remote attacker.  If your computer is so thoroughly compromised that an attacker could use the cookies from your machine, then clearing won't matter since they could either back them up or simply access your accounts while you are using them.

The main gain from clearing caches is privacy.  It prevents (or at least makes it more difficult) for people to tell what your online activity is at all.  There is some amount of security information leaked too if someone can see that you bank with ABC Bank Corp. and maybe even get your username, but they shouldn't be able to access your account simply from the cache unless someone is doing something very wrong.


Passwords verification against a set of breached passwords

"Every successful login" is pointless waste unless you just implemented the password-checking feature and didn't have it before, in which case it might make sense to check every user's login once. The only other time it would make sense is right after you add a bunch of new passwords. Add a field to your authentication DB that indicates whether each password has been checked against the list (defaulting to false), and check each one once, toggling the field to true after it passes (no match). Those that do match the list get forced to change it (if they decline, leave their field false, or even just flag the account for "must change password"). New passwords (either of new users, or if the user changes or resets them) are checked at creation, and once they pass, the field is set true.
The pwned passwords list can be sorted in a few ways, but "alphabetic" (by string comparison logic) is an obvious one, and allows extremely fast lookups (binary search). Stuff it all in a database table with appropriate indices and you won't even have to write the lookup logic yourself. There's no performance reason not to check all 300 million; it's only a bit more than twice as many lookups as checking 10,000 (which isn't enough, really), and that's a pretty easy task for any decent DB engine with a few gigs of RAM to use (give it enough RAM and the whole column can be kept in RAM, though even without that it'll be decently fast). However, you might decide there's some threshold where a password that has ever been compromised is still tolerable (maybe the passwords that have been seen in dumps only once, or just not the million most common ones, or some such thing). The most secure option is definitely to check them all, though.


What are the toughest SSH daemon settings in terms of encryption, handshake, or other cryptographic settings?

You have a good discussion here: https://wiki.mozilla.org/Security/Guidelines/OpenSSH

On modern OpenSSH they recommend:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

This page gives explanations for each choice: https://stribika.github.io/2015/01/04/secure-secure-shell.html

(do not be fooled by the hardcoded date in the URL, the document is updated from time to time as can be seen from its "changelog" at https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md)

Against Logjam, see the end of https://weakdh.org/sysadmin.html :

KexAlgorithms curve25519-sha256@libssh.org


How to determine if an X.509 certificate is a renewal of another known certificate?

So you need either the CA or the client to tell you that the certificate was renewed.  I can guess there are a few ways to approach this...

Renewal + Same Subject

A client holding the old cert and new cert could use the private key of each certificate, and sign the new cert, thus proving they have knowledge of both keys.

A server that revokes a certificate should mark it in the CRL as superseded.  I am not certain if both the RFCs and the software (Microsoft FIM or AD CS) supports multiple revocation reasons, and how that may confuse your software.

Renewal + Different Subject Name

If a renewed key can change the subject name (e.g. a name change of a user via marriage) or SAN, then you will need a custom field in the certificate to link the previous certificate together.  I hope that this kind of field is standardized in an RFC somewhere....??

If this is supported, then I would question the need for a PKI or CA anyway since a simpler solution might be based solely on thumbprints (SSH)

Theft

This gets a little hairy if the previous key is revoked, where a thief could replace the old certificate with a new one.  In addition to revocation logic, you will need logic to address an outage of a revocation server, and perhaps have a new key window that would handle the situation where a thief steals a key, changes the primary authentication key, and the user needs to communicate with the old "unrenewed" key.

Microsoft has key based renewal, where a thief could renew and lock out the user, so don't be under the assumption that a renewed certificate always has more assurance than the identity you're currently using.


LAMP MailServer without SSL... so what's the problem?

1) Using POP3 unencrypted opens you up to all sorts of exploits.  Typically, you aren't going to be so concerned about someone intercepting your mail, or more importantly your login credentials, via the open internet.  The folks who do this would have to have access to internet exchanges,  ISP routers, . It can happen, but it's not that common.

What does happen frequently is the unencrypted credentials are observed over a local network, either by legitimate access to or hacking the router/switch, or observing WiFi traffic.  For example, intrusion detection systems like snort are often configured by default to alert on this and show the administrator your username/password.  In an environment with questionable privacy on their local network, e.g. a coffeeshop, or within a corporate environment.

Thus it is possible for a bad actor to eavesdrop on the mail stream, as well as simply recover your login/password and login as you.  They can then try this password/username combination on other sites, or send password resets to other sites like Facebook and then sign into your e-mail for the reset.  So, it exposes you to quite some area of vulnerability.

Note that SSL over POP3 (POP3S) encrypts not just the password exchange, but all the data therein to prevent snooping on what your mail contents are.

2)  It is not.  If you send out data unencrypted over the internet, it remains unencrypted end to end -- including within both end's local/perimeter networks before the packet reaches its internal destination.  This means that anyone in between the route the packets take has access to the information contained within. SSL removes this vulnerability by applying a layer of encryption, so only the ends that are communicating may see the information.

The internet was not designed for security, it was designed for speed and resilience.  Then, it became like the Wild West for hackers, so layers of security like SSL were added to help make it more secure. Without SSL or other encryption enabled,  you're much more susceptible to attacks which are very old, well known and don't have to be very sophisticated.


How does a server validate the Certificate Verify message in SSL/TLS?

The handshake part of the TLS 1.3 protocol has three goals:

exchange certificates;
let the server confirms that the client really have the secret key associated with the provided public certificate, without exchanging the secret key;
exchange ephemeral keys.

Part 1 - Trust of certificate

Client sends its certificate with Certificate message.

Server determines if the certificate is from trusted source. It verifies the signature of the client's certificate, then the signature of each intermediate certificate, until it finds a trusted certificate, either from a server-side list of trusted certificates, or from a trusted certificate authority (CA).

Pseudo-code:

Alice (client) sends her public certificate to Bob (server) as well as the certificate chain.
Bob hashes the certificate.
Bob decrypts the certificate using the upper-level certificate in the chain.
Bob compares the two results; if they match, Bob has the proof that the certificate was really signed using the upper-lever certificate.
Bob continues through the chain (steps 2, 3, 4) until it finds a trusted certificate.

Part 2 - Trust of client

The client sends the Certificate Verify message:

struct {
  SignatureScheme algorithm;
  opaque signature<0..2^16-1>;
} CertificateVerify;

The signature scheme tells hash function used and signature algorithm.

The signature is produced by the client and verified by the server. The data actually signed is known by client and server and thus not re-sent (it's spaces, a context string, a zero byte and the previous messages).

Pseudo-code:

Alice (client) generates an asymetric key pair.
A trusted authority signs her public key, producing a public certificate.
Alice hashes the data.
Alice encrypts the hash using her encryption key (her private key).
Bob (server) knows, from a previous message: Alice's public certificate and the certificate chain.
Alice sends to Bob: signature, hash function and signature algorithm.
Bob hashes the data.
Bob decrypts the signature using Alice's public certificate.
Bob compares the two results; if they match, Bob has the proof that the signature is associated with the data and Alice's private key generated the signature.

Now, Alice must keep her key secret, and the data must vary between requests to avoid Eve from replaying the request with same data and same signature.

I hope it helps you to better understand.

References:
http://www.garykessler.net/library/crypto.html#why3
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html
https://nodejs.org/api/crypto.html#crypto_class_sign
https://www.tutorialspoint.com/cryptography/cryptography_digital_signatures.htm


You want mutual authentication between client and server.

As per the SSL/TLS protocol, this is supported with client certificates. Both the server and the client have a certificate; the server shows its certificate to the client, and then requests the client to show its own certificate and prove control of the corresponding private key. This works, this is standard, this is supported by usual libraries; but it requires, of course, the client to actually have an installed certificate.

The double-certificate model is fine in cases where the client does not actually trusts the server. In your case, you can do something simpler, because your app trusts your server (the app wants to be sure that it talks to the genuine server, but once it has such assurance, it talks freely with no restraint): you can use the show-the-password model that is really common throughout the Web. In full details:

When the application is first installed or started, it talks to your server, identifying it through its certificate. The SSL protocol makes sure that what the app will send really goes to your server only, and cannot be altered or spied upon while in transit.
During that first connection, the app generates a random value K and stores it locally; it also says to your server: "Hello, I am a new client and my key is K".
Your server stores in its database the information about the new client, including h(K) where h() is a cryptographic hash function (say, SHA-256).
Later on, when the app reconnects, it opens a new SSL connection, there again making sure that it talks to the right server (thanks to the server's certificate); and it then sends K to the server. The server computes h(K) (on the K value from the client) and compares it with the stored value; if there is a match, then the server knows that it is the same client as previously.

When K is something that the human user remembers and types (a "password"), a lot of extra care must be taken, especially with the hash function h() which should then be something quite more complex than SHA-256. But here, the K value is generated and stored by an application, who can use a cryptographically strong PRNG and handle a K of 128 bits or more, which will be immune to the kind of attacks that apply to passwords.

Of course, all of this is about protecting the client-server communication from outsiders. The client itself (i.e. the app user) can reverse-engineer the app at will; you cannot make sure that what is on the client side is "your app", unmodified. However, SSL and the show-the-password concept allow you to make sure that if the data goes into the wrong hands, then the client himself is dishonest (or his smartphone was stolen).


This is an attempt at Bayesian poisoning, a technique designed to fool machine-learning spam filters.  It does not work, but spammers keep trying it anyway.

Quotes from (and about) scripture are rather common in Bayes poisoning for whatever reason, even though their maximum potential would be to confuse only filters that see a lot of similar text in legitimate mail, and even then Bayes is smart enough to know the difference.


Any known vulnerabilities for thttpd 2.25b 29dec2003

Yes the following are the three public vulnerabilities listed for  thttpd -  tiny/turbo/throttling HTTP server  version 2.25b of 29dec2003

CVE-2006-4248
CVE-2006-1079
CVE-2006-1078

Further details can be looked up against these CVE numbers from any vulnerability database.


Using command (dd if=/dev/mmcblk0p1 | sha1sum) while running from initramfs

Verification from inside the potentially compromised system is pointless. If a program is missing from the initramfs you could add it manually via initramfs hook scripts. But just running sha1sum /dev/mmcblk0p1 should do the trick and work out of the box.
You can get a list of the partitions by running blkid.
However, as raspberrys usually boot from SD cards the best solution would be to always carry it with you. Or verify the checksum on another system.


Does the length of a password for Wi-Fi affect speed?

No.

This is because your password is converted to a cryptographic key which is of fixed length (128 bits). For any length of password, the corresponding crypto generated key (CMAC) would be of fixed size. Many other parameters such as the client and server id, large random values provided by client and server are used to calculate this CMAC.

Encryption and decryption uses this fixed length CMAC.


I would recommend putting the data on both.
If you're worried about data theft, you're probably just as likely to have malware steal your files as you are to have malware steal your Microsoft account password (or have someone find your password in a leak somewhere because you reused it) and take your files from OneDrive.
The main reason to store it on both is for backups. If you get ransomware, or just a hardware failure, you've got a copy on OneDrive as a backup. I can tell you from experience that you're much more likely to lose your data to a disk failure than you are from malware. Backups are extremely  important.
My recommendation would be to enable two-factor authentication (2FA) on your Microsoft account, in order to help protect it, and use a password manager such as KeePass so that you can have random passwords everywhere instead of re-using the same password in a bunch of places, which is a major risk.


Found a security vulnerability on gov related site

Any issue with a federal government web application, I would contact the office of my congress-person.

They are becoming increasingly aware of and concerned with security and privacy of government computer systems.  You can say what you want about our deadlocked, ineffective congress, but they are still pretty good at making things happen at the various government agencies they fund.  Tell them what you wrote above, especially that you never got a response.

If you don't get traction from this, let them know that the congress-person is now in the chain of people who "knew but did nothing" when you finally contact the press.

I think calling them up and demanding money is a risky idea.


What does showing a "security picture & phrase" guard against?

Normally these websites ask for a username/email at login first, then show your security picture prior to asking your password. The picture is chosen by you, the user, from a pool of images during registration. So it basically stops you from giving your password to a malicious clone of a legitimate website because the actual user chosen picture likely won't match the malicious site's image (assuming they try to show you one).

If they do show you one, it is indeed up to you to notice. But that's why they also combine this feature with the security question, which could also be the wrong question or completely missing (which you would also need to notice).

To answer the question of forwarding the photos, accurately forwarding the image/question of a financial site would be nearly impossible. There are two ways to do it that I can think of:

They would need a sizable list of active users and a list of the questions/pictures that correspond to each user, then hope no one changes their security photo or questions at any point. This is something that would basically require access to the financial website's database or a data dump of that database.
The only obvious alternative to that would be finding a vulnerability in the web application that allows them to enumerate users, which most financial websites are going to protect against. They would then need to use some automated technique to create a fairly large list of known users. From there they would have to build a kind of mirror database that links these known users to the security questions and photos.

These are pretty impractical. The most effective way (in my opinion) to thwart security pictures and phrases is either to hope users forget they will be asked, or to get access to their machine and perform key logging or screen grabbing because then there is no reason to set up a phishing website.


Generating multi-word passphrases from a wordlist

You probably could use hashcat to combine the wordlists.
I think the mode was called the combinator_attack. However this will also generate passwords with less than 16 chars, but greatly works concurrently.

You could also print out the combined wordlist by hashcat and then write a script which deletes all passwords with less than 16 chars, but I'm not sure if you want to have the full wordlist even saved on your harddisk as it probably will be a very big file.


Cipher suite selection for compatibility with http/2, and TLS 1.0-1.2

Have a look to the list of suites (and the order) supported by https://www.shimmercat.com , I'm pretty sure the site works in Mac OX X and iOS. You can use qualys SSL tools to get the list.


Verification code generation and expiration

Sending a verification code is a good option to make use of the information that you have in the database. For the type of algorithm, you can use a complex or a simple ones. The simple one that I have in mind is the timestamp and add salting to it. Like how cryptography works.

As for the expiry time, make it like 3 mins would be sufficient. The number of attempt would be 3 times as well, once it hit 3 error, create a log detail in your system or send a notification to notify you that someone try to hack into the system or something like that.


Short answer: yes.

Everything you send to Facebook is stored and processed, and that includes more than posts or pictures. All your likes, all links you click, all friends you check, how much time you spend on Facebook, how many times you use it, which hours you check. Everything.

They earn money by knowing everything possible about you and everyone you know. Making a profile of you so detailed that they can predict what you will like or dislike, and send you exact the things you like.


What is the best way to securely keep clear passwords?

Now that the question has been revised, I understand what you're trying to do much better.

The short answer is: Just store the database password in the clear, in the (server-side) session object.  You cannot do any better.

If you want, you can encrypt the database password and store the encrypted password in the session object, but there's really no point, because where are you going to store the key?  There is no place you can store the key that is much more secure than the session object.  You could store the key in a configuration file or a global variable, but really, I'm not sure that this adds any security against any realistic threat.  It's hard to see why to bother -- it feels like security theater to me.

So, just have the user enter the database password at the beginning of the session, store the database password in the session state, and be done with it.  There is nothing better you can do.

And for heaven's sake, use good web application programming practice.  Check out the OWASP resources.  Make sure you are familiar with the common web vulnerabilities seen in the web world.  Write your code carefully, using good security practices.  And ask someone else who knows something about security to do a security review of your code.  If there's a security vulnerability in your code, bad things are going to happen.


OpenSSL Padding Oracle. Specific Ciphers on apache2 seems a little limited

Please have a look at the specific CVE where it is clearly documented what is affected by the issue in the first place:

  The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC

From studying the linked resources you'll find out that the fix is not to disable specific ciphers but to make sure that you don't run any of these affected versions. From the relevant OpenSSL advisory:

  OpenSSL 1.0.2 users should upgrade to 1.0.2h
  OpenSSL 1.0.1 users should upgrade to 1.0.1t


I had the same need and after looking around I ended up writing my own program.

Usage:

memdump <pid>
memdump <pid> <ip-address> <port>

The former will output the entire process memory to stdout, and the latter to the TCP port of your choice (you'll likely use netcat on the other end).

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <sys/ptrace.h>
#include <sys/socket.h>
#include <arpa/inet.h>

void dump_memory_region(FILE* pMemFile, unsigned long start_address, long length, int serverSocket)
{
    unsigned long address;
    int pageLength = 4096;
    unsigned char page[pageLength];
    fseeko(pMemFile, start_address, SEEK_SET);

    for (address=start_address; address < start_address + length; address += pageLength)
    {
        fread(&page, 1, pageLength, pMemFile);
        if (serverSocket == -1)
        {
            // write to stdout
            fwrite(&page, 1, pageLength, stdout);
        }
        else
        {
            send(serverSocket, &page, pageLength, 0);
        }
    }
}

int main(int argc, char **argv) {

    if (argc == 2 || argc == 4)
    {
        int pid = atoi(argv[1]);
        long ptraceResult = ptrace(PTRACE_ATTACH, pid, NULL, NULL);
        if (ptraceResult < 0)
        {
            printf("Unable to attach to the pid specified\n");
            return;
        }
        wait(NULL);

        char mapsFilename[1024];
        sprintf(mapsFilename, "/proc/%s/maps", argv[1]);
        FILE* pMapsFile = fopen(mapsFilename, "r");
        char memFilename[1024];
        sprintf(memFilename, "/proc/%s/mem", argv[1]);
        FILE* pMemFile = fopen(memFilename, "r");
        int serverSocket = -1;
        if (argc == 4)
        {
            unsigned int port;
            int count = sscanf(argv[3], "%d", &port);
            if (count == 0)
            {
                printf("Invalid port specified\n");
                return;
            }
            serverSocket = socket(AF_INET, SOCK_STREAM, 0);
            if (serverSocket == -1)
            {
                printf("Could not create socket\n");
                return;
            }
            struct sockaddr_in serverSocketAddress;
            serverSocketAddress.sin_addr.s_addr = inet_addr(argv[2]);
            serverSocketAddress.sin_family = AF_INET;
            serverSocketAddress.sin_port = htons(port);
            if (connect(serverSocket, (struct sockaddr *) &serverSocketAddress, sizeof(serverSocketAddress)) < 0)
            {
                printf("Could not connect to server\n");
                return;
            }
        }
        char line[256];
        while (fgets(line, 256, pMapsFile) != NULL)
        {
            unsigned long start_address;
            unsigned long end_address;
            sscanf(line, "%08lx-%08lx\n", &start_address, &end_address);
            dump_memory_region(pMemFile, start_address, end_address - start_address, serverSocket);
        }
        fclose(pMapsFile);
        fclose(pMemFile);
        if (serverSocket != -1)
        {
            close(serverSocket);
        }

        ptrace(PTRACE_CONT, pid, NULL, NULL);
        ptrace(PTRACE_DETACH, pid, NULL, NULL);
    }
    else
    {
        printf("%s <pid>\n", argv[0]);
        printf("%s <pid> <ip-address> <port>\n", argv[0]);
        exit(0);
    }
}

To cross-compile it for Android your Android.mk should look like this:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := memdump
LOCAL_SRC_FILES := memdump.c
include $(BUILD_EXECUTABLE)


As a pentester being able to find the subdomains for a site comes up often.  So I wrote a tool,  SubBrute that does this quite well if I do say so my self.  In short, this is better than other tools (fierce2)  in that its a lot faster, more accurate and easier to work with.  This tool comes with a list of real subdomains obtained from spidering the web.  This subdomain list is more than 16 times the size of fierce2 and subbrute will take about 15 minutes to exhaust this list on a home connection.  The output is a clean newline separated list, that is easy to use as the input for other tools like nmap or a web application vulnerability scanner.


LDAP allows conveniently centralised authentication - but can this lead to complacent security practises?

LDAP should only be used on an internal network. Therefore, all services using it should be on the internal network, and should be secured from outside access. In fact, you should make sure you have specific firewall rules in place to prevent LDAP access from the Internet, nor should you try to use LDAP on a website on the Internet. It's simply not secure for those purposes. Finally, users should definitely use a different LDAP password than sites they frequent, and the network should be configured to require a new password no more than once every 90 days (72 is the recommended maximum). As long as LDAP is safe behind a firewall, it makes sense that all internal apps use the same protocol, to minimize the number of passwords you need to set.

That said, I can't, in good conscience, recommend LDAP for pretty much anything. It's an old protocol, and has since had a number of useful successors, like JWT, SAML, and OAuth, which not only allow to you use just one password, but also ensure that your password is never visible to the service requesting the authentication. The only thing the service gets is a unique token that verifies that you are who you say you are, plus a unique identifier that may not even be related to your real username. Users can also generally revoke these tokens at any time, and verify that an app is authorized to use those tokens by way of "grants."


(simple passwords would help reduce the space of possible passwords in a dictionary attack, hence the recommendations of using more elaborated pws)

Actually, WPA3 uses a new algorithm called Simultaneous Authentication of Equals (SAE), which defeats offline dictionary and brute force attacks. An attacker is only able to attempt one password guess each time you connect. This is quite different from WPA2, where capturing the 4-way handshake allows an attacker to perform a fast offline attack, potentially guessing billions of candidate passwords per second. While it's still a good idea to use a complex password, failing to do so is not quite as fatal when using WPA3 as when using WPA2.

  WPA3 uses AES-CCMP because AES alone only provides data encryption, it does not guarantee integrity or authentication, but CCMP provides both integrity because it makes sure that the original message was not tampered with, thus proving authenticity. Is this information pointing in the right direction?

Correct, with one small correction. Rather than using CCMP, which uses the very slow CCM authenticated mode, WPA3 uses GCMP, which uses GCM.* GCM provides the same level of authentication as CCM without the overhead. It is the mode that is commonly used in modern TLS connections. Below, you can see the comparison of the four main encryption standards for WiFi, including a comparison of the data integrity techniques:

* I've read conflicting reports on this. It's possible that both CCMP and GCMP will be supported.


How would a resourceful government block Tor?

Tor is used to circumvent censorship!

No, not directly. Tor is about anonymity, not about availability. Tor alone does not help its users access blocked content. Tor helps by making it hard to link clients with site visits, so that people can publish or read content without being identified. It's used to avoid being caught in relation to banned content, not directly to spread banned content.

A government that controls all the network equipment of ISPs in the country can decide which websites and services residents are allowed to access, and can know who is accessing what. If someone is using Tor, their computer makes connections to hosts that offer Tor services (Tor relays). The ISP-level filter can detect whether the target of the connection is a Tor relay and deny it if it is.

A tool that directly helps circumvent censorship is a VPN. The ISP-level filter can block connections to a VPN, but only if it knows that the service is a VPN. Tor relays are for the most part public and have to be part of a heavy infrastructure (they have to be known from other Tor known). On the contrary, a VPN operates on its own, so it's very easy to create new ones: blocking VPN altogether is practically impossible (blocking all encrypted protocols does block most common VPN, but it's still possible to make a low-bandwidth VPN using steganography if nothing else).

VPN and Tor can of course be combined (and frequently are). An ISP can block direct use of Tor, but cannot block the use of Tor through VPNs. There even exist VPN-like services specialized to use Tor: Tor bridges. There's an arms race here where the ISP/government can block Tor bridges as they discover them, but new bridges can pop up easily.

  France is going to ban Tor

No, that's not what the original article says and that's not what the THN article says either. The original article says that the police administration (not the goverment) has requested a huge array of measures of varying realism, including banning Tor. Even the article you cite claims that this request is a legislation proposal (which it isn't yet), not a law about to take effect.


How can we retire SHA1 in prefernce to SHA256 or SHA-3?

The issue with SHA-1 is not an issue unless you are trying to generate two pieces of data who's SHA-1 collide.  This is a lot different than generating one SHA-1 that collides with an existing SHA-1 which is what you would have to do to compromise sourceforge or github.  This is a statistical difference that is best described with the birthday attack (https://en.wikipedia.org/wiki/Birthday_attack).


How to you prevent accidental data/document leakage in a byod world?

Your question is a bit of a jumble but actually asks about a core problem. It's about authorisation.

Who and what is authorised to download/read a document in a cloud world and how do you enforce it?

Policies define a direction and goal. They guide the design of the authorisation process and enforcement mechanisms. In short, they are only a starting point. Ensuring limits on distribution (email, in your example) and version control (policy versions, in your example) need to be enforced through technology.

From a technology perspective, there have been many attempts to address this.

Blackberry and Samsung Knox (full disclosure, I was part of the Knox advisory team) had sandbox areas of the device that could be authorised to connect and allowed the org to control that part of the device. As you probably know, this saw limited success.

But what about BYOD? This, unfortunately, only has a single solution: do not authorise devices to access data that is not under the org's control. Either issue devices to users or ask their consent to install an agent on the device. This is the only way to address this problem in any efficient way.

What about BYOEmail? This is addressed by simply monitoring and auditing emails to webmail addresses. Anything to an employee's personal email account should be barred via policy and followed up on during audits. This addresses your 'accidental' side of things. But, this requires that you maintain your own email systems and have people and mechanisms to perform this level of monitoring.

Yes, BYOD and cloud make it possible for a 5-person team to do the work of a 50-person team, but what's lost in that efficiency is the control over the team's data, and that's what no one talks about. The leap from 'agile' to 'secure' is a big leap ...


Are old, unused Java SE JRE files insecure?

If it's literally code that's sitting on the server, but is never executed, the risks are mostly one of miss-configuration.  Unless the java code has some special privileges assigned to it, or special location, I don't see how it's any different from any other executable that shouldn't be running.  If the attacker can execute this exploitable java code, can they, as you say, execute bash?  If they can do that, it's not java's fault, it's the attack vector that lead to code being executed that shouldn't be.

I wouldn't dismiss the miss-config issue however.  If you've got 10 versions of Java sitting around, and 8 of which are compromised in some way, it's possible that someone could miss configure the server to use the old exploitable code.  It might be an emergency situation where they tried a different jvm, or just an honest mistake.

But if I were making the call, I'd classify it as "high", not critical.  I'd also make sure it gets fixed, or mitigated.


Information Security on a lost android phone

The only way to "remotely secure" your phone is to track it with ADM.

If you can't track the phone, while you are 100% sure you have ADM on and installed there is a chance that it has been reset. This also means they've wiped most of the installed apps and accounts. So they should not have access to your accounts connected to the apps.

But in case they didn't factory-reset your phone, your info would still be on the phone. If this is the case I would recommend you to change your passwords of all the know apps you used.


New certificate but what about the keys?

A certificate is your public key and some information about the site and then a lifetime. All this is signed by the issuer CA. The certificate is public and thus also the public key, but the private key is not published.

  One of our SSL certificates has expired and along with that so has the keys.

While the certificate will expire the public and private key have no expiration time. Thus you could in theory re-use the same key for the renewed certificate and this is often also done this way (unless the key is compromised or got too weak with the years).

  Was the certificate supossed to come with new keys ...

A certificate does not come with keys. You usually create the keys locally and then send only the public key to the certificate issuer but keep the private key secret. Although some issuers let you create the key online, in which case you get the key pair additionally to the certificate. If this was the case only you know.

  I now get "Warning...Untrusted...(expired cert)"

In this case the site probably still provides the old expired certificate, that is you made some error when re-configuring the site for the new certificate.


bWAPP- SQL injection Hack displays a white screen?

This application is extremely outdated, not only about its contents but also about the way it is distributed.

It is using a PHP extension that is now extinct, which will cause a fatal error in any recent PHP version. Which is the most probable cause for the white screen you are getting. But it has another reason - the error reporting settings. In order to see error messages on-screen you must configure PHP accordingly or check for the error message in the error log.

I've got an article on PHP error reporting where you can learn about these options in detail.

Another problem with this bWAPP stuff is the ancient way it is distributed. If only it was on Github, it would have been very easy to fix the code, but alas, you have to do it manually in your version.


My router got hacked, do I need to reset all 9 devices in my house?

Would there be a problem if I leave one or two of the devices not
  reset? Would the hacker get into my network again through the one
  device that's not reset?

Facts

A Malicious guy accessed your home network for more than an hour, you didn't know exactly what happened there, but for some reasons, you assumed that the router has been compromised.

Answer

Nuke it from orbit.

Wipe all your devices. Within one hour, a malicious person can do some tremendous damages.


From a trust perspective, is renewing a CA certificate the same as trusting a sub-CA?

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points:

Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used for any purpose. Root CA have no issuer (they are "self-issued"); therefore, there is no entity qualified to revoke a root CA. As a result, no CRL or OCSP response will ever talk about a root CA certificate.

When a root CA is conceptually "renewed", the old CA just floats around. Trust in root CA is always direct: a client either trusts a root CA, or does not trust a root CA. As such, it is up to each client to decide whether to include the new root and/or to discard the old root. An important consequence is that there is no way to make a machine aware of a renewal. From the client's point of view, there is no such thing as a "renewal"; there are two distinct root certificates.
"Renewal" is not a well-defined concept. There are variations. Basically the new root CA may or may not use the same key, and may or may not use the same name. In fact, when the CA changes its name (its subjectDN), the notion that the new CA is a "renewal" of the previous one is a business concept; technically, this is just "another root CA".

There is no rule which mandates a change of key upon renewal. Decision to change the key should theoretically be driven by considerations on the safety of the private key storage, within the key lifecycle management. In short, you need to change the key when the previous one is too small with regards to current cryptanalytic results. If the root key is, say, RSA-2048, stored in a good HSM, then there should be no need to change the key. (This begs the question then: Why you would like to "renew" the CA in the first place? Usually, this is because the old root CA was tagged with an expiry date by someone who was not completely aware of what he was doing, and that date was not far enough in the future.)
When a client wants to validate the certificate of some SSL server, the client tries to build a valid certificate chain which goes from a root CA trusted by the client (the "trust anchor") down to the EE certificate (the "end-entity", i.e. the server's certificate). In between are the intermediate CA certificates. Rules for what constitutes a valid chain are mindbogglingly complex but, for the purposes of the discussion here, they can be summarized as follows:

The signature on each certificate can be verified with the public key stored in the previous certificate.
The issuerDN of each certificate is equal to the subjectDN of the previous certificate.
The current date is between the notBefore and the notAfter dates of each certificate.
Each certificate (except possibly the EE) contains a Basic Constraints extension with the cA flag set to TRUE.

As long as the client can come up with such a chain, the client will be happy.

A consequence is that if you renew a root CA by reusing the same name and the same key (i.e. you just changed the validity dates), then the old and new root CA are interchangeable, as long as neither has expired. That is, every chain which begins with the old CA will be equally valid if you replace the old CA with the new CA. In that case, the transition is smooth: both your old "XP" user, and the new "Windows 8" client will be able to validate the same certificates, from both servers.

Now what if you changed the key and/or the name ?

Then trouble begins. For better illustration, let me switch to Microsoft terminology:

We are still at a time when both the old and new root are still valid (when the old root expires, it virtually disappears, so the "XP" user ceases to be able to validate anything).
The "old root" is called root0.
The "new root" is called root1.
As per Microsoft procedures, the renewal included a cross-certification. This kind of thing was initially meant for two distinct PKI to "merge" somehow, but it is also used for renewals. Namely, two extra intermediate CA certificates have been issued:

root0-1 contains the name and key of root0, but is signed by root1
root1-0 contains the name and key of root1, but is signed by root0

Note that whether a CA is "intermediate" or "root" is a property of the certificate, not of the actual CA. Here, both root CA have two certificates, one being "root" and the other "intermediate".
The first server's certificate (signed by the old root) is serverOld.
The second server's certificate (signed by the new root) is serverNew.

From the point of view of the "XP" user, both serverOld and serverNew can be validated, with the two following paths:

root0 -> serverOld
root0 -> root1-0 -> serverNew

while the "Windows 8" user can also validate the certificates with:

root1 -> root0-1 -> serverOld
root1 -> serverNew

So everything is fine ? Not so fast ! What I explain above is that the existence of the intermediate CA certificates root0-1 and root1-0 potentially allows for a smooth transition. But this works only if the said certificates are indeed made available in some way to the client.

An SSL client will build chains based on certificates found in three sources:

What the client already has. For instance, if you inspect the "certificate stores" in a Windows machine, you will see a store called "Intermediate Certification Authorities" which is a repository for intermediate CA certificates. These are not intrinsically trusted but are available for certificate path building.
What the server sent. As per the TLS specification, an SSL/TLS server does not send its certificate alone, but as part of a pre-built chain. A client is entitled to simply try that exact chain and nothing else; but, in practice, modern clients (Web browsers) will do some path building of their own if the chain from the server fails to validate. Importantly, the certificates from the pre-built chain sent by the server can be reused by the client to build other chains.
What the client can download by itself. Any certificate C may contain an Authority Information Access extension with URL pointing to places where "the" certificate of the CA which issued C can be obtained.

So if you want the "XP" client to use the "root0 -> root1-0 -> serverNew" chain, without being able to "push" the root1-0 certificate into the client machine through some out-of-band administrative operation, you have two options:

You may configure the server to send the "root1-0 -> serverNew" chain, instead of just "serverNew". That chain can be validated by the XP client, while the Windows 8 client should be able to notice that the "serverNew" certificate can be linked directly under the "root1" certificate.

Such server configuration cannot necessarily be enforced. First, SSL servers might be under control of people other than the PKI itself. Second, some SSL software cannot be (easily, or at all) configured to send a specific chain. For instance, IIS is configured with just the EE certificate, and will send what is from its point of view a valid chain; if the IIS machine trusts root1, it will not send a chain containing root1-0.
You could arrange for "serverNew" to contain an AIA extension which points at the root1-0 certificate. The XP client will use that URL to dynamically obtain the root1-0 certificate (and hopefully cache it locally for future usage). The Windows 8 client will be able to verify the "serverNew" certificate with root1 directly and will just ignore the extension.

The second solution must be applied on the new CA itself, so that when it issues certificates (e.g. serverNew), it includes an AIA extension pointing to root1-0. This is feasible; however, the dual case is not. The "dual case" is the validation of "serverOld" by the Windows 8 machine: with the cross-certificates, the Windows 8 machine must build "root1 -> root0-1 -> serverOld". However, "serverOld" was issued by the old root before the new root existed, and thus cannot contain an AIA pointing to root0-1, since that certificate did not exist at that time. A corrective action would be, when the new machine is configured with the new root, to also install the root0-1 certificate in its "intermediate CA" store.

Bottom-line: cross-certification does not work well. It is theoretically good, but it fails in practice because of the lack of availability of the cross-intermediate CA (these magic certificates exist, but there is no way to make all clients aware of their existence). In closed environments, cross-certification works: for instance, from an Active Directory server, you can forcibly push arbitrary intermediate CA certificates into all domain machines. You cannot do that in the Internet at large...

In practice, renewal strategies (for when key and/or name is changed(*)) overlap. The "new root" is simply handled as "another root". This is done in several phases:

The new root is created. The new root CA certificate is installed in all machines. EE certificates are still issued with the old root.
After a few months or years, the new root is put to use: EE certificates are now issued by the new root. This assumes that the new root has been distributed to all relevant clients during the first phase.
When all EE certificates which were issued by the old root are expired, we just leave the old root alone, to die silently (ideally, the old root key is forcibly destroyed in a formal key ceremony).

But, really, root CA "renewals" are best avoided. In that respect, the Year 2038 will be a problem, because most root CAs have set their expiry dates in 2037 or earlier to avoid the potential issue (which is probably as exaggerated as the famous Y2K). Consequently, there will be a lot of renewals 20 years from now.

Intermediate CA renewals are easier, because clients download intermediate CA automatically by following AIA extensions (contrary to root CA). This can be explained in the following conceptual sense: validation is context-free. Clients don't trust or mistrust certificates based on history, but only on what certificate chains they can build right now. All certificates are supposed to be downloaded automatically or found in shared repositories or sent by parties to each other; that is, all certificates except the "trust anchors", which are managed manually. So clients have no notion of renewal. Intermediate CA certificates, and EE certificates, can be renewed transparently since they are meant to be downloaded anew every time (though they can be cached locally). But for root CA, local administrative action is required.

(*) It does not make much sense to keep the same key if you change the name. The opposite does make sense (same name, because that's the same formal CA entity, but distinct key) but, in practice, is best avoided: when Windows uses the wrong CA, instead of claiming "this path does not work because I don't have the right CA", it instead says "this path does not work because the certificate has been corrupted and you are under attack" (I am paraphrasing here, but the message is definitely and unduly scary).


Is there a security advantage to requiring a user id instead of just /me in an api request?

Short answer: It doesn't matter

In some cases using /api/1234 could be a disadvantage. If the application lacks proper authorization checks, a user could try /api/1235 and access another user's account. This kind of vulnerability is surprisingly common in practice. /api/me is good because it forces the developer to fetch the ID from the session.

/api/1234 can be an advantage if the user ID is a secret. This depends on the application - usually with interactive applications, users can see other users' IDs. If the ID truly is secret, this protects against CSRF. However, you application should already have CSRF protection, usually through a token in a hidden field.

In general, if someone gets hold of an access token, all bets are off. Focus your security effort on stopping anyone getting hold of a token.


Does every recipient receive a different version of "encrypted" email using PGP?

In a multiple-receiver scenario, does that mean each receiver will get a different version of "encrypted" email but the same version of "decrypted" email?

Usually not.  PGP supports something called "Multi-Key Encryption"; multiple recipients public keys are used to encrypt the data encryption key, which is minimal overhead on top of what is already being encrypted.  Here's a Question that can tell you more about that.

  Also, it is possible to decrypt email with sender's public key?

No, public keys are used to encrypt and to verify signatures.  A single key half (either the public or private key) can't be used to both encrypt and decrypt; they're one-way tools.


These are automated bots (most likely running on compromised machines) that try to use your server as an open relay to send their spam - your server is correctly configured and rejects their attempts so everything is fine from this side.

You say that it only happens every few hours so it isn't really worth trying to do anything about them, the load they put on your server is minimal.

If you still want to block them or if they become more frequent and start to put more load on your server you can adjust your Fail2Ban rules to be more strict, there's no risk of false positives here so you can safely ban them after a single attempt.


Viruses and spyware are rare on Linux.  You can try Clam Antivirus, but generally speaking it is not worth the time.  Generally speaking, it is better to spend your time hardening your Linux desktop and hardening your Linux servers, rather than worrying about anti-virus scanners.  Anti-virus scanners are primarily a Windows thing.

Why do you ask?


Security considerations when naming S3 Buckets

If you embed a bucket name into an application (of any sort), and subsequently you delete that bucket, then someone else might create a bucket with the same name and now effectively have a way to influence your application.  Because of this, it's better to deliver bucket names to applications as configuration rather than embedding the name in code.


LastPass One Time Recovery Passwords--How?

LastPass stores, on the server, a "vault" which is a collection of data, encrypted with a key derived from the "master password". Let's call K that key. Normally, K is rebuild on the local computer by recomputing it from the master password. However, the same key K could also be stored on the server, this time encrypted with a recovery key Kr, allowing reconstruction of K by whoever knows Kr. The "one-time recovery password stored in the browser" would be that Kr (they call it "password" but the user does not type it, so it can be a fat sequence of random bytes, something usually known as a "key").

With such a system, the vault can expanded with a "recovery blob" which is EKr(K). Generating a recovery blob requires knowledge of K, so it must have happened on the client system, since LastPass does not know the K or the master password. This matches the idea that the one-time recovery password is browser-specific.

If one "recovery blob" can be stored, several recovery blobs can be stored as well. When the user wants to prepare his browser for a potential subsequent recovery, he makes his browser generate a new random Kr, store it in the browser entrails, and compute the recovery blob (the user types his master password, the browser recomputes K and does the encryption with Kr). The recovery blob is then sent to LastPass's servers for storage. At no point does LastPass learn K or the master password or any of the "one-time recovery passwords".

What I describe above is a plausible implementation. I cannot vouch for what LastPass actually does.

A point to make, however, is about "one-time". That one is pure marketing. There is nothing intrinsically "one-time" in what I described. What they mean is that the server will refuse to send back a given recovery blob to the user more than once. Presumably, when a user connects and requests download of a recovery blob, the LastPass server sends it back and then destroys it on its side. This is all relative to how well LastPass complies to this data destruction routine.

(There cannot be anything one-time in a system unless parts of the system enforce some state change which the attacker cannot revert. This is generic.)


Security in memory and between local windows processes over localhost

TL;DR: You almost certainly should switch to more secure IPC. Beyond that, you probably don't have a great threat model.
I'll respond to your numbered points first, then write a general answer below:

All recent Windows versions support DEP and all recent Microsoft compilers (and probably most or all third-party compilers too) will automatically mark their output as DEP-compatible (/NXCOMPAT). It is possible to configure Windows to override this flag (in either direction - using DEP even without the flag, or not using it even when present) but the default configuration will use the flag. Note that DEP doesn't really have anything to do with virtual memory per se - you could in theory implement it on a system that doesn't use virtual memory, although I don't think any such system has it - and has nothing at all to do with other processes accessing your memory, so you might want to make sure you understand what DEP (and virtual memory) are.
Virtual memory prevents accidentally reading another process' address space. A process can request access to another process' memory (by calling OpenProcess with a read permission). This will be subject to an access check: the caller's security token (a kernel-mode data blob describing the process' identity) and requested permissions are checked against the target process' ACL. By default, this ACL forbids most permissions (including accessing memory) for other users, but allows code running as the same user (and not at different elevation levels, integrity levels, or using any other sandboxing) to take full control. So yes, if your user is running malware, your app is hosed.
ASLR (like DEP) is a mitigation for a broad class of memory corruption vulnerabilities (including buffer overflows), and has nothing to do with inter-process memory access (except for stuff like "you can't hardcode the address you're reading, because the address space gets randomized"). Also, unless you have to use native code (C/C++) for some reason, instead of a managed language (C# or anything else on the .NET runtime, or Java, Python, etc.), you shouldn't even have to worry about this class of attack unless you're doing silly things with the memory management (or native code interop). Also (like DEP), ASLR is enabled via an optional (but enabled-by-default, in all modern versions) flag on the binary; all modern libraries should have it (and it's possible to force Windows to use it even if the binary isn't marked as compatible) but even a single library not using ASLR can be enough for an attacker to turn memory corruption into arbitrary code execution. Also, even with both ASLR and DEP, sometimes an attacker can still extract memory contents (or just execute arbitrary code); it depends on the vulnerability (actually usually on multiple vulnerabilities) in the program or the platform (runtime, OS, CPU, etc.).
Loopback network connections have no inherent security, and are among the worst IPC options for sensitive code. Any malicious code on the same machine (as any user) can potentially compromise the communication by spoofing one or both ends. Additionally, various remote-initiated attacks (such as SSRF) could allow compromising such a system without even being local to the machine. Finally, using "localhost" (rather than a loopback IP address) is less safe, as "localhost" is merely resolved to the current machine by convention and could instead resolve to another machine (though this would be weird) or cause a DNS lookup that a network attacker could spoof (I've seen this one in the wild, though rarely). You should absolutely use a different IPC mechanism. Windows does not lack for them. Named pipes, local domain (Unix-style) sockets, ALPC / RPC, shared memory, mapped files, even things like window messages are more secure than network sockets. Named pipes are the most socket-like option that is compatible with old releases of Windows, but local domain sockets have been in Win10 for a while now and require minimal code changes (assuming you were programming against the sockets API directly; if using some library then the library may not yet support them).
This depends on how you're communicating the port between the endpoints, but generally speaking, not even making the attacker need to figure out the port is just making things easy on them. Again, though, network sockets are a terrible choice for same-machine IPC of anything sensitive. Also, any program using fixed ports will just break if some other (entirely legitimate) process happens to be using that port, so you typically only use them when you must.
The Windows Credential Store is indeed a good place to hold keys, credentials, and long-lived tokens. A stored value is still readable by any other process with the same or strictly-greater privileges as the one that stored it (any two normal processes under the same user, or if the storing process was a sandboxed app but the retrieving process is not). It also means committing the token to long-term storage, which you might be trying to avoid? The Credential Store encrypts its data using DPAPI, which uses a key protected by the user's password (and transparently decrypts the data for any process running under the same user).

What you're getting wrong:
Don't use network sockets for local IPC; seriously, that's almost always wrong unless one endpoint is a web app, and try to avoid it even then. Beyond that, though, you don't seem to have a very complete view of the threats against this system. Reading a secret out of another process is usually not the easiest way to get it, and any attacker who can do that can probably do far worse. You need a threat model, you need to decide on an acceptable level of risk, and you need to mitigate every threat whose risk you will not accept.

Threat Modeling advice below; not so much directly related to the question.
There's a few different approaches to threat modeling, but they all boil down to trying to enumerate the ways that somebody could do something you don't want. One option is to start by listing your potential attackers, all the things you're trying to prevent them from doing, and all the ways they could do them; alternatively, start by identifing all the places that any attacker could interact with the system ("attack vectors") and then for each interaction point, figure out what an attacker can do. There's a few mnemonics for enumerating threats, such as STRIDE (Spoofing, Tampering, [non-]Repudiation, Information disclosure, Denial of service, Elevation of privilege).
For this system, who are your potential attackers?

Admins (or malware running with admin privileges) on the same machine: go back to the drawing board; it can't be made safe.
Other processes running as the same (non-admin) user as the one that started the app: might be possible but will require admin privileges to install and update; if that's a blocker then back to the drawing board.
Apps running as a (non-admin) other user: you're probably fine so long as you switch to secure IPC.
Other machines on the same network, or on the Internet: you might be fine (so far as the "pass secret between local processes" aspect is concerned) as is but should switch to secure IPC anyhow.
An attacker who can access the disk directly while the machine is off (stolen laptop, etc.): if possible, use a full-volume encryption like BitLocker, but if you can't guarantee that (or can't configure it very securely), consider keeping the secret in memory that won't get written to the pagefile and either not writing it to persistent storage at all, or encrypting it with a key provided by the user in some way (password, hardware token, etc.) before doing so (DPAPI works here, although it depends on the security of the user's Windows password and cracking those is pretty easy).
An attacker who can access the RAM directly while the program is or recently was running (an advanced "stolen laptop" scenario): nothing you can do, short of beefing up physical security and/or embedding a hardware security module in the system (both of which are well out of scope for software).

Now, mind you, if the secret isn't that valuable you can probably just accept the threats from some of those actors, because the mitigation is too expensive or inconvenient. Learning what risks to accept is an important part of security.
A few other things that might be somewhere in a complete threat model for a system like this:

Your secret is potentially used for something outside your processes (like communication with a web server); make sure that is secure too.
Your programs are presumably installed somewhere on the machine's disk; make sure the install location is secure (all the IPC and memory security in the world won't do you any good if the attacker can just edit the executable code).
Similarly, if you're storing any data of any sensitivity at all - even if it's less sensitive than the secret - make sure it's stored in a place the attackers cannot access it and, potentially, that it's encrypted.
If the secret is a security token and there's some way an attacker could try to guess it (making requests to a server, for example), make sure it has enough entropy (length of securely random data) to resist brute-forcing, and try to block side-channel attacks (such as timing attacks).
If the secret is used for cryptography (or indeed if you're writing any crypto code anywhere in there), get somebody who knows crypto to review it. Crypto is hard to get right, and sometimes a tiny mistake makes it trivial to totally break the protection.
... and too many others to enumerate, depending on things like "does the program take user input", "does the program send or receive external network traffic", "does the program process passwords", "how does the program update" and so on.


Why do Firefox and Chrome "leak" critical security information out of the browser and how can I stop it?

Why do Firefox and Chrome allow such easy leaking of these session keys?

To make it easier for developers to analyze their network captures. The first time I used this feature was when trying to understand what protocol is exactly used by the web-based noVNC. Using this functionality, I was able to decrypt the traffic in Wireshark.

  I read some speculation that this was a debugging feature, but why is it left on by default? Note that other browsers do not leak the session keys.

By default no keys are logged / leaked. The feature exists for those who need it (see above).

  Should I be concerned about this?

No. If someone is able to modify your system environment, you have larger issues. Not convinced? Did you know that Chrome has a --disable-web-security command line option? That disables protections such as the Same Origin Policy, allowing any website to modify your bank's website for example. What about the ability to install browser extensions which can listen to all of your HTTP requests and modify them without generating certificate errors?

Do not worry about this SSLKEYLOGFILE feature, it won't affect you and it is more likely that a browser extension will steal all your data or that someone will install a malicious certificate, perform a man-in-the-middle attack and inject advertisements.


Fingerprints of a RSA keys - GitHub not matching?

SSH requires two public-private keypairs. One on server side and one on the client side. In simple therms, when you want to encrypt something going to the server you are using server public key (it is decrypted on the server side using server private key). When server sends something to you it is using your public key (you are decrypting it using your private key stored on your machine).
Server is presenting its fingerprint (not the fingerprint of your certificate). So you can validate the public key presented by the server. Usually fingerprints are cached so the ssh will not prompt you next time.
When you configure your public key on the github, you are basically telling github what key you'll be using for authentication and key exchange. Github “trust” that this key is coming from you cause you are authenticating yourself with your password to upload it. In theory only you can decrypt your data cause only you have the corresponding private key. By uploading the key you're establishing a trust relationship between your machine and the GitHub server.
If the fingerprint of the key that you have uploaded is different than the fingerprint of the key on your machine is most probably caused by:

Fingerprinting wrong keys.
Original key was overwritten by running generation command multiple times.
Confusing fingerprint coming from the server (server fingerprint) with your own certificate fingerprint.


With Firefox 5.0 (at least - not sure about previous versions...) I'm getting exactly this type of information every time I put the pointer on the left side of the address bar, where the site logo is displayed.

(the pointer is missing in the screenshot but it's over the amazon logo)

Which Firefox version are you using?


My suggestion, if permitted in the country you are traveling to (there may be some export control issues, depending on the destination), full disk encryption (FDE) would be the way to go. Without the master password, no alterations can be made to the encrypted portion of the disk. This will not protect you from physical tampering of your device, as you mentioned, but seems to meet your requirements to prevent someone from installing a digital keylogger. Plus, prevention is a lot more secure than detection. Just make sure the device is completely powered down when not in use.

There would be a small risk, as the boot portion of the drive would have to remain unencrypted... there could be some attack vector utilizing that, but it would require money, skill and determination to pull off without detection (if they overwrite the wrong byte, you drive isn't booting up). So for the average person, the risk is minimal someone will go through that much effort.

EDIT: Another risk to consider, FDE would not help if someone exploited your PC over a network, and managed to get a keylogger running in memory. Make sure your PC is fully patched, have a host firewall installed/enabled, anti-virus installed, ect. It's not perfectly secure, but it helps mitigate the risk.


What is the difference between MITMproxy and SSLsplit?

[Disclaimer: I'm one of the mitmproxy authors. My opinions may be biased. :)]

sslsplit

sslsplit is a transparent proxy that can intercept TLS connections using a man-in-the-middle attack. sslsplit supports plain TCP, TLS and also HTTP to the extent that it removes HPKP, HSTS and Alternate Protocol response headers. Intercepted connections can be dumped into logfiles. sslsplit is written in C and thereby pretty performant.

mitmproxy

mitmproxy is a tool that has much more features and is thereby much more complex. In contrast to sslsplit, mitmproxy has an interactive user interface and allows you to pause, inspect, edit, replay, or drop flows. While it can be used as a transparent proxy, mitmproxy can also run as a HTTP, SOCKS, reverse or upstream proxy. Additionaly, there is a simple Python scripting interface. As you already mentioned, mitmproxy speaks HTTP primarily, nonetheless it also supports logging arbitrary TCP connections (although that's not a first-class feature at the moment).

To sum it up,

both mitmproxy and sslsplit perform the same kind of man-in-the-middle attack on TLS
mitmproxy is more powerful and has more features
sslsplit has a more dedicated purpose, is simpler, and faster.
both are (IMHO) excellent tools


These requests are coming from your private network, not from the public internet.
172.20.76.173 is part of the 172.16.0.0/12 subnet, which is dedicated for private networks.  See https://en.wikipedia.org/wiki/Private_network for more info.
Is it possible that the security policy that you created is only applied to the public interface, and not the private interface?


How can you transmit data without revealing your location?

There is no way to transmit data wirelessly without being susceptible to trilateration (using the standard definition of "radio wireless").

That's why attempts to "transmit data without revealing your location" usually end up shifting to things like laser, infrared, or other visible light methods.  These things tend to work well in directional applications, which is why they're either static (like MAN) or military (for whom the benefits of secrecy justify the trouble of maintaining directional links with mobile and semi-mobile equipment).

(Which is, incidentally, the point I was going for with the motorcycles.  If you want non-detectable wireless transmissions, you have to use something other than a radio, and that was a spectacular example).

There's really only two ways to mitigate the the ability to ELINT radio transmissions:

Make them directional.  Requires special hardware, works better for some types of radio than others, not really worth it (if you're going there, use a laser).
Lower the power so that the opponent has to be physically closer to triangulate.  Of course, in turn, whoever you're transmitting to has to be closer than that.  And you don't seem to trust the network operator, so that won't work.

Now, you stipulate that

  parties are using only standard equipment (not specialized equipment
  specifically designed to track users)

That's kind of a difficult stipulation.  You can walk your wifi laptop into most businesses secure in the knowledge that their system isn't set up to locate you.  But getting a system to do it isn't difficult.  And heck, just like Pringles cans weaponized armies of hackers, you can put together your own FindMe pretty easily.  I think it's fair to say that anything you can transmit with "standard equipment" can be located by an opponent using off-the-shelf or homebrew devices.


Bank website forwards to false site - formatted hard drive - still forwards

One common attack method consistent with your symptoms is DNS Hijacking, which is any means that an attacker uses to convince your computer that your bank's web site, "www.mybank.com" is actually at an IP which is a server under their control instead of the IP under your bank's control.  When you type this into any browser, it heads for the malicious server which then shows you a page much like your bank's own page, expecting you to log in without knowing the difference.

A compromised router could cause your DNS requests to all flow through it and therefore be replaced by malicious IPs when they are returned, while using a VPN would bypass it and show you the correct site. Also, another device on your network might not use the local router as its DNS server which could also cause it to not fall for the same router based attack.

To tell if its a DNS issue, from the affected computer try to ping the basic hostname (first part of URL) for your bank, see what IP comes back. Then check that IPs ownership on a site like arin.net, if its not owned by your bank or by a reputable CDN provider, boom you know you have a DNS highjack going on.

You can also test it by pasting the found IP into your browser bar and see what happens, but since your browser might show you a page that looks just like your bank's site, it is not conclusive unless you thoroughly look through the TLS certificate info to ensure it really is your bank. Another possible outcome is it will flag the new site as malicious (if it tries something like showing you a TLS encrypted page with an invalid certificate) but that is also not guaranteed to happen.

Edit: more about router compromises

The attacker has a few possible ways to coerce your router to doing something you don't want: they can simply log in remotely which is especially easy if the router is exposed to the internet (many are) and the credentials are the default (many are).  Both of these should be avoided at all times.  Some routers have had firmware exploits that allow an attacker to bypass the password; updated firmware should be sought and applied on a frequent basis.  Browser based exploits are also possible: a piece of malware in a site, an ad, etc. will go after default IP/credentials of your router, bypassing external access restrictions by using your own computer to do it, and then script a change like setting DNS servers to malicious ones.

Another simple mitigation to primitive router settings hijacking efforts like this is also to simply set your computer up to use a specific DNS host, like the venerable 8.8.8.8 (google's highly available anycast-based DNS server network) which is still possible to hijack if your router is 100% compromised and all port 53 UDP traffic is redirected, but more simple attacks like settings cannot do this so it would be effectively blocked.


There are different ways to measure password strength.  Most sites probably do as you think, which is some formula that takes into account special characters, capital letters, numbers, etc. and the combination thereof.  Another way, which it sounds like WordPress might employ, is measuring password strength by entropy.

In information theory, as the linked Wikipedia article says, "Instead of the number of guesses needed to find the password with certainty, the base-2 logarithm of that number is given, which is the number of "entropy bits" in a password. A password with, say, 42 bits of strength calculated in this way would be as strong as a string of 42 bits chosen randomly, say by a fair coin toss."

You can test whether WordPress works in this manner by gauging how strong it calls your password as you simply make it longer (they probable include bare minimum length and complexity).  It is actually quite likely they are using a hybrid version of these.


Is it possible to get infected when using a smartTV between two computers?

It is theoretically possible for a TV to get malware (either from the internet or a computer connected to it), and then for the TV to exploit a vulnerability in your computer's firmware, display drivers, or some other component it can talk to over HDMI (see @Esa Jokinen's comment about Ethernet over HDMI).
However, such malware would likely need to exploit multiple zero day vulnerabilities across different products in order to pivot in this way, and thus would probably be a very targeted and rare attack.
I do not think this is something the average person needs to worry about.


Role vs Identity based authentication? What is the difference?

Roles tend to be attached to identities, as you don't authenticate a role, but you authenticate an identity. You can authorize an identity, and you can authorize a role. I believe there might be some confusion here.

A role is an extension of the identity, and it usually works such that (for example) the user 'Admin' has the role 'Administrator'. A user with the role 'Administrator' has different rights than a user with the role 'Standard User'. Identities generally have the capability of having multiple roles, so an administrative user might have role 'Administrator' and role 'Standard User' and therefore has the rights tied to both roles.

Passwords are generally tied to identities, so you are authenticating the password against an identity. If there is no username field, the backend system doing the password validation probably has a lookup that compares all passwords (or more likely just looks up the plaintext of the password) to their associated users.

This assumes that roles are even being used though. If no roles are being used, the authorization is simply against the identity itself; e.g. if user == 'administrator' allow admin things.


Is it possible to revert a steganographic process to reconstruct the original image?

Not under normal circumstances.   They have been changed.

Your question does not state whether or not the message is known.  Any information like that can assist in the detective work that would help make any progress along these lines.

There is another possibility of having more information:   For instance, Playboy.com places digital watermarks inside their images.  So given a raw watermark and the steganos message, it is theoretically possible to reconstruct what was changed.

Of course, visually it will not matter.  That is the beauty of steganography.  If there are billions of possible colors and your eyes can really only tell the difference between 50-100,000 of them, then using those low-order bits is visually undetectable.

Where it gets complicated is if you use Steganos to put a message inside an image that already had another, the first one gets lost.