End to end encryption on top of HTTPS/TLS

You can certainly implement a system that uses end-to-end encryption and has the server portion written in PHP [1]. You'll just have to implement the crypto part as something that runs on the "ends" - that is, the browsers, so realistically you'll need to implement it in JavaScript - and your PHP code would serve this JS to the endpoints. The PHP code would also need to serve up the public keys [2] for everybody who is supposed to have access to the data being encrypted. Depending on how you're going to store the private keys, the PHP would probably store (and serve) a "wrapped" (that is, encrypted) version of those, too.

The server-side (PHP) portion of this whole project ends up being slightly more complicated than a typical web app. It needs to be able to authenticate users, which is normal, but without enabling the admins impersonate users (this is not normal) [3]. It probably needs to be able to store (and control access to) private-per-user data (the wrapped secret keys), per-user public data (the public keys), and restricted-access shared data (the actual encrypted user data). Depending on what sort of data is being stored, how much of it, whether you need to be able to adjust who has access to it after-the-fact, and whether it needs any kind of searchability, you may run into any of a host of additional complexities. Secure end-to-end systems are hard. [4]

The client-side (JS) portion of this thing is going to be where the heavy lifting occurs, crypto-wise, though. That's kind of awkward, because JS isn't great at crypto. There exist pure JS implementations of the standard crypto functions, but they tend to have problems (like being relatively slow, and potentially exposing side-channel vulnerabilities such as timing attacks). Some browsers support performing native crypto operations using data from JS, which is faster and more secure (assuming you trust the browser developer, which you kind of need to here), but it's not yet universal.

[1] You probably shouldn't. PHP is a poor choice for any highly-security-sensitive code, as it is relatively easy to make security mistakes in. Secure code in (modern, fully-patched) PHP is certainly possible, but I would recommend using a language that makes it harder to shoot your own foot off, like Java, C#, VB.NET, or perhaps Go or Python.

[2] This presents a security weakness you need to figure out a way around, because the endpoint system - the user and their web browser - have no way to tell if the public keys sent to the client (to which the data is being encrypted) are the right public keys. A malicious server admin could add their own public key to the list of keys, and then any data encrypted with that list of keys would be readable by the malicious admin. You need some way of verifying key authenticity.

[3] One tricky bit here is that, while the server should never store the user's password, the server does typically see the password, briefly, when creating the account and whenever the password is used (logging in, changing the password, etc.). A malicious server admin could modify the server to steal this password. If that password is all that is needed to log in as that user - for example, if knowing the user's password allows you to unwrap the user's private key - then the malicious admin could then decrypt the data that they aren't supposed to have access to by impersonating a legitimate user.

[4] Honestly, this sounds like a project for somebody both more experienced in information security and as a developer. It's not an easy problem, and crypto is hard to do right.


I should be able to see that the user visited Amazon.com and Facebook.com before.

No, you can't arbitrarily access the browsing history.

You can find out how many entries the history has (history.length).
You can navigate back to any of these history entries (e.g. history.go(-2)).
You cannot learn what these entries are, neither the domain nor the URL.

  in order to manipulate the browsing history, the HTML5-App needs to read the history first.

Well, details of the previous entries exist in memory, but the browser hides them from content scripts. Otherwise, being able to access the history cross-domain would obviously cause massive privacy problems. Just imagine one of the previous sites had a password reset token in the URL.

  If it's not true, can you explain to me how exactly this History-API works?

In HTML5 you can manipulate the state of the history stack, e.g. using  history.pushState(). This is particularly useful for websites with lots AJAX interaction that want to change the URL without reloading the entire page.1 But you can only change the URL to paths that belong to the same domain and you can only access the state objects for the current page. You can find additional security considerations in this security review of the API by Mozilla.

(Note that in the past there have been lots of browsing history leak vulnerabilities that could disclose visited URLs through side channels, e.g. by abusing CSS properties. But these attacks aren't directly related to the API.)

1It can also be useful for an attacker who wants to hide reflected XSS in the URL by dynamically changing the path to something less suspicious. That's why back then this extension of the API has been somewhat controversial.


What are PHP allow_url_fopen security risk?

A sample attack scenario using allow_url_fopen that allows me to download your password file:

Suppose your app allows me to provide a URL to a remote image, which you will download and use as my avatar image.
I provide the following URL: "http://my.malicious.example.com/sbwoodside.jpg;cp%20/etc/passwd%20downloads/foo.jpg;"
Your app uses allow_url_fopen to download the file and stores it as "sbwoodside.jpg;cp%20/etc/passwd%20downloads/passwords.txt;". I have now successfully injected a command into the filename.
Your app wants to compress and resize my image, so you use ImageMagick on the command line with something like exec("magick convert -size 128x128 ".$filename." ".$filename.".128.jpg")
What does exec actually execute? If you haven't sanitized the filename, then it executes the following on the shell:

magick convert -size 128x128 sbwoodside.jpg;cp /etc/passwd downloads/passwords.txt; sbwoodside.jpg;cp /etc/passwd downloads/passwords.txt;.128.jpg

Since ; is a command delimited on the shell, that will be broken by the shell automatically into the following separate commands:

magick convert -size 128x128 sbwoodside.jpg
cp /etc/passwd downloads/passwords.txt
sbwoodside.jpg
cp /etc/passwd downloads/passwords.txt
.128.jpg

And now I just go to http://yourapp.com/downloads/passwords.txt and download your password file. Of course, I can do anything I want, since I'm executing commands as your web server on your system.


OpenPGP’s User ID Packet is "intended to represent the name and email address of the key holder".

As a convention (not a requirement!), it uses the name-addr syntax defined in RFC 2822: Internet Message Format.

Name (Comment) <email-address@example.com> is a possible variant that conforms to this syntax.

tl;dr: It is one field. The content is formatted like that because it’s a convention.


Differentiate between internal and external network calls

Is IP based authentication a secure method to know if an API call was
  made from machines on internal network?

What do you mean by secure?  What happens if a machine inside the network is attacked and used as a proxy?  Unlimited access to the API calls?

The REST API needs authentication and authorization before you can pretend it has any real security.  Of course those need to be done correctly, but that is on the lower end of what you need.


API message verification without storing private key?

I asked the same question just yesterday, but in the meantime I have found what I believe will answer both of our questions: SRP. This question has the best answer I've found so far. Here is a reference to SRP.  The main problem with SRP is there are no modern implementations that can be used at the application level.

Edit to add more information from my research:

I have decided to use a database backed session store, so it still meets the definition of stateless.  This requires SSL to be the only protocol for communication, which eliminates MITM and replay attacks.

Use bcrypt to store passwords in DB
use Two Factor Authentication, such as Authy or Google Authenticator - this does not meet your requirement of no external dependencies, but in my case I'm ok with that. It prevents a user leaking his password - attckers still need the user's TFA device.
Have a session ID and Session length (in secs) field in each user record
Upon successful authentication (typical auth, user sends userid and password, use bcrypt to hash password using stored hashed pw from db), compare hashes, etc)
Upon successful password, generate cryptographically sound guid, and store in db, along with how long you would like to keep session alive
send this session id as response to auth
if you want true statelessness, require client to HMAC hash every request with this ID - he can keep the ID, he doesn't have to send it to you
verify request by hashing request with stored sid, compare to hash he sent you
on each request, verify that expire-time hasnt passed - you dont need a process that checks expires, just check it each time the client attempts an API call.

I have compromised and used express-js's secure session storage, which DOES use a client side cookie, but the cookie is signed with a shared secret that all of my application servers know, so it meets the stateless definition in that the cookie is not unique to the server the client is connected to, since the cookie is still in my app server's domain


How client certificate works for authentication (in Web API)

Mutual TLS (aka Client Authentication) is a solution to this.

As for issuing certs I wouldn't do that.  I would take self-signed certs from the client and pin them directly to principals (users) in some manner.  I would have a lookup table indexed by both common name and certificate public key to do that.  This makes potential problems like cert revocation (delete the row) and CA compromise (none involved) much easier.

Alternatively you could request CSRs from clients and sign them using a CA you trust (either a third party or your own in-house CA if your org has the expertise and resources to protect it properly).

Here is a good high-level description from The Code Project and they have .NET sample code demonstrating it:

  Mutual SSL authentication or certificate based mutual authentication
  refers to two parties authenticating each other through verifying the
  provided digital certificate so that both parties are assured of the
  others' identity. In technology terms, it refers to a client (web
  browser or client application) authenticating themselves to a server
  (website or server application) and that server also authenticating
  itself to the client through verifying the public key
  certificate/digital certificate issued by the trusted Certificate
  Authorities (CAs). Because authentication relies on digital
  certificates, certification authorities such as Verisign or Microsoft
  Certificate Server are an important part of the mutual authentication
  process. From a high-level point of view, the process of
  authenticating and establishing an encrypted channel using
  certificate-based mutual authentication involves the following steps:

  A client requests access to a protected resource.
  The server presents its certificate to the client.
  The client verifies the server’s certificate.
  If successful, the client sends its certificate to the server.
  The server verifies the client’s credentials.
  If successful, the server grants access to the protected resource requested by the client.

SOURCE: http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication


Set the Proxy chain and authentication  in
Options->Connection


How to set up a single sign-on for multiple domains?

