How does a security countermeasure failure impact a system? In the context of safety-critical systems, such as transportation systems, it is important to verify if such systems meet/do not meet safety requirements.
ISO26262 expresses these requirements as a maximum number of failures per hour of operation. It is generally of a very small magnitude for the most critical components of a system, i.e., 10^-9 failures per hour of operation at most.

As there is a trend towards inter-connected safety-critical systems, there are higher risks that such systems become the target of remote attackers. In this context, remote attackers can eventually control the system remotely (e.g., CarShark attack or Jeep Cherokee remote control). Therefore, there are cyber-attacks that can impact the safety of the system (i.e., endanger the environment of the system).

Therefore, more and more works are dedicated to integrate security and safety such that the addition of security countermeasures inside a system can increase the system overall safety. In existing works, to the best of my knowledge, nobody takes into account the fact that security mechanisms can fail, just as any other components.

My question to you guys is the following: do you have any information about what could be the consequences of a security countermeasure failure on a component or system safety? Is it possible for example that, if an encryption mechanism fails, it flips a bit in a message which could provoke (eventually) a DoS (or anything else), that could lead to a catastrophic event (again, think of it as a worst case)? Is there any discussion/document about this?

You are asking a quite open question, and I think you are in a too-theoretical situation, whereas in the outside world you would probably find that the critical system is using a Windows XP that hasn't been patched in the last 15 years.

Obviously more security checks will lead to “more complexity” in the code/design, which means a larger surface where things could go wrong. But actually, the extra checks should benefit the whole system.

If the countermeasure is properly designed, it should be clear what the status would be on failure. For instance, a system that was available through plain HTTP may have been updated (the security countermeasures) to use HTTPS. Then there was a failure on this countermeasure (the certificate expired). The result is that the system is no longer available (it fails-closed).
It could instead have been designed to fail deadly. Different systems may have different goals. The important thing is that such goal is documented and a conscious decision. Not just that, "nobody thought that if the countermeasure we added failed, everyone would die".¹

Note that I don't think the case "if an encryption mechanism fails, it flips a bit in a message" is a suitable scenario. There may be bits that get erroneously flipped, and an encryption layer could amplify it (rather than getting one bit wrong, you get a whole block of garbage). However, if the security countermeasure only added encryption (confidentiality), I would consider it as being badly implemented, since you also need to authenticate that what you received is the right message (integrity), which is what you should be detecting in such failure and whose output situation should be defined in some way (stop the car, drop the internet connection...).

As a non-IT security countermeasure "failing", see the following real-life scenario:

Initial state: Terrorists can enter into the plane cockpit and hijack planes
Security countermeasure: a security door is added that can only be opened from the cockpit, in order to protect the pilots.
Final state: One of the pilots can hijack the plane with the "good" crew members not being able to stop him due to the security door.

Here it is not really a "failure" of the security countermeasure, as it is working as intended (not allowing external access to the cabin). Actually the issue is that it is working so well that it then creates a different problem in the system as a whole.

The problematic part would be to detect that in the design phase of the countermeasure. (And then figure out how to mitigate it)

¹ Even if it is done on purpose, the people that would be killed may still object to that design, though.


How did my network admin identify my iPhone and how can I hide my ID? I recently got a call from our network admin asking that I stop the app updates on my iPhone to open up bandwidth. It is my personal phone. My question is 2 part:

Out of all of the personal devices in the office, how was the admin
able to identify the device as mine.
What can I change on my phone so it does not personally identify me?

There's any number of ways that your company's network administrator may have identified you. The principal thing you need to realize is that, while you may be using your own device, you are on your company's network. That grants the company a lot of visibility to the traffic your device generates, should they choose (as it appears they have) to examine it. It also means that you are responsible for complying with your company's policies regarding efficient and appropriate use of their resources (e.g. bandwidth).

The easiest way they could have identified you is by your device's hostname. If it's called "Chuck's iPhone", and you're the only "Chuck" in the office, it's not a huge leap to figure out whose device it is. Changing your hostname is perhaps the simplest thing you can do to obfuscate your identity.

Another way to identify the device is by registration. Your company may have forced you to register via a web portal when you joined the WiFi network. At that time, your iPhone's MAC address could have been logged. Though it's possible to change a device's MAC address, it's rarely done. So it's still a fairly reliable identifier, if you have data to associate it to a person. I'm not aware of any built-in mechanisms to change the iPhone's MAC address, but I've heard there's supposed to be a feature coming in newer iOS versions.

If your phone is making any connections to other corporate systems (e.g. e-mail) while you're on their WiFi, your connections to those systems will be logged. That will associate your company username, which is associated with your identity, to your iPhone's current IP address. The first step to avoid this is to stop using company applications on your phone when you're on the company's WiFi network. (Also make sure that you don't have any apps installed or configured in such a way that they might do so in the background.) The next step, after you've done that, is to get a new IP address. Since you don't know how the DHCP server is configured, the best way to do this would be to disconnect from WiFi, delete the WiFi profile, change your MAC address (if possible), rebuild the WiFi profile, and reconnect. Then, check to make sure that you got assigned a different IP.

The last way they could identify you, which is generally the most difficult to mitigate (especially on a non-jailbroken iPhone), is by direct analysis of your network traffic. Smartphone applications send a lot of data in the clear, both when you're actively using them and when they're running in the background. This data can contain any number of things that might be used to associate the phone to you, personally. It could have your name, user account IDs for online services (which may be based on your name), names of your friends/family, pictures of yourself or friends/family, phone numbers, addresses, or various other flavors of PII. Unless you've personally vetted how every application on your iPhone handles your data, there's no way to know for sure what information might be readily available to the administrators of any network your iPhone connects to. The only way to avoid this is to route all of your iPhone's traffic through a secured VPN gateway. These usually are paid services, and may or may not support your device.

In the end, we come back to what I said in the first paragraph. The company's network is not yours to use however you choose. Especially now that you've been warned, any attempts you make to circumvent their management systems will only further strengthen a disciplinary case against you. Also, just because you might be able to make yourself unidentifiable via network traffic from the data-link layer or above, there are no measures you can take to prevent a network administrator from identifying you at the physical level. With enough access points acting as sensors, network administrators can isolate your device's location to within several meters and follow it as it moves around. This can be used to build an activity profile which could be roughly correlated against your personal work and meetings schedule. To further narrow it down, a tablet or other man-portable device can be used to find your device's location within a few feet.

In short, the best way to keep your personal device from being identified on the company's network is to not use it on the company's network. Keep your personal devices and Internet activities off of corporate hardware, and your network administrators won't care what you do with them.


Restrict access to a specific type of entity I want to create a web service that can only be accessed by a specific type of entity: my own mobile application. Is there any well-accepted methods to do this?

I'm thinking about embedding a secret into this mobile application, but it seems to be susceptible to reverse engineering and can be easily sniffed on network. I would appreciate if anyone can suggest me some alternatives.

Thanks

Client SSL certificate authentication would be something you could consider. Instead of providing credentials, your server will request you to provide a certificate (which you can embed in your application).

A small overview I took from Wikipedia:

  The following full example shows a client being authenticated (in
  addition to the server like above) via TLS using certificates
  exchanged between both peers.

  Negotiation Phase:

  A client sends a ClientHello message specifying the highest TLS    protocol version it supports, a random number, a list of suggested
  cipher suites and compression methods.
  The server responds with a ServerHello message, containing the chosen    protocol version, a random number, cipher suite and
  compression    method from the choices offered by the client. The
  server may also    send a session id as part of the message to perform
  a resumed    handshake.
  The server sends its Certificate message (depending on the selected    cipher suite, this may be omitted by the server).
  The server requests a certificate from the client, so that the    connection can be mutually authenticated, using a CertificateRequest
  message.
  The server sends a ServerHelloDone message, indicating it is done    with handshake negotiation.
  The client responds with a Certificate message, which contains the    client's certificate.
  The client sends a ClientKeyExchange message, which may contain a    PreMasterSecret, public key, or nothing. (Again, this depends on the
  selected cipher.) This PreMasterSecret is encrypted using the public
  key of the server certificate.
  The client sends a CertificateVerify message, which is a signature    over the previous handshake messages using the client's certificate's
  private key. This signature can be verified by using the client's
  certificate's public key. This lets the server know that the client
  has access to the private key of the certificate and thus owns the
  certificate. The client and server then use the random numbers and
  PreMasterSecret to compute a common secret, called the "master
  secret". All other key data for this connection is derived from this
  master secret (and the client- and server-generated random values),
  which is passed through a carefully designed pseudorandom function.
  The client now sends a ChangeCipherSpec record, essentially telling    the server, "Everything I tell you from now on will be authenticated
  (and encrypted if encryption was negotiated). " The ChangeCipherSpec
  is itself a record-level protocol and has type 20 and not 22.
  Finally, the client sends an encrypted Finished message, containing a
  hash and MAC over the previous handshake messages.
  The server will attempt to decrypt the client's Finished message and    verify the hash and MAC. If the decryption or verification
  fails, the    handshake is considered to have failed and the
  connection should be    torn down.
  Finally, the server sends a ChangeCipherSpec, telling the client,    "Everything I tell you from now on will be authenticated (and
  encrypted if encryption was negotiated). " The server sends its own
  encrypted Finished message.
  The client performs the same decryption and verification.

  Application phase:

  At this point, the "handshake" is complete and the application    protocol is enabled, with content type of 23. Application messages
  exchanged between client and server will also be encrypted exactly
  like in their Finished message.


MITM Attack on Gmail's SSL in 2011 I have read these posts: https://www.cnet.com/news/fraudulent-google-certificate-points-to-internet-attack/

