Is it compulsory to have https on e-commerce site?

If you don't use HTTPS, but plain HTTP, then:

You will get hacked; credit card numbers will be stolen while in transit, and customers will sue you into oblivion.
You would be hacked anyway at some point, that's the lot of Web sites. Even if the hacker entered by some other way, post-mortem analysis will show the lack of SSL, and this will look real bad.
You will lose customers. Many potential customers won't enter their credit card number, for lack of the reassuring padlock picture; they will instead shop at a competitor's Web site.

So you are not mandated by Law to use HTTPS, but if you do not, your business will fail. Open business competition is quite akin to Darwinian selection: the weak dies.

Edit: @XzKto's comment shows that I have not been completely clear: the SSL bit is needed for the actual transaction, when banking values (e.g. credit card numbers) travel over the Internet. That's the one I am talking about. If the site records payment details (so that you can come back and buy again without reentering the credit card number), then the "buy it now" button must also be SSL-protected (to avoid an attacker "clicking" on it in your name). The rest of the site needs not necessarily be SSL-protected, although site-wide SSL is still often a good idea (it is much simpler than trying to work out which parts of the site must be protected, and which parts can be left out).


Penetration testing against an ignorant target - Is it legal?

Since we are not, and do not aim to provide, legal advice (since we're not lawyers) this is a really hard one to talk about. That being said, it is generally considered a good idea to obtain written permission from the organization, signed by someone within the organization who is authorized to sign such things, permitting you to perform any kind of scan or penetration test. Without that authorization there is a very fine line between "I was checking to see if the fix had been made without malicious intent" and "I was checking to see if the fix had been made with malicious intent".

Within Canada the most likely relevant portions are going to be Section 184 and Section 342 of the Criminal Code of Canada. I won't attempt to interpret the contents, since quite frankly I'm scared of the potential of accidentally giving legal advice.

The short of the matter is that whether or not the kid was criminally liable for what he did he was, in my opinion, a fool for not obtaining permission before conducting a vulnerability assessment/penetration test.


Setting the HTTP header X-Frame-Options DENY for static assets

So after the little conversation for clarity in the comments on the opening question and finding out a bit more(like that you aren't allowing uploads to your server), then the answer is a simple No, it should not harm it. In fact in the simple case that a malicious person does get code onto your server some way, this could help it, however in that case I think you have a much larger problem to worry about.

Really it comes down to more of a question of "Do I want someone else having access to my static assets inside of a frame?", in which case the answer is usually a no.


What happens if my signing subkeys are compromised?

Lets assume that we're talking about PGP/GPG keys, and you've uploaded your public key for signing to one of the main PGP/GPG key servers.

If you're curious how to revoke a certificate, here's a Guide to Revoking PGP/GPG Certificates.

With those assumptions in mind:

  Will all things I have signed in the past with those subkeys be
  considered "invalid"?

Yes.  As long as the software is checking certificates for revocation anything signed in the past will be considered signed with a revoked certificate.  It does not stop anyone from viewing a document, or reading an email.  It's now at the user's discretion to trust the information or not.

  Will the person who stole my keys be able to sign whatever he wants,
  assuming the person doing the validating hasn't updated their keyring
  in a while and doesn't know that the old signing keypair has been
  revoked?

If the attacker has your private key then they can sign data as if it were from you.   Once the certificate is marked as revoked in the keyserver anything the attacker signs will also come up as signed by a revoked certificate.  Again, it's up to the user to verify the data, and decide to trust it or not.

  Are there other dangers resulting from compromised signing keys that I
  need to be aware of?

Signing keys can be used for user identification/verification.  Let's say your company uses your signing keys to identify you on their network, and provide you with privileged access.  Compromised certificates that aren't revoked can now get into your company's network, and gain access as you.

All of this is contingent on the software used for verification actually checking if a certificate is revoked, and using a keyserver.  There are various opinions of this one way or the other.

Adam Langley has written an interesting article on revocation checking.


It's not verifiable.

At least, without putting in effort to reverse-engineer the software.

As it turns out, "How trustworthy is [this software]?" is in general an incredibly tough question to answer. The problem is that it's hard to verify, especially if no source-code is present. Even if source code were present, how can you know that the pre-built version would correspond to that source code?

In the "best case" scenario, the program is benign and does what it's supposed to do (which is still illegal and may get you into trouble).

In the most likely case, the program will do what it's advertised to do, plus a number of other things. Which things? That depends on the author.

Consider the following: Would you let a random stranger have admin access to your computer if they gave you 139 USD for it?


Decrypting arbitrary offset of encrypted file

If you can require that the ranges are block-aligned, the disk encryption modes (LRW, XEX, XTS, CTR, etc.) seem ideal for your purposes.  ECB mode also works with block-aligned ranges, but is, well, ECB mode.

If you need byte-level alignment, the only mode that looks promising is OFB mode: you compute a keystream that includes the range you want to decrypt, then XOR the appropriate section of the keystream with the encrypted section of the file.  For a large file, this can be rather inefficient, as you may be computing and discarding gigabytes of keystream before you get to the part you're going to use.


How can I detect unencrypted self-executing code in JPEG images?

This is the easy case for anti-virus software.

However, do not suppose that a malware has to be unencrypted to be executable. Polymorphic code brings self-decryption to malwares, it can be helped by Metamorphism to ensure that even the very start of the decryption routine, since there must be indeed a unencrypted starting point, does not present any recognizable constant pattern.

It is trying to fight such kind of methods which make anti-virus software to be complex programs.


Is SQL Injection possible in this PHP registration script?

You're using the wrong approach to prevent SQL injection. Sanitizing inputs can help provide security, but by far the best way to avoid SQL injection is to remove the thing that allowed it in the first place: mixing code and (user-supplied) data in the same string, such that the database doesn't know what was supposed to be code and what was supposed to be data.

There is no need to do this in SQL anymore, and you want to look into prepared statements. The way those work is that you first send the database everything but the actual data; the database compiles the query, and only then do you supply the actual data of the query. What this means is that the user-supplied data is placed by the server into specific slots in the query, and cannot change what the server is doing.

To be more explicit, you send the server something like SELECT username FROM accounts WHERE username = ?. The server processes this query (the titular prepared), turning it into a function that's just waiting for a value for the username. You then bind the specific username to the statement, and execute it. The key is that the server already knows exactly what it should do before it ever sees user data; nothing a malicious user sends can change what the database is going to do (i.e. find rows with the given username and return their username).

Sanitization of database inputs is fundamentally an attempt to mitigate an attack vector by blocking inputs that exploit it. Prepared statements actually remove this attack vector, because they eliminate the conditions that allowed it to exist.

Details of how to use prepared statements vary by language, framework, and database server; look up PHP/MySQL documentation for the actual details.


Hide Database Secret in offline Java application without user credentials

Do your users have admin rights on their respective desktop machines? If yes, there's no way you can hide the password from a motivated user for long. Methods like obfuscation and so on may help preventing a curious but lazy user from discovering your secrets, without any guarantee though.

If no, allow your users to run the application but forbid debugging it and reading the secrets file. How exactly do you do that depends on what OS is used in your organization.

Note that this also requires you to install all the security updates on users' machines as soon as it's possible, as elevation of privilege is among the most frequent consequences of vulnerabilities out there.


How do I make or get computer certificates to use with IPSEC user authentication on Windows?

In terms of making the certificates and requiring the server to use certificate authentication, have a look at this resource: http://support.microsoft.com/kb/814394

In order to get the certificates, the following is a handy way to do it over HTTPS so you won't need to get into reconfiguring firewall rulesets to permit:
https://blogs.technet.com/b/askds/archive/2010/02/01/certificate-enrollment-web-services.aspx?Redirected=true


How do I decrypt a .dmg image if I know details about the password?

The answer/thread you linked to stated (regarding the brute force tool):

  Practically, this will bring you absolutely nowhere, unless the .dmg was encrypted with an extremely naive password (like 'admin' or '1234').

Unfortunately, based on your description of the passwords:

  I don't know the first 38 characters but I do know what they might be (a-z, A-Z, / and )

it appears that you are not in the situation where the password is naive or trivial.

Rather, you are going to have to try to brute force

(26+26+2)**38 = 677583580243194174785518969776514402284639204793077421485626228736

different possible 38 character prefix combinations.

Even if you were using millions of state-of-the-art processors to perform the brute force attack, it would still take longer than the lifetime of the universe... So, the linked-to brute force attack will not work for you.

Update:

The OP has updated the question with much more information about the 38 character prefixes. The additional information greatly increases our knowledge of the potential passwords. In particular:

  The 38 unknown characters are words.. .All words begin with a capital letter followed by only lowercase... Minimum length of the words is 3 characters and maximum length is 8. The password only has four possible starts... The password only has two possible ends

OP goes on to state:

  This leaves brute forcing either 21 or 20 characters depending on the possible start

The OP's above statement above brute forcing up to 21 characters is (happily) not correct assuming the OP's previous statement "The 38 unknown characters are words" is true.

It is much more difficult to brute force 20 or 21 characters than to brute force sets of words that add up to 20 to 21 characters.

The key point here is the words are not just random strings of characters and this fact greatly decreases the "entropy" of the passwords.

In order to take advantage of this fact we need a word list of potential words OP would have used to construct the passwords. Luckily these word lists exist. If we know that OP would have only used very common words we can probably get away with a list of a few thousand words (maybe less). But, if OP might have used more obscure words, the list will probably be a few tens of thousands of words long.

The fact that the first letter of each words is capital and the rest are lowercase does not increase the entropy at all, since there is no choice being made.

To estimate the entropy and the difficulty of brute-forcing, let's assume that the words were selected from a list of 10000 words. And let's further assume the average length of unknown word is (3+8)/2 = 5.5 characters.

Thus, contributing factors to the entropy are:

Four (4) possible starts
Two (2) possible ends
Approximately (10000)**3.23 = 8,317,637,711,027 possible infixes
Approximately (2)**3.23 way to choose "/" or "\" to divide the infix words

In step three, I have assumed there are approximately n=3.23 "words" on average in the password infix. This number came from the fact that if there are "n" words in the infix then there are also "n" "\" (or "/") characters and thus (assuming 21 characters rather than 20):

n = 21/(<len(w)> + 1) = 21/(5.5 + 1)

The details of the above-described approximation don't really matter much, but it's useful to try and get an order-of-magnitude approximation. In practice, what one would probably do is write a sub-routine to construct the infix by iterating through all the words in the word list multiple times and concatenating words and "/" or "\" until the infix is 20 or 21 characters and then break/return.

So, in all, the total number of combinations is approximately:

624,333,836,962,635

Which is still a large number of potential passwords, but much more manageable than before.

In order to construct a program that brute-forces theses passwords one must "simply" (in practice it will take a bit of work) construct a program that iterates through the four types of choices stated above to choose concrete realizations of the passwords that conform to the conditions.

Assuming you can try something like 100000 passwords a second, this method will still take about 200 years, but it is a great improvement over the previous method.

The greatest contribution to the number of passwords comes from the assumption that the word list is 10000 words long. If there is any way to further reduce this based on your prior knowledge then you made be able to brute force these passwords in a reasonable amount of time. For example, basic english words lists are only about 800 words long. If we can assume basic english instead of 10000 word english then the number of combinations is only:

178,812,358,291

Which you might potentially brute force in a few hundred hours if you can try 100000 passwords a second.

Per the comments:

The total amount of cracking time clearly depends on the number of attempts you can make in a given amount of time.

I have assumed, based on not much else than the desire to put down some concrete numbers as examples, that in the OP's latter case the number of attempts per second is 100000.

If the number of attempts OP can make is different from this, then the total cracking time will scale accordingly. The scaling of total time with number of attempts per second is linearly with the inverse of attempt time. For example:

total_time_in_days =  number_of_combinations/number_of_attempts_per_second/60/60/24


What information to provide for an overseas bank transfer?

Yes it is safe, although this information qualify as personal identifiable information (PII), yet they are needed for transaction, as long as the person doesn't ask for information that are needed for authorization such as PIN, Credit CARD CVV/CVC etc. you are fine.

As usual ensure due diligence when sharing your information


Are there technical reasons why state actors may be more able of carrying out malware cyberattacks against critical infrastructure, than individuals?

The main question you probably need to ask is who has the motivation to do such an attack. While in former times it was often enough to brag about the attacks you did and show what a capable hacker you are, cyber attacks are now predominantly seen as crime. This means that bragging about it might even be dangerous and there must be other motivations. Thus the main motivations today are money in the direct form (i.e. ransomware, spam), getting access to important information (espionage) or causing damage against a competing individual, company or country (for example with DOS attacks).

Given that cyber attacks are seen as crime the return of investment should be much higher than the risk of getting prosecuted. If you are a lone individual mounting a larger attack then the risk of being prosecuted is high. If you are instead somehow backed by one state and attack another state then the risk of being prosecuted is usually  much lower since you cause damage to competitors in the interest of "your" state. Such state-backing might take several forms: it might be that the attacker is actually employed or otherwise paid by the state for doing such attacks (i.e. state-sponsored) but it might also be a criminal or group of criminals who gets not prosecuted as long as their attacks are only directed at the competing state (state-backed). Or it might be something in between, i.e. criminals getting paid for doing a job for the state.

Many (but not all) of the attacks you see today could actually have been done by motivated individuals or small groups. This includes attacks like NotPetya. But you have to ask what the motivation was. It looks like that in case of NotPetya the main goal was to cause damage and that the main target was Ukraine. So, who might have a large interest in spending resources just to cause damage there? And who might therefore either pay somebody to do such attacks or at least protect the attacker against prosecution? Probably not some lone individuals acting only in their own interest.

Apart from this, some attacks actually require state level resources or at least resources only a larger company has. These are for example access to brilliant cryptographers, power to influence standard bodies or the power to make companies weaken the security of their products (like weakening cryptography or adding backdoors) if they still want to sell to the government etc.


Should I back up automatic strong passwords of iCloud?

I would use a good password manager that encrypts the password database with a strong key, and use cloud to backup the resulting file. This way even if the cloud storage is hacked, your password database is encrypted.

If the cloud storage is offline, nothing is lost, because you use it to backup the database. And you don't need to trust your brain to create and remember complex passwords. Because no matter how complex your password is, if you reuse it and a malicious agent (or malicious service) gets your password, you are toast.

A good password manager solves both problems: creates very strong passwords, unique for each service, encrypts the database and allows for safe cloud backups.


How risky is to use non-free wireless network driver?

A closed binary is harder to audit than something you have source for, so technically you add some risk by doing this.

However, you may already be taking equal or greater risks:

Are you compiling Debian from source yourself or downloading a binary ISO?
Are you auditing the source code yourself or just assuming someone else has done it, like everyone assumed someone was checking the OpenSSL source.
If you're building from source, how do you know the compiler is OK?
As you mention, how do you know someone hasn't tampered with the hardware?
Is your BIOS open source? (I would have linked to that weird farming laptop Stallman used to use but apparently he has a ThinkPad now.)

As always, you must evaluate your threat model and assess the risk for yourself.


Is signature validation mandatory if encrypted assertions are sent over HTTPs in SAML 2.0?

Unless you are using Artifact binding (not very common), signature validation is always required. While the communication with both the SP and the IDP is via HTTPS, the user's web browser is relaying the responses/assertions, so you cannot trust the integrity of those messages. Thus the use of signing.

Encryption, on the other hand, might be a duplication of what HTTPS provides, depending on the structure of how the IDP is generating/receiving those assertion. But keep in mind that decrypting a message does not prove its integrity.

Summary: you might be able to drop the encryption but you cannot drop the signing.


Is server public key and Diffie Hellman public are the same?

CloudFlare explains that Diffie-Hellman and RSA, both used in key exchange mechanisms, have advantages. Keyless SSL: The Nitty Gritty Technical Details
.

The RSA and DH handshakes both have their advantages and disadvantages. The RSA handshake only uses one public key algorithm operation, RSA. A DH handshake with an RSA certificate requires the same RSA operation, but with an additional DH operation. Given that the certificate is RSA, the RSA handshake is faster to compute. Public key algorithms like RSA and DH use a lot of CPU and are the slowest part of the TLS handshake. A laptop can only perform a couple hundred RSA encryptions a second versus around ten million per second of the symmetric cipher AES.
The DH handshake requires two algorithms to run, but the advantage it brings is that it allows key establishment to happen independently of the server’s private key. This gives the connection forward secrecy, a useful property that protects conversations from being decrypted after the fact if the private key is somehow exposed. The DH version of the handshake also opens up the possibility of using non-RSA certificates that can improve performance, including ECDSA keys. Elliptic curves provide the same security with less computational overhead. A DH handshake with and elliptic curve DSA certificate and elliptic curve Diffie-Hellman key agreement can be faster than a one-operation RSA handshake.

I believe Diffie-Hellman and its TLS/SSL usage will further explain.
Presuming the "server's public key" is used for authentication, then no. The DH public key and the server public key, are not the same. However, I have seen very much mixed opinions on this matter. TLS 1.2 appears to use DH and RSA for the key exchange mechanism.
DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network.


Nmap has alternative output formats for exactly this reason. The Normal output (-oN) that you show is for human-readability only, and shouldn't be processed with scripts, since it is subject to undefined change from version to version.

Most fully-featured Nmap output viewers (like Zenmap or ScanHub) use the XML output format (-oX), which is the machine-readable format that contains the full results of the scan, including advanced features like NSE scripts and traceroute. If you intend to use these features or expand your scanning and reporting beyond simple "all hosts with this port" queries, using one of these output viewers or writing your own that uses XML are your best options. There are libraries for parsing Nmap's XML for most common programming languages.

For simple queries like this one, you can also use Nmap's Grepable output format (-oG). This puts all the port scan data for a host on one line along with the IP and hostname like so:

Host: 10.33.131.56 (ap4403.a740)    Ports: 80/open/tcp//http///, 9100/open/tcp//jetdirect///

In this case, you could just grep -v ' 9100/open' to remove those lines.

When scanning, I prefer to use the "all outputs" option (-oA) to save Normal, XML, and Grepable output to the same filename (with .nmap, .xml, and .gnmap extensions, respectively). That way I have all the output formats in case I need to do post-processing or want to quickly do a visual scan through the output.


nmap script "smb-os-discovery.nse" does not output information about the host OS?

Script name doesn't need a full path. Try:
nmap --script=smb-os-discovery.nse 192.168.56.5 -v


Can a biometric device serve as a user based entropy source?

No,

If a device sequenced the user's genome from a skin cell, the results would be the same each time. Assuming the skin cells have replicated without errors.  But it seems what you are asking is impossible, since you have to have a database somewhere that stores the answer to your key.


Senario:SSL Enabled Online Banking Application. Question: Should card numbers be provided back to a user un-masked, when there is a failed login?

PCI-DSS Section 3.3 Obtain and examine written policies and examine
  displays of PAN (for example, on screen, on paper receipts) to verify
  that primary account numbers (PANs) are masked when displaying
  cardholder data, except for those with a legitimate business need to
  see full PAN

If the argument can be made that the user has a business need to see the full PAN, then it would be perfectly fine to display it after a failed login if it was being used as the login credential, though there could be a strong argument that the credit card number shouldn't be the login credential.  SSL will ensure that the end point is the same that made the request, so if they'd be able to see the CC# being provided back, they would have been able to see it going across the wire in the first place.  Note that this assumes that the user entered the CC# and you want to show them what they entered when they enter it incorrectly.

My understanding of section 3.3 is simply that an employee should not be able to see the PAN unless they have a need to.  The user whose PAN it is would have a legitimate business reason to see it as it is there number.  The concern is making sure that the number is not shown to those who shouldn't have access to it.

That said, it sounds like a few things could be done better about the process you are describing even if SSL and PCI-DSS section 3.3 are not directly a problem with the situation described.  You don't want to use a CC# as the username.  This is why most there are account registrations in which the PAN is entered once and from then on, the username is used instead.  This should make it so you never need to display back the CC# used.  Also, if the field was masked going in, it should remain masked.


Allowing users to input a safe subset of HTML

You are in a correct path as you go with whitelisting, but implementing it bullet proof is tricky.

I.e. your  links can be fooled to execute JS by just writing:

xss

Also, especially older browsers may execute JS in img src etc.

I'd recommend you to go with HTMLPurifier, which, besides XSS, also helps you to deal with broken HTML (tag nesting etc.).


Found a bug in a software product used by the pentesting customer; Who to report it to?

For an ethical disclosure, I would create two different reports:

Report it as a general finding to BlueCorp, which would help them to decide whether to stop or interrupt using the product or mitigate the threat otherwise, depending on how severe it is.

Send a more detailed report on the bug, possibly with a proof of concept (POC), to the developers of the software i.e. to SecCorp.

This prevents BlueCorp from using or selling this information before the SecCorp has had time to fix it. After all, it is unlikely BlueCorp would need more detailed information, as they would not fix it by themselves anyway.
Unfortunately, you are only contracted and paid for the first report, but that is a responsible thing to do. Who knows, you might even get another gig from it.


How WEP/WPA authentication works in a WiFi environment?

The 802.1x protocol is built on multiple steps.

The supplicant (entity who wants to connect) identify the Access point by its SSID as it would do for any wireless network. Be noted that 802.1x also work on traditional wired networks. For what we know, this can be any hardware that provides this SSID, it can be changed, maybe spoofed.

When you are connected to the LAN/WAN, you can begin to authenticate. You can do this by negotiating with an authenticator (usually the AP itself, or an Ethernet switch). Until you are correctly authenticated, this authenticator will act as a barrier and deny you all traffic to any destination.

There are many mode of authentication available EAP, Radius and many mode for each. All provide many way to exchange keys and way to ensure confidentiality or not. But basically, until you forwarded the required information to the authenticator and it got a positive authentication validation from the authentication server, the switch will remain blocked.

For what I know, you can use a wide range of tools not to send clear text credentials: server certificates (public key encryption), client certificates etc. It kind of share properties with SSL authentication scheme. If you change AP, you will have to do the authentication again. There are possibilities to activate a Fast-roaming protocol by I do not know enough of it to talk about.


Spoofing `localhost` to connect to a server that only accepts connections from localhost

This concept (typically used as part of an attack) is often called "pivoting", as in "I used the server's request forwarding feature to pivot from the Internet to localhost". There's no way to "spoof" localhost traffic over TCP; TCP requires a valid source IP address to complete the handshake. On UDP, you might manage it if the application was listening on external interfaces but was rejecting any connection that doesn't come from the local host - this is different from only listening on the loopback interface, which is what you would normally do if you only wanted local traffic - but I've never heard of that approach being used, probably because it's a stupid way to configure a server.

There are a number of ways you can pivot a network connection to a local (internal) network, or to localhost (which is essentially an extra-small - one machine only - local network). Let's take a trivial, contrived example: the machine running the local-connections-only server is also running an open proxy server exposed to the Internet. You connect to the proxy, and tell it to connect you to 127.0.0.1 on the desired port. The proxy server sends out that request on your behalf, and connects to the restricted server. The proxy then relays your traffic to the restricted server, and its traffic back to you.

There are a number of less-contrived examples that may work. XML External Entity attacks are probably the most common, and can be used to make various kinds of requests, such as HTTP, HTTPS, FTP, and possibly others, to a host and port of your choice (relative to the vulnerable XML parser, which is usually in a web server, so requesting "localhost" in the XXE would make the web server connect to itself on the specified protocol on port). That won't usually get you interactive traffic, but is good for simple requests and can usually be made as often as desired (this can also be used to port-scan an internal network for certain kinds of servers). Anything that lets an external program have the server make an arbitrary request on the external user's behalf can be abused to send a request to the server's localhost-only services.

Another option that might sometimes be relevant is to use this sort of attack to gain privileges on a host after you have compromised it and gained arbitrary code execution in a low-privilege environment. Imagine, for example, a sandboxed web server. You compromise the server and drop a reverse shell on it, letting you run code within the server's sandbox. You then open a network connection to another service on the same server (but outside the webserver's sandbox) that is listening on localhost but is otherwise unauthenticated. If the sandbox doesn't restrict you from doing this and the target server exposes anything not visible from within the sandbox directly, you've just effectively gained additional privileges.


Does Windscribe VPN keep logs even when disconnected?

Theoretically, any software running on your system could monitor socket activity if given the appropriate privileges.
(It's not exactly clear from your question, as it stands, as to what you want an answer to.)
I'll assume that you're asking whether a free VPN provider that you use is logging network activity of other applications running on the same host, even when it is not functioning as a VPN.
On Android, all (or most) traffic is routed through the VPN software, so when it is installed as a VPN it will see all connection attempts. This is because Android routes all packets through the VPN, up to v10 (? not sure when this changed, please feel free to clarify with edit ?), and since v10 some packets (specifically root) can still flow via the underlying network connection and aren't forced through the VPN. TODO ref.
Other software running under the same context can use host tools such as the /proc/ vfs or ss etal. to poll for open sockets and compile a log of these, viz. NetMonitor. Depending on the default configuration, none, some or all of the sockets you currently have open are visible tovia this interface.
The VPN service provider will often make use of some standard VPN software, such as OpenVPN or WireGuard, but they will also offer a convenience application that will instal and configure everything. Often, you as the user will be able to configure this or at least audit the configuration to ensure that no logging is occurring on your device.
From a logical perspective, you must assume that your free VPN provider is logging as much as possible, because there's no way for you (or any of us) to prove the alternate theory. Repeat after me: "there is no such thing as a free VPN".
So, the question that you need to consider, in answer to your question: how does your VPN provider cover the costs of providing you with a "free" VPN?


Is there a difference between a VTI and a regular VPN tunneling process?

Quick Googling indicates (1,2) that the idea of VTI is to use virtual interfaces to de-attach the routing from the VPN tunnel.

Specifically, IPsec configuration typically requires you to specify the IP networks that you want the IPsec engine to handle. As a result of that handling, the packets are encapsulated and so the routing decision for that packets implicitly changes. So to understand how packets are routed you have to understand the routing table AND the IPsec security policy (SPD).

What Cisco proposes in the above pages is to use another layer of encapulation, GRE(3), to detach routing from the VPN channels. They setup virtual interfaces with GRE that provide a simple IP tunnel. Then they configure IPsec to work only for those configured GRE tunnels(based on their outer IP headers, which you can chose to be small networks(transfer network, /2) with untypical IP addresses.

As a result, you can use the regular (much more flexible) routing tools on these interfaces to determine which traffic should go through the IPsec tunnel.

This can make sense in case you have many VPNs with sometimes changing IPs, or in some very special setups. For example, I recently had the problem to connect two networks with IPsec and also let network A be the Internet gateway for the other network B. That means network B has no dedicated Internet but should have a default route towards network A. It also means that the IPsec policy should apply to all traffic(0.0.0.0/?), which apparently does not work in practice in Linux. So we used GRE tunneling and set the default route towards the virtual interface provided by GRE.

Not new technology but certainly has the potential to ease use and management in some cases..


TaintDroid is a modification of android to provide realtime privacy monitoring.

ProxyDroid forces all communication though a proxy such that it can be intercepted.


The Poodle attack model is one where the attacker triggers the requests (normally with some Javascript in the client -- note that, in that case, requests will be GET, not POST, since that "evil Javascript" will be served as part of an unprotected Web page load from another site, and the same-origin policy will prevent arbitrary POST) and manipulates the resulting on-the-wire packets. The two parts of the attacker (the insider and the outsider) dynamically talk to each other.

Therefore, you can organize some initial discovery procedure in which the insider first triggers some requests with paths of increasing lengths, and the outsider observes at which point the encrypted request length increases by a full block (8 bytes for 3DES or RC2, 16 bytes for AES).

Of course, in practice, the attacker knows the length of the cookie of the target site, because he registered his own account to see what to expect. In many cases, the length for an authentication cookie is constant. Such a preparation step is needed for the attacker to reliably know at which point the cookie starts in the requests, anyway.


Decoding SMS in Chinese extracted from a Blackberry

The source data is clearly UTF-16. In your post it is displayed interpreted as ISO-8859-1, and has become slightly mangled in the process - some bytes have been converted to �.

There are also either some missing bytes caused by the copy-paste, or there are some control bytes in the middle of the sequence, which disrupt the two-bytes-per-character flow. Hopefully the former - can you post the raw bytes (eg as hex dump)? If this is the case, you should be able to just decode them as UTF-16 (probably UTF-16LE).

For what it's worth, trying to recover the original bytes, with � interpreted as null (as the most common byte in UTF-16) using Python:

>>> data= ur'''N mwyûR¨geu5cÐN:`¨g R¡ÿ�0�0�9�0�5�3�2�2�1�3�0�0�8�9S÷xW(�2�0�1�3^t�0�3g�0�6eå�2�3�:�3�8bèbSÇ`¨vbKg:ÿ÷SÊeöVÞu50\0\0Y)s+UFWÎmilýQÀl4VheàPOS[cÿQí¤Áx�8�0�1�1bèbS�4�0�0�8�2�0�2�6�6�7bSÖN÷P<�2�5�8�0QCQÀl4VhN�Sð00milýs¯OÝ0\0\0�(�1�/�3�)NûOUbRONýDg,g`gFÿN mwN¤Y'mwY[fbê�0�6^t_�R0 yÁRß¡gCNN ^D`;Ásí0NågeÇ|û~ßþz¾nÿNÎUFN0N¤Y'mwY0'''
>>> bytes= data.replace(u'\uFFFD', u'\0').encode('iso-8859-1')
>>> print bytes.decode('utf-16le', 'replace')
>>> print bytes.decode('utf-16be', 'replace')

Then pick the characters you find most fitting from each line of:

⁎睭ﭹꡒ敧㕵큣㩎ꡠꅒÿ0090532213008匹磷⡗㈀　㄀㌀瑞　㌀g0收å23:3戸拨읓ꡠ扶杋Ｚ号旊囶痞〵ぜぜ⥙⭳䙕칗業ﵬ쁑㑬桖佐孓｣솤x801戱拨S400820266户홓㱐㈀㔀㠀　䍑쁑㑬桖N〰業ﵬ꽳�尰尰0(1/3丩俻払佒﵎杄本杠ｆ⁎睭ꑎ❙睭孙扦ê0帶彴刀‰셹�枡乃⁎䑞㭠珁ロ敧糇绻ﻟ빺ｮ칎䙕ぎꑎ❙睭す
丠海移动来电提为您朠务＀　　㤀　㔀㌀㈀㈀㄀㌀　　㠀㥓在2013年03最　㙥㈀㌀㨀㌀㡢叇您癢䭧㫿쩥�㔰尰尰天猫商城浩泽净水器无偏卛揿凭꓁砀㠀　㄀ㅢ匀㐀　　㠀㈀　㈀㘀㘀㝢取价值2580元净水器一台〰浩泽环保ぜぜ　⠀㄀⼀㌀⥎ﭏ啢剏份䑧Ⱨ恧䛿丠海交大海奛晢　㙞瑟R〠私募ꅧ䍎丠幄总셳以来일ﭾ�窾滿从商丰交大海夰

eg something like:

丠海移动来电提为您朠务0090532213008匹在2013年03最0623:38戸Ｚ号旊囶痞㔰尰尰天猫商城浩泽净水器无偏卛揿凭x801戱拨S400820266户取价值2580元净水器N浩泽环保0(1/3啢剏份杄本杠䛿丠海交大海奛晢0帶彴刀私募枡乃⁎䑞㭠珁ロ以来敧糇绻窾滿从商丰交大海夰

which is as near as I can get to intelligible given the mangled input.

ETA:

  Here's a hex dump of a longer SMS:

OK this is straightforward, it's UTF-16BE (with a couple of lead control bytes and some trailing ones):

>>> print '0848674376CA90FD4E0D80FD4FDD969C76845BA26237300262404EE573B05728770B6765FF0C516C53F85B81613F9AD86210672C9AD84E8E6052592971364EF7683C53BB57F9517B6276630151764ED676844F9B5E945546FF0C4ECE957F671F770BFF0C7EE77EED51CF5C11548C605259297136768454084F5C657091CF548C53606BD43002000000084900'.decode('hex').decode('utf-16be')
ࡈ权益都不能保障的客户。所以现在看来，公司宁愿高成本高于恒天然价格去培养扶持其他的供应商，从长期看，继续减少和恒天然的合作数量和占比。䤀

  The corresponding encoded/analyzed SMS.Body was:

OK, so that is another string of UTF-16BE bytes that has been interpreted as ISO-8859-1. Recovering the control characters from your post we get:

>>> u'q\x8ae\x87cw:N\nk!u5\x8b\xddN_T\x8cO`\x8b\xf4N\x86\xff\x0c`RY)q6v\x84\x88LN:\x8b\xa9QlS\xf8\x8b\xa4N:\xff\x0c`RY)q6N\nf/b\x11N\xecv\x84b\x18ueT\x08O\\O\x9b^\x94UF\xff\x0cZ\x03T\xc8T\xc8[\xf9`RY)q6ge\x8b\xf4\xff\x0cN\xc5N\xc5f/NN*fn\x90\x1a[\xa2b7\xff\x0c\x80\x0cN\x14f/kc^8gCv\xca\x90\xfdN\n\x80\xfdO\xdd\x96\x9cv\x84[\xa2b70\x02b@N\xe5s\xb0W(w\x0bge\xff\x0cQlS\xf8[\x81a?\x9a\xd8b\x10g,\x9a\xd8N\x8e`RY)q6N\xf7h<S\xbbW\xf9Q{bvc\x01QvN\xd6v\x84O\x9b^\x94UF\xff\x0cN\xce\x95\x7fg\x1fw\x0b\xff\x0c~\xe7~\xedQ\xcf\\\x11T\x8c`RY)q6v\x84T\x08O\\ep\x91\xcfT\x8cS`k\xd40\x02\n'

Undoing the misdecoding:

>>> print _.encode('iso-8859-1').decode('utf-16be', 'ignore')
熊文捷㩎੫ⅵ㖋彔豏悋蛿ౠ剙⥱㙶蒈䱎㪋ꥑ汓ꑎ㫿ౠ剙⥱㙎੦⽢ᅎ葢ᡵ敔ࡏ屏魞鑕䛿ౚ͔졔졛怒剙⥱㙧斋౎앎앦⽎
个普通客户，而且是正常权益都上能保障的客户。所以现在看来，公司宁愿高成本高于恒天然价格去培养扶持其他的供应商，从长期看，继续减少和恒天然的合作数量和占比。

As you can see, the second part of this string is the complete message of which the above was a partial hex-encode.

The first part (before the 个普通客户...) is a mystery. It decodes as valid UTF-16LE (ie no need to 'ignore'), which would normally be an indication that the byte alignment had slipped (again, maybe as a result of character mangling from posting it to SO?). The result of this decoding even fits mostly inside the han character block, but it is:

話蝥督为權甡謵仝呟侌譠仴ﾆ怌奒焩瘶袄乌謺冩卬诸交Ｚ怌奒焩丶昊戯丑盬抄甘呥伈作庛喔ｆ娌吃哈寈惹奒焩朶譥丌仅曅丯

which from my limited understanding of Chinese text appears to be gibberish.

I'm not too impressed with this Cellebrite thing, especially if it is including those control codes directly in XML! (This is not well-formed.)


Proxy Firewalls, Content Inspection, Application Layer Firewalls & Web Application Firewalls

A web proxy is the part of an Application Layer Firewall which does Content Inspection for connections from client (i.e. browser) to the web server. It resides on the side of the client and its task is to protect the client against malware etc. A Web Application Firewall (WAF) is a different part of an Application Layer Firewall which also does Content Inspection but sits in front of the server. Its task is to protect the server against application layer attacks like SQL injection. In a way a WAF is also a proxy, but a reverse proxy. Some Application Layer Firewalls provide both web proxy and WAF, others only one. This depends on what the firewall is used for.

Apart from these basics there are other kinds of proxies for different protocols (i.e. mail, ftp...) which can also be part of an Application Layer Firewall.
The quality and depth of content inspection between various products differs a lot but all of them provide at least a basic parsing of the application protocol.


Where or how can I get list of domain dependencies of top 100 popular sites?

About dns domain dependencies

Domain dependencies are only registrars. There is nothing else.

But you could ask for:

whois gstatistic.com | grep -A1 Holder

Hmm. nothing? Ok looking for names servers:

whois gstatic.com | grep Name.Server
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM

and

whois googleusercontent.com | sed '/Name Server/q;d'
   Name Server: NS1.GOOGLE.COM

Also, building a proxy (meaning web proxy), is a HTTP concern. What you call dependencies are only web links to other repositories where to find some objects.

Web domain dependencies

Web pages depend on a lot of things:

scripts: Libraries could be stored on development site
fonts: Fonts are generally located on fonts servers.
styles: Styles could be linked to scripts, stored on development servers.
videos: Mostly located on stream servers.
map: Geographic maps, stellar maps, oceanographic, human... And other specialised big data systems..
photos, images, others...: Some copyrighted files could only be shown from original site (artist, photograf...),

But web domains strongly depends on

advertiser where links to advertiser host is required for log count and further analisys.
captcha I hate captcha but...
online banks required for web shops.

Where to get such a list

On your web history, cache and mostly on the log of your proxy server...

Unfortunely such a list could not exist, because every web site could be build and modified at any time.

So if you plan to build a strongly restrictive proxy server, you have to keep some hotline up and stay ready to change your rules, adding some new
kind of third party site, at any time.

And finally, about Top 100 popular sites

Answer could only be subjectives...

You could try:

duckduckgo.com
bing.com
google.com
wikipedia

... Then have a look at your proxy logs ;-)

Tip or trick:

Have a look at my answer about How to display the Subject Alternative Name of a certificate?,

Displaying Subject Alternative Name of SSL certificates give some exhaustive list of directly related domains.


Implementation review - Independent key, admin side and user side

This is not unlike a scheme I posited in this question, which got some derision as overly complex. Yours is simpler (because user authentication is handled separately and only user data security/recovery is covered here), but there's still quite a bit going on here with encrypting encryption keys multiple ways. Necessary, probably, but still complex.

I would recommend two changes. First, the private RSA key, instead of being obfuscated behind a single admin account's credentials, could be stored offline. I'm assuming here that recovering user data is not an everyday occurrence, if an admin is required in order to do it (admins have better things to be doing all day than recovering user accounts). So, when it does need to happen, a user with admin privileges could retrieve an HSM (or a thumb drive with the keyfile if you're cheap) from physically-secured storage, and use it with an offline program (not part of the PHP app) to decrypt the user's data.

The advantage here is that it isn't dependent on one common admin account, and thus doesn't require one common admin account, avoiding the inevitability that the admin account credentials will be written down and subsequently fall into "enemy" hands. The key and/or recovery program would still be accessible only by someone with admin privileges, who would use their own personal access credentials to get the key from storage and to log into the program. This also gives you the possibility of an audit trail; you know exactly whose credentials were used to get the key out and run the program, so if there's ever a suspected compromise you can narrow the search.

You can implement whatever additional pomp and circumstance you deem necessary for retrieving and using the private key; just make sure the measures aren't so draconian that they make users want to circumvent them (or alternately, make sure the measures physically prevent circumvention; this usually requires some serious $$$).

Second, I would also store p in the data layer, not in code. I realize that this scheme is in place in a PHP site, and so there's only one place to publish a code change that updates the public key. However, should the public key ever need to change, IMO it's still easier to go into the DB and update it than to publish the code change, and not that much more difficult to get the public key (which is, again, apparently not extremely common; it would only be needed when a user's dk changed, and even if that changes every session it's a trivial DB query to make).

Of course, changing p in the first place will make any dk' encrypted with a previous p obsolete. There are several ways to mitigate this:

Decrypt and re-encrypt every user's data key whenever the RSA keypair changes.
Store the "revision number" of the RSA key last used to encrypt a user's data key, with the current revision number stored alongside the current public key, and keep several past revisions of private keys in storage.

Coupled with forcing users to change their password every 90 days (regenerating and re-encrypting their data keys) the number of old keys you'll have to keep should be pretty low.

Force users to change their passwords when the RSA keypair changes, resetting and re-encrypting their data keys with the new public key.


It is certainly possible that a fresh install could be infected but remember that it will be connected via a router that won't be allowing inbound connections.

So as long as you only run Windows Update, you will be fine.


Probably you need to have more clear the requirements of your client. If the password is encrypted properly you don't need to obfuscate the password again. May be what your client don't want to see is the name of the parameter "managerPassword" and that is what you need to change, ask him.


In an Arm TrustZone based Trusted Application (TA), how can a remote party tie an output to a particular TA?

Have the TA's output include a signature of the result of the computation, made with a key that only the TA knows.
The signed data needs to include the parameters of the computation as well, not just the result. Otherwise an adversary could take results of one computation and pretend they were the result of a different computation that the TA has also performed. If it's more convenient, you can use a cryptographic hash of the parameters instead of the parameters themselves.
Include the TA version as well, so that if there's a bug in a version of the TA you can decide to reject its computations. (This doesn't help if the TA has a vulnerability that allows the attacker to modify the version in the signed data. If this happens, you either need to rotate the signature key, or rely instead of the TA version in the TEE's attestation as described below.)
The next question is, given a signature, how do you know that it's genuine? You need a public key infrastructure to tie TA's public keys with their identity. The root of trust for the computation includes:

The TEE manufacturer. A TEE consists of hardware and software, often made by different entities, but for your purposes you can consider the TEE manufacturer to be a single entity.
The TA manufacturer.
The entity or entities involved in installing the TA onto the TEE. In this answer, I'll call these entities collectively “the TSM” (trusted service manager).

TEEs usually offer an “attestation” functionality. Exactly what goes into an attestation varies, but the general idea is that an attestation is a signature over some data which includes both identifying information for the TA and identification information for the TEE it's running on. The signature is by a key which has a trust path to a certification authority (CA) run by the attestation authority. The attestation authority is usually the TEE vendor or the TSM. The attestation says something like:

TA {1234-567-89a} version 4.2 running on Yoyodyne TEE operating system 1.1.7 running on an ACME-TZ-5522 chip, on 2020-06-25 at 22:16:44, said:

Moo

Signed, the TEE.
Signed the public key of the TEE, the TSM operating CA.
Signed the TSM operating CA, the TSM root CA.

Depending on how your TEE/TSM infrastructure is set up and the circumstances under which you perform the computation, it may be more convenient to have the TA emit an attestation for each computation result, or to have a TA generate a private key when it's installed, attest the public key once and for all, and use its own private key to sign each computation result.


Secure Hash of a very short payload - is it possible?

Asymmetric keys are only really valuable if one of them needs to be made public (though "public" can mean different things in different contexts).

If you both generate and verify codes in private, than you can just use a private secret as part of an HMAC with a reasonable hashing algorithm.

If space is a premium, you can even get away with using the first X bytes of the resultant HMAC output, with the understanding that each byte you remove decreases your protection slightly.

If the codes need to be verified or generated in public, then first of all recognize that even a properly valid result can be subverted by some other aspect of the software chain, but ideally you can do the public part (generation of validation) using a public key and the private part using the private key.


GPU powered Password cracking machine - buy metal or cloud?

This is a simple cost / benefit analysis, so it's a business question rather than a security one since you've already decided the merits of how to approach the security aspect. Write your code, benchmark it, and compare numbers in a spreadsheet.

For the metal

* Cost of metal
* Cost per hour in terms of electric bill (assume under full load)
* Budget for parts replacement
* Operations per second

For the EC2

* Amazon rate per hour
* Operations per second

Compare the numbers on a month by month or year by year basis. Pick the one that makes more sense based upon expected life. Front-loading cost, net present value, expected utilization, risk, etc are all accounting problems.


So it appears that the Red Hat errata and CentOS errata are the same numbers.

This is Red Hat's format:

 RHSA-YYYY-####

And this is CentOS' format:

 CESA-YYYY:####

Where #### is the same number for both. So, to solve your example question, here's what I did:

I went on the RedHat site and searched for the CVE number. This led me to the CVE page that linked to errata RHSA-2014-1552
CentOS releases its errata on a publicly archived mailing list. In that email, they have the "CentOS Errata and Security Advisory" number, and the package they uploaded to fix it. Now I use the magic of Google and search for "CESA-2014:1552". site:lists.centos.org is optional, since it should be the first result regardless of domain restriction. The search leads me to this email listing the updates to OpenSSH packages. Click the link for the list.

It's not as easy as searching a central online repository (which CentOS woefully does not have) but you can get from point A to B without too much finagling.


If you are looking for malware to study and understand how it works metasploit is great. The framework is open source so you can study how it works.

You can search the metasploit database.

I'm not sure what exactly you're looking for when you say "JavaScript Malware" but if you mean JavaScript that could compromise users who view a site CVE-2012-3993 looks pretty cool.

If your looking for JavaScript that if injected to a site could do nasty things OWASP is a good resource.

I also quite like Troy Hunt's Intentionally Vulnerable Site it gives you a good playground where you can break things and he has some good training on what not to do.


unfamiliar IP when logging into ssh server

That's a truncated hostname, and it's actually in reverse IP order.  The full hostname is 182.53.252.66.knds.xdsl.dyn.ottcommunications.com.  OTT Communications seems to cover from Maine to West Virginia.  Maybe they're your ISP, or your ISP resells for them?  Does your IP match 66.252.53.182?


The smartcard based systems like the product in the link you provided are based on PKI (public key infrastructure) which is a means to authenticate a user based on their ability to sign something with a private key (held on the smartcard) that can be proven with application of the public key.  Since the private key never leaves the card (at least, in fully secure implementations) it is a means to guarantee that the user does have the card since there is no practical way to duplicate it and it is challenged to prove itself during each sign-on.

So, the RSA SecureID has a similar purpose (proving the user has the object in their possession, and is impossible to duplicate) but is not as robust because the smartcard can interact with the OS, to do things like force the user to log out if the card is removed from the computer, and provide other cryptographic functions like signing emails.

In the case of the keyfob, the "private" section is still known to RSA (or whoever issued the fob) because it is needed to validate the code.  In the case of the smartcard, the private key could (should) only exist on the card, and the public key is used to validate the card.


Does SSL certification have anything to do with the website legitimacy?

No.

You are confusing an SSL / TLS certificate with some kind of standards-compliance certification from either government or industry (ex.: ISO-9000).

A TLS Certificate:

Is used only for encrypting connections from one computer to another.
Links your public key to your server's domain name so that a web browser knows that it is talking to the correct server.
To get it, all you have to do is prove that you own the server and the domain name.
The people who give out TLS certificates absolutely do not care what you do with the certificate after you have it (that's not their job).

A standards-compliance certification:

Is used for showing that your company is accountable and trustworthy.
Shows that the people in your company follow a set of rules in their day-to-day business (either government rules, or industry rules like an ISO certification).
To get it, auditors come to your workplace and observe that your people do things according to the rules.
Standards bodies will continue to audit your company, and you can lose your certification if you stop following the rules or do something bad.


ARP spoofing kills victims connection and other issues

I've not used mitmf.py, but from your description, the most obvious cause is that the tool is only poisoning the victim's arp cache at startup and is not intercepting the refresh of the cache (fast enough). This should be apparent from a packet capture (though you'll have to wade through a lot data to validate it).

If this is the case, re-running the arp cache poisoning at regular intervals may fix the problem.


How do you explain the necessity of "nuke it from orbit" to management and users?

In my experience management doesn't like to listen to clever analogies. Depending on the person they care about the bottom line in dollars or hours of productivity. I would explain:

  The actual bottom line is that a compromise of our data will cost the
  company approximately X dollars + Y hours to recover. This is Z%
  likely to happen given the malware that is on this machine. A new
  install will cost A dollars + B hours to recover. You pick the
  appropriate action.

It's short and clear and doesn't really leave them any room to argue. They will clearly understand the risk and should make the right decision.


What should I do about Gmail ad asking me for password?

This seems unlikely but not unthinkable. From the information in your question and the supplied screenshot, it seems that the Google ad domain was or currently is compromised.

What to do now?

Firstly, make sure that you have antivirus and anti-spyware software installed and that this software (including your operating system) is up-to-date. It is a good idea to let your antivirus and anti-spyware software run a full system scan.

Secondly, even if you didn't fill in your credentials, I'd recommend to change your password as soon as possible with an ad blocker (like Adblock Plus, Adblock, uBlock Origin or similar) installed and enabled in your browser. It is recommended to enable two-factor authentication on your Google account (if you didn't do that already) to prevent (future) leaked credentials from being misused.

Thirdly, contact Google about this and supply them with details like your IP, URL, screenshots, date/time and as much information as you have. You can contact Google about this at "goo.gl/vulnz" or check https://www.google.com/about/appsecurity

Additional information

Alternative explanation

Another explanation for this could be (although this would be unlikely and amateurish for a company like Google) that the developers overlooked a mistake in the development, testing and releasing process.

Also (as mentioned in different comments) this result could possibly be caused by some kind of man-in-the-middle attack (like a hacked proxy) or a malicious browser extension.

Why change your password if you didn't fill in your credentials?

The site showed an unusual but visible "basic auth" prompt from an external domain. Assuming that the domain was compromised (at least until it is proven not) the attackers could as well include other code that was not directly visible. Maybe persistent in cache? Maybe some kind of malware? Since we can't exclude that possibilities also, and since a password change or virus/malware scan won't hurt anyone, these are extra measures, just to be sure.

Is doubleclick.net really owned by Google?

Yes! As described in this Wikipedia article and as shown in the WHOIS information of doubleclick.net. Registrant Organization: Google Inc.


Can a nessus scan running on top of a Windows OS do full internal scans of devices using ssh?

Cisco devices use IOS, and they have the ability to accept ssh connections. Nessus is an ssh client and can perform scans externally as well as by logging in, if the credentials are supplied. It makes no difference if there is an ssh client installed on the server it is being run from.


What Are The Best Practices (Application Security Policy) For Modifying Rijndael Salt, IV, Pass Phrase

AES only takes a key and an IV. The IV should be random and different for each encryption. Just prepend it to the ciphertext. I also strongly recommend adding authentication.

Concerning passphrases, I'd avoid them where possible in favour of a simple random key. Keys are simple secure and avoid the cost of key derivation. Only use passwords when the user needs to enter them.

When you really need a password, a sufficient iteration count, generate a random salt, and use PBKDF2(or better). This hashing and salting is only there to compensate for weak passwords.
When to choose a new salt in key derivation is more complicated. Ideally use a new random one for each encryption, but that might be too expensive. Sometimes you can reuse them, sometimes you can cache the key, but that's application dependent.

I wouldn't hardcode the key in your source-code. The web.config file seems like a more appropriate place. You can't really hide the key, since your application needs it.


There are a number of misunderstandings here:

Tabs can not be "authenticated" or "unauthenticated". If you are using cookie based sessions for authentication, it is the presence of the session cookie that gives you access. That cookie belongs to the browser session, and not to a specific tab.
Loading a "priveliged location", i.e. a page that an unauthenticated user should not have access to, is not proof of CSRF.

The victim could itself just open a new tab, enter the URL to the priveliged location, and have access to it, right? All you have done is to do this with a bit of JavaScript. How could you, as an attacker, leverage this? You couldn't! The browsers Single Origin Principle would stop you from reading any data, and you didn't trick the server into performing an action.

So what would consitute proper CSRF? For this to be useful, you have to get the server to do something - create a user, delete a post, change a setting, whatever. As you say, this would normally require a POST request, but on a poorly designed page it might be possible with GET as well. Anyway, that is what you should be looking for!


Why is it recommended to use accounts without sysop rights for everyday work?

You misunderstand. The recommendation is to use sudo and elevating permissions through the windows built in thingy (where you enter credentials of admin account) instead of using root account or su or admin account by default.

If you use su or root account, you give root permissions to everything you run. If you use sudo, you only give root to apps that need it and hopefully only well trusted apps. This reduces chances of malware getting root access. Even apps that are not malicious by themselves may not be designed to be run as root and have vulnerabilities if they are. A good example of this are web browsers.

On windows, the important thing is UAC does not protect against file permissions. So an app run by admin even without UAC admin privileges may have access to files and folders an app run by normal user would not have access to.


Why do I sometimes need to "bypass" SSL intercept?

My guess is that your Proxy is stripping off the Authenticate header from the request. I did a quick Google search on the issue and found this forum page. From the same page:

  It is by design if the proxy sees an Authorization header and the
  proxy have authentication enabled or used in the policy, the proxy
  will consumed the Authorization header, thus the Authorization header
  will not be forwarded to the upstream device.

  In this case, the Authorization header was generated from the client
  and NOT due to the proxy's authentication challenge, this is why it
  failed. So in order to 'tell' the proxy not to suppress the
  Authorization header, we would need to disable authentication for this
  URL and forward the Authorization header to the upstream as what the
  CPL suggested will be doing"

I believe the issue you are having is kind of similar. The solution proposed on the forum:

  Solution at present would be to have "security
  force-credential-forwarding" enabled or use the CPL to bypass Auth for
  the domain. Since the command will affect the "Proxy-Authorization"
  headers too.

Hope this helps.


Certificate handling on a small network VPN

Despite Alexey Vesnin's answer, feel free to keep the certificates you issued for various reasons. They are considered public knowledge and no harm is done whatsover keeping them as long as you like.
Having said that:
Being a CA comes with some responibilities:

Make sure you keep the private key safe and secure. (An encrypted USB stick with the CA data on it will be fine, as long as the machine you decrypt it on is not compromised. A smart card would be a better (albeit more expensive) solution.)
Offer the parties relying on your certificates a way to check for revoked certificates (for example, if a key pair somehow gets compromised
Make sure compromised keys/certificates are reported to you (do not punish the people for being not careful enough)
Make sure to revoke certificates as soon as you see the need
Make sure you inspect every CSR you get from clients thoroughly before signing it

Depending on your actual use case (does every client need a certificate? How much fluctuation is there? How good are the clients in keeping their private key private?) you might only need to work with your CA setup when the initially granted certificates are about to expire.
Or every other day, that completely depends.
Additional considerations for the changed question
You might only need the LAN side to trust the self-signed certificate of the only connecting party (and vise vesa). As long as the two machines are trusted, you may just add the certificates itself to the trust store and leave out an actual CA signing both certificates.


How the attacking vector of Skygofree is composed?

From the Kaspersky blog:

  The malware is distributed through fake mobile operator websites, where Skygofree is disguised as an update to improve mobile Internet speed.

There's probably a lot of people on the Internet who will easily trade all their privacy and security for a slightly faster network connection.


Can message length be useful information?

While the length of a message alone is not suitable to directly extract the secrets it might be a valuable context information. If the length of the plain message alone provides useful information then the length of the encrypted message will usually not fully hide these information (only a bit due to padding). Such context is especially useful if there is not only a single message but when many messages can be observed.
The length information can for example together with timing information be used for fingerprinting traffic, like distinguishing DNS over HTTPS from "normal" HTTPS. With DNS over TLS it might also be possible to narrow down which requests where done based on the length. Length information played a major part in the BREACH and CRIME attacks against TLS and HTTPS, where the visible length of the compressed and encrypted content made it possible to figure out parts of the unencrypted content.


Content Security Policy Header not stopping attack

[from comment] ... IE was not working, but, does ie11 even support this header?

According to can i use content security policy there is only partial support in IE11: only the sandbox directive is supported and the header needs to be specified as X-Content-Security-Policy. Thus, no support in IE11 for what you are trying to do.


Why do browsers clear HTML forms when the user click the back button over an HTTPS connection?

Some times, form data may be dynamic. Example, only when you select a country, the drop-down to select a state will be enabled. Now to actually know what values need to be filled in the "state" menu, the information about the "country" you just selected will be sent to the server. server will then send to the client, a list of all states that come under the country and will populate the drop-down menu.

Now, all these exchange of information between the client(web-browser) and server are done via encrypted channel using SSL. When You click on the "back" button, the current SSL session becomes invalidated. And all data exchanged over that session must no longer be valid. Even if you want to have the same values again when you visit the page next time, those values need to be communicated via a channel secured using a different session key.(i.e, a new SSL handshake will be initiated, resulting in new pre-master, master and session keys and the HTML form data will be encrypted with new keys.)

So, to prevent the data of old SSL session to be used in the current SSL session, the form  data will be cleared.

Note that sometimes, cookies and session tickets will be used to retain the form data/session keys. But servers generally dont support session tickets, rather they encourage having a separate session.


Is it possible to restrict a client-side certificate (for web auth) valid only for a given site name?

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in the certificate against your own database to see if they should have access. The certificate contains subject info which should probably include some form of username, and you should be keeping the list of users and who's allowed to access what. That also allows you to change the scope of someone's access without needing to reissue a cert.

Client certs do not tie to domains; that's because they aren't meant to authenticate a server. I should be able to use my certificate anywhere that'll accept it, and with client certs that is what happens.


The URL hash isn't transmitted to the server. It's only available to the client, so the server is never aware of its value. Thus, non-DOM XSS isn't possible via URL hash.

Since the client is aware of its value, it could try to use it, fail to sanitize its value, and insert malicious markup / execute some Javascript code, leading to a DOM XSS vulnerability.


How do e-mail relays detect who clicked "Report Junk" or "Report as Spam" on an e-mail?

Yes, email providers offer a way to acquire such information. It's called a feedback loop. The exact implementation depends on a particular email service with some of them using a standard Abuse Reporting Format reports and some having their own solutions.

It's unclear which providers send the user's email address to the campaign originator, as Wikipedia notes:

  The majority of ESP offering Feedback Loop do not include in the report the email address of the recipient, who marked the message.

More info on feedback loops with details of particular implementations is available at www.emailfeedbackloops.com.

Campaign Monitor is clear about them using the feature:

  Through a direct feedback loop (FBL) with major ISPs, like AOL, Yahoo! and Hotmail, our system can automatically detect if a significant number of your recipients flag your emails as spam.

An important note from the article is that in case of several email providers, clicking the "Spam" button triggers an automatic unsubscribe action which identifies an individual user. At the same time Gmail does not perform this action automatically.

In case of Gmail the data is statistical and doesn't identify individual users and their actions, so at least Google's feedback doesn't allow to tell "which of [the] recipients clicked [Spam]".


You simply can't protect your website from illegetimate requests like this. Consider moving your site behind a service which does packet scrubbing and verifies the legitimacy of the connection. One free service you could have a look at is CloudFlare.


Why are js libraries designed to be loaded in iframe?

Loading javascript in an iframe "automatically" protects the parent from unwanted changes with respect to some flavour of the Same Origin Policy that browsers adopt.

So they limit the damage that a third party library can do when attempting to change your original web content; for example, they may modify an legitimate link to some other same-looking place that performs some phishing and steals user's information, cookies, etc.

This is not the only way where the same origin policy is implemented, but it is quite an easy one. In the case you need (safe) interaction between the parent and the iframe, one of the ways is to perform postMessage calls.


How to find the origin of some invasive html?

I have the same issue on my website.

I have found the cause of it to be the Facebook Pixel Code.

Commenting the Pixel out resulted in the unwanted div disappearing.


Why is plain dm-crypt only recommended for experts?

If I stick to standard operations, and I do not require any of the features from LUKS, what risks am I as a non-expert taking?

LUKS partitions have a header that ensures such a partition won't be seen as ext2, vfat, etc. A plain dm-crypt partition may coincidentally end up looking like a unencrypted filesystem, and has a chance of being written to accidentally, destroying your data.

LUKS checks if you entered the correct passphrase. If you put in the wrong passphrase, plain dm-crypt won't pick up on this; instead, it will happily give you garbled crypto-mapping which may also coincidentally look like an unencrypted filesystem, and has a chance of being written to accidentally, destroying your data.

LUKS stores the type of encryption used, while dm-crypt requires you to supply the same options each time. If, after a period of not using your encrypted device, you find there are a few gaps in your recollection of what the password was, and it turns out you forgot the encryption options as well, you are doubly hosed (this happened to me personally before LUKS existed; the encrypted data wasn't so important so I just reformatted after unsuccessfully trying to get in for an hour or so).

Also, there may have been a period during the development of cryptsetup in which essiv was not the default for dm-crypt, but was for LUKS, and the documentation you are reading may have been intended to allude to that.

Finally, some of the options of LUKS do things that are important from a security standpoint. For example, suppose you fall asleep while authenticating with gmail and accidentally type in your drive password. In dm-crypt there is no way to change the password without re-encrypting your whole device (and doing so in-place is risky, since a system crash or power loss event will leave you with a guaranteed hosed system). With LUKS, you can change the password.


Why is a one-way hash not enough to secure a password alone?

The point of using bcrypt over regular hashing is that throttling (key stretching) can be easily and reliably implemented which makes brute-forcing a time consuming, thus impossible job. Hash functions even with thousands of iterations are still relatively easy and no time job for the processor. Bcrypt is designed to be brute-force resistant as cryptography or computing develop. If password cracking becomes easier, you just increase the cost parameter.


Is it ok to use computer while scanning for viruses?

Your AV might be unable to scan some files while they are in use. If that does happen, then any good AV should report this in a summary of the scan when it finishes, I'd have thought.

Performance could be pretty dire while it's running a scan, too!


The general idea is to embed shellcode in a bitmap which a browser loads into the heap.

The original presentation discussing this technique is Punk Ode: Hiding Shellcode in Plain Sight.

Also discussed in this paper is using code embedded in a gif to create an exploitable heap overflow in NetScape 6.x, x86 Linux RedHat 7.0, 15 years ago (slide 9).

As for the technique discussed on slide 13 of Advanced Heap Spraying Techniques, the code used to demonstrate it can be found  in the section titled "Alternative ways to spray the browser heap" of  corelan's Heap Spraying Demystified tutorial:

# written by Moshe Ben Abu (Trancer) of www.rec-sec.com
# published on www.corelan.be with permission

bmp_width           = ARGV[0].to_i
bmp_height          = ARGV[1].to_i
bmp_files_togen     = ARGV[2].to_i

if (ARGV[0] == nil)
    bmp_width       = 1024
end

if (ARGV[1] == nil)
    bmp_height      = 768
end

if (ARGV[2] == nil)
    bmp_files_togen = 128
end

# size of bitmap file calculation
bmp_header_size     = 54
bmp_raw_offset      = 40
bits_per_pixel      = 24
bmp_row_size        = 4 * ((bits_per_pixel.to_f * bmp_width.to_f) / 32)
bmp_file_size       = 54 + (4 * ( bits_per_pixel ** 2 ) ) + ( bmp_row_size * bmp_height )

bmp_file            = "\x00" * bmp_file_size
bmp_header          = "\x00" * bmp_header_size
bmp_raw_size        = bmp_file_size - bmp_header_size

# generate bitmap file header
bmp_header[0,2]     = "\x42\x4D"                    # "BM"
bmp_header[2,4]     = [bmp_file_size].pack('V')     # size of bitmap file
bmp_header[10,4]    = [bmp_header_size].pack('V')   # size of bitmap header (54 bytes)
bmp_header[14,4]    = [bmp_raw_offset].pack('V')    # number of bytes in the bitmap header from here
bmp_header[18,4]    = [bmp_width].pack('V')         # width of the bitmap (pixels)
bmp_header[22,4]    = [bmp_height].pack('V')        # height of the bitmap (pixels)
bmp_header[26,2]    = "\x01\x00"                    # number of color planes (1 plane)
bmp_header[28,2]    = "\x18\x00"                    # number of bits (24 bits)
bmp_header[34,4]    = [bmp_raw_size].pack('V')      # size of raw bitmap data

bmp_file[0,bmp_header.length] = bmp_header

bmp_file[bmp_header.length,bmp_raw_size] = "\x0C" * bmp_raw_size

for i in 1..bmp_files_togen do
    bmp = File.new(i.to_s+".bmp","wb")
    bmp.write(bmp_file)
    bmp.close
end

  This standalone ruby script will create a basic bmp image that contains 0x0c all over the place. Run the script, feeding it the desired width and height of the bmp file, and the number of files to create :

root@bt:/spray# ruby bmpheapspray_standalone.rb 1024 768 1
root@bt:/spray# ls -al
total 2320
drwxr-xr-x  2 root root    4096 2011-12-31 08:52 .
drwxr-xr-x 28 root root    4096 2011-12-31 08:50 ..
-rw-r--r--  1 root root 2361654 2011-12-31 08:52 1.bmp
-rw-r--r--  1 root root    1587 2011-12-31 08:51 bmpheapspray_standalone.rb
root@bt:/spray#

Additional information on this subject from Phrack article Self-patching Microsoft XML with misalignments and factorials:

  --[ 3.4 - Filling the memory 1: images

  Because the memory region that must be controlled is rather big, my
  initial idea was to utilize some pre-calculated big objects for filling
  it, such as images. The core of the idea is that, every piece of data
  that can be consumed and processed by the target application (e.g. output
  or rendered) has its place and a representation in the target process
  memory. Thinking like that we don't get caught in stereotypical terms of
  'heap spraying' and the specific techniques associated with it, many of
  which are already mitigated in browsers.

  The idea of using graphical images in vulnerability development is not
  new. It was first introduced in 2006 by Sutton et al.[3], whose research
  focused mainly on the aesthetics of shellcode steganography in images
  rather than solving of any problems of heap spraying (as there were none
  at that time). Later, a few researchers revisited the same idea in the
  context of heap spraying, but it has never found a real application,
  mainly because bitmaps (as the only format capable of incorporating a
  byte pattern 'as is') are huge and can only be shrinked with the help of
  server-side measures, while using other image formats for memory control
  purposes is burdened with calculation problems of recompression.

  Apart from the server-side GZIP compression, another solution that's never
  publicly noted is PNG. The PNG compression is very simple and does not
  affect the bitmap structure at large. As a result, a 2Mb BMP image
  containing a simple 1-byte pattern can be converted into a ~500 bytes PNG
  image, that will be decompressed back into the original bitmap in the
  rendering process memory.

  There are two problems however:

  The more variable is the source bitmap pattern, the bigger is the
  resulting PNG image; a natural limitation of any compression.
  The decompressed PNG has extra bytes in the bitmap data, injected after
  every 3 bytes of the original bitmap. It's probably a transparency channel
  or some other data specific to the PNG format.

  The good news:

  At the point when the PNG image is loaded and decompressed by the
  browser but is not yet displayed on the web page, the bitmap data in the
  process memory fully corresponds to the source BMP.
  A large image is mapped into a comparably large and continuous chunk of
  memory, located at a somewhat predictable memory offset.

  The PNG spraying technique proved to be not suitable for this particular
  case because a highly variable memory padding pattern would be required,
  and so the images would have to be too big anyway. However it still looks
  like an interesting technique for rapid filling of huge memory areas with
  a simple byte pattern.


How does the TPM provide security for the cloud?

The most useful case for TPM-backed security in cloud computing is providing greater assurance to a tenant that the cloud provider is running the software they expect. Because the cloud provider controls the hardware the software is running on they (or someone who hacks their infrastructure) are in a privileged position and could insert rootkits or otherwise compromise the expected security properties of the software the tenant asks them to run. However, software running on machines equipped with TPMs can attest to the state of their platform, allowing the tenant to remotely verify that the software is in a desired state (i.e. only the expected code has been run). A TPM can also be used to restrict the usage of certain keys or credentials so the cloud provider cannot copy them or use them outside of the context of running the tenant's workload.

It's important to realize, however, that TPMs do not provide physical security. They are typically tamper-proof themselves, but even if you trust that the TPM can protect its root keys and is operating correctly its only awareness of the system's state is through by a series of measurements provided by other hardware components and software processes. Barring serious CPU/chipset/firmware flaws, this sequence of measurements cannot be faked by malicious software -- but it can be faked by anyone with physical access to the TPM chip and a soldering iron. This means that a tenant always has to trust the cloud provider to some extent; still, TPMs can provide effective defense against hackers who might compromise a cloud provider's infrastructure, which is usually what people are more concerned about.


Please help verify my understanding of Domain Validation (DV) SSL Certificate

A Certification Authority, before issuing a certificate to an entity E, with E's name and E's public key in the certificate, is supposed to verify that the public key in question really belongs to E. For SSL server certificate:

E's name is a host name, like www.google.com, possibly with a "wildcard" (*.google.com). This is what SSL clients verify; this is all about names, not IP addresses.
The public key is received by the CA as a certificate request.

So the notion of "identity" in force here is really a question of domain ownership. The CA wants to make sure that it received the request from someone who controls the domain. There are several methods for that; the two most used are the following:

The CA sends a challenge by email to the email address specified for the domain in the WHOIS database.
The CA challenges the requester with some information to be included in the domain, e.g. a random host name to be included in the DNS.

These checks are not extremely robust (they rely on the "impossibility" to hack into, respectively, emails or the DNS, neither being well protected) so there is a recent fashion for stronger verifications, called Extended Validation Certificates. For an EV certificate, the CA is supposed to do a lot more paperwork to make sure that it talks to the right entity. Retrospectively, non-EV certificates are dubbed "DV" (as "domain validated").

The net effect of an EV certificate is that Web browsers recognize them as such, and may show that fact to the human user with a more lavish display, with a lot of green. But non-EV certificates technically work just as well. An EV certificate is worth the effort only if your users are trained to recognize EV certificates and feel more comfortable with an EV certificate than they would with a "normal" certificate (which is still shown with the famous "padlock" icon). Right now, I'd say that most Internet users are far from being aware of the distinction, so buying an EV certificate is kind of useless.

(EV certificates will become useful when they become mandatory, i.e. when Web browsers begin to reject or warn about SSL server certificates which seem valid but are not tagged "EV". This is a rather tough transition and I don't see it happening in the near future.)

For a bad guy to obtain a seemingly valid certificate with your server name in it (the prerequisite for mounting a really successful impersonation attack), he must do one of the following:

Fool the CA. Fooling the CA is harder for EV certificates (that's the point). However, even if you get an EV certificate, it would not prevent the attacker from obtaining a non-EV certificate in your name from a gullible CA. An EV certificate will protect you against sloppy CA only as long as your clients are trained to pause and become suspicious if they see a seemingly valid but non-EV certificate bearing your site name. This hardly seems realistic right now.
Steal your private key. If an attacker steals your private key, then he can use it with your certificate (which is public) to install his fake server. EV or non-EV is irrelevant here; what matters is that you should protect your private key well. If your server is broken into, inform the CA so that it may revoke your certificate, and issue you another one (with a new key).
Fool the human user into disregarding the very red and scary warnings from the browser when an invalid certificate is shown. You cannot really defend against that, except through educating your users. The warnings shown by Web browsers tend to increase in scariness (and redness, too) over time.
Fool the human user into connecting to an attacker-owned domain with a perfectly valid certificate, and a name which looks like the intended server name. E.g. www.gogle.com or www.google.business.com instead of www.google.com (fictitious examples). There again, only user education can really work against that.

Most phishing attacks are based on one of the last two methods, so this means that you should not be overly worried over the DV/EV dichotomy. The really important point for security is user education.


Is PSK-protected IKEv2 secure against MITMs?

With the hypothesis there is already a MITM attack installed between your iPhone and your Linux VPN server, this attack won't be able to get your PSK, because this one is not exchanged during
the encryption tunnel building and during its use. Your IPsec tunnel will use your PSK from the beginning with the encryption schemes you configured (aes256).

This is the uniq advantage to use a PSK.

To settle in place a MITM attack once your tunnel is built, an attackant would need this PSK and to configure a fake VPN server configured with your PSK and located on the Internet route used.

The PSK biggest weaknesses are on the 2 ends of the crypted tunnel,
and next on the channel through which you exchange this PSK to configure it on the 2 ends of your crypted tunnel (here an iPhone and your Linux VPN server).

These are not at all light risks since most of the real attacks against
crypted tunnels are conducted by entering at one or the other end of the tunnel at the OSes or application levels. Most of common OSes (I mean on the mass consummer market) are running infected and compromised. My personnal estimate is that the see level of corrupted OSes is actually pretty high, above 90%.


How to scan PHP code for vulnerable functions?

It's important to note here that phar_fix_filepath is not a PHP function that your web app uses. It's a function in the C source of the PHP engine. You security issue that the pentester is referencing is probably CVE-2015-5590:

  Stack-based buffer overflow in the phar_fix_filepath function in ext/phar/phar.c in PHP before 5.4.43, 5.5.x before 5.5.27, and 5.6.x before 5.6.11 allows remote attackers to cause a denial of service or possibly have unspecified other impact via a large length value, as demonstrated by mishandling of an e-mail attachment by the imap PHP extension.

So what has the pentester done here? She has probably checked what version of PHP you are using (by default this is conveniently displayed in a HTTP response header, but it can also be found through fingerprinting). Then she just needs to check any list of known vulnerabilities to see which ones affect that version.

But does the pentester know that your code results in this function being executed and that the vulnerability can be exploited? Probably not. My guess is that she is satsified with pointing out that the PHP version is vulnerable, no matter if your app is affected or not. And honestly, that is bad enough. Even if this can't be exploited at the moment, the slightest change in the source code might change that fact. You need to upgrade your PHP engine no matter what.

With that view, you don't need access to the source code, since the analysis is based only on the version number. If one were to determine if your app can actually be exploited, access to the source code would help a lot, though.


Exposing different services on the same port

I would caution coding your own version of a switch; is the development time really worth it compared to using a VPN solution? Can you securely code it and ensure no internal data is inadvertently accessed?
Should you decide to proceed with a modified TCP proxy, you can implement some architectural changes to increase security:

Ensure the TCP proxy server is in a segmented DMZ, and will only have access to those two applications. Should the TCP proxy server be compromised, only those two applications may be impacted.
Only allow communication to encrypted ports. Do not allow plaintext transmissions.
Log IPs in traffic -- remember, your applications may not see the true client IP anymore.
For any applications using HTTP(S), implement a WAF.
If the applications have a High Availability requirement, possibly consider implementing a load balancer as well as some mirrored servers.
It would not hurt to run a monthly or quarterly vulnerability scan with a tool such as Nessus, OpenVAS, or even nmap's Vulners plugin to get a picture of how exposed your application is to known vulnerabilities.

I would additionally recommend looking at the Application Security Verification Standard and reviewing what security controls you may be missing, and whether or not you can accept that risk from a business standpoint.

However for the sake of the argument, I would lean towards a VPN (or SSH proxy) anyway. From a security standpoint, here are some benefits:

All traffic is encrypted
You can implement some form of access control based on user ID
You can rest assured that VPN software is security tested very well, as it is the front door to most organizations.

For security purposes, make sure that your VPN server is in a segmented DMZ from the rest of your network. Ensure that this DMZ can communicate externally, as well with the two applications you need to be accessed externally. Therefore, if the VPN server or user credentials were ever compromised, the attackers would only be limited to attacking those two internal applications.


Sharing a number while maintaining privacy

You can use Oblivious Transfer.

Oblivious Transfer (OT) is a cryptographic primitive in which the sender transfers one of potentially many inputs to a receiver but remains oblivious to the input sent. The receiver also remains oblivious of the inputs he or she did not choose.

Chou and Orlandi define OT as it follows:

  ”In its simplest flavour, 1-out-of-2 OT, a sender has two input
  messages M0 and M1 and a receiver has a choice bit c. At the end of
  the protocol the receiver is supposed to learn the message M c and
  nothing else, while the sender is supposed to learn nothing.”

Below is an 1-out-of-2 OT protocol that is secure against semi-honest
adversaries, as it was described by P. Snyder:

In your case, you have many numbers (ten to be precise) and you want to pick one each time. So you need a 1-out-of-K OT protocol. Such a protocol exists but it is much more complicated because it is based on Oblivious Transfer Extensions.

Oblivious Transfer Extensions:

There lies a problem found in every OT implementation. Due to the fact that
every OT protocol is implemented via Public Key cryptography, it is increasingly difficult to simulate a very large number of OT transactions. To answer the previously stated problem, a solution would have to be found.
Indeed, in 1996, Donald Beaver proved that OTs can be extended using symmetric
cryptography. This notion was later proven efficient by Y. Ishai et al. As it explained by Asharov et al:

  ”An OT extension protocol works by running a small number of ”base
  OTs” de- pending on the security parameter (e.g. a few hundred) that
  are used as a base for obtaining many OTs via the use of cheap
  symmetric cryptographic operations only. This is conceptually similar
  to public-key encryption where instead of encrypting a large message
  using RSA, which would be too expensive, a hybrid encryption scheme is
  used such that the RSA computation is only carried out to encrypt a
  symmetric key, which is then used to encrypt the large message.”

You can check an implementation of the most known OT Extension protocol here.

Regarding the 1-out-of-K OT protocol, in 2013, Vladimir Kolesnikov and Ranjit Kumaresan proposed an optimization and generalization of the IKPN03 protocol which you can read here.

To conclude, OT is a known cryptographic primitive which does exactly what you want. You can use it in its simplest form (the 1-out-of-2 OT) and run it many times since you have 10 numbers instead of 2. Or, you can implement something more sophisticated such an OT Extension scheme.

See also:

https://en.wikipedia.org/wiki/Oblivious_transfer
https://crypto.stanford.edu/pbc/notes/crypto/ot.html
http://scapi.readthedocs.io/en/latest/interactive_layer/ot.html
https://github.com/search?utf8=%E2%9C%93&q=oblivious+transfer


Securing a public computer meant for banking

Any form of hacking involves being able to change the underlying operating system or applications.  If an attacker were completely prevented from doing this, then attack is impossible.

Operating systems have vulnerabilities.  They always have, and they always will.  But what if the OS and all applications ran off of a medium physically incapable of being altered, say on a read-only medium and had no ability to write to permanent storage?  Furthermore, if the OS rebooted when each user was finished with the computer, and sufficient physical access to the computer was prevented, it would be exceedingly difficult to hack the computer.

So in my estimation, a secure public computer would need the following properties.

A read only operating system, at the physical medium layer.
No medium capable of writing information anywhere permanently (obviously you still need RAM).
The operating system reboots after every use in order to prevent someone gaining control of the running operating system.
Physical access is extremely limited.  No USB ports are available, the physical box is in a locked box that can't be tampered with easily.  Even the keyboard is "bolted in" and can't be removed.  Think the level of physical security associated with an ATM.


/etc/passwd is always world-readable; without it you can't do things like map ownership on files (which only have user and group IDs) to the names of those users / groups. By design, multiple users on a single *nix (or Windows) box can tell who else has an account, and where its profile directory is (not that this is usually at all hard to guess), but not much else. In the classic use of a shared server (providing resources for a corporate or academic department, or similar), knowing other peoples' user names is not really a risk.

Virtualization is easy enough these days that it's kind of weird your hosting service is putting multiple tenants on the same logical machine. It probably means you could (at a minimum) do a partial denial-of-service attack against the other tenants by consuming excessive CPU, RAM, and I/O time (although careful sandboxing can mitigate this). It also might reveal some detail about who your other tenants are, which you otherwise presumably wouldn't know.

As for accessing your directory, the answer is most likely no if the host is keeping the machine up to date. Local privilege escalation bugs are found reasonably often, and usually patched immediately, but if the sysadmin is less that fully vigilant there may be an opportunity between publishing the vuln and it getting patched where it could be abused. With that said, do check the permissions on your home directory - it should be 0700 (full access to you, none to anybody else) - because some poorly-designed *nix systems (coughUbuntucoughOS Xcough) make your home directory world-readable-and-traversable by default. Some programs (OpenSSH, for example) specifically make their files available only to the user, but others (bash in things like .bash_history) are world-readable if the user's home directory is traversable.