The way that single sign-on has been implemented for the Stack Exchange Network is very interesting. It makes use of HTML 5 Local Storage. Depending on the browser support that you require you maybe able to use a similar method.

You can check out the stackoverflow blog post Global Network Auto Login for more details.


Taking password letters not whole one, is this secure?

This is just really terrible. The only way this can work is if they encrypt your password instead of hashing it. Or even worse just store it as plain text. I would never sign up for that service ever. <update>As @lynks stated the above is probably not true when using HMS. However if only a username is asked before this step. And the password is a fixed password of the user the rest of my answer should still stand.</update>

Also the fact that you only have to guess 4 characters (instead an entire password) is just stupid. Also those blocks may indicate the length of the password which is also really crap (if that indeed is the case).

Not only that, but they also show you on what place the characters should be added which is even more stupid, because you can now make better guessing of the characters being used based on the distribution of characters in words / sentences.

All in all what you have there is mega crap and should not be used... ever. I would go as far as saying that the person who tought this would be a good idea should stop doing stuff like this and start looking for another job.

In fact it is so bad it wouldn't surprise me if the actual characters that are hidden by those blue blocks are just hidden and stored in the source of the page ;-)

As a side note based on the last paragraph of your question:

  or do they have saved password in salted hash (MD5)?

MD5 should never be used for hashing passwords. It is waaaaay too fast for that purpose.


Might Google log every website I visit using Chrome?

Read Google Chrome's privacy policy here

Navigational errors caused are resolved automatically through Google servers. You can disable them in the Settings > Advanced Settings > Privacy. In fact, you may disable all checkboxes in Privacy section in order to not allow contacting Google every time you search something.

You can also block cookies from Google in the Content Settings, disable auto-translation, Auto-fill and password manager. And of course, disable all extensions, themes and apps.


Probably not. If I need large prime numbers, I will want to pull them from a trusted source using a secure method. To do that, I'll either need pre-shared keys or I'll have to use something like SSL. If I'm using SSL, I'm probably consuming a fair bit of CPU...

A chicken and egg problem at the very least, and trust issues after that.


The choice of the key file among 1000 possible files, assuming that you can do it perfectly (e.g. the choice does not leak through access times), is equivalent to adding three digits at the end of the password. Adding three digits means remembering (beyond the password) a three-digit number, which is the exact same memory effort than remembering which of the 1000 key files to use.

Therefore, instead of using your key files, just append that extra secret data (the three-digit number) to your password. This will be at least as secure as your key files (and probably more secure, because your choice of file will probably leak in some way) and much less cumbersome to use.


Actually, the whole WCF/SOAP security stack in .NET is based around these sets of standards for encryption and signing (if you are referring to what Thomas linked to).

Message security with encryption uses it to encrypt the message. I have no hard evidence of it, but I believe its fairly well used in WCF-centric shops. We use it for our stuff. It's all in-transit though, not for long term storage.


Are there tools to isolate protocols on major operating systems?

An application protocol is just a description of how applications interact with each other. This protocol description might be too vague or inaccurate or have a bad design and thus might lead to security relevant implementation problems. But the description itself is not vulnerable and can not be isolated. Vulnerable instead are the applications and services implementing the protocol, i.e. web browser, file sharing service etc which means that at most these can be isolated in the way you already described: "... isolate running code in various ways(qubes-os, bromium, fireglass), i.e. using a micro-vm for each task, either locally or remotely."


How hard to receive a TCP packet then resend it to another IP on the local network keeping the Source IP address?

This is achievable with TProxy in Linux, however I cannot say it has been very stable in testing.

I have implemented it in Java for TCP, had to use JNA to do native Linux library calls, as well as wrapping JRE Socket classes (based on this post, with extra changes done).

In summary, they steps are:

IPTables firewall module configuration.
Copy the address of the source socket.
Native library call to setsockopt with the IP_TRANSPARENT option, for the client socket to use the TProxy module.
Set the originating address in the outgoing socket

Apparently there are many implementations for it online, such as this one in Golang.


If I fill a hypothetical 1gb HDD with 1024 single 1mb files, will all sectors be overwritten?

No, that doesn't guarantee overwriting. If sparse files are enabled for your filesystem, long strings of zeroes might not actually be written out. Also, the area used by the filesystem to keep track of files (inode table or other nomenclature depending on the filesystem) probably wont' be filled and behavior varies greatly based on the filesystem you're using.

You must write at a lower level than the filesystem to blank out all writeable areas on a disk. Many drives also have remapped sectors at the firmware level for replacing bad sectors, so no normal OS behavior can access those.


Why are DNS requests visible with DNS over HTTPS enabled?

With tcpdump dst port 53, you select explicitly everything that goes to port 53, the traditional DNS port.
DNS over HTTPS uses Port 443, which is the standard port for HTTPS traffic.

    Apparently, this doesn't look encrypted.

The tcp-dump shows that you are doing normal DNS requests, not DoH. The DNS requests are resolved by 192.168.1.1, what probably is your router to the Internet. Because you limit your tcp-dump to port 53, we cannot see whether there are any DoH packets; we just see the traditional DNS packets on port 53.

And the DNS packets on port 53 suggest that you are not using DoH.

So, that is why they do not look encrypted.

    When I changed my DNS server to Cloudflare, I could only see the entries for Cloudflare's DNS server (which is what I expect from DoH).

So how did you do that? Change it in Firefox? What did you see? DNS packets on port 53? In that case, you are not using DoH. Or port 443 calls to the DoH server from cloudflare?

    So, what's wrong with NextDNS?

Nothing. It works (except for some IPv6 issues).

    How is NextDNS different from unencrypted DNS?

NextDNS provides (also) DNS over HTTPS. If you have configured your DoH with NextDNS correctly, you should see the DNS requests with

tcpdump host 45.90.28.0

You will not be able to read the contents of your DNS query, ofcourse

    And, am I missing something here?

As I can see it, you are making a number of assumptions that are wrong.

DNS=port 53. Although this is true for traditional DNS, DoH uses, as I stated above, TCP port 443.
192.169.1.1 is NextDNS. It is not.
You assume your Firefox config is such that it uses DoH with NextDNS. The TCP-dump you provided shows that this is not the case. You probably made a configuration error.

    But, why am I not able to intercept my regular traffic when I use Cloudflair?

Apparently, your DoH configuration is correct then. You might be able to see them with

tcpdump host 104.16.249.249

or

tcpdump host 104.16.248.249

    which result will be entrusted by the browser in case they happen to be different?

The first that is used for resolution. Once the hostname is resolved, Firefox will look no further.

    Why are unencrypted requests even generated by FF when I've asked it to use DoH?

Seems like a miss-config

    And how do I know that my router doesn't forward this unencrypted requests to my ISP if it's not able to resolve the query

I am positive that your router will forward the DNS requests to port 53 unencrypted to whatever DNS resolver you have configured in your router.


Prove a received mail came from a company email when company is tampering on their side

X can probably prove those things the headers, but you'll need the whole message so the cryptographic proofs can be verified.

You're mentioning ARC, which unfortunately requires a bit of trust, so it depends on who signed what. X should have a cryptographic signature from the ARC signer, which might be good enough assuming that comes from Google or something internal to the company, since that means the ARC signer received the message with a valid DKIM signature. It's also possible that the DKIM signature itself, which I assume is what you're seeking, is intact enough (e.g. if you revert any Subject or body alterations to how they looked when X sent the message, it's likely to pass DKIM). If the DKIM signature can't be vetted, you must rely on the ARC signature and therefore you must trust that additional infrastructure.

Armed with ARC from a trusted party or a valid DKIM signature, you can prove at least that the message passed through the DKIM-signing relay with the given DKIM-signed headers (h=…), which should include the Date, To, Subject, From, and a hash of the body (b=…).