https://support.google.com/mail/forum/AAAAK7un8RU3J3r2JqFNTw/?hl=en&gpf=d/category-topic/gmail/share-and-discuss-with-others/3J3r2JqFNTw

As far as I know, a certificate should be installed on a server.

So I don't quite understand how issuing a fraudulent certificate for *.google.com (the spelling of the common name is correct - it is not phishing) could trigger these browser warnings without installing it on a server.

I understand that a private key is in their hands but how did they manage to throw this certificate from the official Google website to users?

Did they install it on a Gmail server?

Could you explain, please?

Within a man in the middle attack the attacker is in the path between client and server and can thus sniff and manipulate the traffic. This is for example possible if the attacker is a government agency which has sufficient control over the traffic leaving and entering the country, as it was true with Iran in this specific case.

In the context of SSL this is used by terminating the connection from the client at the attackers system and then creating a new SSL connection between the attacker system and the server. I.e. the attacker decrypts the traffic from the client, analyzes and manipulates the unencrypted traffic and then encrypts it again when sending it to the server. And the same for traffic from server to client.

In order to terminate the SSL traffic the attacker needs to have a certificate which will be accepted by the victim (the client). Usually the attacker does not have such a certificate which was issued by a publicly trusted CA which causes the client to display a warning that the certificate is not trusted. But in this specific case the attacker could compromise a public CA and make it issue the necessary publicly trusted certificate. With no certificate or CA pinning the browser will simply trust this new certificate since it was issued by a CA trusted in the browser.


What can I do to increase security of a small open source application I've been developing a small CRUDish Ruby on Rails application on my free time for a non-profit organization. The app is already running in a small scale in Heroku.

Lately I've been thinking about open sourcing the application. There are many pros for this, eg. I already know a couple of possible contributors, and even my employer has shown interest in supporting the project in a couple of ways if it would be open source.

Normally I wouldn't hesitate with this kind of possibility at all, but the problem here is that the application stores at least somewhat sensitive information about people using it. I have a fear that as the project is small, and after all will always have just a limited amount of developer time and resources, open sourcing it would attract more malicious hackers than actual contributors. I don't want to harm anyone, and especially not the targeted users of the app, so even the slight increase in propability of a data leak worries me.

When thinking sensibly, I understand that

As the app is very small, there is a very limited possibility that someone would actually try to attack it
RoR gives me quite good and real-life-tested environment to build on top of
Security through obscurity is mostly regarded as non-sense
IMHO pros of open sourcing overweight the cons

I don't want this to became another discussion about Open Source vs Closed Source Systems. However to relief my mind, I'd like to know what can I realisticly do to minimize the possibility of an attack. So far at least these things have wondered through my mind:

Use the latest Rails version, and apply all security fixes as fast as possible
Purchase an SSL certificate and enforce HTTPS connections so that all data that users enter will be transferred encrypted
Encrypt data at the database with a key stored in Heroku config vars. However I'm not so sure about this one, because after all, I have to trust Heroku, and as far as I understand, this would help only in cases where the actual database would be compromised. Or am I mistaken here?
Beg some security company to make an audit to the application for free (as there is no $$ involved)

What else could/should I do?

Look up the OWASP Top 10 (which is the most relevant resource for your question) proposed by edvinas.me and the list of Web-oriented attacks covered by fel1x.

I don't have good advice for Web server security because I haven't done it in ages, but make sure you keep your servers up to date and that they run with only the privileges they need (separate OS account, no write access outside of their own temporary folders, and all other services on your machine should have a private account, /tmp directory and so on). Use encrypted connections for all logged-in users everywhere on your site, and store passwords properly!

You can improve the quality of your code by making sure that:

Input Validation: you verify the domain of all possible user input. You must verify length, type and structure e.g. for strings that you intend to parse later on. Be particularly wary of SQL injections and XSS attacks! See this page for some advice. Make sure to use parameterized queries for your database.
Access Control: you verify that whenever some form of user input is used to access data, access control hooks are in place to verify that this data is within the scope of the user's privileges. Much of this is done implicitly (i.e. your user has an ID associated with their current session and that ID is used to retrieve entries in a database) so it's not always obvious to see what would go wrong. Think in terms of how users could craft their input to access different data/code branches, and how you can ensure that this does not happen.
Bug Hunting: you actively try to crash your server, by using fuzz testing. You should look for generic HTTP fuzzers and do both naive fuzzing (the fuzzer will randomly inject errors in its requests) and more structured fuzzing (the fuzzer knows what packets should look like in your app and will instantiate parameters e.g. the advertised size of a packet, some POST parameters, etc.)
Code reviews: you should really have a third-party pentesting but I understand that you don't have the budget for it. You could ask potential contributors and users to review specific sections of the code and keep a track of which code hasn't been reviewed yet in your project. The people managing GNOME Shell extensions might have some good experience of this to share with you. Note that reviews will not address incorrect installations and server issues and probably not design flaws, usually only obvious bugs...
Documentation: since you're providing an app as FOSS, describe how to set it up securely in some documentation and distribute it along with your sources. Be open to criticism and help from other sysadmins and developers who think you're doing something wrong or not giving the best advice.


Is it possible for an attacker to log my keystrokes on a linux server which has no X window system? assuming the following:

publicly reachable webserver - administered via SSH
no X window system installed and no X11 forwarding through SSH
attacker has gained access and is able to run a shell as my regular non-root admin user

Can they obtain the passwords I type at the command line, e.g

sudo
ssh-add some_priv_key
passwords to access git repositories etc.

If so, are there any precautions I can take to minimise this keylogging risk?

attacker has gained access and is able to run a shell as my regular non-root admin user

If this is the same account as you use to do privileged operations with sudo then the attacker could make changes to your environment which make you run a different binary. In the simplest case this would be changing PATH so that just typing sudo would actually not run /usr/bin/sudo but some rigged /home/admin/.attacker/sudo. This attacker provided sudo implementation could then sniff your password and then just start the real sudo.

But one can make it more stealth, like changing your profile so that it spawns an attacker provided shell with included key logging. Or just run script to log every input and output.

  If so, are there any precautions I can take to minimise this keylogging risk?

Don't allow local users on the system. General hardening of the system. Limit the users with special privileges (like ability to sudo) to only some well-protected accounts.


Within a CSR, is there a field to have the MS PKI server change the default cert filename I'm not intimately familiar with MS PKI, but it was a question that came up in a discussion for an issue a coworker is having. When you input the request fields manually on a PKI server, the cert generated has an automatic name given to it. When requested via a pasted CSR, it's just called cert-new. Is there a field in the CSR that can control this?

From what I've seen, no - usually the certificate signing requests (CSR or PKCS10) are all about what the cert should look like, or what the cert will be describing.  How it's stored when it's retrieved is a matter of the software you are using to request and retrieve the certificate.

I'm not sure quite what you are trying to do, but it's possible to rewrite the client side of the request if you have the time and money to spend - I seem to remember than the Microsoft CA and/or a fronting IIS server can be configured to listen for CSRs and respond appropriately - with that capability, you'd have the option of storing the output any way you like.


How to store passwords written on a physical notebook? Answers to the question "How safe are password managers like LastPass?" suggest that storing personal passwords on a physical notebook might be a reasonable option:

  I know someone who won't use Password Safe and instead has a physical
  notebook with his passwords in obfuscated form. This notebook is
  obviously much safer against malware... whether it's at greater risk
  of loss/theft is an interesting question.

Obviously, a piece of paper is secure against any malware attacks.

  The requirement is for an offline access of credentials. For example a
  small notebook on which you write all your security details for all
  banks, stores, websites, even combination locks, addresses and all
  other details you may wish to be able to access from any location in
  the world.

Also, it can sometimes be easier to look up passwords in a notebook -- e.g. if you travel a lot, you could store passwords on your smartphone using a password manager app. However, this means your phone needs to be charged and operational all the time, which adds another point of failure.

Now, disregarding the posibilities that a notebook might be lost, stolen completely, destroyed or otherwise physically harmed, I'd like to focus on a one question:

How would you obfuscate (as mentioned in the first quote) passwords so that they cannot easily be deciphered by someone who is able to throw a glance at the notebook?

On the other hand, the algorithm must be simple enough so that the owner of the notebook can decode his or her own passwords in almost no time.

Bonus questions:

Could such an algorithm be considered more or less secure even if it's posted here on Information Security or does obfuscation always imply security through obscurity (i.e. keeping the algorithm itself secret)?

Could an obfuscation algorithm be designed in such a way that it would be impossible or unlikely to decipher the passwords, even if a hypothetical attacker had access to the notebook for at least several hours? Or would that naturally contradict the requirement that the owner can decode his/her passwords quickly?

In approximate order of increasing complexity (not security, and methods may be combined), here are some ideas that would be easy for anyone used to puzzles/writing code/maths.  A more complete idea is below.  NB: when I say "secret" I mean not written in the book. These are all easy, and most useful to deter the casual thief.

Have a memorised secret element, common to all passwords. *
Minor variant -- an secret element easily derived from the website name/username.
Put too much information in the book, e.g. know that actually you omit the first 4 characters of each password.*
Offset the account and password by some constant number of entries. *
Never write the full username, just enough to be a clue to you.

* These items have the significant vulnerability that once the obfuscation is cracked for one entry, it's automatically cracked for all entries with no further effort.

If the exact algorithm is published, clearly a notebook-thief who could also script login attempts (or a team of course) could apply the algorithm automagically -- or all published algorithms.  The type of algorithm could be published, for example:

From the password as written, call the first digit x and the second y.
Count x characters from the first punctuation mark (or first character, or first digit).
Then swap the cases of the next y letters (or preceeding y) letters.
For a memorised 4-digit PIN, increment the first four letters by the numbers of the pin (e.g. 1234 applied to a!bcd would give b!dfh).

Of course you could:

Swap the meanings of x and y
Increment/decrement x and y.
Count from the first vowel.
Swap the cases of y consonants.
Replace digits with their corresponding letters by alphabetic position and vice versa.
Swap digits for the punctuation on the same key (you either need to be confident in the keyboard layout you'll encounter or know your own keyboard very well.)

All these operations, by definition, can be scripted.  But the notebook thief would have to get hold of (or write) a script implementing these (and it's actually quite a variable space even without a secret element.  Then they'd have to type in the passwords (an error-prone process with randomly-generated text), run the script over the list, and attempt to log in with the now potentially thousands of passwords per site.  And hope that the site doesn't lock out after several failed attempts.

It would be worth keeping a backup list, even if not a backup copy of the book, as a list of sites for which the passwords should be changed/accounts flagged if the book went missing.

As with many security measures, the goal must be to make it too much effort to break in.  By combining manual and scripted effort you're doing quite a lot towards that, and increasing your chances that they'll give up.


Relative Strength of Automated Password Suggestions Some password management applications suggest strong passwords formed by groups of random words stringed together with a simple delimiter. For example:

duplicate.aught.cavemen.length

In contrast, I believe that a suggestion based on groups of four digits is not as noisy (important when trying to read and type the password), easier to support (no need to research and maintain a dictionary), and just as secure in practice. For example:

1202.8746.9173.0953

The alternative shown, is equivalent to stringing four random words extracted from a 10,000-word dictionary to which everyone has access.

As presented, an attacker who is neither lucky nor unlucky would need to check about 158 million guesses per second to crack the password in one year.

Provided that both are generated using a cryptographically-secure RNG and persisted using a strong key derivation function, would you have any reason to prefer a dictionary-based policy over a random-digit policy?

The "phrase of random words" is much easier to remember

The text duplicate.aught.cavemen.length is easier to remember than 1202.8746.9173.0953. The problem with the latter is that you need to remember the right digits in a search space where there's no meaning attached to it (Was it 9173 or 9174?). You can have some doubts with the words (perhaps trying cavemen or troglodyte), but in the end, the familiar dictionary makes it is easier to remember.


Should users be able to update their avatar using URL instead of uploading a file? I am building a web application where a user can update his avatar by uploading a picture from his computer file directory. Here's how I implemented it:

<input id="profile_pic" class="avatar-upload" type="file">

However, I have noticed that if a user changes type="file" to type="url", he will be able to upload a picture using any URL.
So is it a safe option or should I prohibit users to act so? How can this be exploited?

Assuming the user is submitting a URL that is then stored on the server and put into the image link:

Its generally good practice for web sites to not give up personal info about their users (including IP addresses) which, if you put a URL to a server you control with an avatar that will only be used by that one site, an attacker could use to build a list of all the users' IP addresses and probably even cross reference it with when they are posting or show up as "online" to narrow down who is which IP.  While it is still possible to gather this (i.e. by posting a link to the same, that entices users to click on it) having it done automatically is bad form.  Users can't avoid giving away their IP to any other user when visiting the page.  I would strongly advise against this as a "feature".


Can a phishing website use the original (HTTPS, TLS) certificate? If one has a phishing website that uses the original certificate that was obtained by accessing that website, can an attack fool users to believe they are accessing legitimate websites?

If not, how will it get caught?

If one has a phishing website that uses the original certificate that was obtained by accessing that website,

No it cannot, because it does not have access to the original website's private key. If it could, the whole PKI would make no sense at all.

  can an attack fool users to believe they are accessing legitimate websites?

Yes, but using means other than the original certificate.

  If not, how will it get caught?

The phishing website will not "get caught". User will not see a correct certificate in the client's browser.


Find salt from md5 hash if password is known I have a salted MD5 hash and I also know the password. How can I recover the salt using tools like John The Ripper (I have JTR jumbo installed)?

With known plaintext, and assuming salting that uses simple string concatenation, some password-cracking suites like hashcat or MDXfind will let you bruteforce the salt. This will only be practical for simple salts (short enough to bruteforce, or if the character set of the salt is known well enough to keep the keyspace small).

For hashcat, the (perhaps non-intuitive) trick is to pretend that the salt is the password, and the password is the salt. This works when the salting is performed as a simple concatenation.

In this example, the known plaintext password is "password" and the unknown salt is "GR7". We'll be using hashcat's algorithm mode 20 (md5($salt.$pass)).

Here's the salted hash:

$ echo -n 'passwordGR7' | md5sum
a598e9df477f07dadee6b6bee9ac1daa  -

... and here's the target hash and "salt" (in the expected hash:salt format), but the "salt" is actually our known plaintext password:

$ cat hash.list
a598e9df477f07dadee6b6bee9ac1daa:password

We then use a '?a?a?a' mask (all three-character printable strings) as potential "passwords" (really the salt):

$ hashcat --quiet -m 20 -a 3 hash.list ?a?a?a
a598e9df477f07dadee6b6bee9ac1daa:password:GR7

To handle salts of different lengths or formats, simply adjust the mask  or attack type. If the length of the salt isn't known, use --increment to try all lengths up to the length of the supplied mask.

If the salt is prepended instead of appended, hashcat mode 10 (md5($pass.salt)) can be used instead (again, remembering that the "pass" in this context is actually the salt, using the same method as above).

I haven't explicitly done this with John the Ripper, but since John supports md5($p.$s) and md5($s.$p) using dynamic formats, I believe that the same technique can be used with John. But these dynamic formats are only on CPU at this writing, so if you have GPUs available, I'd recommend taking a look at hashcat instead.


Can WiFi absorbing wallpaper absorb enough signal to provide a legitimate security benefit? This French website reports that a wifi-absorbing wallpaper provides a security benefit.  Is there any legitimate support for this, assuming that most rooms have windows, and signal can escape from there?

If wallpaper absorbs RF energy and not reflects, then the only way to gain access to wifi is by a direct line of sight through the window. And I would never call Wifi absorbing wallpaper a security measure. Its primary purpose is to reduce interference.


Which host key algorithm is best to use for SSH? When you first connect to an SSH server that is not contained inside your known_hosts file your SSH client displays the fingerprint of the public key that the server gave. I found from this question here that as a client you are able to specify within ssh_config which one of the public key pairs from the hosts' /etc/ssh/ directory you would like.

From the ssh_config man page I found that the current defaults are as follows:

    ecdsa-sha2-nistp256-cert-v01@openssh.com,
    ecdsa-sha2-nistp384-cert-v01@openssh.com,
    ecdsa-sha2-nistp521-cert-v01@openssh.com,
    ssh-ed25519-cert-v01@openssh.com,
    ssh-rsa-cert-v01@openssh.com,
    ssh-dss-cert-v01@openssh.com,
    ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,
    ecdsa-sha2-nistp521,ssh-ed25519,
    ssh-rsa,ssh-dss

Only recently my SSH server has been sending me a ECDSA fingerprint instead of an RSA, but I was wondering which algorithm should I choose if it even matters?

This article claims that ECDSA is the old elliptic-curve DSA implementation that is known to have severe vulnerabilites
Should I be using RSA or the newest ed25519 algorithm?

Currently,

RSA is still recommended as a gold standard (strong, wide compatible)
ed25519 is good (independent of NIST, but not compatible with all old clients).

Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones.

Frankly, for you, as an end user, it should not matter. Some of the keys might have some security concerns, but none of them is considered completely broken with reasonable lengths, which could possibly cause man-in-the-middle attack or something similar.

The article mentions "severe vulnerabilites", but not saying anything specific. If it had such serve vulnerability, nobody would use it, support it, nor recommend it. Without any reference, it is pretty hard to comment on your concerns.


Unexpected TLS extension reply in server hello What is the expected behavior when a server hello contains an unexpected reply for a TLS extension (e.g. ALPN)?

Should I (as a client) terminate the connection or just ignore the extension? Is it defined in the RFC? Should the behavior be different for different extensions?

In the TLS 1.2 RFC Section 7.4.1.4 it says the following:

  An extension type MUST NOT appear in the ServerHello unless the same
     extension type appeared in the corresponding ClientHello.  If a
     client receives an extension type in ServerHello that it did not
     request in the associated ClientHello, it MUST abort the handshake
     with an unsupported_extension fatal alert.

For TLSv1 and TLSv1.1 look to RFC 3546 which applies to both versions.

Section 2.3:

  Note that for all extension types (including those defined in
     future), the extension type MUST NOT appear in the extended server
     hello unless the same extension type appeared in the corresponding
     client hello.  Thus clients MUST abort the handshake if they receive
     an extension type in the extended server hello that they did not
     request in the associated (extended) client hello.

Section 4: Error Alerts

  "unsupported_extension" - this alert is sent by clients that
        receive an extended server hello containing an extension that they
        did not put in the corresponding client hello (see Section 2.3).
        This message is always fatal.


Which key questions to ask while vetting an incident response company? If I ever suspect a security incident exceeding internal capacity & skill sets, my plan calls for outside professionals. In choosing a specific Company, I expect to expose the company to these risks:

Company does not have someone available for us right when we need them
Company sends someone lacking experience & competence to help us
our understanding of how much it costs to involve Company is way off
their services are are delayed beyond the desired damage control, e.g. by our inability to provide the documentation and credential-sharing they need, or by our inability to efficiently communicate with essentially unknown contractors

What I have:

two companies which someone I trust praised
hourly rates (but no idea how they translate to totals)

Questions I considered:

How long has Company been in the security business? -> XX years.
Does Company present at relevant conferences? -> Yes, at X-con.
Does Company employ sufficient personnel to suggst immediate availability? -> They claim XX!
How does Company homepage look? -> Full of essentially meaningless security buzzwords
Do they employ notable people? -> Yes, author of tool X worked there at some point.
Did we encounter them before? -> I once read a pretty neat writeup on Company blog. And I was once in a short call with Ms W. from Company who confirmed that yes, they do "incident response" a lot.

I do not believe these questions adequately help mitigate those risks. How should I improve my vetting to verify whether my choices really do mitigate some of the relevant risks?

When vetting a company where you are unqualified to assess the service they would provide, the main thing to ask for are references where you can talk to their own customers.
As for your list of risks that you want to mitigate:
The biggest mitigation is the contract, not the qualifying questions you ask.

Company does not have someone available for us right when we need them

If you need a certain availability, that should be in the SLA, not a question on a vetting list.

Company sends someone lacking experience & competence to help us

This is also an SLA issue. The maximum level of the expertise in the company is determined by the vetting process, but who they ultimately send needs to be covered in an SLA.

Our understanding of how much it costs to involve Company is way off

This isn't a vetting question at all, but a contract question.

we lack experience & competence to efficiently communicate with essentially unknown contractors during a crisis

we lack appropriate documentation and credential-sharing procedures to get them setup quickly

These are not vetting questions at all, but completely separate issues. I'm not sure why they are on the list.


Security hole when bridging OpenVPN tap interface with the same ethernet interface used to connect to the internet I currently have the following network set up:

A few desktops connect to my modem (which doubles as a Wifi router) via Ethernet cables.
A few laptops connect to my modem via Wifi.
All PCs are in the same private subnet, and run Windows.
A Raspberry Pi 3 connects to my modem via Wifi (which I currently use as my CCTV).

I intend to turn my Pi into a OpenVPN server, so that I can access my resources on my PC, and play LAN game while being away from home. From what I've gathered, bridge mode with TAP seems to be the most suitable solution. I would try something like this:

Create a TAP interface and bridge it with my Pi's wireless interface.
On the modem, forward OpenVPN port to my Pi's IP address.
Config so that remote devices will be in the same subnet as local devices.

However, according to this link https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

  Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole.

So my questions are:

When they say potential security hole, what vulnerability does they mean?
Does the wireless interface on my Pi counts as a private interface or a internet connected interface in this case (after all, everything is behind a modem)?

Your rpi interface is not directly connected to the Internet, and thus the warning does not apply.

You are behind a modem/NAT, as you say your are forwarding the OpenVPN port. So the other ports are firewalled e.g. inaccessible.

The problem here would be if you had your rpi like my lamobo R1, which is the router for the Internet, and the machine doing NAT.


TLS at layer 4 BUT 802.1X EAP-TLS at layer 2? In the CISSP books, SSL/TLS has been through the arguments and fell rest onto the transport layer 2 instead of the session. OK - Fine.

Port security 802.1X and EAP is a data link layer 2 authentication mechanism. Since EAP is a framework, it consists of EAP-TLS (among others like EAP-TTLS, PEAP and LEAP).

There maybe something silly I am missing here, but how can the book call EAP-TLS a layer 2 authentication mechanism when TLS doesn't even kick into the picture until layer 4?

The "layers" are from an old ISO abstract classification which has been applied to how things really run in the physical world, often with the rhetorical equivalent of a sledgehammer. You should not try to follow layers as gospel, it will often lead to confusion.

SSL/TLS is a protocol which can be applied over a bidirectional data tunnel, and which provides a bidirectional data tunnel, with authentication (server by client, or mutual), confidentiality (through encryption) and verified integrity. In terms of "layers", it goes right between layer 4 and layer 6 of the OSI model, which shows that the concept of "layers" fails to capture the actual position of SSL/TLS.

It so happens that the authentication part of SSL/TLS (the "handshake") consists in a series of messages, which are exchanged in an alternate sequence; see the TLS specification, page 36, for a diagram showing that sequence. In "normal" SSL/TLS, the messages are exchanged over whatever bidirectional data tunnel SSL/TLS is applied on, usually a TCP connection. However, the cryptographic properties of the handshake come from the message contents, not from how they are sent. At that point, consider EAP: this is a framework for authentication protocols, consisting in messages; EAP is meant to be used over any transport mechanism which can send messages ("layer 2" if you really want to think about it in layers). Hence EAP-TLS has been defined: this is an authentication protocol, consisting in a sequence of messages which are the ones specified for the SSL/TLS handshake -- but sent as so many messages over the transport mechanism used by EAP. EAP-TLS is not TLS, it does not provide a tunnel for data; it is a protocol which reuses parts of the handshake which occurs at the beginning of a TLS connection.


How does streaming and downloading work on Zero Knowledge-based cloud storage services? So there are a few cloud storage services such as mega.nz, syn.com and others which state that they use zero knowledge encryption. This would mean that they don't have access to the private keys which are required to decrypt and view the content stored by a user on their cloud storage.
If that is the case, then how is it possible to do the following?

I login to my account and I can view all the content and even stream it (for example, videos can be played directly). Does it mean that all this is decrypted on the fly when I login to the account?

If I generate a download link and share it with another user, how are they able to download the content using that download link even though they don't have the password to my account which would be required to decrypt the content?

Or does mega.nz store the information required to decrypt the content in the link itself? For instance, decryption key is a part of the download link?
I wonder if there is a way to actually verify that these cloud storage services which claim to use zero knowledge encryption are indeed using it? Maybe there is some type of third party audit done to confirm this?

Or does mega.nz store the information required to decrypt the content in the link itself? For instance, decryption key is a part of the download link?

Exactly. You can notice that their link contain a hash and a bunch of characters. Anything after the # is not sent to the web server in the petition (that's supposed to contain the anchor to which the client browser should jump). The encryption key is provided to the other party in that section of the link there. The browser javascript is able to access that part of the url and decrypt it completely client side (note that as the javascript is also provided by the cloud storage, they could use a "malicious" javascript to leak it to them).

I wonder if there is a way to actually verify that these cloud storage services which claim to use zero knowledge encryption are indeed using it?

You could use a third-party program to operate with their service. If they are following their documented api and encrypting locally the file contents, then the service supports not knowing the contents of the file (this doesn't mean it won't leak them otherwise, but it's possible). Quoting from an old megatools changelog entry:

Megareg tool is now implemented, and can be used to register new
accounts without the need for Mega website. Unless you login to
Mega, Mega will never be able to get your password key.

Generally, local clients or web extensions are safer than the site javascript, as that one is under complete control of the website. If you are a trusted client which only shares with the service files encrypted locally (in a safe way, etc.). then you can be sure they won't be able to access your files.
(Note that they might gain that ability once you provide them your password through their web interface!)
Additionally, for your peace of mind, you could always encrypt a file locally before uploading to a cloud ervice, even if it's one which supposedly encrypts the file itself in a way that the service is unable to access them.


How vulnerability scanners identify version of services on targets I would like to know that how vulnerability scanners identify the version of services running on the target after identifying the service by the port number.

How Fingerprinting works

For every service fingerprinting would be done differently, generally, it works by finding differences between the implementations, and using them to detect the version of the software, I have included a few simple examples:

SSH

If you run the following command:

nc HOST 22

You can see that the first thing that a server sends is a string identifying it's version, such as:

SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

From this you can get the version

HTTP

If you run the following command:

curl -v URL > /dev/null

You can see that the server sends many headers, one of which is likely to look like this:

< Server: cloudflare

This can show you the server if it has not been changed, and possibly the plugins running also

Wordpress

Looking at the feed available at /feed/ gives an xml file with the following tag:

<generator>https://wordpress.org/?v=4.9.2</generator>

If this is disabled then differences in the readme can be used to detect the version instead


Msf and exploitdb on Backtrack 5 Metasploit (msf) doesn't see exploits from exploitdb. I've just updated directory on my Backtrack

cd /pentest/exploits/exploitdb
svn update

How can I load them now into msf? When i use a script searchsploit <name> I can find what I need, but I don't know how to load it inside msf.

Metasploit develop their own exploit database. You cannot simply load a random exploit from ExploitDB into Metasploit.


Is OpenID Connect implicit flow safe to use? In researching OAuth 2.0, I see that implicit grant is no longer recommended:-

  In order to avoid these issues, clients SHOULD NOT use the implicit
  grant (response type "token") or any other response type issuing
  access tokens in the authorization response, such as "token id_token"
  and "code token id_token", unless the issued access tokens are
  sender-constrained and access token injection in the authorization
  response is prevented.

(source OAuth 2.0 Security Best Current Practice)

I'm looking into the implementation of Open ID Connect (specifically the Microsoft implementation for Azure AD) and notice the OpenID concept of implicit flow is the basis for many of their implementation examples.

I can see that implicit grant != implicit flow, however, the explanations of the various scenarios seem to indicate that it works the same way, and it's not immediately obvious what the material differences are (at least to me).

For example, the flow diagrams for implicit grant and OpenID connect appear to be very similar.

Is OpenID Connect implicit flow as unsafe as OAuth 2.0 implicit grant, or does it somehow avoid/mediate the issues that cause implicit grant to be discouraged?

Implicit Flow is now discouraged in favour of Code Flow with PKCE. This is a fairly recent change (in the last year or so), which is why you might see quite a lot of documentation and libraries still recommending Implicit Flow, and support for Code Flow with PKCE is sometimes still lacking in OIDC libraries.

The main concern with Implicit Flow is that at the end of the authentication process, the user is redirected from the identity provider to your app with an access token in the URL. Visited URLs are often stored in browser history and other places, so there is a risk of a malicious actor gaining access to that token and impersonating the logged in user.

Code Flow with PKCE on the other hand makes a HTTP request for the token instead, allowing it to be returned in the body of the response.

This blog has a good comparison of the two.


java keytool - how to modify a keystore's Owner and Issuer information? I have a product that initially used a keystore in which the certificate as the Owner and Issuer information as "unknown".

Now for security policy reasons and still guaranteeing back compatibility I have to update the Owner and Issuer information while retaining the original public/private key pair (for back compatibility).

Is it possible to do such thing?

TLDR: You can't modify a cert; you can and should replace it.

You can't change anything within a certificate because it is digitally signed precisely to prevent anyone from changing anything in it. However, you can get a new certificate for the same keypair but with new dates, different name(s), and possibly other changes.

No real CA issues a cert with either Owner (which is really Subject) or Issuer containing only 'unknown', much less both, so this is almost certainly the dummy (placeholder) self-signed cert created by keytool when it generates a keypair.

If you want to get a 'real' cert from an established, trusted Certificate Authority aka CA, you can do so with keytool; in fact this is the normal process:

keytool -genkeypair: create keypair and selfsigned cert (in keystore)
keytool -certreq: create Cert Signing Request aka CSR (for keypair in keystore)
send CSR to CA along with evidence of identity (often, especially for SSL/TLS server, an Internet domain name, but sometimes another kind of identity) and if applicable payment
receive/fetch new cert from CA along with any applicable 'chain' or 'intermediate' certs
keytool -importcert: install new cert and chain into keystore

See the Java manual at e.g. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html#keytool_examples . The details of steps 3 and 4 vary depending on the CA you use, and all CAs I've ever seen have customized instructions for issuing a cert to a Java system, often listed under Tomcat as the 'typical' Java system, tailored to that CA. You effectively have already done step 1 but with the wrong subject name, and need to complete the remaining steps with one variation:

in step 2 keytool -certreq add the option -dname 'newnamefields' (use " on Windows) to specify the corrected requester/Subject name for the CSR.

General info about cert names is on the same page at the heading X.500 Distinguished Names. If this cert (and key) will be for an SSL/TLS server, the Subject name should be or include 'CN=servername' where servername is not the name of a person as described in the manual, but instead the name, or a wildcard (in first component only) matching the name, of the server as it is accessed by client(s). For public/Internet servers this is usually a Fully Qualified Domain Name aka FQDN or in rare cases an IP address, but some intranet or LAN environments use other names.

Otherwise: if you want to create a new selfsigned cert, keytool does not have an option for that; you can write a program to do it, but it's easier, though a bit roundabout, to use OpenSSL instead. You can also use OpenSSL to request a real CA cert with some options that keytool doesn't support. If you are on Linux you most likely already have OpenSSL; on other Unix you may need to install it, almost always from the vendor's normal repository/channel/etc; on Windows (unless Windows10 with WSL) you will need to install the ShiningLight package. In outline this is:

keytool -importkeystore -srckeystore jksfile -destkeystore tempp12 -deststoretype pkcs12 # convert from Java-only JKS to standardized PKCS12
openssl pkcs12 -in tempp12 -nocerts -out tempkey # convert from PKCS12 to OpenSSL's 'private' PEM format
For selfsigned: openssl req -new -x509 -inkey tempkey -validity days -out newcert and answer prompts for the name (or instead specify -subj 'namefields'); see man req on Unix for details, or on the web or earlier version as applicable. Then keytool -importcert -file newcert -keystore jksfile [-alias entry_if_not_mykey]
For CA-signed: modify the OpenSSL config file (or a copy) if need then openssl req -new [-config conffile] -inkey tempkey [-subj 'namefields'] -out csrfile then submit this CSR to a CA in the same fashion as for Java above. When you get a new cert and its chain, do one of the following:

4a. keytool -importcert the needed chain cert(s) to a different entry, or  to different entries individually from the top down, then the EE cert to the same entry, as described for Java

4b. combine the EE cert and its chain certs, all in PEM, into a single file, and keytool -importcert the whole chain to the same entry

4c. use openssl pkcs12 -export to combine tempkey plus the (new) cert and chain into a single file say newp12, per man pkcs12 or here or earlier, then keytool -importkeystore -srckeystore newp12 -srcstoretype pkcs12 -destkeystore jksfile after deleting the old entry, or just deleting the file if this is only (desired) entry


Regulations that specify password length? I have read:

PCI DSS 1.2
SOX 404
AR 25-2
ISO 27001

But only PCI DSS specifies a minimum password length.

Are there any other regulations that dictate password lengths for any industry?

NIST documents talk about the impacts of certain lengths and complexities [NIST SP 800-63b now provides guidance on password length]. OWASP, SANS, and others give their opinions on password minimums, but they couldn't be considered official.

Not looking for recommendations or impacts of various lengths, but actual regulations that require a certain length. For the purposes of this question, it doesn't even matter if the regulations are good or not, just some regulatory body saying that passwords must be at least a certain length.

I believe the National Institute of Standards and Technology (NIST) publishes the United States Government Configuration Baseline (USGCB, formerly known as Federal Desktop Core Configuration or FDCC) checklists, which specify the password complexity, lifetime, and history requirements for U.S. federal organizations.  Also, the Center for Internet Security (CIS) publishes Benchmarks for various platforms, which include similar recommendations.

Between the two, the highest mark is:

12 characters minimum.
At least three character types.
Expiration in 60 days.
Minimum lifetime of 1 day.
No reuse within 24 passwords.
Some OS-specific additional requirements may be applied.

Those settings are applied at the OS level.  I'm not sure if either organization has similar specifications specifically targeting applications or websites, but most organizations which are subject to these will probably just use the same requirements as they do in the OS.

A Google search for any of the above terms should turn up a wealth of information.  (I may add links here myself later, or anyone else is free to edit them in.)


Is my server under some kind of reconnaisance/attack? Recently, I started up nginx on an Amazon EC2 instance. After a day, I started seeing these messages in my log. Some client keeps trying to call /add and /health.html on my server.

I don't have those files on my server, so my server tries to return a 404.html (I should really put one).

my-server | 54.71.125.15 - - [11/Feb/2019:01:35:15 +0000] "GET /health.html HTTP/1.1" 404 153 "-" "-" "-"
my-server | 54.71.125.15 - - [11/Feb/2019:01:35:15 +0000] "GET /add HTTP/1.1" 404 153 "-" "-" "-"
my-server | 54.71.125.15 - - [11/Feb/2019:01:36:14 +0000] "GET /add HTTP/1.1" 404 153 "-" "-" "-"
my-server | 54.71.125.15 - - [11/Feb/2019:01:36:14 +0000] "GET /health.html HTTP/1.1" 404 153 "-" "-" "-"
my-server | 2019/02/11 01:36:14 [error] 7#7: *4106 open() "/usr/share/nginx/html/add" failed (2: No such file or directory), client: 54.71.125.15, server: _, request: "GET /add HT
TP/1.1", host: "ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com"
my-server | 2019/02/11 01:36:14 [error] 7#7: *4106 open() "/usr/share/nginx/html/404.html" failed (2: No such file or directory), client: 54.71.125.15, server: _, request: "GET /a
dd HTTP/1.1", host: "ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com"

Upon doing an nslookup of the client, it appears to be an EC2 instance in us-west-2.

$ nslookup 54.71.125.15
Server:         172.31.0.2
Address:        172.31.0.2#53

Non-authoritative answer:
15.125.71.54.in-addr.arpa       name = ec2-54-71-125-15.us-west-2.compute.amazonaws.com.

Am I under some kind of attack? If so, what is the attacker trying to exploit?

These appear related to EC2 health checks

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html

So I'd say no you are not under any type of recon check


How to restrict access to unwanted sites? I use Ubuntu 13.10. I tried to used OpenDNS to restrict some websites. Unfortunately, I couldn't do that. I use AirStream 1200 USB modem to access WiMax internet. OpenDNS setting didn't work for me at all. Any alternatives to OpenDNS or any methods to secure my web browsing. I want solution that can't be easily hacked.

I advise you to install squid.
It is a highly customisable web cache providing many configuration possibilities to protect of most of the attack web servers.
I'm using it to protect my network of add web servers, spying web servers,
any web servers without a DNS name, and many other sorts of attacks.

I'm testing many a priori filtering, and most of them are successfull:
when checking afterward the blocked web server I often discover a well
of malware.


Result disparity between nmap and curl/nc for TRACE method By using nc or curl I get HTTP status code 405 for TRACE requests, but if I scan my site with NMAP, it seems that TRACE is enabled. Could someone explain to me if TRACE is correctly disabled or not?

NC

nc hd1.aon.it 443
TRACE /js/jquery.cookie.js?param=1 HTTP/1.1
Host: hd1.aon.it
X-Wind: custom

HTTP/1.1 405 Method Not Allowed
Content-Length: 83
Content-Type: text/html
Date: Thu, 12 Jan 2017 12:59:04 GMT
Via: HTTP/1.1 sophos.http.proxy:3128
Connection: keep-alive

Error405 - Method Not Allowed

NMAP

nmap -p 443 --script http-methods hd1.aon.it

Starting Nmap 6.46 ( http://nmap.org ) at 2017-01-12 13:41 CET
Nmap scan report for hd1.aon.it (93.63.129.73)
Host is up (0.00026s latency).
rDNS record for 93.63.129.73: 93-63-129-73.ip27.fastwebnet.it
PORT    STATE SERVICE
443/tcp open  https
| http-methods: GET HEAD POST TRACE OPTIONS
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 2.19 seconds

The http-methods script just issues an options requests and if this returns Allow methods than it trusts this information. Just try an OPTIONS request and you will get the following response:

> OPTIONS / HTTP/1.0

< HTTP/1.1 500 Internal Server Error
< Allow: GET, HEAD, POST, TRACE, OPTIONS
...

Thus the OPTIONS request itself reports that TRACE is supported. And actually the method is supported by the server:

> TRACE / HTTP/1.0

< HTTP/1.1 405 Method Not Allowed
< ...

This means that the server supports this method but actively refuses using it, at least with specific URLs. Not supported methods would result in a different kind of response:

> FOO / HTTP/1.0

< HTTP/1.0 501 Not Implemented
< ...

  ... it seems that TRACE is enabled

nmap does not check if enabled or not, it checks if it supported (i.e. implemented and allowed according to OPTIONS) or not. Actively denying use of the method on specific resources does not mean that the option is not supported, i.e. implemented in the server and maybe available for specific resources.


How can I decrypt ADFS-based SAML/p or WS-Trust claims? I'd like to audit the claims that are sent to a client from a SAML/p or WS-Trust authentication.

What private keys do I need and how would I decrypt this information?

If it makes any difference, I'm auditing Microsoft ADFSv2 and a SiteMinder implementation

SAML tokens, if they are encrypted, are encrypted against the X509 certificate of the relaying party, either the public HTTPS certificate, or an agreed upon certificate between the STS and RP.

So you'd need to private key for that certificate to decrypt.


What issues exist in generating a signed, paper-based PGP message stored by a hostile organisation? I have recently been the victim of having my medical record tampered with by the organisation holding it. Under state law I have a legal right to submit information to be included in my medical record, but I cannot request any information to be deleted (including information I have submitted). I plan on generating a notice to be inserted advising anyone - and any other entities who might obtain access - of the tampering.

Considering the organisation is hostile and may attempt to tamper with the notice as well, I figured cryptographically signing it with my PGP key would be the perfect solution. However, the organisation exclusively uses a paper-based record system.

The notice:

must be output in paper form
should be A4 sheets
must be in a legible format for the content of the notice to be immediately readable (ie. easily read by non-technical persons)
must be able to support several physical pages of plaintext at a standard font (ie. if the content of the notice were to be printed as is, it would be several physical pages long)
must be able to be verified in the future in some manner (ie. by another entity), possibly with/without my involvement in authenticating it
must be kept confidential, subject to the same confidentially as with the rest of my medical record (the content of the notice cannot be external to the medical record and obviously cannot exist publicly)
must be capable of being verified after being [photo]copied in the future
may be damaged (ie. stapling, wear-and-tear, etc...)

What issues might I run into if I generate and sign the notice?

What issues might I run into if I generate and sign the notice?

Not considering the practical issues with paper-based digital signatures, let's consider what an attacker could do with your signed message. Consider the attacker a man in the middle: he's broking the information between you and possible readers of the records.

Obviously he cannot modify it maintaining a proper signature.
He is able to suppress the message, not handing it over to people reading the records.
He is able to replace the document by another, unsigned and modified copy.

You can hardly change anything about these, unless the reading party is expecting a signed statement.

There are some practical, technical issues with digital signatures: you must be able to derive an exact digital copy of the analog paper-based document, even the tiniest change will result in broken signatures. OCR is not a proper method of doing so, although compare with the publishing of PGP's source code having each line annotated with a checksum. The signature itself makes things even worse, being a rather large (for human readers) unstructured pile of hexadecimal or Base64-like encoded data (at least, this is the obvious representation likely to be chosen).

Encoding in a machine-readable manner (like QR codes) will enable proper reproduction of the signed message, but prevent humans from reading the documents immediately. There is no standard for digital signatures on paper-based documents, and I'm not aware of any applications providing easy access. You'd have to put everything together using several components, describe the workflow and the reading party would have to do everything in reverse: I would not expect people in medicine being able to understand such technical documentation, and additionally also have a proper understanding of cryptography required to analyze any issues and possible attacks.


Which method of WPA2 enterprise is more secure: TTLS or PEAP Say we have two WPA2 enterprise setups using a RADIUS server. If both implementations use MSCHAPV2 and the same credentials. Which of the two would be more secure and how are these two implementations actually different.

The difference between these 2 implementations is that one uses Tunneled TLS (TTLS) and the other PEAP.

By secure I mean protection to:

Bypassing authentication
Session hijacking
Sniffing traffic ( and decoding )

The most upvoted answer:

  PEAPv0, PEAPv1 and TTLS have the same security properties.

  PEAP is a SSL wrapper around EAP carrying EAP. TTLS is a SSL wrapper
  around diameter TLVs carrying RADIUS authentication attributes.

  EAP-TTLS-PAP can be useful over EAP-PEAP if backend authentication
  database store credentials in a non-reversible hash format such as
  bigcrypt or any form not compatible with MSCHAP (NT-OWF) In this case
  it is not possible to authenticate using any of the CHAP based
  methods.

  While you could also emulate PAP using EAP-PEAPv1-GTC this is not as
  widely supported by clients.

  PEAP has some added baggage over TTLS in the form of PEAP version
  negotiation headaches and historical incompatibilities in PEAPv1 (Such
  as client magic when deriving master key from PRF) which have made
  their way into early implementations.

  I normally see EAP-TTLS implemented in embedded clients such as
  subscriber modules in wireless gear with PEAP used more by laptop
  computers and mobile handsets.

  EAP-TTLS has historically not been supported in Windows clients
  without having to install third party software. EAP-TTLS is now
  supported starting with Windows 8.

  Some additional thoughts:

  EAP-TTLS was invented by a RADIUS vendor. EAP-PEAPv0 was invented by
  Microsoft. EAP-PEAPv1 came out of the IETF process.

  There was some additional IETF work on a PEAPv2 which would have made
  the system more secure by way of crypto bindings to inner
  authentication methods. This has not gone anywhere as near as I can
  tell.

The accepted answer was:

  You can support both, if your RADIUS backend supports it. However some
  clients "auto"-connects (Mac OS X >= 10.7 + iOS for example), and they
  might work less than optimal if you support more than one type, since
  they just try different combinations until one of them works i.e. they
  connect with less hassle if there's only one way to connect.

  So Basically: support PEAP only, or PEAP+TTLS if you have clients that
  require TTLS.

Source: Why would you use EAP-TTLS instead of PEAP?


Will double encryption increase the security of cipher vs bruteforce? Assume I have a function encrypt(mes,key) where mes is the message, and key is the key. The length of key is 64 bits. Last but not least: assume the only way to crack my cipher is a brute-force attack.

If I use double_encrypt(mes,key1,key2) = encrypt(encrypt(mes,key1),key2)), does definition of double_encrypt() mean that only way to crack double_encrypt() is to brute-force a 128 bit key?

I was told that it does not, but I can not come up with any attack with better performance than a simple 128 bit brute-force.

First point: there is a practical security increase only if both encryption algorithms, taken alone, would be independently vulnerable to exhaustive search, i.e. by using too small a key. That is the main issue, and it is better to fix that. Exhaustive search works only up to the key sizes such that the space of key can be enumerated with existing or foreseeable technology. There are good reasons why a 128-bit key would resist such attempts. Thus, if you use a decent encryption algorithm, there is no need to "double" it. There is no security level beyond "cannot break it": you cannot not-break an algorithm more than "not at all".

Doubling or tripling algorithms has been used in older days to reuse previous algorithms which were definitely too weak on their own; the prime example is Triple-DES (aka "3DES"), built over the previous DES. DES and its 56-bit key space is vulnerable to exhaustive search (it has been done). As @CodesInChaos points out in his comment, doubling and tripling don't give you your money worth: double-DES would use 112-but keys, but would not offer 112-bit security.

In a nutshell, for double-DES, the attacker would encrypt the known plaintext with the first DES and all possible keys k1 (256 possibilities), and also decrypt the known ciphertext with all possible keys k2 (256 possibilities again), and then look for a match in the two sets of 256 "intermediate values". Matching will have cost about 2·56·256, i.e. about 263 (that's the cost of sorting the two sets, so that matches are detected with a linear search). With a merge sort, the sorting-and-matching steps only require linear access, thus compatible with hard disks. We are talking here about 257 128-bit values (two known plaintext blocks, so that there won't be ambiguity about the keys), aka 261 bytes, aka 2 millions of terabytes. One million hard disks is expensive... but technologically doable, contrary to a 2112 exhaustive key search.

Therefore, doubling algorithms does not bring that much of a benefit. Tripling increases security when beginning with weak algorithms (at least when the weakness is only about key size), but, there again, not as much as the invested effort (with 3DES, you have 168 bits of key, but resistance is "only" up to 2112). Of course, tripling also means dividing performance by three, which may or may not be tolerable in any given context. Tripling, quadrupling... does not fix other issues, such as blocks which are too small (3DES still uses the 64-bit blocks of DES, which means that serious issues arise when encrypting about 232 blocks worth of data with a given key, i.e. about 32 gigabytes, which is not much by today's standards).

It is much better to start with an encryption algorithm (like AES) which does not have exhaustive search issues to begin with, making doubling or tripling useless. Doubling (or tripling) algorithms is like a pegleg: it helps you keep upright if you had the misfortune of losing a leg; but, if possible, it is better to keep your two biological legs.


Policy for remote-access situations? We have network which users (mostly management, it, and the presidents) use VPN to remote into their work desktops or to use their laptops from home.

After some users took it upon themselves to install their own remote access software, I suggested we write up a remote access policy that explains to the users what is acceptable and what is not, only use the software on OK'd systems, etc.

The bosses suggested that we just don't tell anyone about remote access - the less that know about it, the less of a problem it is .. I was just to block unauthorized remote access from the firewall (gotomypc etc.)

I feel that it is important to have policies for just about everything - but they disagree in this situation.

What do you think?

If remote access should not be allowed, having no policy will leave your bosses no base for disciplinary action if someone manage to circumvent your firewall and creates any kind of problem, because doing so wasn't forbidden.

How important that is in your situation is up to you and your bosses to decide.


Why not use weak passwords? In a specific situation: online stores that cannot possibly store payment details because you pay using paypal, but require registration.  What reason is there to use good passwords here? Breaking into my account will only give access to my order history (assumed to be boring) and my address (realistically publicly available anyway).

If I'm using a good password manager synced across all devices I might want to access the site from, a strong random password that I never need to know is easy.  If I'm not, why shouldn't I use "password"?

The paypal account is assumed to be using a strong password, of course.

The simple answer is that there isn't any reason to use a strong password in this case.  Security is entirely about balancing risks and costs.  The cost of a stronger password is that it is harder to remember and use.  For low security sites, where there is either little risk of being compromised or little risk to being compromised, then it is perfectly fine to follow less stringent security measures.

The main thing is to make sure you are accurately judging the risk of your exposure, but if the risk is minimal, then the security can be too.


Possible to use sqlmap when URL changes after each request? I am testing a website login that is constantly changing its URL after each request. The first request does a POST login request to /login?0-1.FormSubmit, the next login attempt has to POST to /login?1-2.FormSubmit, and so forth.

Is it possible to use sqlmap on this login, eventhough the URL changes after each request?

Tools are seldom written generic enough to handle obscure test-cases. It might be tempting to blame the tool for its shortcomings, but more often the problem is obscure/non-generic, and should be solved by other means.

You can solve this problem by creating a small webapp that acts as a proxy between the target application and your tool.

The tool accept the vulnerable input as a parameter, and forward it to the application as required.

Here is an untested python/flask code to illustrate how this can be done:

from flask import Flask, request
import requests

i = 0

app = Flask(__name__)
@app.route("/")
def app_proxy():
        sqli = request.args.get("sqli",None)
        data = {"somekey":"someval","vulnerableparam":sqli}
        resp = requests.post("http://target.com/login?%s-%s.FormSubmit"%(i,i+1),data=data)
        i += 1
        return resp.text, resp.status_code

app.run(host="127.0.0.1",port=8008)

After you have started the flask-app, you should be able to use sqlmap against http://127.0.0.1:8008/?sqli=value


Is Acronis True Image encryption safe? This question has been asked before but a lot of time has passed since then.
The older question had an answer that the Eula said that Acronis can decrypt the data. I can no longer find that part.
Can you trust their encryption? By trust I mean that nobody can decrypt it (not even Acronis) as long as you have a very strong key and your encryption is set to AES-256?

Without reverse engineering the software and analyzing what all data is being sent, there is a minimum amount of trust that must be given to the application.
If you want to go by what they have publicly stated, the current EULA (as of 3/11/2021) states that "Acronis cannot decrypt your files if You have elected to encrypt."
This would imply that Acronis does not have a method of decrypting the (encrypted) data you send to them.
Additionally, in 2017 the GM stated that Acronis does not have the ability to decrypt data that users uploaded if they have encrypted it locally. Data uploaded in plaintext and encrypted by Acronis can (by necessity) be decrypted by them.


Suspicious GitHub fork Update (April 15): The forked repo and the user do not exist any more.
Yesterday, one of my GitHub projects was forked and there is a suspicious commit on the fork of the repo. As you can see from the commit the GitHub Actions configuration installs ngrok on the server, enables firewall access to rdp and enables rdp on the server.
Can someone explain what the potential attacker is trying to achieve and why the person behind it couldn't do the same in their own repo? Is this a new type of attack and what should I do?

This isn't trying to make users install malware. This is trying to run malware on the build server. They fork the repository, install a malicious build script, create a Pull Request (PR) for the fork, and then the build will run for the PR and it will look like it's coming from your repository. When Github staff look at why their build servers are mining bitcoins, they'll see that it's a build job for your repository. (But they're probably smart enough to see it's from a malicious PR)


SQLMAP and DBMS credentials, how do you use them? for educational purposes and in order to develop a test for students, i try to "hack" a website developped by a friend : http://www.websitetohack.com.index.php?id=5
When i launch SQLMAP, it finds a "Time Based Blind SQL Injection".

After some dbs queries ; there are the infos i found :

There are three databases:

db01 (php website example with phpbb forum)
mysql
information_schema

The back-end DBMS is MySQL
The current user "username" of DBMS is : administratorforlife
The current user "password" of DBMS is : ohmygod
The current db is : db01
The hostname is : db01hostname
The current user of DBMS is : (DBA) (Database Administrator)

db01 contains a column called "USERS" where 100 fake "accounts + passwords" are listed.
The problem: I don't know where ADMIN PANEL is. I tried to find it via some scripts without success.

With the help SQLMAP, is there any way to connect to the DBMS with the infos that i have in order to retrieve all users data in db01 ? If yes, how ? Do you know some command line to enter DBMS ?
As all of you know, in blind mode i would spend years.

Thanks for your help !

You can connect to the database using the credentials unter some conditions

1.) The MySQL Daemon needs to run on the external IP-Address of the server. MySQL can either be configured to be used over a unix socket or a network interface. For security reasons it's advisable to bind the daemon only to the loopback so it cant be attacked from an external offender (like you in this case). You have to check if your frind did configure it secure. By running a portscanner like nmap for example

nmap -sS -p 3306 you.hostname

the -sS tells nmap to perform a SYN scan which is more inconspicuous than a CONNECT scan and -p 3306 tells which port to scan. Port 3306 is the default port of the MySQL Daemon.

2.) The user needs to be unlocked for external access. MySQL gives the adminsitraor the possibility to only allow a specific user to connect from a specific host like the localhost for example. You can check this by having a look at the mysql.user table through your SQLi.

When these conditions are fullfilled you can connect using the mysql command or using the mysql workbench if your not so into terminal based work.

mysql -u yourusername -p -h your.hostname

The -u yourusername tells the username the -p tells the client to prompt you for a password and the -h your.hostname is the hostname of your target.

Before you do this you should also check the /robots.txt on the webserver. This file conaints urls blacklisted for link crawlers like the google bot. Often these files contain the pathes to administrative interfaces. So maybe you find the login page this way...


Could DKIM be used as a proof that an e-mail was sent by a given party? For quite some time, I was wondering if there are ways I could record forms of communication with, say, Facebook servers and have a plausible proof that a specific event (such as receiving a private message with given contents) actually took places. While I learned that I cannot record TLS session and use it as a proof that would be difficult to forge, I wonder if the DKIM-signed notification e-mails would work better.

In other words, if somebody sends me an e-mail and his server supports DKIM - do I have a reliable proof that this e-mail was sent by this person and is genuine? Are there any caveats?

The only proof you have with DKIM is that the mail was sent over a specific mail server. You can only conclude that the mail was send by a specific user if

the mail server only accepts mails from this specific user (unlikely)
enforces that the From header in the mail (which is part of the DKIM signature) matches the actual sender of the mail, i.e. no spoofing possible (unlikely too)
the mail account of the user is not compromised so that somebody could use it to send mails in the users name
everything else is secure, i.e. the mail server is not hacked, the DKIM entry in DNS not compromised due to a weak key, compromised key, DNS spoofing or similar.

Thus, a valid DKIM signature helps to narrow down possible senders but taken alone it is far from a proof that a specific user has send this mail.


Inadvertent clickjacking on page causes LastPass login dialog to appear. I like the idea of password managers but have become leery of the way they interact with browsers (especially given the recent "LostPass" exploit).

Today I found that viewing a certain page with "Prominently highlight unhidden fields" in Burp, the page munging caused some UI redressing that made the LastPass login appear when clicking other links on the page (in addtion to when clicking on the asterisk in the password box.  It made me think I was being attacked.

Central question is:  what could a malicious or infected site do with this ability to launch the LastPass dialog?

Here is a screenshot showing the dialog appearing after clicking on the sunglasses link:

A basic phishing attack springs to mind.

However, a malicious site could of course construct a LastPass login box themselves and hope the user uses it to login.

I suppose the advantage here is that the LastPass box will only appear if the LastPass extension is installed, plus it may have the advantage of always being current and that of the username being pre-filled in because it is from the actual LastPass dialog generation code.

It is difficult to answer further without seeing a full POC in action.


Is zero knowledge possible with webbased encrypted email services? I'm presently using mailfence.com

They claim all encryption happen in the browser and that they are zero knowledge.

My question is this: Where do they store my key.  If my private key is stored on their servers, can't they decrypt all my mails?

I work at Mailfence as an Information security analyst.

  Where do they store my key.

When you generate your keypair, we first encrypt it with your passphrase in the browser and then store it on our servers. This way, server never sees the key in plain-text, and a zero-knowledge framework gets established.

  If my private key is stored on their servers, can't they decrypt all my mails?

No, we can't. As your private key is encrypted with your passphrase, which only you knows.

The blog-post Mailfence end-to-end encryption and digital signatures will give you more insights in this regard (including the open-source libraries that we use to perform crypto-based operations).

We are always open to external (legitimate) audits, and to further strengthen our transparency - we have also planned to go open-source. It's now only a matter of time and priorities.


How to prevent sharing my Internet by Bluetooth tethering? If my neighbor (whom I have allowed to connect to my router) is sharing my internet via Bluetooth tethering, is there a way to prevent anyone else from sharing my internet via his or my Bluetooth without cutting him off?

Basically, anyone allowed to connect to your router/wifi access point can in turn make their computer (or whatever device) into a router of their own.  They can then, without your router even knowing, create their own little network and share internet amongst themselves, then relaying the traffic through one device.

You can generally see what devices are connected directly to your router from its administration page, but this will not show ones that are connected via bluetooth tethering or some other means, thus relaying through a device that does show up in the list.

Unfortunately, there's no easy way on a home router to prevent this type of thing.  I think the best approach might be to talk to him and ask him if he's doing that, and negotiate a solution.


My ISP (BSNL India) is injecting ads using Phozeca which spoils websites and makes them unresponsive, can anything be done? I've been recently having a problem where my ISP (BSNL India) has been injecting ads/weird Javascript Tracking codes onto my browser, making the website unusable and unresponsive.

I've written an article regarding this too: https://www.nonstoptrend.com/bsnl-is-injecting-adsscripts-onto-your-browser-using-phozeca-2017/

You can read that to understand what exactly is happening. You can refer to the article above to see what the injected code is doing.

I'm sure this is my ISP because the domain starts with "bsnl.phozeca.com" and uses the port "3000".

Points to note:-

Script injection works only on Non HTTPS sites, such as Steam Store and other Non HTTPS websites.
The code being injected, uses the port 3000.
Websites which malfunction normally work when CSP (Content Security Policy) is disabled in the browser.
Websites which malfunction work properly on Tor Browser.
I personally have investigated into this matter, and after reading through the code (Read my article to know what i'm talking about), and after reading the code, I called the "loadnewads()" function from the code, and once it's called, weird ads come up, such as fake Flash player ads and fake download buttons.

-Things I have tried to solve this problem.-

Checking hosts file and blocking the domain: Not working. The script is still being injected.
Scanning the PC for malware: Not working. I've scanned with over three antiviruses including Malwarebytes, still it doesn't detect anything.
Disabling CSP (Content Security Policy): Worked! However ads automatically start playing.
Changed DNS to Google's DNS: Not working.

Is there any way to solve this problem? Please help.
Thanks!

I had similar issues. I have a simple trick but it is temporary, but it is working for me and stopped BSNL ISP from tracking and pushing malware AD popup. I added a host entry in my computer for bsnl.phozeca.com and pointed it to localhost.


Application is validating the file extension but not file content - Is this a security vulnerability? An application has a file extension validation at the server side and rejecting the request if the Extensions are not matching to (.pdf/.docx). But if i modify an exe file's extension to .pdf and upload it, its processing the request. Is this a security vulnerability?? If so, how an attacker can take advantage of?
PS: Application is using this feature to attach some support pdf documents where an approver can download and refer. Its not processing the uplaoded files anywhere in the application.

It is unclear what the expectations on the application are in this case and thus your question can not be answered.
For example if the recipient expects data from untrusted sources anyway, it can be expected that the PDF is checked at the recipient. If the recipient instead expects fully trustable data, then more checks need to be done on the way to the recipient. These might be done in the web application during upload but also might be done at a later stage during delivery.
In other words: you cannot have a look at the application in isolation but must see the bigger picture. From that you can derive the requirements on the application. Only with the actual requirements you can decide if this is a vulnerability in the application or not. And only with the bigger picture it can be determined if and how such a vulnerability could actually be exploited.


Effect on PCI compliance of not checking SSL certificate? PCI DSS states:

"[You must...] verify that only trusted SSL/TLS keys/certificates are accepted."

Long story short, our payment service provider just asked us to please stop verifying their certificate after we had some SSL handshake issues. Is this wrong?

Yes, this is wrong, and here is why.  As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel.  As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to.  If you do not validate the  certificate, the traffic may as well be unencrypted because you have no idea of who is on the other end.  It could be your merchant provider, or it could be a man-in-the-middle who's reading and storing all of the card data you send before forwarding it on to the provider.  Without validation the cert, you can't know who's seeing the data, so your trust level that the transport channel is secure must necessarily be 0%.

So, as I said in the comments, do not accept this condition.  If your merchant provider can't, or won't fix the issues so that you can confidently validate their certificates, find another merchant provider.  In fact, that may not be a bad idea in any case because if they're willing to play fast and loose with PCI and security here, you can't know where else in their system they've taken similar liberties putting you and your customers at risk.


An attacker has my IP address;So what? There seems to be a general bad vibe for someone having your IP address, but what are the real dangers? After all, I give my IP every time I connect to a website, regardless of the legitimacy of said site.

Assuming a malicious party has obtained my IP and wish to do Bad Things, what can they do?

What every company on the planet with assigned static IPs does.

At a minimum, firewall with default drop on unneeded inbound ports, patch all exposed services for vulnerabilities, don't have unneeded services listening, enable some sort of intrusion detection.

And you're not going to do anything much on inbound DDOS. Usually you have to do something to invite this kind of attention.

If they seriously want to mess with you, they will do targeted attacks by other means than directly working with an IP address. Once they're successful on that end, their malware phones home and knowing the IP address ceases to become an issue.

And it answers the question kind of in reverse. They will scan your IP to find out what kind of services are responding, attempt to use any replies to fingerprint both the responding OS and any service versions to see if there are vulnerabilities that can be exploited. And then there's the old Distributed Denial of Service attach where they just slam the door shut so you can't get out.


Most secure way to store a cryptographic key for encrypting/decrypting stored application data I would like to encrypt some of my application data stored on a MySQL DB using AES-128. I wonder thus what is the best way to store my key on the webserver.
Should I encrypt the key itself or store it raw? Should I store in a file, a BLOB or as a record on some table? Should the key be stored on a server other than the one the web application  lives in in case the server got compromised? Is it okay to transit an encryption/decryption key over HTTP/SSL from one place to the other? If yes would not jeopardize the performance of my web application?

I will not give a direct answer here, because it can depend on the context.
First, if the application must run in an inattended way, for example automatically restart if the server reboots, there will be no truely secure way to store the primary key. So you have 3 options here:

most secure: require a human action to enter a password when the application is started. You can securely store the main key in an encrypted container, but you need a password owner each time the application is restarted.

standard: store the key in an unencrypted container in a file accessible only to the application or to the administrators

median: use obfuscation. The main key is mangled before being stored and will be demangled by the application before use. Any bijective operation can be used for mangling.

The fact is that obfuscation is not security, because if an attacker manages to find the key, it will probably be able to find the mangling in the application source or code. But it can give you some more time to detect the attack. You must just be aware that it does not add any security by itself, and because of that is seldom (if any) used in large datacenters.


Charles Proxy can not capture message sent over SSL connection I have setup Charles Proxy app and it can captures my https request/response sent through browser.
Now instead of using the browser, i have an app that setup a SSL connection to the server, and then the app construct a HTTP message and send over the SSL connection.  I receive response from server so i believe everything is working fine. But somehow Charles Proxy cannot capture the message i sent. Technically i think what i do is not different from what the browser does. But i must be wrong here.

So what's wrong here ?

If I understand correctly, your setup is

app - mobile configured to proxy web requests - Charles Proxy on a PC - target server

If so, this is a correct setup, but the SSL traffic may be problematic, as the proxy will intercept the SSL traffic and the application may recognize this as a MitM attack (it expects to see the right certificate, but gets the one from Charles Proxy).

You can try browsing on the mobile to a http site and see if the traffic is intercepted.

If it is, then you will probably have a hard time analyzing the traffic from the app as it will defend itself against wht it perceives to be a MitM.
If it is not, then the proxy on the mobile is not set correctly


Is storing the private key and public keys in same directory on server recommended, like OwnCloud does? Is this recommended or a good/normal practice? I think not.
Because I saw that OwnCloud stores all encryption keys in one directory on the server.
One directory contains the private key(s) and one all public keys.

But their documentation says about their encryption: "But you should make sure to never lose this password, because that’s the only way to recover users’ files."
doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_encryption.html

This seems totally wrong and unprofessional to me.
Or is there any good reason why both are stored there?

https://github.com/owncloud/core/blob/master/apps/files_encryption/lib/util.php#L60
All keys are in the main data directory, not in a special key directory somewhere else

Well the public keys are fine to store there. Thats why they are public. Anyways, you should seperate the private keys and make sure nobody else gets access to them. So probably storing them on another server would be good practice.


Getting real machine information from a virtual machine If a malicious software gets into a virtual machine, what is the most information of the actual machine it can obtain?

Ideally, the virtual guest is not able to see anything from the host. But the world is not ideal. Here we go back to the discussion of Joanna Rutkowska. She developed a technique to determine  to test if you are living in a virtual environment. It was called the "red pill".
Joanna just provided a proof-of-concept, which you can see in https://stackoverflow.com/questions/46267618/red-pill-detect-virtualization
It, however, does not mean that you can just read (or even write!) all sorts of host data.
Some virtualization techniques provide explicitly some information for their virtual machines. If you are running Windows as a Hyper-v  client, you can see in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters that you are a guest. If you use Vagrant, you will see a directory vagrant somewhere. This directory may also be available to your malware.
And there is always the possibility that a form of malicious software made a new discovery how to access the host from a guest. We may think that is not likely, but we also thought that of processor-microcode.