For X to prove a DKIM match, all signed portions of the message must be provided unmolested (this includes each header in the h=… part plus the body if there's a b=… part). ARC merely signs the Authentication-Results header, but it's still best if you provide the whole email.

This might be complicated if there's confidential content in the body, but perhaps you can use the body hash instead.


Is there a way to keep sudoers from editing stuff in /etc/ssh/sshd_config?

Ultimately, blacklists don't work: it would be a vain endeavour to try to find all ways by which a root-equivalent user could alter the contents of /etc/ssh/sshd_config and try to fix them all. For instance, a lot of commands can output some data in a file whose name is provided as parameter -- that could be used to alter /etc/ssh/sshd_config.

Instead, use whitelists: explicitly allow sudoers to run an explicit, small sets of commands (e.g. a command to trigger a reboot, if that is relevant to your situation), and all others must be forbidden.

Alternatively, use SELinux to constrain sudoers into a not-exactly-root role and get /etc/ssh/sshd_config out of their reach. But this may involve some considerable configuration work (SELinux seems to be up to the task, but I have not tried it, so I do not guarantee success here). Also, be aware that the power of nuisance of a rogue root user tends to be pervasive: there are many many ways by which such a user can harm your security. It seems better to just not trust evil people with sudo powers. Or maybe some more comprehensive isolation layer would be warranted: instead of having several users in a single machine, with some semi-administrative powers, give a virtual machine to each user, that he may play with at will without impacting the other users. Depending on your context, this may or may not be applicable.


Hiding ip address when using coinomi wallet

If you want to hide your personal IP from Coinomi itself, you can use a proxy or VPN on your device, or connect to the internet using a wifi/4g connection that is not your personal one. If you have a Bitcoin ElectrumX server, you can also point your BTC wallet in the app to it, so your wallet information comes from your own server. Coinomi is already an anonymous wallet, however. No user information is collected or transmitted, IPs aren't logged on transactions.
If you want to hide your IP from other participants on the Bitcoin network, you don't have to do anything. Transactions you send from the app are relayed by Coinomi's servers. Network observers monitoring transactions will see all transactions coming from Coinomi's IP, so the user's IP is always hidden.
You can read more about Coinomi's privacy features here: https://coinomi.freshdesk.com/support/solutions/articles/29000030207-what-are-coinomi-s-privacy-features-


How much of a security issue discontinued vendor security patches are on Android?

There are two exploits that I've found at https://www.cvedetails.com/vulnerability-list/vendor_id-16630/product_id-38593/Lineageos-Lineageos.html but there may be more 0-days that are unreported.  The device seems to still get Android security updates, which is important as that will be controlling more areas and offer a larger attack surface.

Without knowing your exact situation and the usage of the phone it's hard to say whether it's worth it.  If you are potentially a target or use the phone to hold sensitive data then I would recommend getting a more suitable device, or at least rooting and installing a system that is fully updated.


Authenticating a Proxy server over HTTPS

As is customary, let's first answer the exact question which was asked.

Right now, using HTTPS to connect to the proxy is not widely supported. The squid documentation has some information on the subject; to sum things up:

Chrome supports it, but it must be configured through a proxy auto-configuration script because there is no GUI support. This also means not using the "system-wide proxy configuration".
Firefox does not support it, although the feature has been marked as requested since 2007. (UPDATE: Supported in FF 33+)
No indication on other browsers, which can be surmised to mean "no support whatsoever".

What Chrome does when encountering a "somewhat invalid" certificate for the proxy should be tested, but it is likely to depend on the exact browser version (which changes all the time, often transparently), the operating system (since certificate handling tends to be delegated to the OS), and in what ways the certificate is not valid (expired, bad server name, unknown trust anchor,...). Also, there is an inherent chicken-and-egg issue here: full certificate validation, as is mandated by X.509, includes checking revocation, i.e. download of CRL for all certificates in the path. URL for CRL download are usually located in the certificates themselves. But if you are using a proxy for your HTTP traffic, then the CRL download will need to go through that proxy... and you have not yet validated the proxy certificate. No chicken, no egg.

We may also note that the proxy auto-configuration file format does not really support HTTPS proxying. There is no formal standard for this file, but custom is to follow an old Netscape draft which says that a PAC file defines a Javascript function which can return proxy hostnames and ports, but not protocol. So, no HTTPS. For its HTTPS-proxy support, Chrome implicitly uses an extension to this de facto convention by stuffing an HTTPS URL where it has no right to be, and hoping for the browser to make some sense out of it.

As is customary, let's see what alternate proposals can be made.

To ensure protected communication between the client and the proxy, the two following solutions may be applicable:

Use a VPN. This is highly generic, and since it operates at OS level, it will apply to all browsers. Of course, it requires that whoever installs the thing on the client machine has administrative rights on that machine (you cannot do this as a simple unprivileged user).
Use a SSH-based SOCKS proxy. On your client system, run: ssh -N -D 5000 theproxy ; then set your browser to use localhost:5000 as SOCKS proxy. This solution requires that you have the proxy server (theproxy) is also a SSH server, and that you have an account on it, and that the SSH port is not blocked by some ill-tempered firewall.

The SOCKS proxy solution will ensure that the traffic goes through the proxy machine, but does not include caching, which is one of the reasons we usually want to use a proxy in the first place. It can be altered by using some additional tools, though. SOCKS proxying is about redirecting all TCP/IP traffic (generically) through a custom tunnel. Generic support for applications is possible, by "replacing" the normal OS-level network calls with versions which use SOCKS. In practice, this uses a specific DLL which is pushed over the standard OS libraries; this is supported in Unix-based systems with LD_PRELOAD, and I suppose this can be done with Windows too. So the complete solution would be:

You use a SSH-based SOCKS tunnel from your client to the proxy machine.
The SOCKS client DLL is applied on the browser, and configured to use localhost:5000 as SOCKS proxy.
The browser just wants to use theproxy:3128 as plain HTTP proxy.

Then, when the browser wants to browse, it opens a connection to theproxy:3128, which the DLL intercepts and redirects to a SOCKS tunnel that it opens to localhost:5000. At that point, SSH grabs the data and sends it to theproxy under the protection of the SSH tunnel. The data exits on theproxy, at which point the connection to port 3128 is purely local (thus immune from network-based attackers).

Another way to add caching on the SSH-SOCKS setup is to apply a transparent proxy. Squid can do that (under the name "interception caching").

Yet another way to do caching with SSH protection is to use SSH to build a generic tunnel from your machine to the proxy. Run this:

ssh -N -L 5000:localhost:3128 theproxy

and then set your browser to use localhost:5000 as an HTTP proxy (not SOCKS). This will not apply proxying on alternate protocols such as FTP or Gopher, but who uses them anyway ?

As is customary, let's now question the question.

You say that you want to protect against a man-in-the-middle attack. But, really, the proxy is a MitM. What you really want is that the proxy is the only entity doing a MitM. HTTPS between the browser and the proxy (or SSH-SOCKS or a VPN) can protect only the link between the client and the proxy, and not at all between the proxy and the target Web server. It would be presumptuous to claim that MitM attacks are reliably thwarted without taking into account what happens on the Wide Internet, which is known to be a harsh place.

For end-to-end protection against MitM, use SSL, i.e. browse HTTPS Web servers. But if you do that, then extra protection for the browser-to-proxy link is superfluous.

Protecting traffic between browser and proxy makes sense if you consider proxy authentication. Some proxies require explicit authentication before granting access to their services; this is (was ?) common in big organizations, which wanted to reserve "unlimited Internet access" to some happy few (usually, the Boss and his favourite underlings). If you send a password to the proxy, then you do not want the password to be spied upon, hence SSL. However, an attacker who can eavesdrop on the local network necessarily controls one local machine with administrator privileges (possibly, a laptop he brought himself). His nuisance powers are already quite beyond simple leeching on the Internet bandwidth. Also, limiting Internet access on a per user basis maps rather poorly to modern operating systems, which tend to rely on Internet access for many tasks, including software updates. Internet access is more efficiently controlled on a per usage basis.

Therefore, I think that protecting access to a HTTP proxy has some merits, but only in rather uncommon scenarios. In particular, it has very little to do with defeating most MitM attacks.


Is there any difference between visiting Facebook via their Tor address, and visiting them via their normal address over Tor?

Here is what using Tor to access an ordinary, non-onion facebook URL looks like:

You -> Tor... -> facebook.com

Now both of those links (from you to Tor and from Tor to facebook.com) happen on the open internet, so an attacker might watch packets flowing across those links like this:

You -> (attacker) -> Tor... -> (attacker) -> facebook.com

In a timing attack, the attacker watches the flow of packets and eventually correlates the timing of packets flowing between you and Tor with the timing of packets flowing between Tor and facebook, and hence realizes that you're accessing facebook. Note that this only lets the attacker determine that you're using facebook; if you're communicating with facebook over https then a timing attack does not help the attacker decrypt your communications.

More on timing/correlation attacks here: https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting

Accessing facebook via a hidden service should prevent trivial timing attacks, since it's then much more difficult for an attacker to identify packets flowing between Tor and facebook.


How to create a proxy so that no website or web service can know that I am connecting through a proxy?

Running a proxy server
As schroeder says, getting a residential IP would be the real issue. Everything else is simple. You can register a VPS and put a proxy application on it, such as Tinyproxy, a lightweight HTTP proxy that can be configured not to advertise the fact that it is a proxy server. At the worst, it would be advertising in its rDNS that it is a VPS. The ports used can also be easily customized to avoid detection based on common ports. Note that Tinyproxy in particular does not support authorization, so active probing (a technique used by, among others, China) could attempt to connect to it using the CONNECT method on all ports to discover if the server is running an instance of Tinyproxy.
Running a proxy simply involves installing a proxy daemon on a server, configuring the ports you wish to use to connect to the proxy, and opening the ports in the firewall. It's that simple. This can be done on a dedicated server, a VPS, or even a shared shell account. All you need is basic understanding of running a server, and the ability to open ports if they are firewalled off otherwise.
IP and DNS leaks
Preventing proxy leaks is an entirely different class of problems. The best solution for that wouldn't be to disable JavaScript (which doesn't have a built-in way to bypass proxies anyway), but to set a firewall rule that blocks all traffic not going to the proxy server. This prevents both malicious exploitation and accidental misconfigurations from bypassing the proxy and revealing your IP.
HTTP proxies do not require you provide the IP address, so the domain will be resolved by the proxy server itself. This is also true for SOCKS5 and SOCKS4a proxies. With an HTTP proxy, requesting an example website is done by sending headers such as the following to the proxy:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

It is up to the proxy server to resolve server.example.com and relay the response to you.
Getting a residential IP
Using a residential IP generally requires you run a proxy server on a computer connected to a residential line. Unless you have someone who is willing to do that for you, there is no simple, legal solution. If you have online friends who may not mind running a proxy for you, you could take advantage of that. For example, I have a friend in Moscow (Russia) who was willing to run a proxy server on his own system and allow me to connect to the internet through it.
There are several commercial proxy services that can provide residential IPs, however they are rather sketchy at best of times, and certainly are not what I would call "trustworthy". Many of these services are likely to run proxy servers on a botnet and sell access to the proxies for a profit. While this may give you a residential IP (and "reputable" services will guarantee that IPs will not be shared, or will be minimally shared), it is likely that it is running on a compromised machine. An example is VIP72, which has been known to (perhaps unwittingly) utilize botnets.
It is also possible to exploit consumer routers and run lightweight proxies on them. Many routers have vulnerabilities in exposed web interfaces, or even just use default credentials. As the majority of routers are rarely if ever updated and behave as magical black boxes to their owners, detection is exceptionally rare. Scanning the IPv4 range for particular router vulnerabilities can prove very fruitful. Relevant vulnerabilities are often posted to mailing lists such as Full disclosure. Note that this information is for educational purposes only, as hacking routers is illegal in many jurisdictions.

Encryption is not needed. Encryption through OpenVPN introduces its own issues of detection - or this is what I have read.

That isn't true. The OpenVPN protocol does not hide the fact that it is a VPN tunnel from your ISP, but the website you connect to will not know anything about that. The encryption used by OpenVPN (or other encrypted tunnels such as IPSec) terminates at the VPN server. There are other ways to detect that a VPN is in use though, so a (secure) proxy can actually be more stealthy.


Is there a HeartBleed Honeypot so that I can pentest it?

It should be easy to create one of your own, which is usually preferable. Fire up apache, install an old libssl (prior to 1.0.1f) and give your install a self-signed cert. Then, generate some traffic with curl.

You should be able to fire up your exploit and start reading memory.

It's probably best to do this in a VM, since you don't want anyone else exploiting your test bed.


How to harden against credential stealing in EC2 via the http://169.254.169.254 API?

Since you're using Linux, you can do this using iptables. It's possible to block specific UIDs from making specific requests. See https://unix.stackexchange.com/questions/104830/block-specific-application-with-iptables, or https://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html (the latter is quite old, but I think still correct).

What I'd do for your case: add a rule that DROPs network OUTPUT from the UID that your server(s)/process(es) run as to that IP address. Assuming you don't run everything as the same user, that shouldn't break any other processes that want to access the metadata service, while preventing SSRFs or similar issues for that specific endpoint.

iptables -I OUTPUT -d 169.254.169.254 -m --uid-owner <UID or maybe username> -j DROP

This (I think; not tested):

Adds a rule to the beginning of the OUTPUT chain (used for outbound packets)
Filters to packets that are bound for 169.254.169.254
Matches only packets originating from a process with the specified owner (unsure whether this checks real or effective UID but you should drop any higher privileges as soon as possible anyhow)
Drops it on the floor.


Understanding how password based encryption works

The algorithm definition here is for password based encryption (as the name perhaps obviously implies) and not just password based key derivation.

So Bouncy Castle is providing not only a way to derive a key, but also the ability to encrypt data, and in this case would use AES-128 in CBC mode to do so.

If you only care about the key derivation part, you can use the resulting 128-bit key with any cryptosystem that accepts a random 128-bit key. No need to limit it CBC mode, or even to AES.


With any decent key derivation function and a 128-bit secret key, it's possible to generate blocks of output for every UID such that, if you know all the outputs except for one bit of one block of output for one UID, and you don't know the secret key, then you have no way to know what this one missing bit is. (As in, if you used all the computers currently existing, it would take you more than the age of the universe to have a better chance of guessing the value of that bit than flipping a coin.)

So unless somebody did something stupid or there was no attempt at security, you can't find how the output was generated by observing outputs alone as a black box. You'll need to reverse engineer the code.


Is VLAN Hopping through switch spoofing possible without DTP?

Short answer: Yes. As long as you can get a trunk link between your device and the switch.

Long Answer: This attack takes advantage of how the native vlan works with dot1Q packets. A trunk link negotiates the encapsulation protocol of the link, which is usually 802.1Q. If you just send dot1q packets to the switch they are going to be dropped so that is why you need to create that trunk link between the devices, so as long as you can do that then you can replicate the attack. You will have to do some more research on how LAPD works and its default settings. For example, in Cisco's Catalyst family of switches, DTP is set to 'desirable' by default, meaning that it is willing to trunk and all you have to do is tell that port that you want to trunk and it will create that trunk link and negotiate the encapsulation protocol (Usually 802.1Q). I demonstrated this using a tool called Yersinia. So, you will have to see if LAPD does something similar. You will also have to make sure the other correct variables are in place to make this attack work as well but overall, if you can create a trunk between your device and the switch then it is possible to replicate the attack.

Things to think about:

Make sure to research the default configurations of the HP switch and the different modes of LAPD if you are going to make a practical case for this attack. For example, how I outlined above about the default configuration of DTP and why it works.
If you are going to target LAPD then you might have trouble finding a tool that does this as Yersinia attacks DTP because Cisco is much more popular. If you need or have the time to create your own tool, then you can accomplish this with the Scapy library for Python which allows you to create and craft packets at the each layer of the TCP/IP hybrid model and let's you to implement and define specific protocols and parameters.
For this attack to work in demonstration make sure you get a trunk link, you are sitting in the native vlan as an attacker and the target is in a different vlan.

If this is just to demonstrate the VLAN -hopping attack itself and not HP LAPD specifically then I recommend you try to get your hands on a Cisco device even if its virtual through GNS3 or Cisco Packet Tracer. It would be much easier to demonstrate as Yersinia is an already created tool that can attack DTP and craft double-tagged packets.


How to determine if a PC's hardware and firmware have been modified?

Could re-flash the firmware, that should overwrite whatever's there.

I'm not sure what you're looking for in the "modified hardware" department, any extra devices added should be visible from looking, unless you think a chip or device has been de-soldered and replaced with an identical looking "bad" one... practically anything with accessible hardware is vulnerable to that.

There are virus & malware scanners that might detect known samples (like rootkits), but maybe not custom (zero-day) samples


localStorage vs. HTTP-Only Cookies + XSRF: Is either better when it comes to XSS?

As per the OWASP cheat sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
None of the prevention techniques are effective if you have a XSS vulnerability in your site.


Do I need microcode update if I update Kernel?

Yes, you need both.  The Linux-side changes make use of the microcode-side changes to mitigate these vunlerabilities, both are needed for it to work.

Note that you also need to disable hyperthreading if you are really serious about mitigating this.

I should add, Intel published details on how to "maybe-perhaps" mitigate it partially using some code sequences, and those work even without the Microcode changes.  At least one of the BSDs deployed these, but Linux did not (and there are no plans to, either. Apparently, they don't mitigate things nearly enough to be worth the hassle).


why wireshark shows tls1.2 but it's actually tls1.0

Because of buggy TLS servers, TLS 1.2 clients send the ClientHello with TLS 1.0 at the record layer protocol_version and TLS 1.2 as the client_version (proposed by the client). A TLS 1.2 server sends TLS 1.2 in server_version back and then they continue with TLS 1.2 flow.
See the RFC and blog posts by major implements about version intolerace.
With TLS 1.3, the version mechanism was revised to try a mechanism that is even harder to mess up when implementing, as part of GREASE effort to lessen ossification. With TLS 1.3, the protocol layer version in the ClientHello is TLS 1.0 (legacy_record_version), the client_version is TLS 1.2 (legacy_version) and the real version in the version negotiation extension is TLS 1.3 (supported_versions). This is needed to get the connections past crappy middleboxes.


Sending your logged in user credentials (SSO) is limited only to the intranet zone. http based NTLM authentication is widely used inside corporate networks and is not considered a security risk unless an attacker managed to get a foothold inside your network. (which will happen)

By default the intranet zone is defined by anything that's in the same subnet as you, the same DNS suffix as you, local proxy exclusions or anything that you manually defined.

This is still a good attack vector to gain credentials assuming you managed to get into the corporate network, and i've used it many times when pentesting networks. (for NTLM reflection/relay, or just as to brute force the password)


An ISP should be able to identify the accountholder details (including address on file where applicable) and at least the street address corresponding to the IP at a given time when dealing with wired residential connections, but there is not much more. There are some circumstances under which it is simply not possible to identify a person based on their IP address alone, e.g. public hotspots might give you the name of some McDonald's franchisee who operates several locations under the same Verizon account while controlling his own IP addresses (although a hotspot IP address might be better information than many other cases in practice).

If you intend to track down clients who come in via chat, it ought to be made explicit right off the bat. If it is not hidden from the user that the outcome may be a rescue team being dispatched, then they should have no issue sharing their location from the browser. Add a disclaimer that if the location is not correct to some reasonable accuracy, you will not be able to help them effectively.

Do what you can. If a user on chat is using their phone, the location shared should be GPS coordinates. If they are tethering or have disabled location services, you can compare against ranges of IP addresses used for wireless Internet service if lists may be provided to you by the major carriers (this way, you do not need to consistently query them; you know what's what from in-house data). In this case, you can ask the user to specify their address (and provide a very decent auto-suggest, maybe a map with quick zone options for rapid pinpointing). If they are not willing to do so out of fear that they may be tracked and visited, they are entitled to that information anyway. Tell them very clearly how the service operates, enable quick manual entry when it is not possible to derive location automatically (if it is, ask to verify), and just do what you can.

As for IP addresses, if you are working under a government-sponsored operation then you may be able to acquire access to certain details on a need-to-know basis with guaranteed accuracy to the ISPs' fullest abilities. You should not be questioning whether or not the operator is competent enough to provide the information required, and if you are then you need to push for better facilities.


What physical, electronic, and software characteristics are important in a smart card?

There is a security standard for smartcards under the Common Criteria scheme: the Smart Card Protection Profile. A protection profile defines the security properties that are expected from a device or system.

The smart card PP is defined for EAL4+. To put it succintly, the EAL defines what aspects of the product's design are evaluated and to what extent (design documents, code review, developer and independent testing, maintenance practice, delivery, etc.). A CC certification also involves penetration testing, and the + in smartcards' EAL4+ is an extra amount of attacker potential in the penetration testing.

You can find a list of certified products on the Common Criteria website as well as on various national websites (certifications up to EAL4 are recognized internationally). Products in that list might be evaluated against a different protection profile that covers a different target: you'll find smartcard components there, and smartcard-based devices such as passports, health cards, cards with a defined software interface such as JavaCard, etc.

Unless you're a government or bank purchaser, you don't have to get a certified product. Certification has a cost, which is reflected in the device's price. Certification isn't a silver bullet: it only says “this looks good”, not “this is absolutely guaranteed to be secure”. In principle, a CC certification gives you independent assurance, because it is conducted by a government-approved third party.

If you consider buying a certified product, be sure to read the fine print. Certifications reports usually come with assumptions that must be met for the certification to be valid; check that these assumptions make sense for you. Also, certification is often a way to shift liability: by having their product certified, the vendor demonstrates that they have used best practices, so you are unlikely to be able to claim damages if their product turns out to be vulnerable.

Even if you don't get a certified product, the protection profile contains useful information: it provides a definition of security objectives, a threat analysis and other elements of security analysis.

Keep in mind that a security infrastructure is only as strong as its weakest component. A super-secure smartcard won't do you any good if it's stolen and the PIN is the user's birth year, or if using the card is so much hassle that people set up ways to bypass it.


How malicious 3rd party toolbars on IE could be?

Are they able to modify my page results and maliciously implement
  Cross-Site Scripting stealing for example credit card or social
  security numbers?

Yes. Such malicious extensions have always been developed. I think one of the best example we can mention is the notorious ZombieBrowserPack which is an opensource project develop first as a POC by Zoltan Balazs and which targets various the most used browsers (Chrome, Firefox and IE). This plugin can be manipulated remotely to steal authentication credentials and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google, or simply hijack your Facebook account.

  Are they able to access information beyond the browser (files, list
  applications, network configuration information?

Yes. The same extension we just mentioned is able   take screenshots using your machine's webcam, and not only can be used to mainuplate your files but also download other malicious files to execute them on the machine's victim.

  Are they able to transmit information regarding my Internet surfing
  behaviour back to their developers even when I don't interact with
  them?

Yes. Actually this plugin behaves as an HTTP proxy  allowing an attacker to communicate with a server on the victim's internal network without any interactions required to be performed by the victim.

In the beginning, such extensions were used by attackers for click fraud  by, for example, hijacking search queries; but the short and very rich history of the Web shows teaches us a long list of extensions developed to fulfill a targeted goals . Just to give you an example:

  Through the analysis of more than 48,000 extensions from the Google
  Chrome web store, the group of researchers was able to detect 130
  malicious extensions, including one with 5.5 million affected users.

Nowadays, you do not need only to use a malicious extension to be a victim of one of the scenarii you mentioned, but a simple visit to a given compromised webpage could lead to a drive-by download attack by exploiting your browser's vulnerabilities which are more frequently carried on by the extensions you install leading to spyware and adware (in the less dramatic cases) to infect your machine as it happened with visitors of Amnesty International's homepage on 2011 of which many users became victims.

So before making the decision to install any plugin to your browser, you need to be careful by checking the permissions requested by its developers, and when you visit a webpage prompting you a message to install a plugin to be able to view its content then do not hurry to follow the instructions (for example if you have already the Flash plugin installed and the page asks you to install it then this is likely to be a drive-by download attack requiring the user's interaction). And as a general safety practice, never install a plugin unless useful and install as few as possible of them and verify if you can the behavior and source code of your extensions from time to time as it is done here.


The first problem I seem to encounter revolves around the difference between systems/devices that process/store/transmit cardholder data (aka Category 1 systems/devices) versus those systems/devices that are connected to those Category 1 systems/devices (aka Category 2 systems/devices).  The guidance here is that if a Category 2 system has the ability to effect the security of a Category 1 system (i.e., the Category 2 system/device has inbound access to the CDE system(s)/device(s)), then administrators should also use MFA to access those Category 2 systems/devices.

Curled from https://pciguru.wordpress.com/2017/01/07/getting-ready-for-8-3-1/Chris


Is using `file_get_contents` on a URL with concatenated parameters secure?

There are two advantages (from a security standpoint):

Starting with a hard-coded URL makes sure that nothing local would be loaded (although it would be hard to take advantage of it even still depending on what happens to the data after it is json decoded).
The user input is injected into the data parameters (i.e. after the question mark).

These limits a malicious user to only modifying the request parameters sent to the google geocoding API.  Looking at the available options,  it doesn't seem like there is much damage to be done there.

It is still best practice to filter user input.  The concept here is defense-in-depth. At the moment the risk seems to be very low, but what if a later code change further modifies the way the data is used, resulting in a vulnerability?  For instance, is that latitude and longitude from the user persisted into a database later down the line?  I presume not (or you have found it if so) since you are auditing and checking these less obvious issues.  However, my point is that this function hides the fact that it is working with unsanitized input, and therefore it later changes might inadvertently introduce a vulnerability.

So yes (as you know), best practice is to sanitize/validate user input before doing anything else.  However, there does not appear to be an immediate vulnerability as a result of that oversight here.

Of course, you can always just use the fact that this endpoint is directly connected to the google maps API to spam the page constantly, resulting in either a) a larger-than-expected bill or b) DOS part of their app because google rate limits their geoip lookups.


Password sent via email upon registration

First, its generally a bad idea to send permanent passwords for secure things via email, especially user generated passwords (which the user may share on other resources).  Your email is often automatically saved to disk if you use an email client, which is easily read by anyone with physical access to your computer if you don't encrypt your hard disk or ever leave the encrypted hard disk unlocked.  Also there are generally no guarantees in email that an eavesdropper isn't reading your email messages, e.g., if you check your mail via POP/IMAP without SSL or someone is scanning your email server-side, or while the email is routed between mail servers.  Granted a computer-generated password is being stored with your email may not be that much of a compromise, especially if the system allows someone with access to your email could reset the password.  (And if the site uses cookies to store login information you could read cookies off the hard disk just as easily as reading email off the hard disk).

Its nice that the process described above verifies that the email address is (initially) readable by the registering user.  This can also be done by requiring a registering user to click a link with a random token.  Granted temporary email services like 10minutemail.com can get around this, a user may be less likely to lie as they'll want to have the password in their records.

Another nice thing is that it sets a strong password by default.  Many people will not change defaults or if they do change the password, will use a similarly strong password.  Consider organ donation with countries opt-in/opt-out countries.  99% of Austrians are organ donors as the default is to be a donor (opt-out), and 12% of Germans are organ donors as the default is to not be a donor (opt-in).   This aspect of psychology is probably more of a factor in choosing the default for other security features like "this is a public computer (do not remember my login)", but for users who already save passwords in their browser this isn't particularly different.

The password change functionality ideally can attempt to check that the new password is sufficiently strong.  E.g., is not similar to passwords in a common password list, is not dictionary word, or a dictionary word followed by a 1 or 2 digit number or punctuation mark.  This could be a very annoying and more CPU intensive to make every registering user generate a strong password, but possibly less intensive if the check is only done on password change page (assuming some frustrated users give up).  Also, its better to have them frustrated at changing the password once they already have a working account versus before they have one.


Now, the question is, do you know what a HTTP request looks like?

Well, assuming not, here's an example of one:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

All of this information is enscapulated within the SSL transport - as the comment on your answer kindly says. This means:

Get parameters are encrypted.
HTTP Body (post parameters) are encrypted.

What's not necessarily secure:

The host you're asking for. Most web servers these days support Host: something parameters so multiple domains can be handled by one web server on one interface and IP address. Clearly, this header is encrypted, however, if you run non-https traffic to the site it should be clear which hosts you might connect to. Even if that's not the case, reverse DNS will certainly tell you what's hosted on that IP and you can probably make a reasonable guess from there.
Your browser/client information. Unfortunately each https client is different and its negotiation process might potentially give away what platform it runs on, or what browser it is. This is not the end of the world by any means, it's just a fact to understand.

POST requests look similar to get requests, except they contain a body. This may look like this:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

There are some more complicated variants, of course, but essentially it is all encrypted anyway.


Extracting Facebook ID or email from browser's history

You can probably obtain information by looking at the browser cache. When the browser downloads pages, it stores copies of them in local files, so as to speed up operations if asked to inspect the same page again. Whether a specific page will be cached or not depends on what the server says about the page (there are HTTP headers for that); old pages are automatically removed from the cache so that its total size remains low; and the user has the possibility to "clear the cache" manually.

Location of the cache, and its internal format, depend on the browser type and version, and the operating system. If you use Chrome on Windows, this freeware utility purports to be able to let you see and navigate the cache contents (I have not tried it and I do not vouch for its quality). Alternatively, go have a look at the files in [User Profile]\Local Settings\Application Data\Google\Chrome\User Data\Default\Cache where [User Profile] is the home directory of your account on the machine (you may have to configure your file explorer to show hidden and system files).

Of course, if someone potentially evil and hostile could use your computer, then he could do a lot of bad things with it, including planting malware which will spy on you and siphon out the contents of all your files and passwords and secrets. However, if the said person used your computer to log on Facebook and left enough traces for you to see it, then chances are that he was not that competent or did not try very hard for concealment.


A LUKS volume is protected by a volume master key.  This key is generated when the encrypted volume is created, and is the maximum strength the chosen encryption algorithm permits.  Access to this key is by means of a number of "key slots": the volume master key is encrypted using a user-supplied password and stored in the header.

Strictly speaking, LUKS does not support keyfiles.  Instead, it supports reading the user-supplied password from a file -- something that is roughly equivalent to TrueCrypt's keyfile system.

A password-protected keyfile can be equivalent to a password+keyfile, or it can be worse.  It all depends on how well your password protects the keyfile.  I can't think of a situation where it would be better.


Log of all processes running on a computer

Windows systems can log all processes that are started via system policy:

  In Windows 2003/XP you get these events by simply enabling the Process
  Tracking audit policy.  In Windows 7/2008+ you need to enable the
  Audit Process Creation and, optionally, the Audit Process Termination
  subcategories which you’ll find under Advanced Audit Policy
  Configuration in group policy objects.

  These events are incredibly valuable because they give a comprehensive
  audit trail of every time any executable on the system is started as a
  process.  You can even determine how long the process ran by linking
  the process creation event to the process termination event using the
  Process ID found in both events.

Linux systems can log all processes that are started using auditd:

  In /etc/audit/audit.rules we need to ensure that the following exists.

  -a exit,always -F arch=b64 -S execve

  This will capture any execve system call (on exit) and will log this
  to the auditd log. A log entry will look similar to below.

  type=SYSCALL msg=audit(1318930500.123:3020171): arch=c000003e syscall=59 success=yes exit=0 a0=7fff65179def a1=7fff65179ec0 a2=7fff6517d060 a3=7ff54ee36c00 items=3 ppid=9200 pid=9202 auid=0 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=(none) ses=4 comm="xscreensaver-ge" exe="/usr/bin/perl" key=(null)
  type=EXECVE msg=audit(1318930500.123:3020171): argc=5 a0="/usr/bin/perl" a1="-w" a2="/usr/bin/xscreensaver-getimage-file" a3="--name" a4="/home/welby/Pictures

If data exists, it can be analyzed :).  But these are just methods of enabling the data capture.


Can my network admin examine files I upload on a HTTPS site?

No, it is not possible to listen to your network traffic and reconstruct the files you're sending over HTTPS, provided the HTTPS connection is good.

That "provided the HTTPS connection is good" is a fairly significant caveat, though.

HTTPS works on a certificate signing basis. Your computer will have a relatively small number of root Certificate Authorities that are trusted to verify that a given site is owned by who it says it is. That means that when your computer gets a certificate saying it's for Google Drive, it can be confident it really is from Google Drive, and nobody but the Google Drive servers can decrypt the packets and recover your data.

Your company could intercept your traffic and replace Google's certificate with theirs. They'd then decrypt your data, do what they want with it, then re-encrypt it with the genuine Google certificate. Provided your laptop is secure, you'd normally get a warning about an unexpected signing authority or certificate pinning or similar if this were happening. However on your work desktop, since it's not your computer, it would be entirely possible for your network admins to set it up to trust their own Certificate Authority, at which point it would be more-or-less indistinguishable from the genuine Google certificate, at least without paying very close attention.

Unless your company is very security paranoid, I think that's unlikely. But at the point at which you're worried about them intercepting your traffic and decrypting it, you should probably be aware that that's a method they could use to do so.


It's a good idea to want to approach this problem with automation. The OWASP list itself, however, is not a list of vulnerabilities, where a vulnerability is a known bad version of publicly-released software or known bad configuration that can be scanned for, identified and rectified.

Instead, it is a list of what OWASP calls risks, which are classes of security failures that have led to compromise and loss. In other words, each OWASP item is a higher level abstraction, not an individual, identifiable vulnerability.

Also, many of the vulnerabilities that can be classified under one or another OWASP risk are themselves abstract, and not necessarily easy to scan for.

For instance, there are code patterns that are recommended to help prevent SQL Injection (one class of vulnerability under the Injection risk, the #1 risk now for many years)- like, use prepared statements. However, not all application code that does not use prepared statements is vulnerable to SQL Injection.

From an automation perspective, source code scanning tools known as "static analyzers" specialize in finding suboptimal code patterns- suboptimal both from a security perspective and also from an idiom/tech debt perspective. In my experience, they require an enormous configuration investment and still often only yield barely usable results.

Standing up automation for application security scanning as a whole is not a solved problem, depending only on the availability of machine readable resources. We are still in the banging-stones-together-to-haphazardly-make-fire stage of application security.

Perhaps the most automatable risk is risk #9, using components with known vulnerabilities. Every language platform now has tooling to check versions of libraries in use in a particular codebase against a list of libraries flagged for having known vulnerabilities. Which is great.

However- enormous respect to the overworked folks who without reward or fame toil in these areas- these latter lists are not exhaustive, comprehensive, or definitive. That a particular library doesn't have a vulnerability associated with it doesn't mean one doesn't exist. It more often means vulnerabilities exist but they just haven't been a) found or b) reported.

Overall it's a pretty poor state of affairs, and again, that particular risk is probably where current state of automation is strongest.

To close on a hopeful note, there are a number of promising projects. One that I keep my eyes on is Google's Grafeas:

https://grafeas.io

Its goal is to support the promulgation of machine readable metadata artifacts, from which an application security pipeline can be constructed. It is not close to production ready, but is progressing.


This is intended behaviour! Your exploit is being thwarted by an exploit mitigation technique called address space layout randomisation (ASLR). The address at which the target executable is being loaded at is randomised at every launch in order to make it harder to exploit vulnerabilities.
When you debug a program with gdb, it disables ASLR on the target process by default in order to make debugging easier. You can turn this behaviour off with the set disable-randomization off command.
Many years ago the standard approach to exploiting this kind of stack buffer overflow vulnerability was to inject instructions into memory (usually the stack) and jump to that memory. Modern systems have a feature called no-execute (NX) - also referred to as Data Execution Prevention (DEP) in Windows - that prevents the CPU from being able to execute code in memory pages that are not explicitly marked as executable. This prevents you from just putting an executable payload into the stack and jumping to it.
In order to get around NX, folks instead started abusing existing executable code in the program. This is what you're doing here - jumping to existing instructions in order to modify the behaviour of the program, instead of trying to provide your own instructions. This is often referred to as ret2libc because a common approach with this technique is to cause the program to set up the stack and jump to a libc function such as system() in order to execute arbitrary commands, or mprotect() in order to mark some memory you control as executable in order to defeat NX and execute arbitrary instructions.
A more general form of this attack is known as return-oriented programming, in which gadgets - small chunks of code from the application code that are followed by a ret instruction - are chained together through stack manipulation in order to make a libc call.
With both NX and ASLR enabled, ret2libc attacks are much harder to pull off. You can't load your own instructions into the stack because of NX, and you don't know the memory addresses of instructions that you can abuse because of ASLR. Defeating both of these protections can be tricky. Usually you need to discover the address of some executable data in the program first. This might be possible if one of the libraries that is loaded is not marked as position-independent (PIE), and therefore is always at the same address. Alternatively, you might try to find a pointer leak in the target application that allows you to discover the address at which the program was loaded in memory.


how to use hash passwords to retrieve keys from keystore or access database

You don't.  The entire point of hashing is to render the original difficult (hopefully very difficult) or impossible to recover.  Hashing is used for storing credentials that will be checked by a server.  The server gets the password in plain-text (over an encrypted connection) and then hashes it to see if it matches the hashed password it has on record for the user, this way, if the server is compromised, the entire database of passwords is not immediately available to the attacker.

Things like DB passwords and passwords to access other services would have to actually be stored encrypted, but unhashed.  Alternately and preferably, services could be asked for an authorization token (such as how oAuth or many other APIs work) that would allow for a particular client to access for that account, but not allow general access to the account.


Is sending personal information over email between different providers secure?

Mail servers generally encrypt traffic between themselves. Gmail will actually warn you (albeit quietly) when you are sending mail to a server that doesn't support in-transit encryption. Here's what that looks like:

Note the little red lock icon on the right. If you mouse over it, you will be offered a link to this Google Support page, where you can learn more.

To answer your questions individually:

Google and Microsoft (and thus anyone who has a bug on their servers) can read your email. Their policies prevent any human actor from actually doing so, though their advertising bots will automatically read it. They could also be instructed to turn it over to law enforcement.
Yes, email data is encrypted when at rest, at least on Gmail and Hotmail servers.
It will be encrypted in transit between Gmail and Hotmail servers. So any snooping network switches between them will only see encrypted data.
Google's Policy. Microsoft Policy. There are many industry standards; I recommend starting by looking at the ISO 27000 series. The ISO 27017 and 27018 are specifically about cloud security and privacy (respectively).


Frequent flyer number security risk or not?

On United States legal fields and privacy laws, PII (Personally Identifiable Information) should be protected and should not be disclosed. PII is any information used to identify a person and your frequent flyer number is unique to tag you.

In this ground, yes exposing your PII is a security concern (If this is visible in public).


There's a good paper published named Bachelor thesis:The Effects of Different Bayesian Poison Methods on the Quality of the Bayesian Spam Filter ‘SpamBayes’ by Martijn Sprengers.

I'll try to make TL;DR:

Bayesian spamfilters try to decide if an email is spam or not by looking at keywords in an email. What it  does is review the words present in normal and spam email and update the scores for each word. These scores are used to deduce if an email is spam or not by making a score based on the overal score of words present in the email.

Words are re-scored, meaning that if "Viagra" appears in several normal emails, it will get a lower score over time. This is abused by spammers by generating  email with several low scoring words, commonly found in legitimate emails and adding a single bad word. Because the score of the email will overall be considered good "Viagra" will get a lower score over time making it a legitimate word, and causing spam email to pass through spam filters.

There are three attacks the paper discusses:

  Random Words: This attack method is based on the research by Gregory et
  al. [6]. It can be seen as a weak statistical attack, because it uses
  purely randomized data to add to the spam e-mails.

  Common Words: This attack method is based on the research by Stern et al. [7]. They added common English words to spam e-mails in order
  to confuse the spam filter. This attack can be seen as stronger
  statistical attack than the Random Words method, because the data used
  is less random and it contains words that are more likely to be in
  e-mails than the words added with the previous attack.

  Ham Phrases: This attack is developed in this research and tested against the other two. It is based on a huge collection of ham
  e-mails. From that collection, only the ham e-mails with the lowest
  combined probability are used as poison. The ham e-mail is then added
  at the end of the original spam e-mail. Most people read downwards, so
  the effectiveness of the message is maintained. This is also a strong
  statistical attack, maybe even stronger than the Common Words attack,
  because the words are even less randomized.

Highlights from the paper's conclusion:

  From a spammer’s point of view, the ‘HamPhrases’ technique seems to work best.  It does decrease the performance of the spam filter. … The ‘Random’ and ‘Common Words’ techniques seem to score worse from a spammers point of view. … When we train the spam filter on those poison methods, the performance gets even better than normal. …

  However, the HamPhrases method used in this research is a little bit cheating. This is because both ham and spam e-mails that the spam filter uses for testing and training are available for the algorithm. Real spammers do not have the ham e-mails of real users.


What are the Pros and Cons of allowing users to stay logged in to a web application?

I'm working with cookies in PHP for a login script and my friend thinks storing a hashed password in a cookie is bad news.

Your friend is absolutely correct, there is no reason to do this. It's not a matter of staying logged in, it's a matter of needlessly exposing the password hash (side note: please use PHP's password_hash function for hashing passwords).

While exposing the password hash over an encrypted connection (you are using HTTPS aren't you?) isn't the end of the world, the real problem is that it indicates to me that you're probably authenticating sessions by comparing the cookie's value against the stored hash. This means you have no way to invalidate session cookies, if the password hash is ever exposed, that's all an attacker needs to access someone's account!

Use PHP's built-in session management, which uses a sufficiently long random value to keep track of users (at least in recent versions, old versions have had problems with this).

To answer your original question of how long sessions should last, it varies wildly. My desktop is indefinitely logged into my Gmail account, but most bank sites expire sessions after 15-30 minutes of inactivity. For a site that doesn't have anything too important, long lasting sessions are fine, though it's good to allow users to see existing sessions on their account and expire them manually.


I'm an enterprise penetration tester for my company, and breaking into systems is what I do day in and day out.  I'll share some of the techniques I use to perform man-in-the-middle attacks, to give you an idea of what to look for (as well as how to defend).  If none of these scenarios sounds like something you encountered, then there's a significant majority chance that your encrypted communication wasn't compromised.

HTTPS is only as secure as the dependencies it was built on.  In typical circumstances, HTTPS does its job just fine.  However, when one of the foundational requirements isn't met, it is vulnerable.  Breaking just one of the links in the chain can compromise the communication believed to be encrypted.

Attack using tools such as BEAST, CRIME, and/or BREACH tell us that knowing some plain text in the message being protected allow the encrypted tunnel to be reversed/broken.

Attacks involving the Heartbleed vulnerability are another example of a flaw in the SSL protocol that allows attackers to retrieve data which should have been encrypted.

Attacks using a rogue wireless access point and a tool like SSLStrip show us that just because we typed "HTTPS" doesn't mean it'll be there the next time we look.  This is a very simple to implement attack scenario which returns a significantly high degree of success (I typically see ~90% success rate from the penetration tests I'm asked to perform).

Yet another way would be for a hacker (read: not a law-abiding penetration tester) to break into a certificate authority and generate working certificates for sites they wish to intercept communications for.  A hacker a few years back who called himself "Comodohacker" compromised multiple certificate authorities, which are the businesses/organizations which issue SSL certificates for the websites we connect to via HTTPS.

Finally, a simple but incredibly effective attack would be to generate a self-signed cert.  The cert will "technically" good, but the CA will be untrusted.  From a computer user's perspective, all you will see is a message saying that the Cert is good and the CA is unknown, with a yes/no box asking "Do you want to proceed?".  In an attack scenario, after the user clicks yes, they would see that the communication channel is HTTPS, but won't know that they are connected to a rogue internet proxy that's intercepting and decrypting traffic.   (Note:: This technique commonly used for legitimate purposes as well, such as a corporate SSL proxy scanning all outbound communication for company IP and trade secrets.  The difference there is that the org will typically add the signing authority to a list of trusted authorities on the company owned computers to prevent the message box from popping up.)

Of the scenarios above, the CA compromise is the worst one in this list due to it being undetectable directly.  For that reason, and also since it's not very common anyway, I don't worry about it.  The others are what need to be looked out for.

BEAST and successors are now client side attacks.  Most of the vulnerabilities they exploit can be mitigated by keeping your operating system, internet browser, and other software up to date.  This has to be done on a regular basis.

The Heartbleed vulnerability was more than just client side.  Servers deployments of OpenSSL  on every popular website were equally as vulnerable.  If you're patching regularly, I also wouldn't worry too much about this one.  Most successful attacks against this vulnerability were made against servers owned by websites (i.e. nothing we can do but change passwords).

The last scenario (the self-signed cert) is typically the most dangerous threat to look out for on this list.  While there are legitimate uses for the technique itself, I personally do not care.  I never click yes when asked to trust an unknown certificate authority, and I'd recommend anyone else do the same.

One side note in case it's relevant - I personally wouldn't use the Safari internet browser.  Apple finally patched their browser in November of last year for the BEAST exploits, but it took them more than 2 years after the BEAST exploits were released to do so.  Even though Safari is patched currently, I'm concerned about their lackadaisical approach to IT Security.


Choosing the right X.509 certificate infrastructure for securing LAN communications between a PC and a device

It's rather hard to give a sensible answer without knowing what you are trying to acheive.

Using self-signed certificates you'll get secure point to point communications, but there is no intrinsic authentication - I can walk into your office with a laptop using my own certificate and start connecting to your services. OTOH if you run your own certificate authority, then you have the ability to restrict communications based on the issuer of the certificate (in this case your CA). The common name is just a convention used as an assertion of identity (it doesn't have to be a fqdn) which is certified by the CA.

  However, I don't have a domain name because all of the computers and devices will get dynamical IP addresses inside the LAN

Nonsense:

1) what you don't have is an entry in the public DNS to identify your network - there's nothing to stop you calling your network anything you like - but you may experience problems connecting to the other google.com if you call your network that.

2) DHCP does not preclude using using static IP addresses for some hosts

3) DHCP does not preclude having a consistent hostname with varying IP addresses.

  I want that only users in posession of the certificate

Then why are we talking about FQDNs and IP addresses? These are properties assigned to machines not to people.

I think you've still got a long journey ahead of you before you are asking the right questions.


Open source firewall with multi wan support

pfSense - http://www.pfsense.org - and Untangle - http://www.untangle.org both support multi-WAN configurations.  Smoothwall and m0n0wall may do so as well, but I don't have experience with them.


Is it possible to detect the type of key required when connecting to a wireless network?

Yes. Pretty straight forward information provided by each wireless access point.

For instance in Android, this is what this information looks like in Wifi Analyzer:

Only the security types listed for an access point will be accepted.


Why should the value of the cookie be encrypted?

Well, I guess if the information is secret it could be to protect the data "at rest". This could be against legit users of the PC, or against persons getting a copy of the PC.

Generally though the cookies should be protected against change (integrity), rather than offering confidentiality. This can however be performed by placing a MAC value over the cookie rather than encrypting it.

Sometimes people are encrypting a magic value (crib) instead of placing a MAC, so this could be a case of performing DIY cryptography.


Where to find the security hardened docker images

I would consider the Center For Internet Security (CIS) Benchmarks the current gold standard for hardening.
I'd caution against a pre-hardened image and instead recommend that you harden it yourself using an open source script that can be reviewed/approved to ensure you are not introducing malicious/purposeful flaws into your environment.

CIS Benchmarks for Docker can be found here.

An open source hardening example (there are many out there) can be found here.

Docker then offers the following script to check that the changes have been made successfully.


Secure way to save connectionString in .NET?

If you have different users connecting to the same database directly the only way to make it secure is to allocate each user a different database account (/password) with rights only to access their data - although this is easier said than done while maintaining a sane database layout.

If each user uses the same connection string then this means that anyone can pull the connection string out of the application and run queries directly against the database. Any kind of encryption is useless - if the app can access it at run time it needs the key. Which means anyone with access to the application files can get the key too.

An alternative would be to proxy the connection through a service which users must authenticate against (usually with a username and password). You can have them store their username/password into the application so they don't need to provide it on every launch or even store a cookie / auth token once successfully authenticated. Normally these days that would be an HTTPS based REST service. The client application sends the request to the service. This verifies the user is allowed to perform that request and handles it returning the information. This comes with the added benefit that the database can be firewalled off.


How are assets assessed for criticality?

If using the security triad of confidentiality, integrity and
  availability, are these the only factors that define criticality?

While the CIA triad is important to us as security professionals when defining various criteria, the business often defines severity levels based on $$$.

They ask questions (from a business perspective) such as:

What infrastructure / applications do we need in place to accept money
from customers? (think POS systems)
What infrastructure / applications do we need in place to move money? (think wire/ACH systems)
How much money do we lose per day if XYZ application is not available?
Are there operations / processes that can be completed manually (paper, pen) until the systems are back online?

  How does one calculate the cost of the associated risks? For example,
  if the business deems a given set of assets as high across the entire
  triad, how does one determine the impact, costs and risks?

This is where your quantitative and / or qualitative analysis comes into play from a risk perspective.

Below are a few good links that cover the formula in detail:

http://www.pearsonitcertification.com/articles/article.aspx?p=418007&seqNum=4

http://www.sans.edu/research/leadership-laboratory/article/risk-assessment


Ask your security officer, or your contact/security officer at the NSA (the originator).

(When it comes to handling of classified or FOUO material, you probably should not be following security advice from the Internet anyway...)

Apparently, FOUO often means that it contains personally identifying information that should not be made public.
A cynical part of me says that FOUO also seems to be used where disclosure of the information to the public could be embarrassing to some government employee.
Either way, FOUO means that the information isn't very sensitive.  (If disclosure actually posed a danger to national security, it would be classified Secret or higher, not marked FOUO.  The primary purpose of FOUO is to make sure the public doesn't read about it in the newspapers.)  Regardless, breaching confidential information or embarrassing a powerful government employee can be a career-limiting move.  So, your primary concern should be to your own job security.  Think about this from a CYA perspective: what do you need to do, to make sure you won't be blamed if the information gets leaked?

The standard way to CYA is to make it someone else's decision.  Find someone else who is responsible for making these decisions, ask them what they want done, document what they told you, and then do what they told you, whatever it is.  That way, you can't be blamed: you were just following instructions, it's someone else's fault.


Router Receiving Unknown Packets from the Same IP and Port Even After Address Rotations - How?

How much of the public IP is changing upon the DHCP renew? How quickly before you see the packets upon getting a new IP?

This is unlikely a targeted attack and more likely a shotgun-approach scanner bound to scanning a large subnet. It only takes a few minutes to scan an entire class B with SYNs.

The IP in question has been reported by several as an abusive IP already:
https://www.abuseipdb.com/check/45.227.254.22


Is this setup truly insecure as mentioned by other IT companies and what are best practices for securing such a setup?

The quality of both open source and commercial solutions differ widely. There are commercial firewalls which more or less do what pfSense does and there are firewalls which do a lot more. From what you mention as security features of your firewall the only one is actually "ClamAV", neither a squid proxy nor a radius authentication are security features by themselves: it does not matter if the authentication uses radius if the passwords are weak and it does not matter if you use squid if it allows unlimited access to all websites.

ClamAV is definitely a weak option compared to many commercial AV. Commercial solutions for example are often backed by cloud services which allow dynamic code analysis for suspicious files and thus can react faster to new threats. But commercial AV don't provide 100% security either. Relying for security only on an AV in a perimeter firewall is a bad idea from start.

A secure setup would not just put some firewall at the perimeter and then forget about it. For a secure setup one would first analyze the actual risks and threats and then decide how these can be mitigated best using the time and money available. This usually does not only involve using firewalls but also endpoint security and maybe segmenting the local network further. In some cases free firewalls are sufficient, in other cases commercial firewalls are better since they often allow a more granular addressing of the risks, more visibility into what's going on and have a faster reaction to new threats. But again, the actual advantage depends on which firewall is used since the quality, capabilities (and price) vary a lot.

  This firewall has handled security very well and load balancing/traffic shaping without any drop-outs.

What you address here is mainly availability and performance and not actual security. From this statement it is not really clear what your installation does better in terms of security than a simple network cable - which is even cheaper.

  Are large security companies truly afraid of such solutions rendering their products obsolete, looking at the most used servers and firewall operating systems world wide Linux is used over commercial offerings like Microsoft?

Not really. Commercial companies today use open software a lot themselves. For example Microsoft is actually a very large user of Linux itself and not only in Azure. Open source software is also often used in commercial firewalls and security companies also contribute to open source themselves.

Also, open source does not magically address all the needs: while one can use Linux to build a firewall (and many commercial firewalls are based on Linux) it takes lots of time and lots of specialized knowledge to create and maintain a solution which does more then just filling basic needs.

  Yet these same companies that made such claims have been attacked with viruses such as WannaCry, while our infrastructure was maintained without incident.

Such Anecdotal evidence is pretty useless for comparing security solutions. It comes down to picking the aspects which support your claims and ignoring the others. See also Cherry picking and Confirmation bias.


How SSL server can select cipher suite from Client proposed parameter?

The server checks which ciphers are offered by the client and are also supported by the server. From this it then select the final cipher. If this choice is more based on the clients preference (order of ciphers in the ClientHello) or on the servers preference depends on the server configuration, e.g. the ssl_prefer_server_ciphers setting in nginx or similar settings in other servers.


Is changing default admin URLs an effective security measure?

It will unquestionably protect you from automated attacks that rely on the location of the wp-admin directory as part of their programming, which is not insignificant, since automated attacks make up the vast majority of wordpress compromises. You may call it security through obscurity, but you're not actually replacing any of your security apparatus with obscurity, you're augmeting it. So a better term would be defense in depth.

Note that a far better strategy is to require HTTP Authentication to access the wp-admin directory. Just plunk an .htaccess file and .htpasswd file in there and you're done. This is widely regarded and recommended as a good idea. That way not only do you have to log in to wordpress to use the admin features, but you also have to provide a password to the server just to allow it to show any content from that directory. That protects you against all sorts of authentication-bypass vulnerabilities if they ever crop up.

See the rest of the Hardening Wordpress documentation for more similar "good ideas".


Malware Threat Hunting in Airport Systems - KPIs/Metrics to Track

You can't really know whether an attack is imminent. All you can do is try to identify what the security posture of the systems is, and what resources, processes, and procedures you have in place in order to identify and respond to security incidents that affect those systems.

If you really need to boil it down to KPIs, here's what I would try to quantify for each of the devices/systems in question:

How long has it been since this system received updates/patches?
When was this system last covered by a penetration test?
Does the system have any known issues that are documented in your risk register? How many? Of what severity / CVSS scores?
When was the last network security architecture review that covered the network segment(s) that the system is connected to?
Is this system in your asset management database and is the information up to date, including contact information about key stakeholders and maintainers?
Do you know where this device physically is? Do you know what the physical access controls are for that location? Can you easily identify who has access to, and who has recently accessed, that area?
Do you have a documented threat model that encompasses this system?
Do you have visibility of this system within your SIEM? If you make changes to a critical system without the proper procedures, does your SOC notice?
Do you have specific guidance relating to this system within a security incident response playbook? If that system were to be hit by ransomware, for example, do you have a predefined set of steps to follow in order to handle that incident? Can you recover?
Are there any regulatory requirements relating to this system? Are they being properly considered as part of your security testing process?
Could a breach of this system lead to a safety hazard? If so, what compensating measures do you have to help minimise the risk and impact?

And more generally as an organisation:

When did you last test the responsiveness of your security monitoring and security team? e.g. with a red team exercise.
Do you have a plan in place for the eventuality of several of your infosec team being unavailable (e.g. due to illness) during a security incident? Are others trained to use your security incident response playbooks? Do they have the necessary access to perform the steps within them?
When was the last time you had a comprehensive review of all of your security documentation?
Do you train your staff on how to handle phishing attacks? Do you send phishing emails to test them?

The more of these you can answer in a positive manner, the better. But don't just answer off the cuff based on your own personal memory of your organisation's security activities. Check that the documents you think exist, do exist, are up-to-date, and are known about by your staff. Verify that the procedures work as you expect them to. Run mock incident exercises. Where you have answered no to a question, or where you find deficiencies as part of your review, ensure that you put together a list of things that need further attention.

Finally, the key part: you can't just do this once. You need to go through and do this annually, at least.