Tamper-proof BIOS password & settings storage with Trusted Platform Module?

The TCG Trusted Computing concept devices the BIOS into two parts. The initial BIOS is assumed to be secure and will initialize the TPM. This so-called CRTM will then measure the remaining BIOS components and log their values in the TPM. From the spec it appears that CMOS data is part of that measurement and is stored to PCR1. But since a changed BIOS password or other setting would invalidate things like Bitlocker, I don't think this register is actually used. Or the implementations don't actually measure this configuration space. Best try it out and see what happens. If it is measured, you can use a system like Bitlocker(or a linux initrd plus shellscript) to protect your OS data against a manipulated BIOS.

Note however that the TCG specification explicitly excludes hardware attacks. Also, the TPM is always dependent on the BIOS to correctly program and protect SMM and TXT, so you should always verify the BIOS measurements.

Note also that full disk encryption and protection of passwords against brute-force attacks are the only practical use-cases of a TPM today. Everything else is generally impractical due to the huge configuration space of the OS(infinite valid measurements..) or not as secure as one might think(SVM/TXT/VT, though they still present an advancement over the state-of-the-art).


How are the disk encryption keys protected when a laptop is locked?

Short answer is "data STILL readable but just behind a password". It is rare that anything in RAM is encrypted, simply because it would require some sort of a password to decrypt, and most passwords would reside in RAM anyhow.

Going a bit further with this, the decryption password for the majority of disk-encryption programs would actually also (ironically) reside in memory.

Keep in mind that Full-disk encryption (or your home directory) applies only to your drive (HDD or SSD), not your memory.


When you write,
template <typename T>T* safe_malloc(const size_t num_elements)

you're saying that num_elements can hold a full size_t. But if that is the case, then multiplying it by sizeof(T) might make it overflow, since the result also has to be size_t.
return static_cast<T*>(malloc(sizeof(T) * num_elements));

I do not know how to easily make fortify stop complaining. Possibly you can cast the desired memory amount to a larger size representation, check explicitly that it does not exceed SIZE_MAX, and if it does not, cast it back to size_t. That ought to be clear enough for the static analyzer to understand what's going on.
template <typename T> T* safe_malloc(const size_t num_elements) {
  unsigned long long required;
  required = num_elements;
  required *= sizeof(T);
  if ((0 == required) || (required > SIZE_MAX)) {
    return NULL;
  } else {
    return static_cast<T*>(malloc(required);
  }
}


How does this test prove my application is vulnerable to clickjacking attacks?

Your webpage allows itself to be put inside an iframe.

An attacker can easily put your site in an iframe on his webpage, cleverly mask most of it, and trick the user into clicking a button there.

Because of CORS and CSRF tokens, usually websites under a different domain cannot spoof requests to your website. However, they can trick the user into clicking buttons (for example, the "logout" button.)

Read this OWASP page to learn how to protect against clickjacking


There are several ways to manually confirm the results:

1- Using nmap:

nmap -sV -sC [IP]

2- Using SSLyze

sslyze --sslv2 [IP]

3- Using Google SSLScan

sslscan --no-failed [IP]

4- Directly with openSSL

openssl s_client -no_tls1 -no_ssl3 -connect [IP]

5- Externally-accessible hosts can be tested with

https://www.ssllabs.com/ssltest/

Make sure you have SSLv2 enabled on your machine. For more information, please see http://www.softwaresecured.com/2016/03/01/how-to-confirm-whether-you-are-vulnerable-to-the-drown-attack/


Unfortunately no, there's no way for an end user to trace that information. Your cell phone provider should at least be able to trace it back to the SMSC that it was sent from, however they are unlikely to do so without some sort of police request or court order.

If you are being threatened or genuinely harassed then get the police involved, they have the power to compel the phone company to research that. It's their job to deal with these types of things after all. If it's an annoyance you can almost certainly just set up a block of that number on your phone.


A second factor is defined as independent of the first factor. That means your system should stay secure, even if one of the factors is compromised (and you are aware of the compromise).

For example, a door badge and a fingerprint are independent of each other, and just having the door badge or the fingerprint is not enough to gain access.  This is often called "multi-step authentication" instead of "multi-factor authentication".

Now imagine your scenario: You have a private key, encrypted with a strong passphrase. Are those two factors? No, because the private key can also exist without passphrase. An attacker that compromises the private key can thus log into your system, even without knowing that passphrase. In fact, the server is completely unaware if your private key is protected by a passphrase or not.

If you want true multi-factor authentication, there are SSH modules that do exactly that. That being said, a private key encrypted with a strong password is often enough.

  Note: The original question talks about "an SSH key with a Passphrase to login on a server", which I interpreted as a private key, encrypted with a passphrase.


What is the entropy of a password made with pwgen?

The actual answer to your question is too hard for me to reasonably calculate, but I can say a few useful things about this.

pwgen does not produce passwords uniformly. Some passwords are more likely than others. This is because it tries to mimic some of the frequencies we have in English. This is true of most "pronounceable" password generators. Note I discuss this in my PasswordConLV15 talk. A link to the video of the talk and the slides are here: https://blog.agilebits.com/2015/08/07/unspeakable-passwords-jeff-goldberg-talks-to-passwords15/

There is no clear answer to what notion of entropy is most appropriate when password creation schemes when the schemes do not produce uniform output. I have argued that we should be using min-entropy in such cases.

Additionally, some versions of pwgen are subject to the modulo bias. It is a relatively small bias that comes up through a common design error when trying to pick a number between 1 and N even when the underlying random number generator is good.

So between the relatively small modulo bias and the much larger deliberate bias toward more likely sounding syllables, it would require a level of analysis beyond what I am willing to do to actually calculate the min-entropy.

It is frustrating that popular password generators are hard to actually analyze in terms of strength. But for most practical purposes, if you just be sure to generate things that are a few characters longer than you otherwise might, then your gain in strength from generating a longer password will surely overwhelm the loss of strength from their non-uniform behavior.


This question is both too broad and too narrow, but I'll see what I can do.

Your understanding about AES block and key sizes is correct.

Usually, yes, you'd want to use a cryptographically secure (P)RNG to generate encryption keys (for any cipher, AES included). However, there are times when this isn't practical, such as when a human needs to be able to remember the key (or remember some data that can be used to generate the key). For situations like that, there are key-derivation functions that turn a "secret" (potentially a password/passphrase) into a key. KDFs don't actually add any entropy, so the resulting key is far more subject to brute-force than a truly random one (a truly random 128-bit key is practically impossible to brute-force, much less a 256-bit key), but sometimes that's a risk you have to accept. KDFs are usually deliberately slow and sometimes (relatively) RAM-intensive, to make brute-forcing the key from a (usually large) pool of potential secrets much slower / harder to parallelize.
I don't know what that site is doing, and without examining its source code I couldn't say with confidence even if it has a "what am I doing?" write-up somewhere. It doesn't require the passphrase (though it produces buggy-looking output without it). It might be using a PRNG (secure or not) to generate a "salt" and then generating a key from that salt and your passphrase using a KDF. It might be using a PRNG - secure or not - that allows you to "add entropy" and inserting the passphrase as added entropy then generating the key out of that PRNG directly; this is not technically insecure but is generally pointless and may be misleading. (For example, Java's SecureRandom class can accept additional entropy but there is approximately never a good reason to do this.) If you want more info about that site, ask it in a separate question.
If you need to rotate any encryption key (AES included) for any reason (policy included), then you need to decrypt the data using the old key before the old key is discarded, or the data will be lost. You then need to re-encrypt the data using the new key, or the data will be in plain text. The usual way to do this performantly is to generate a "master key" that is the one actually used to encrypt and decrypt data, and encrypt (and decrypt) the master key with a user key (which might be derived from a passphrase, stored in a file, whatever). The master key is never stored in plain text, and is only decrypted briefly when it is necessary to encrypt or decrypt the data, or to rotate a user key. This way, rotating the user key just requires decrypting the master key and re-encrypting it with the new user key; you don't have to decrypt and re-encrypt the entire body of data. Since the master key is itself stored encrypted and is never exposed to the user or to any other system (at least, not in plain text), it does not, itself, need rotation unless you suspect it to have been compromised. This is how many systems that need to encrypt large amounts of data, such as full-disk encryption utilities, work.

Without a lot more information about how your application works and what its goals are, I cannot comment on when or where the key rotation process would happen. If you want help with designing a specific cryptosystem, you could ask another question here but you really should hire somebody who is familiar with designing cryptosystems. Cryptography is hard, and rolling your own design - while probably safer than rolling your own implementation of a primitive, much less designing your own primitive - is still a risky business.


Can the following .htaccess rules prevent this attack?

You should be fixing the code that causes the problem, rather than throw stuff at it and hope it blocks the malicious stuff. Your .htaccess blocks access to /proc, which is good, but it's not the only thing you want to protect. Blacklisting like this won't get you far, as there are dozens of other directories you want to protect, and which ones those are depends on the server OS and configuration.

Part of the attack you've been a victim of involves path traversal, that is, breaking out of the web root by submitting a relative path in a query string parameter that somehow gets worked into a filename. To fix this part, check the entire codebase for strings that are used as filenames (this includes include and require statements), and sanitize those. The worst cases are those where the filename is used to execute a file as PHP code (intentionally or not), but an innocent file_get_contents can be enough to form a security risk (e.g. when an attacker can trick it into serving a file containing database passwords).

Next, check all parts of your codebase that use strings as code (eval and friends). It's best to eliminate them entirely - they're hardly ever needed, and the price you pay for the perceived convenience is not worth the trouble.

Then there's XSS; you want to make sure that anything you send to the client is properly encoded as HTML. Any string you pull from the database should be considered text, and sending it without converting it to HTML first is plain out wrong and dangerous. Check everything in your code that produces output (which is typically a lot), and make sure all dynamic strings are properly encoded (htmlspecialchars() does this for you). It is important to have a clear understanding which of your strings are text and which ones are HTML - while using one as the other technically works, it is, again, wrong and dangerous.

SQL Injection is another low hanging fruit for attackers. The way you are trying to protect yourself is popular, but very inefficient. It fails on multiple accounts - there are tons of tricks you can use to still inject SQL without using any of the blacklisted strings, and the more you blacklist, the higher the chance for false positives. I've seen people block single quotes altogether as part of SQL injection prevention, with the result that it was impossible to find any customers named O'Brien (of which there were several). To properly solve SQL Injection, make sure all your queries are parametrized. Unfortunately, the old-school mysql_XXXX() API doesn't support these, so people just happily concatenate queries, which, again, is wrong and dangerous. I'm talking about things like these: mysql_query("SELECT * FROM foo WHERE bar = '$baz'");. Since PHP offers both the mysqli interface and the PDO API, you should really use these and provide all dynamic values as parameters to your query - the underlying MySQL library will then handle all escaping and safeguarding for you.

Also very important: PHP settings. Turn off register_globals (the most dangerous setting I've ever seen), magic_quotes (it does nothing but suggest a false sense of security and an excuse to write sloppy code), review the recommendations from php.net themselves.

And: file permissions. Make sure your web server has read-only access to your scripts, write access only to specific directories where it is absolutely required, and no access at all to files it doesn't need.

Additionally, put a .htaccess with Deny From All in it into every directory you don't want to serve from. Note that this will not prevent the web server from accessing those files, but it will cause apache to ignore requests that resolve directly to anything in one of these directories - you can still include from there, or read data from files in them, they just can't be requested from the outside.

And finally, a more general thing to do: Review all points where untrusted data enters your system ($_POST, $_GET, $_COOKIE, parts of $_SERVER, and anything that comes from the database is untrusted in this context), and follow its path. See if at any point abuse may be possible.

If you have the budget, you should also consider a professional audit - a skilled hacker will be able to quickly poke through any remaining security holes, and tell you how to fix your specific problems.


At what point is a Bitlocker drive unlocked and how does additional pre boot pin add to security?

No, thats not how BitLocker works. BitLocker has an additional partition thats stores information about the encryption/decryption process together with some metadata. It holds the cipher used, block mode, keysize, number of used slots and authentication method (amongst other things).

With enough information from this partition the decryption process can begin. The user is asked for his passphrase or private key file (in case of USB) and can decrypt the modules, driver and bootstrap executables in order to load the kernel.

The disk is not decrypted at boot, but instead Windows makes use of an additional IO layer. This layer hooks between the file system driver and the disk driver and decrypts the information on retrieval (and encrypts on write). As long as the operating systems runs, the secret is stored in protected (kernel) memory. Therefore it is important you shutdown the computer gracefully and give Windows the time to nullify the memory. The same is true for other systems.


Is it possible to bypass this Xss Filter?

Output encoding is context-specific. If you're only putting the output of this function into HTML text elements - not into attributes, not into strings (or anywhere else) in a script, not into CSS, etc. - you might be OK. For now. If you're aiming for any other context, you're definitely not OK. Here are just a few (this isn't a comprehensive list, don't try to make a comprehensive list, you'll most likely fail and even if you don't the next ECMAScript or HTML update will break your magical unicorn of a viable blacklist for you).

You're not filtering \, which can be used to escape the legitimate string-ending ' or ". If the attacker controls another string on the same line, that string will be interpreted as code.
You're not filtering `, which is used to delimit template strings in JS; an attacker would be able to break out of one of those trivially.
You're not filtering ${ or }, which are used to create expressions for expansion within a template string; the text between them is treated as code.

Just use output encoding of everything non-alphanumeric if you want to be really safe, or at least use a whitelist of non-alphanumeric characters to not encode (and be conservative with it). If you're using the filter only for a specific context or two (say, HTML text and non-event HTML attributes), you can maybe get by with a specific "blacklist" of characters to filter, but it's riskier than going the other way.


Services disclosing private data to a third country

What private data? It is likely that your government already has most data about you. They may not have data you have created privately. If you put private data on a public cloud, you can never be totally certain what will happen to it.

You need a vendor with a strong privacy track-record that operates in a territory with strong privacy laws.

Even then, it may well be easier for a nation state to hack through to the data than to tip their hand to a foreign commercial organisation.

I'd start then by looking for a vendor who has a lot to lose, has very strong and open standards/policies/processes and who takes a strong, consistent stand against government bullying & underhanded behaviour.

Are they all the same? Certainly not. Google, for example, makes most of its revenue from being able to process other people's data. Amazon and Microsoft don't have that credibility issue. Both have strong policies and processes for privacy. Both allow you to keep data in a specific region. Both take steps to restrict access to customer data from operations staff. Microsoft at least has additional services to further protect data at rest (customer private keys for example). Microsoft in particular has a lot to lose since much of their Cloud offerings are targeted at government data, that would all be lost if they messed up on data privacy, at least in the EU.

The smaller the vendor, the less likely they are to have the resources to stand up to state interventions.

Just realise though that if a major government wants your data badly enough, they are going to get it one way or another.


Why doesn't my leaf certificate validate against the root CA only

Why do I need to provide curl the full chain instead of only the root CA?

In order to build the trust chain the client has to know the intermediate certificate somehow. Usually this is done by sending both the leaf certificate and the intermediate certificate in the TLS handshake but it is a common error in server configuration to send only the leaf certificate. This is probably the problem in your case too.


Are exposed php class files a security vulnerability?

Fundamentally, whether something is a security risk depends on whether or not they can find and exploit a vulnerability, whether it be in the code, in the system, or in the people.

In your case, your users may be able to guess file names of class files, but cannot see their contents. Let's assume the worst case and they manage to guess the names of every file so now they have an entire index.

If the file names tell them that you're using some library that has a hole in it, then that's a risk.

If the file names themselves give information that can lead to a risk, then that's a risk too.

If the file names match some file names which have some esoteric bug in Apache or something, then that could be a risk too.

If the knowledge of the file names allows them to call up some of your staff and convince them to give them the contents of the file or modify the file, then that's a risk.

But no, knowing the names of the files isn't inherently a risk; it's only a risk if that tells them something about how the system works and clues them into a vulnerability.


There are no known public sandbox escapes for the latest version of Chrome so this would require a Chrome 0-day. This means that while it is not impossible it is very unlikely that a particular person has that knowledge.

Also note that such an exploit would possibly be worth quite a lot in the right context and thus unlikely to be widely spread or used on any low-value target.


SQL Server connections with TLS vs. through an encrypted tunnel?

You don't need to do anything specific in this regard. If you need secure channel to SQL server, just insert encrypt=true in SQL connection string. This will request secure channel. The behavior of connection is controlled using TrustServerCertificate connection parameter. If it is set to True, client will fallback to insecure transport (if SQL server does not implement TLS) and will accept arbitrary certificate (potentially, untrusted, or MITM) when presented by server.
By default and when not configured, SQL server automatically generate a self-signed certificate to clients that require secure transport. If TrustServerCertificate is set to False, then client will fail if either, SQL does not implement TLS or server certificate is not valid according to validation rules. ADO.NET clients use Windows built-in certificate chaining engine to validate server certificate.
That's all what you shall to do regarding transport security for SQL client. If you expose connection string altering to systems administrators or application users, leave it up to management personnel.


Is it possible for ssh app on Android to collect my credentials?

There are malicious applications in the Google Play Store. Extracting your SSH login data like the password or the private key is possible for a developer of a malicious Android application. Once the adversary is in possession of your password or key, he can connect to your server.

Back in 2013 attackers created a trojanized version of PuTTY to steal SSH credentials.

Thus, you should only use trustworthy applications for your SSH connections.


How to find why so many host are talking to an IP which is blacklisted

Tell your client that they need to run virus scans on the source IPs and to inspect the browsers of those machines. They can also run netstat on the Windows machines:

netstat -a -o -p TCP

That will show them the process that initiated each TCP connection.

Once they know what is triggering the connections, they can plan how to address the problem.


Authenticate WCF call to ADFS through Web Application Proxy (WAP)

The Web Application Proxy uses an authorization token to decide whether or not it sets the EdgeAccessCookie. If you can request the authorization token and put it in the URL of your HTTPRequest, the WAP will let you pass. Code snippets:

        List<KeyValuePair<string, string>> postData = new List<KeyValuePair<string, string>>();
        postData.Add(new KeyValuePair<string, string>("UserName", username));
        postData.Add(new KeyValuePair<string, string>("Password", pw));
        postData.Add(new KeyValuePair<string, string>("AuthMethod", "FormsAuthentication"));
        HttpContent content = new FormUrlEncodedContent(postData);

        WebRequestHandler webRequestHandler = new WebRequestHandler();
        webRequestHandler.AllowAutoRedirect = true;
        webRequestHandler.MaxAutomaticRedirections = 1;

        HttpResponseMessage response;
        using (HttpClient client = new HttpClient(webRequestHandler))
        {
            response = client.PostAsync(https://FQDNADFS/adfs/ls?version=1.0&action=signin&realm=urn:AppProxy:com&appRealm=REALMOFAPI&returnUrl=RETURNURL&RedirectToIdentityProvider=IDENTITYPROVIDER, content).Result;
        }

        authToken = HttpUtility.ParseQueryString(response.Headers.Location.Query)["authToken"];
        return authToken;

The above snippet will give you the authorizationcode, which you should include in the URL of your HTTPRequest:

HttpResponseMessage response = await httpClient.PostAsync(Url + "/?authToken=" + authToken, new StringContent(jsonString, Encoding.UTF8, "application/json"));

In combination with the code from my question (no changes there), the WebAPI is secured by the WAP. Good luck.


Home wifi: is it typically possible to prevent WLAN devices from selecting their own IP address?

There is no way to force IP addresses on clients in an Ethernet network as such, as they can simply opt not to use DHCP at all. Clients can pick and use any valid IP address. Furthermore, static leases by MAC address will not guarantee an IP assignment even if DHCP is used as MAC address not static and can be chosen arbitrarily (equal to MAC filtering in the first place). More intelligent firewalls will usually force the source address of packets to belong to the interface subnet. You could also really make a firewall rule to at least enforce that only some range of IP addresses are routed.

Embedded router devices are spectacularly non-versatile and preventing some devices form accessing the internet is not a particularly common usage case. Forcing IP addresses to devices is kind of an XY fallacy for the problem. This task is definitely impossible, but your objective is fairly straightforward.

For example, you could use another NAT router for the restricted devices and give it a static LAN IP address on the WAN interface. Then make rules preventing that LAN address on WAN interface from reaching the internet on the main router. This works because the devices behind the internal router have their addresses translated to the single WAN address which they can not change. They would still be able to access the main LAN addresses through the default route of the internal router. To communicate back to them you would need to add port forwards. Another possibility would be to use 1-to-1 NAT with a pool of addresses.

As stated, using a VLAN per SSID capable AP would at least allow a router running a full version of Linux to trivially segregate the traffic between VLAN segments (I recommend Ubuntu w/ Shorewall). Some "open source" firmware images for home routers supposedly can do VLAN/SSID and firewall rules based on VLAN tag, but they tend to be horrible and I strongly do not suggest them.

Perhaps a sincere analysis of the threat model would be helpful as well. Why is it important that these devices can not reach the internet. How strident will attempts to circumvent these controls be? Is a MAC whitelist not good enough? You say the devices are partially trusted... are you sure you trust them to have unprotected access to your trusted machines anyways?


Why is it dangerous to stay logged in as root for an extended period of time?

In fact is it not inherently dangerous to stay logged in as root; what is dangerous is leaving the room with a root shell open, because any casual attacker could then do quite some damage (he could do it nonetheless, because physical access is physical access, but with an open root shell it is much easier and faster).

sudo, on the other hand, as an inherent timeout: it will require that you enter your password again if you have not executed it for a few minutes. This feature is like the "automatic screensaver lock" for root command lines, that a root shell does not have. It is a protection against your own distraction.

Of course, the same attacker could use an open shell at your name to install a fake "sudo" command, which calls the real one but also sends him a copy of your password, so leaving open shells around is a bad idea anyway, root or not root. Also, some people add "NOPASSWD:" to their entry in /etc/sudoers (I have done so myself quite a few times). The ban on root shells has become a widespread dogma, that people parrot mindlessly without thinking about the why.


Sites sending email using my email address

Well the bad news is you can't stop it, it is fairly easy to spoof the email address. And you can't effectively stop others from using your email.

The good news for you is that most of the time your spam folder is going to filter this out due to the spam like nature as well as the other identifying factors. Emails have some information in the headers that usually will be a sign that the email is spoofed thus alerting your spam detection system. Since gmail is picking it up as spam and NOT your account then whoever receives that type of email will be placed in the spam folder while your legit emails should be fine.

Bad News - Can't stop them effectively
Good News - Hard to really spoof an email the correct way and change and alter each bit of information correctly, and spam detectors are getting better and better


The short answer is that MD5 is widely discussed because it's had widespread historical use, and MD6 isn't because it's relatively unused and has faded into obscurity due to a multitude of better of alternatives.

Why isn't it more popular? It was an entrant in the SHA-3 competition, but was eliminated in the first round because it simply didn't stack up against the competition. It was noticeably slower than other competitors, didn't offer much in the way of advantages over them, and its formal proofs weren't complete.

In the meantime, SHA-2 is still considered secure and is in widespread use, the Keccak digest was chosen to become SHA-3 and serves as an emergency backup should Merkle–Damgård constructions in general become broken, and BLAKE2 — a derivative of one of the other finalists in the SHA-3 competition — has gained support as a direct successor to SHA-2 due to improved speed, security, and features. Given that, there's not much of a reason for anyone to further consider MD6.


Question about saving credit card info on PW reset [PCI]

I am wondering if this has any sort of PCI implications that could
  land us in hot water?

None that you're not already dealing with.

PCI cares deeply about how you store PAN (Primary Account Number) and related information.  If you are storing credit cards, they need to be securely encrypted, and the machines they're stored on require certain security measures, and the network they're transmitted using requires certain security measures... when you store PAN, you're signing up to do a lot of security and auditing work.

That is true whether you're storing them for a day, a year, or any period.  If you expunge a user's PAN data every 3 months when they change they're password, your obligations are no different than if you don't expunge it.

(Tokenization - probably offered by your Processor - can reduce the scope which you have to protect, because you aren't storing the PAN personally.  However, it doesn't make any difference for your concern; a non-expunged token remains usable after the password reset just as a non-expunged PAN would)

Personally, I don't know that I've used a merchant who requires full PAN re-entry after a change, although re-entering the CVV I have seen.  You may be able to find alternatives (re-enter the CVV; answer a Security question; ...) that are less intrusive ways of being extra careful following a password change.

(To be clear, the point of asking for the CVV is to use that during the credit card auth as an extra validation, not to compare it to a previously stored value - DSS doesn't permit you to store CVV between transactions.)


How do the authorities know who's downloading protected software?

Yes, web service providers of all kinds store some information about their users and users' activities. For various reasons — infrastructure monitoring, resource allocation, targeted advertisement… That information can be obtained by authorities with a warrant, subpoena, or a polite request, depending on the provider, type and amount of data. Here Google for example provides a map with requests broken down by country.

Raiding is usually not necessary, though happens sometimes. Even Megaupload provided information requested by the authorities with a warrant and held on to the potential evidence.

The situation is a little different for p2p networks. There, evidence against users is usually provided by companies doing active monitoring of the "swarm" by joining it and downloading data from users to confirm that they are indeed sharing copyrighted materials. Torrentfreak obtained some insider details a few years back and the general idea remains the same.


EMV as authentication technology and not a data security technology

1: Since EMV uses dynamic CVVs, a CVV of a recorded transaction is useless, since its spent. Thus they lack the complete info to create a (functioning) magnetic stripe card. However, doing a fake transaction might give a working magstripe card. But that magstripe card will only work a single time, and not work after the cardholder does any legit transaction, and then the bank will immediately detect the out-of-order iCVVs and thus block the card.

Also the frauster needs to be able to predict certain random numbers, which in some cases might be predictable due to terminals lacking good RNGs.

2: Different CVVs are used for different purposes, eg one CVV for CNP transactions, one CVV for magstripe transactions, one dynamic CVV using keyA for Contact chip transactions, Another dynamic CVV using keyB for RFID transactions.
This allows the bank to differentiate by different transaction types.

All POS transactions are recorded differently from all online transactions, HOWEVER:
Some webstores process their transactions as POS transactions. That causes the system to accept the transaction anyways.

Some retailers also do not require CVV, sometimes this is retailers that do not put a authorization hold on the account when first setting up a stored card to account, and since its prohibited to store CVV in ANY WAY, they don't ask for it since they have no means to verify it without charging the card. They allow you to set up the stored card.
Most reputable companies instead ask for CVV when storing the card, and then charge like 1$ to the card to check if the card does actually work and then adds this amount to your account on-site. This does however put off some customers.


Identifying vulnerabilities in simple program with malloc

Malloc is used for -

char* firstName = malloc(sizeof(char)*50);
char* lastName = malloc(sizeof(char)*50);

You are right in that these are on the heap. But what then happens to this data? And how do these functions work?

What else is read from the user? And how?

Reply to your comment below

  So as I see it in my limited scope and understanding, the vaulerabilities are: all the printf, the scanf for studentid

studentid is an int. So I believe the operations on it are safe.

  , gets for first and last name

  But because malloc was used for the first and last name, does that kinda safegaurd all instances of the gets for them.

The data immediately after the gets will be on the heap yes. But does this make it safe? What happens if the user puts in more than 50 characters for either field? I'd suggest reading up on Heap Overflow. Even if corrupting heap data wasn't an issue look at what the code then does with that data. What will the strcpy and strcat do?

  gets for level / gets for percentage

Yes. Not only can these both be caused to overflow but what happens after the "graduateLevel = &level;" line?

Reply to second comment -

  confused as about you last point and what happens after "graduateLevel=&level;"?

"char level[2];" is declared within the curly brace directly above. This means it is only protected within that blocks scope. That scope ends on the line after "graduateLevel = &level;". So graduateLevel points to the address where level used to be. But the compiler no longer has any obligation to make sure level is not overwritten. Any operations using level after this point are undefined behavior.

Now this issue is pretty minor. There is a fairly high chance the compiler won't reuse it. Compared to level being read in from a gets call above its negligible. But code like this frequently leads to odd and hard to track down bugs - some of which can be exploited.

  I am bit confused cause I have read a few places that strcpy and strcat are issues, but I have also found that they are not?

First of all you need to read and understand the definitions for strcpy and strcat. Lets take strcpy -

  Copies the null-terminated byte string pointed to by src, including the null terminator, to the character array whose first element is pointed to by dest.

So, it copies characters out of the source array into the destination array until it hits a null terminator ('\0' - usually byte value 0). Notice the warnings -

  The behavior is undefined if the dest array is not large enough. The behavior is undefined if the strings overlap. The behavior is undefined if either dest is not a pointer to a character array or src is not a pointer to a null-terminated byte string.

So - for the line

strcpy(studentName, firstName);

do these apply? Dest is studentName - a 100 character array. Source is firstName - a pointer to a 50 character array. But is firstname null-terminated? Well its value came from -

gets(firstName);

gets is defined as -

  Reads stdin into the character array pointed to by str until a newline character is found or end-of-file occurs. A null character is written immediately after the last character read into the array. The newline character is discarded but not stored in the buffer.

With the warning -

  The gets() function does not perform bounds checking, therefore this function is extremely vulnerable to buffer-overflow attacks. It cannot be used safely (unless the program runs in an environment which restricts what can appear on stdin). For this reason, the function has been deprecated in the third corrigendum to the C99 standard and removed altogether in the C11 standard. fgets() and gets_s() are the recommended replacements.

  Never use gets().

So. If I were to enter "Dylan" in firstName would contain 'Dylan\0'. What happens if I entered in 200 bytes?

The standard says its undefined but for most real systems its easy enough to guess. Its just going to keep writing into whatever memory is after firstName. What happens then? Well - if it leaves the memory space the process can legally write to the OS is probably going to kill it. But if it doesn't then it will keep running oblivious until either something goes wrong enough to cause it to crash (whatever was supposed to be stored back there isn't any more) or the program terminates. Now as you pointed out the damage is limited - this data is stored on the heap.

So. Lets assume everything continues with no issues until the strcpy. What happens there? strcpy does not know firstName is only supposed to be 50 characters. Or that studentName is only supposed to be 100 characters. Its just going to keep copying until it hits a null terminator.

lastName and strcat have exactly the same issue.


ssl client authentication: check only one certificate VS certs signed from a ca

Certificates are signed. When a server authenticates clients through certificates, the following three things happen:

The client demonstrates mastery of the private key corresponding to the public key which is contained in its certificate. This part happens within SSL; as part of the protocol, a signature is computed by the client over a challenge from the server. You don't have to care about that because the SSL library you use already does it.
The server validates the certificate. Validation is about making sure that the certificate contents are genuine. To validate a certificate, the server verifies the signature on the certificate, with regards to its issuing CA public key. The CA public key is itself obtained through the CA certificate, which has to be validated as well, and so on. This process ultimately binds to a public key known a priori, called a trust anchor or root CA.

The Apache SSLCACertificateFile and SSLCACertificatePath directives are used to configure which root CA your server will use.
The server decides whether the authenticated user should be granted access or not. This is what Apache's SSLRequire directive is about: a filter on authenticated identities.

The first step is the method by which the server makes sure that the client is "whoever owns public key Kp" (as found in the sent certificate). Second step is the mechanism which reveals to the server the identity I of the owner of Kp. First and second step together give to the server some guarantee about the identity of the client. Now that the server knows who is calling, the server must still verify that the caller is indeed allowed to do the call. If we want to use strict terminology, the first two steps are authentication per se, while the third step is authorization.

An analogy:

The client is Bob.
The private key is Bob's face.
The certificate is Bob's ID card.
The SSLRequire directive is the list of expected guest, within the hands of the security guard.

Bob demonstrates ownership of is face by virtue of that face being firmly attached to his body (the guard checks that the face is not a mask); that's the first step.

The security guards inspects the ID card, concludes that the card is genuine (we assume here that ID cards cannot be falsified), and that the photo on the ID card matches the face of the individual currently standing in front of him. Since Bob's name appears on the ID card, the security guard now knows that he is talking to the genuine "Bob". That's the second step.

Then the security guard checks whether his list of allowed guest contains Bob's name. If it does, he will let Bob in. Otherwise, he will shoo Bob away.

Dave, a party crasher, wants to get pass the security guard. To achieve that, he has to break through one of these steps: either get a fake Bob face (with a mask so perfect that the guard will be fooled), or get a fake ID card (with Dave's face but Bob's name), or alter the guard's list (simply adding his own name to the list). Going back to the Apache server, this means either stealing the client private key (e.g. by cryptographically breaking it -- good luck with that !), obtaining a fake certificate (which entails bribing or hacking one of the CA which Apache has been configured to accept), or altering Apache's configuration (its SSLRequire directive). Since altering Apache's configuration means that Dave already has root access to the machine, this is usually not a relevant attack.

Knowing Bob's name is not sufficient for Dave. THAT is the answer to your question: no, knowing what to put in a fake certificate (the issuer and subject DN required by SSLRequire) does not allow crafting a fake certificate; the attacker still has to corrupt some CA so that he gets his certificate signed (in a way that the server accepts).


Why does whatsapp use phone number instead of username for identification?

It's easy to use.

Everybody has a phone number, and you normally have the phone numbers of most people you want to chat with.

Therefore, you only need to allow WhatsApp access to your contacts and can chat right away.

This has of course some privacy implications, but the easiness seemed to be more inportant to the developers of WhatsApp than better privacy.

(And even the "private" messenger Signal asks for access to the contact list and compares it to the list of registered users... see https://whispersystems.org/blog/contact-discovery/ )


What is the best way to transmit password hash over unreliable TLS?

You can't.

There is no secure way to transmit it if you can't authenticate the server and establish a secure channel. If you can't authenticate the server then you can't be sure if you are talking to the server or the attacker. Hence, even if you use TLS to establish a secure channel, it doesn't protect you at all since you could be talking to the attacker while thinking that you are talking to the server.

The certificate is essential. Without it, or some knowledge of the public key of the server, you cannot be sure that you are really communicating to the server as an attacker could act as a man in the middle between you and the server.

TLS use Diffie-Hellman for the key exchange. If you look at the security section of the wikipedia page you will find the following attack which is exactly what you are vulnerable to.

  In the original description, the Diffie–Hellman exchange by itself
  does not provide authentication of the communicating parties and is
  thus vulnerable to a man-in-the-middle attack. Mallory may establish
  two distinct key exchanges, one with Alice and the other with Bob,
  effectively masquerading as Alice to Bob, and vice versa, allowing her
  to decrypt, then re-encrypt, the messages passed between them.

Conclusion

You need to have a valid certificate to be able to authenticate the server or you will be vulnerable to man in the middle attack. An easy way to achieve that is to include the server certificate in your application which is also known as certificate pinning.


Allow only YouTube videos and block other videos

As Far As I know, you have 3 choices:

You can use URL filtering by allowing "youtube" or any URLs in the MikroTik firewall in the layer7 protocol field and deny the other specifically or deny all as that link shows.
You can use content filtering to block Adult WebSites in your MikroTik.
You can use proxy servers such as Squid for URL filtering.

There is also another solution that may help you, you can monitor your network NetFlow Traffic and find out what is exactly going on, on your network and based on that you can provide a good and suitable solution for issue.


What threats are you concerned about? Being able to perform a SELECT is a security risk, if that user is not supposed to be authorized to view the data. You need to be more explicit in your question, and with yourself.

Other than that, you will need to get specific answers from Oracle professionals. For instance this site.


Would client side hashing provide security from a comprised server

Your proposed scheme "works", but it achieves nothing. If a cracker obtains your database, they will still be able to guess-and-check potential passwords for users. The salt used when you hash on the client side has to be the same each time (otherwise the same user wouldn't be able to log in again with the same password).


Is it Social Engineering when a keylogger is installed from a compromised account on the domain?

but what of the case where an adversary has gained access to a machine over a network and installed keylogger software on the target machine.

This is not social engineering.

You are describing the outcome of an attack: an attacker gains access to a machine an put a keylogger. You are describing what happened. However, social engineering is not an attack per se, but an attack vector. Social engineering is more about how it happened.

To call this social engineering, you would need to interact somehow with the victim and influence them to perform some action needed for the attack. How did the attacker managed to gain access to the machine? If the attacker impersonated one of the victim's friend and sent a mail along the lines of:

  Subject: Lol dude

  Message:
  Dude, have you seen that pic of you? Why did you do that lol!!

  File attached: IMG_1234.jpg.exe

Then, it would be social engineering. :-)

One last, thing, when you said:

  In general using a keylogger as a physical device […] [is] related to SE

Once again, this is not social engineering. It depends of how you managed to get that device plugged into the victim's computer.

Did you break-in, during the night and plugged it discretely?
That's not social engineering.
Did you make a malicious USB key, put a sticker TOP-SECRET on it and dropped it in front of the victim's door?
That's social engineering.


Has my GPG subkey been uploaded to the keyserver?

The normal pool.sks-keyservers.net contains a bunch of SKS software versions, requiring at least 1.1.2. SKS only fully supports ECC keys since the most current version 1.1.5, so some servers are not able to work with your keys, and they will omit what they don't understand, thus throw away some packets of your key.

Use subset.pool.sks-keyservers.net instead, which is limited to servers running the 1.1.5 release, and thus fully ECC compliant.

Update based on the mailing list reply: ed25519 OpenPGP keys have only been standardized after release of SKS version 1.1.5. As of January 2015, only prerelease-versions of the SKS key server will print the key without missing packets (with newer versions supporting it by defualt), but will already be fully retrieved by appending &clean=off to the URL with servers running version 1.1.5.


What are the loop holes in SSH tunneling?

My question is what is the risk of doing such thing

You are exposing an application running on an internal system to the wild internet. If a feature or bug in the application allows for example remote code execution then the attacker will be able to execute this code on your machine and thus inside your local network and thus might reach and attack internal systems in your network which should not be accessible from outside.

  ... only giving access to the authenticated user to port forward?

My initial interpretation of this question was that you as the one exposing the internal application wants to restrict which external users could connect to this forwarded port. But there is no authentication at this level, i.e. it is simply a TCP port which is reachable from outside for everybody. Any kind of authentication need to be done in your application. Only, this is then done again at your internal systems which means problems before or during authentication might again affect your whole internal network.

Based on your feedback it looks like you switched roles for this part of your question, i.e. no longer being the one which wants to make its application accessible but instead being the administrator who wants to prevents this. In general: if the user has only restricted access via SSH (can execute selected commands) then one can limit also the port forwarding (option no-port-forwarding in OpenSSH). If the user instead has full shell access he can work around such restrictions.

  is there any other way around without using third party apps like ngrok?

ngrok is not a simple broad port forwarding but instead allows to publish the application only for selected users by requiring authentication. If this restricted access is used the risk is greatly reduced, i.e. only users which know the URL and have the authentication credentials can connect. Still, if you cannot trust these users to keep these access credentials private and also to not attack your system then you should not do it.


Can't explain data from side channel attack attempt

First, some comments on the code:

Your calls to strlen are a black box - you cannot possibly know how they react to timing attacks.
Your compare loop exits after you exhaust the shortest string, leaking the shorter length.
You did not remove bias generated by the loop in test_with_length.
Array accesses are not O(1) time complexity, especially if each element is smaller than the word width of your CPU.

A better way to compensate for such attacks:

bool CompareStr(char* strA, char* strB)
{
    bool result = true;
    int lenA, lenB = 0;

    while(strA[n] != 0)
        lenA++;
    while(strB[n] != 0)
        lenB++;

    int maxLen = (lenA > lenB) ? lenA : lenB;

    // compensate for array access to some extent
    int diff = (lenA > lenB) ? lenA - lenB : lenB - lenA;
    char dummy = '\0';
    for(int i = 0; i < diff; i++) { dummy = strA[0]; }

    // better way to avoid timing attacks
    for(int i = 0; i < maxLen; i++)
    {
        if ( ((i >= lenA) ? strA[0] : strA[i]) != ((i >= lenB) ? strB[0] : strB[i]) )
            result = false;
    }

    return false;
}

// compute loop overhead
time_pre_loop = getTime();
for(int i = 0; i < LOOP_COUNT; i++) { }
time_post_loop = getTime();
double diff = time_diff(time_post_loop, time_pre_loop);

time_pre_test = getTime();
for(int i = 0; i < LOOP_COUNT; i++)
    CompareStr(strA, strB);
time_post_test = getTime();

double result = time_diff(time_post_test, time_pre_test) - diff;

Anyway, here's where the fun part starts. Consider the following assembly code that could be used to compute whether two strings are equal, with early-out optimisation removed as a basic timing attack defense:

 xor ecx, ecx                         ; clear counter to 0
 mov dword ptr ds:[0040AAAA], 1       ; set result to true
loopStart:
 mov ah, byte ptr ds:[ecx+00401234]   ; read char from string A
 mov bh, byte ptr ds:[ecx+00402468]   ; read char from string B
 cmp ah, bh                           ; compare the chars
 jz match                             ; are they equal?
 mov dword ptr ds:[0040AAAA], 0       ; strings don't match! set result to true
match:
 cmp ah, 0                            ; are we at the end of string A?
 jz done
 cmp bh, 0                            ; are we at the end of string B?
 jz done
 inc ecx                              ; increment counter and continue loop
 jmp loopStart
done:
 ret

There are actually a few timing attacks here. The first two instructions are O(1). However, the two single-byte reads that follow are not.

Whilst memory reads are usually O(1), in practice they will not be. In fact, they don't fit into the big-O model at all. On a 32-bit system, every 4th byte read will be faster than the others. On a 64-bit system, every 4th byte will be faster, and every 8th byte will be faster still. This is due to non-aligned memory reads. The CPU is great at fetching blocks of data that are aligned to its bus size, but not so great at fetching random individual bytes. The CPU will attempt to optimise this by pipelining instructions and loading the block into its L2 cache, which makes this issue more subtle, but it's still there.

The next trick is for strings that are larger than the CPU's cache. If you have a string that exceeds this size (usually 128KB or higher for the L2 cache) you'll see slight delays in memory fetches every time a read exceeds that boundary. This is usually only a small delay, since the L3 cache will be used to store the next block, but we can see an even bigger difference for larger strings (8MB+) as the memory fetches have to be done from system memory.

If we consider a block memory copy as O(n), where n is the memory length, this makes some sense, but does not properly depict the small variances in timing caused by implementation idiosyncrasies.

Finally, we can see that the mov dword ptr ds:[0040AAAA], 0 instruction is executed whenever one string does not match another. This leaks information in two ways:

Allows us to estimate the relative length of the shorter string by identifying the extra time used when repeatedly setting the result.
If we can measure accurately, allows us to identify which characters are different.

As we can see, it's quite difficult to prevent these issues. Here's my attempt at a better system, assuming fixed-length strings padded to alignment with null bytes:

int r, d = 0;
int* bufferA = (int*)stringA;
int* bufferB = (int*)stringB;
for(int i = 0; i < BUFFER_SIZE; i += 4)
{
    d = bufferA[i] ^ bufferB[i]; // if equal, d = 0
    r |= d; // if all cases are 0, r will be 0
}
return r; // result is 0 if equal, non-zero if not equal

This is almost perfectly O(n) for the following reasons:

Bitwise xor of aligned ints is O(1)
Bitwise or of aligned ints is O(1)
Memory reads are aligned.
Neither length is leaked, due to BUFFER_LENGTH padding.
No branches, excluding the loop.


Detection for corruption in HTTP and FTP

How is data downloaded from HTTP or FTP get checked for corruption?

By itself, not  at all.

HTTP and FTP as protocols don't offer integrity¹.

However, HTTP and FTP are usually used atop of TCP/IP, which both have checksums in their transports – if a TCP checksum fails, your operating system will just discard the TCP packet and ask for it again. So there's no need for HTTP to even implement integrity checking.

When tunneling anything (including HTTP and FTP) over TLS, you get an additional layer of integrity checks.

  So how does FTP and HTTP ensure that data is not corrupt?

They don't. It's usually the transport's job to guarantee integrity, not the job of the application protocol.

 ¹ there is an optional header in HTTP1.1 that allows the server to specify a checksum, but since that is practically impossible for resources generated on the fly and comes at high cost for large files, and has little advantage over  the much more fine-granular TCP-checksuming, it's rarely used. I don't even know whether browsers commonly support it.

I'd like to add here that it's of course harder to cause a collision within MD5 (which is used in these headers) than to forge TCP packes, if you'd want to intentionally modify the transfer. But if that is your attacking scenario, TLS is the answer, not HTTP checksums.


Why hashing algorithms in layer 2 are weak?

The answer to this question will depend on the vendor in question, but in general the answer is likely to relate to cost, backwards compatibility and cost of upgrading.

Implementing new alorithms requires testing which costs money.  There is sometimes a requirement to support older algorithms so that older client or peer systems can still communicate with the device and also sometimes older hardware with slower processors may need upgrading to cope with more CPU intensive newer algorithms.


As was already mentioned in the comments, keys are not alphanumeric. They are binary, but because binary is hard to work with, they are often encoded either as hexadecimal or Base64 strings.

It allows you to for example post them online, view them in a text editor and so on, while you could not do any of that properly with their binary form.

When keys are being used, they are decoded into binary again and stored in memory (RAM).


When to use a Bind shell vs. a Reverse shell?

Bind tcp opens up a port on the victim's device. Usually a machine is behind a firewall (or NAT) and firewalls don't allow ports other than a few specific ones (like 80, 443, 22, etc). Reverse TCP tries to connect to you (from the target machine back to you: you open a port and wait for the connection). The attacking machine (yours) has a listener port on which it receives the connection, after which, code or command execution is achieved. If it is remotely, port forwarding should be done on your router.


Why can't you steal the synchroniser token to do CSRF?

What stops a malicious site from obtaining the anti-CSRF token is the Same Origin Policy. The Same Origin Policy, or SOP, is at the browser level, and defines where JavaScript is allowed to communicate.

JavaScript on example.com cannot call example.org to get data. Also, JavaScript on http://www.example.com/ cannot call http://www.example.com:8080/ as the port differs. There are further restrictions which are set and can be found here: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy.

There are exceptions to this with Cross-Origin Resource Sharing, but that has its own rules that browsers have to follow. CORS can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS.


Security of Linux Full Disk Encryption (Ubuntu / Mint) -insecure?

Am I paranoid or is it just a lie that SHA1 has been broken

As you can read here and elsewhere, SHA1 is no longer that robust. You may be also interested in reading How secure is Ubuntu's default full-disk encryption?.  Check the list of supported LUKS ciphers, and For LUKS: The most preferable and safest cipher?.

Depending on the goals you are using LUKS for, maybe the answer to this question will calm you down.

Now if you are as paranoid as all the members of this website, of course LUKS is not that safe as you can read here. There are even practical and opensource tools to crack LUKS volumes.  Such as this one.

Another alternative to LUKS is the use of TRESOR or maybe you will be interested in reading Linux, TRESOR and XTS to feel safer until your next paranoid crisis :)

Regards.


The certificate has (almost) nothing to do with the encryption used in the SSL/TLS communication. The only purpose of the certificates used by the websites you mention is to authenticate the server.

RC4, AES-128, AES-256 are the encryption algorithms used by the SSL/TLS channel itself. In this context, SHA is the MAC algorithm name (used to ensure the integrity of the communication).

Both are encryption and MAC algorithms are set up with the cipher suites, which are configured on both client and server, and are (relatively) independent of the certificate. The only dependency is that some cipher suites require a certificate with an RSA key, others a certificate with a DSA key.

If you look at the cipher suite list in the TLS 1.1 specification, there are cipher suites for RC4-SHA, AES128-SHA and AES126-SHA with RSA keys. Any modern certificate with an RSA key should be able to supports these, provided that the SSL/TLS stack you want to use also supports them, and is configured to do so.

(You may also be interested in this question.)

In openssl genrsa -aes128, -aes128 is used to tell OpenSSL how to encrypt the private key it's generating (in the file itself).


Did D-Link's certificate revocation really only invalidate 1 day (of a six months long exposure)?

OCSP provides a dynamic mechanism for checking whether a given certificate has been compromised or not and, in case it has been compromised, after what date (and time) should signatures using this certificate considered unsafe (basically, it is a dynamic version of CRLs).

This has several consequences:

OCSP responses SHOULD be backdated in case they indicate a "revoked" status. The reason for this is simple: a key is usually discovered to be compromised long after the actual control of that key has been lost. Therefore, it is logical to provide a way to inform users of that certificate whether old signature should also be considered invalid (without revoking ALL signatures).
Once a certificate has been revoked, it CANNOT be considered valid again.

All this is made more complex by the fact that OCSP responses can be 1) cached and 2) pre-produced. This means that, during a period of time after a certificate revocation status has been issued, it is possible for different OCSP clients to receive different answers. This situation can last until the date indicated by the nextUpdate field of the last "certificate valid" answer is reached.

So:

  Does D-Link's move retroactively invalidate just 1 day of possible use/misuse of their key?

No. They retroactively invalidated the certificate starting at 00:00:000 that day.

  Will an (hypothetical) EXE signed on Sep 2 with the stolen key STILL work, despite the revocation?

Yes because it was signed before the certificate revocation time.

  Are you supposed to backdate that to the first point in time that you think the key was compromised?

Yes and no: you're supposed to backdate it to the date when the key was last known to be safe.


Should JWT token be stored in a cookie, header or body

By putting the token in the cookie and setting that cookie HttpOnly, you can prevent access to the cookie by malicious client side script (ie, XSS) - there is no access to an HttpOnly cookie from JavaScript, the browser will protect it and handle sending the cookie only to the right origin.

https://www.owasp.org/index.php/HttpOnly


Is this jQuery ajax call vulnerable to XSS?

Yes it is vulnerable, but not it the way you suspect. The attacker would not try modify the loaded URL, but to execute the code directly. For example:

$_GET['fname'] = '"+(function(){/*any_code_i_like*/})()+"';

will become:

$.ajax({
   url: "http://mywebsite/script?param="+(function(){/*any_code_i_like*/})()+""

and the code will execute even before requesting the URL with ajax. It's just an example, there are other vectors that would work here too. The simplest way to escape the parameter to prevent XSS in this context would be using urlencode() in PHP like this:

$.ajax({
  url: "http://mywebsite/script?param=<?php echo urlencode($_GET["fname"]); ?>"
  dataType: "jsonp",
  success: function(response) {
      document.write(/*fields from response object*/);
  },
 });

Also, take a look at OWASP XSS Prevention Cheat Sheet.

Update: After you updated the question - there is no XSS vulnerability here (you can't e.g. point the request to another domain), but the example is vulnerable to a different beast - HTTP parameter polution. It might not matter in this exact case, but imagine that the given parameter is:

a_valid_value&param=another_param_injected

The attacker is able to inject additional HTTP GET parameters which might be important for your application and might change the execution flow (e.g. parameter admin=1). You should get into habit of escaping/encoding everything coming from user input. In this modified case you should use Javascript encodeURIComponent function which prevents attacker from injecting '&','=' and '?':

"http://mywebsite/script?param=" + encodeURIComponent($("#field").val()),


Is it a real security benefit if a host uses static IP Addresses for authentication?

I'd say that there can be a benefit from using static IP addresses.  Essentially if at the firewall you can say "only allow traffic to this port from these specific IP addresses" then there are a number of effects.

An attacker scanning the Internet for vulnerable hosts is unlikely to detect the service and therefore be able to attack it
An attacker who is more determined will have to compromise a host which has one of the allowed IP addresses to get access to the service.  Depending on how the list is configured this would be more or less difficult.  For example if one of the IPs is a proxy server which allowed anyone in a large company to get to the service then the benefit is reduced as there's more systems for the attacker to try and compromise. However if it's server-to-server then the attacker has a likely harder job.

As to IP address spoofing, on the Internet this is an overplayed risk (IMO).  Spoofing TCP based services (e.g. HTTP) is impractical on modern Operating systems.  UDP services can be spoofed but you need to know information about the receiving service so it's still likely to be an impractical attack for most attackers.

As to rented against ISP assigned, I'd say there's not a major difference although there is a risk with rented that after the rent expires someone might forget to update the ACL so you end up with more systems than necessary having access...

So overall I'd say it's a reasonable part of service security, although I wouldn't rely on it, on it's own.


How do we know that input to TPMs actually comes from the measured code?

You don't. A TPM only protects against “mild” physical attacks. For example, it does protect against plugging in an alternate hard disk and booting from that. If the disk is encrypted with a key in the TPM, it protects against taking the hard disk out and plugging it into another machine. But it doesn't protect against an attacker who can inject data into the bus between the CPU and the TPM.

Remote attestation answers the questions “am I talking with the computer I think I am?” and “is this computer running the software I think it is?”. If “the computer” is not some monolithic entity and an attacker might have tampered inside it, remote attestation isn't enough, you need local anti-tampering protection.


Where to put a code signing server with EV code signing certificate and plugged-in HSM

Since I think all 3 of the CIA model would apply here, you would want to physically store it in a location where you can enforce physical access controls to restrict access to only those that need access to it. You would also want to install a FIM (File Inegrity Monitoring) solution of some type to ensure the integrity of the file system doesn't change from unauthorized changes. I would recommend locking it down based on one of the CIS benchmarks depending upon the operating system along with a host-based firewall and probably have a network firewall in front of it to restrict network access to it as well.


Location of Password Hashes on a Windows Local Machine?

C:\windows\system32\config\SAM (Registry: HKLM/SAM)
System memory

The SAM file is mounted in the registry as HKLM/SAM. Windows locks this file, and will not release the lock unless it's shut down (restart, BSOD, etc). However, if you look at the SAM entry in the aforementioned registry section, you will not find the hash.

Therefore, it seems more than likely that the hash, or password, will also be stored in memory. In fact, there are quite a few password crackers that take your password directly from memory.


What sort of attack can reset MySQL Privileges and unmount remote drives without root or shell?

A reboot of server A.

What's the uptime of server A ? Is it possible that it is having an disk error / getting restarted? In that case, the sshfs mount would obviously require a remount. And sometimes there are boot scripts in place that could be resetting some credentials to the default ones…

PS: You don't need the FLUSH PRIVILEGES when using the GRANT statement. Only when directly changing the mysql.user table (INSERT, UPDATE…) it is needed.


Is there non human risk related to idle sessions?

There are many risks.  The examples I am will be giving can be done even when the session is actively being used by the user.
First example involves a malware that first acts as a key logger, to catch a sudo credential, then it automatically starts to send keyboard strokes to the OS.  These key board strokes involve commands being entered into the SSH console.  Think of it as a rubber ducky attack with a key logger that does not involve a USB or removable media.
Another example involves an exploit with the SSH console software at the user end.  This exploit would use a port other than the SSH port.  An adversary that may know what SSH software (ex. PuTTY) is being used and send arbitrary data to that port.  This arbitrary data would be an exploit that might cause unseen changes at first to the configuration of the SSH software.


What is the purpose of using random IP addresses in SYN Flood Attack?

A client opens a TCP connection by sending a SYN packet to a server. The server replies with a single SYN+ACK, and the client responds again with an ACK. Because of natural network latency, the server may wait a short time after sending SYN+ACK to the specified source address for an ACK reply, and this behavior is what a SYN flood exploits. Because the source address was spoofed, the reply will never come. If the server is waiting on enough fake connections that will never be completed, it will become unable to open any new connections, legitimate or not. This condition is called denial of service.

SYN flood attacks do not require the attacker receive a reply from the victim, so there is no need for the attacker to use its real source address. Spoofing the source address both improves anonymity by making it harder to track down the attacker, as well as making it more difficult for the victim to filter traffic based on IP. After all, if each packet used the same source address (whether spoofed or not), any decent firewall would quickly begin blocking all SYN packets from that address and the attack would fail.


Need raw certificate/key to sign PDFs via Java app. But vendors seem to only sell HSMs for this. What to do?

Is there some regulation that digital signature certificate can only be given in form of hardware token for security reasons?

I'm not sure what Adobe requires of you but it seems to hint in the "secure hardware only" direction.
If you want to use Adobe Certified Document Services, then indeed, you must fulfill some requirements:

6.1.5 Key Sizes
CDS Subordinate CAs shall use an RSA key pair with at least 2048 bits.
CDS Subscriber certificates shall use an RSA key pair with at least 2048 bits.

And further on this: (line breaks added for readability)

6.2 Private Key Protection
6.2.1 Standards for Cryptographic Module
Standards for cryptographic modules to be adhered to in the CDS PKI are decided by the Adobe Policy Authority.
CDS Subordinate CAs must use cryptographic hardware modules that meet or exceed FIPS 140-1 Level 3 standards.
CDS Subscribers must use cryptographic hardware modules that
(a) meet or exceed FIPS 140-1 Level 2 standards or
(b) for which the cryptographic hardware module manufacturer has applied for FIPS 140-1 Level 2 status within the previous year without receiving a notice of noncompliance or other communication indicating that such device fails to meet such standard.

But: I don't know if "Adobe Certified Document Services" is indeed the only way to get a PDF signed so that it will be recognized by Adobe Reader out of the box.
There may be other ways. I don't know. But we now know this: if you want Adobe CDS, then you need special key storage hardware.


Why should I expire validator links after a while?

[1] Efficiency:

Assuming you issue a new token for each link for every registration attempt, you will end up with a with a number of tokens that you have to keep track for an indefinite amount of times. For practicality terms I would suggest you set a time/date expiration period depending on the nature of your application.

[2] Security:

In the case of password reset function you want fresh tokens to minimise the likelihood of your token to be guessed or stolen by an adversary. Let's say for example we have a web application that issues a 6 digit password reset token that never expires. It will allow an attacker to initiate the password reset process and guess the correct password via bruteforcing all possible combinations. A time/date expiration will significantly minimise the attack window.

Creating a static token that is valid forever is bad practise. For all the reasons stated above depending on the nature of your web application, tokens must be adequately complex, fairly random and valid only for a reasonable amount of time.


Overwrite eip twice for buffer overflow?

Keep in mind with an overflow that you are not just "overwriting EIP", you control the stack completely. This then allows you to ensure the next return address on the stack is whatever you want. It only ends up in EIP when it is time to execute it. This is important to understand.

When you redirect control flow to a different function using the overflow, where does that newly called function look for a return address when it's done? Again, the stack!

Using this knowledge plus the proper calling conventions for the program's architecture, we can shape the stack to chain together multiple functions. This is a basic example of ROP (return oriented programming).

For an x86 Linux binary, this is how the stack needs to look regarding calling functions, from lower addresses to higher addresses (in the order you'd overflow):

<function_to_call_addr> <next_return_addr> <arguments_for_function>... <function_to_call_addr> <next_return_addr> <arguments_for_function>... ...

Now, you don't always need to call functions. You can also return to "ROP gadgets"; usually one or more useful instructions followed by a ret. However, if you are not passing any arguments, you shouldn't need to worry about cleaning up the stack or anything. Therefore, your payload should look like:

overflow + privileges + password + AAAA

This calls the privilege function, and tells it that the next return address is the address of password. The next address doesn't matter, since hopefully you've gotten what you've wanted. To be complete, you could change it to resume normal execution of the program.

Let me know if this is wrong. I mostly work with x64 Linux these days so my x86 is a bit rusty.


Specify Location of Certificate Signing Requests in OpenSSL Configuration File?

Such functionality is not there - and it is not needed: contrary to ca the req command creates exactly the files as given on the command line. So the easiest way is to use absolute path with req and creating a wrapper script around it which sets the directory part for these absolute path based on your preference.


Why do testers often use the single quote ( ' ) to test for SQL injection?

The character ' is used because this is the character limiter in SQL. With ' you delimit strings and therefore you can test whether the strings are properly escaped in the targeted application or not. If they are not escaped directly you can end any string supplied to the application and add other SQL code after that.

The character ; is used to terminate SQL statements. If you can send the character ; to an application and it is not escaped outside a string (see above) then you can terminate any SQL statement and create a new one which leaves a security breach.


Is there a way for a consumer to report PCI non compliance?

The PCI organization sets the standards. The card brands enforce those standards with fines. If you contact a brand (Visa, American Express, etc)., they may act on it. I am not aware of any PCI compliance hotline, and it may involve a lot of transfers and "call this person" redirects to find somebody... who may do nothing anyway. If you have the time, though, I encourage you to work on finding your way through that process.


Would authorisation codes in Star Trek be secure in real life?

You could setup the Google Authenticator and use the Google app to allow access. This comes the closest to your OTP idea without building anything yourself. If you want something more fancy, you should look at tiny RSA tokens, the kind used for SecureID.


Same password for full disk encryption, user account, admin account

Those three passwords protect you from different threats. Which ones are most important will depend on your threat model.

The non-admin password protects your personal files from other non-admin users
The admin password protects your system from being modified by other non-admin users
The FDE passwords protects your system from attackers with physical access

As what the attacker may obtain from each one:

If the attacker obtains the non-admin password, s/he may try to use it to access admin accounts too. Therefore controlling the entire system.
If the attacker obtains the admin password, s/he controls the entire system  (Including non-admin accounts).
If an attacker obtains physical access to your computer and has the FDE password it doesn't matter the remaining passwords as s/he can change them.

IMHO, admin password and non-admin password should always be different. The risk of an attacker escalating privileges with the same password is too high. But maybe in your threat model it's not a major risk as you have only one account

About FDE, it's not a must have for every user. If physical access to your computer is part of your threat model (Like robbery, law enforcement or 3 letter agencies) then you should use a completely different password for this too. In case this is not part of your threat model it doesn't matter which password you use

About your assumption that FDE password are harder to obtain from software keyloggers, while this is true, an attacker that has been able to deploy a keylogger in your system may be equally capable of obtaining the encryption key from memory


Can benign software modify Widnows DLL files?

If the owner (user) of the process of the software has the ability to do so, then the software also can delete/replace/modify DLLs.


Should 2FA be enabled on service accounts?

The trouble with requiring MFA on service accounts, is that it would have to be fully automated.  For instance, a time based OTP.

But as this OTP is based on a secret seed, it is effectively just another password stored in a config available to the service account.  And it therefore gives no real additional security above that of just a single factor such as a password.


Does Windows Subsystem for Linux provide additional security (VM-like isolation) over running native Windows programs?

In a nutshell, WSL is just a Linux ABI compatibility layer, i.e. a set of libraries that translate a Linux system call into something Windows kernel is able to do.

The general idea is to have this compatibility layer as thin as possible to ensure Linux binaries run under Windows almost as fast as natively. Thus it's nowhere near a virtual machine. E.g. all Windows filesystems get mounted in WSL under /mnt for your convenience, and so on. Except for limiting the attack surface somewhat (as you've pointed out already), WSL doesn't provide any secure isolation.


Revised answer

In general, you may want to start by basing your cipher (mostly relevant for asymmetric ciphers) on a known hard problem. You may want to make mathematical proofs verifying your cipher has the desired properties and breaking it indeed requires solving the known hard problem. What kind of problems to choose was explained more on Crypto SE. By creating these mathematical proofs, you will make sure your cipher is not easily breakable directly.

The next step may be to look at side channels. Most notably timing attacks. If your cipher takes different amount of time for different inputs and keys, you may want to at least add code to either make it take the same amount of time always or just add random amount of time by active waiting.

There are many other side-channels and considerations a widely used cipher has to take into account, but this should get you started. Of course, making all these mathematical proofs is very difficult and even then, it does not give you any guarantee the cipher can't be broken. Even if the cipher is secure on its own, in combination with other cryptographic primitives, it may turn out to be easily breakable. That is why rolling your own crypto is such a big taboo. Getting it right is very very difficult and you will not find out you did something wrong until someone breaks it, or if you are unlucky, not even after that.


Is any plaintext stored as a password hash an effective way to lock out an account?

Why not have an additional field for special users?  Don't rely on just the password to set your policy -- define your policy in an appropriate field.  Username/password is used to authenticate a user.  For authorization, build that into your model.


Does S/MIME provide means to propagate a certificate's revocation?

In X.509, all revocation goes through objects signed by certificate issuers. The decision to revoke or not revoke is not in the hands of the certificate owner, but of its issuing CA. The CA makes its decision known by including or not including the target certificate serial number in the CRL it produces (ditto for OCSP responses, which are just CRL with a scope reduced to a single certificate).

S/MIME relies on CMS (formerly known as PKCS#7) for the format of signed and/or encrypted emails. CMS can embed arbitrary "helper objects", including CRL and OCSP responses, if whoever assembles the message thinks that these CRL or OCSP responses might be helpful to recipients for the certificate validations they will perform. This can be used in case the CA does not have a reliable way to push its CRL in a place where the recipient will be able to grab them (a relatively rare scenario: people who receive emails often have an Internet access). Nevertheless, these CRL or OCSP response must necessarily come from the CA (or an entity to which the power was delegated, e.g. an OCSP responder).

In the X.509 model, everybody is assumed to be able to obtain fresh CRL or OCSP responses (and they should reject certificates if they cannot). In S/MIME, the sender's certificate is included in every email he sends, and recipients are supposed to automatically record the received certificates; when they respond, their tools should pick up the newest known certificate (after validation with revocation check, of course).


DOM Based XSS attacks: what is the most dangerous example?

Cross-site scripting is cross-site scripting -- the difference between DOM/persistent/reflected is only in how the attack is done (and prevented).

The threat is the same -- an attacker somehow has injected malicious javascript into pages that they shouldn't be able to control, usually due to vulnerabilities in the design of the website.

Take the example from OWASP, where the HTML page, included some inline javascript (part inside the  tags).  The purpose of the inline javascript was to a variable from the "default" query parameter and use the value of it to modify the DOM -- that is change the value of the first <option> tag to the value of that query parameter.

The webpage source (sent over the network) looked like:

Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>

but after being viewed from http://www.some.site/page.html?default=French, the DOM would become:

Select your language:
<select>
<OPTION value=1>French</OPTION>
<OPTION value=2>English</OPTION>
</select>

Meaning your web browser treats the webpage like the above was sent over the network once its run the DOM-modifying javascript (the calls to document.write).

Now a clever attacker then sends a link (via email/webpage link) that a victim clicks pointing to http://www.some.site/page.html?default=<script>alert(document.cookie)</script>.  Then the webpage on the page (after processing the initial javascript with the document.write) looks like:

Select your language:
<select>
<OPTION value=1><script>alert(document.cookie)</script></OPTION>
<OPTION value=2>English</OPTION>
</select>

Again alert(document.cookie) could be whatever arbitrary javascript the attacker wants.

Maybe there's a secret username/password or session cookie or credit card number on the page, and instead of alert you bind pressing the submit button to an ajax call so that when the user presses submit, it sends all the secret data to a server that the attacker can access.

There isn't really one worst-case scenario -- any action you can do with javascript you should be able to do if there is a DOM-XSS vulnerability.


zip file downloaded: is it enough to remove it to be secured?

Whenever you download files you must be sure that you've turned autorun off, because some batch files or vb files or the java prompts asks your permission to allow the programme to run and they are always with fake prompt like some security issue for your computer. And one more thing you should be aware of is, you can check the directly connected network to your system and if any IP of different network is there it means someone else you don't want connected to your system and hence can send payloads to your system.
After getting known to the malicious activity in network you just can restart your system or delete the files which you've downloaded or end the services which may turned on due to that files.
Or better you can take help of a strong firewall security.


"%5c" (encoded backslash) is commonly used to circumvent sanitisation of the "../" (forward slash) in a URL - tries to stop directory transversal via the URL. As you can't have a backslash in a URL it needs to be encoded.

So if the forwardslash is blocked the backslash may work - allowing the attack.

I've seen this more often on IIS attacks rather than Linux/Unix servers.


Confusing definitions of "parasitic virus" and "worm"

The difference between a virus and worm can be confusing. Both are self-replicating computer programs, but while a virus needs human interaction to propagate, a worm is standalone and can replicate on its own (usually exploiting security holes in computer systems). For example, a virus might replicate by sending itself as an attachment in an email and trick the user into opening it, but a worm might exploit a vulnerability (like EternalBlue) to gain access to systems.


Wouldn't forging the balance of a prepaid telephone card allow to make a lot of calls?

Back in the 90s these prepay cards were easily hacked in a number of ways. First, as you said, people could reprogram them with much larger amounts for free calls. A more low-tech method was that they'd simply scratch off or cover the conductive surface on the pin which decreased the amount on the card, allowing for infinite free calls on a one-time topup. These systems are now almost universally obsolete.

Modern prepay cards usually use one of two methods.

In some cases they'll contain just a numeric identifier (ID) and your balance will be maintained on a remote server, which is the case with many MAN systems. These are usually the most secure, but they have a downside: you need continuous connectivity between the phone system and the remote server.

However, in some scenarios (particularly remote areas with poor infrastructure) the validation can't be done against a remote server. Instead, the prepay card is a smart card (similar to a SIM) with certain functions exposed. Each function requires a different access key. One function is "charge an amount to the card", and the key for this is present in a payphone box. However, this key can't be used to access the "add funds to the card" function, which is only accessible by top-up devices in stores. The keys in top-up devices are kept in tamper-sensitive systems, similar to how chip & pin machines work. The actual amount value on the SIM is kept in an encrypted form within a tamper-proof EEPROM (or similar), with an authenticity record maintained using a key pair deployed in the phones and top-up machines. Attacking these is very difficult, but potentially possible if you compromise a top-up machine.


Are there any concerns with sending and storing 3rd party cookies?

InfoSec is always a balance between risk, cost, and convenience.  In your case we're talking about a game that perhaps is not well known, so it is not a high value target.  If there is literally nothing worth hacking, there is nothing worth protecting.

Also, InfoSec tends to focus on threat modeling specific attack vectors.  You may not have to do anything if there are no attacks that would cause you grief, e.g. if the only attacks that would work are ones that don't affect anything important to your operations.  So you should try to list these.  What sorts of things are you worried a hacker could accomplish?  For example, is it a big deal if someone can alter their own scores and reports?  Is it a big deal if they could see someone else's scores?  If they could modify them?  Etc.

That being said, I can introduce you to a couple general practices that certainly wouldn't hurt anything if you did them:

If you are actually storing data in the cookies (as opposed to an identifier which can be used to obtain data) then the cookies can be modified by any user who is in control of the machine on which the cookie is stored.  Of course, they can only modify their own cookies.  But if this is still a concern, you can make your cookies a bit tamper-resistant through various means: you could encrypt the cookie (probably using private key symmetric encryption like AES), or you could sign the cookie with a Machine Authentication Code.

If you are not storing data, only an ID, and you use the ID to get data from the database, there are three suggestions I'd make.  First, make the identifier random, not sequential, so that nobody can guess others' IDs just by adding 1 to their own ID.  Second, generate the identifier with sufficient entropy (say, 64 bits) so that it is difficult to find IDs using a brute force search.  Third, tie the identifier to a user (e.g. add a UserID column to the database table) and check to make sure it matches the current authenticated user before you pull any data.

If you are worried about physical security of the endpoint-- e.g. a user playing your game in a coffee shop, who leaves the computer without clearing his cookies-- then I suggest that your cookie be provided with an expiration, or that it be a session cookie which is deleted when the user closes the browser.  Re-issue the cookie when the user signs on using his user name and password.

If you are worried that a hacker could use the cookie to inject malicious code into your application, use the cookie only to store an identifier in a known format, and validate the format of the cookie when it is submitted to your server.


Do file hosting services check user data manually by human?

Yes and no.

There are examples where such companies analyzed content stored by particular user, where it was a part of eg. criminal investigation. So, yes.

However such companies host amount of user data, that manual analysis of everything would by physically impossible, or at least unscalable and horribly expensive.

So, if any company would try to implement any anti-piracy mechanism, it would surely be fully automatic, where human analysis would take place only in later phase, for files automatically marked as suspected or something like that.

On the other hand, if we are talking specifically about piracy indicators, then there already exist several more or less intelligent analyzers, that will detect possible piracy attempts even by more subtle things than strings like "crack" in the file name.

Many aspects can be taken into consideration: file name, size, date of upload (correlation to eg. movie premieres), upload IP, relation of uploader account with other accounts etc.

If you want to know more about this matter, google for Hotfile.com closure.


Were software "CD key" schemes backdoored or simply misdesigned?

CD Key is a fundamentally flawed design. The software that checks the CD key validity runs on the user's machine, so it's running under the user's control. There's little that the software can do to protect itself from the user who knows what they're doing to bypass the check. There's little to gain for software vendor to deploy advanced security technique to prevent users from using pirated CD keys; it's simply there to raise the bar just enough to keep honest users honest, and not to keep pirates out.

Indeed, most companies that attempted to do anything beyond a very basic key checks have inevitably gotten a bad rep, because the techniques that they'll have to employ are very similar to what malware uses to hide itself, and they often get caught by anti malware software's heuristic scanners and such advanced techniques often increases the rate of legitimate users being unable to use legitimate keys. Some advanced DRM schemes have such a bad rep for using malicious techniques for implanting itself into the system so deeply, that they sometimes causes legitimate security issues on the system, which might cause some antimalware vendors themselves to consider flagging such advanced DRM as legitimately unwanted software and offer to remove them.

Many companies would rather have some pirates being able to break their DRM schemes, rather than having some legitimate user not being able to use their rightfully purchased keys. So, they keep the DRM simple and permissive by design.


'SSL Session Resumption using Cached Session IDs'

Yes, it's secure in that most implementations do it properly and the method is not flawed. However it does make it more likely that you'll reach a point where re-negotiation will occur - and there are a number of vulnerabilities in that area. OTOH disabling ssl sessions for HTTP will have a dire effect on performance.


PHP filter_input() not protecting from eval()

Which should be the correct way of securing the eval() in the case above?

There is no way to secure input to eval. Just don't use eval on any user-generated data.


Is there a term for one specific step before/during reconnaisance?

I would suggest that if this is targetted, this is part of reconnaissance. Specifically you talk about attacking the telephone network so reverse engineering the correct protocols, etc, which involves getting info on what the correct protocols and details for that network are. This is an early part of reconnaissance - possibly strategic rather than tactical reconnaissance.
If you're just talking about downloading some generic tool then well, that's just gearing up I guess?


Are password-protected ZIP files secure?

To answer this, there needs to be a better definition of "secure" and/or "safe".  It's always got to be defined in light of the purpose of the protection and the risk to the system.  There's no one size fits all here, what's "safe enough" for one system, may be abysmally weak on another.  And what's "safe enough" on another may be cost prohibitive or down right impractical in a different case.

So, taking the typical concerns one by one:

Confidentiality - marginal at best.  Confidentiality is usually rated in terms of how long it will take to gain access to the protected material.  I may be able to change the zip file, but as a hacker it'll take me some amount of time either crack the password or brute force it.  Not a lot of time, passwords are one of the weaker protections, and given the way zip files are often shared, social engineering one's way to the password is usually not hard.
Integrity - nope - as the asker points out - it's easy to change the package and make it look legitimate.
Availability - generally not applicable to this sort of security control - this usually refers to the risk of making a service unavailable - the data storing/packaging usually doesn't affect availability one way or the other.
Non repudiation - nope, no protection - anyone can modify the package, so anyone contributing to it has probable deniability.

The trick is - how much better do you want to get?  Encrypted email is an option - as a better protection.  Although it poses it's own connectivity concerns.  And there's many better ways to encrypt data - but the better options also involve key distribution challenges that can add time and cost concerns.

As a quick way to package and share some data that you don't want to make completely public - it's better than nothing, and it's sometimes the only common denominator you can work out.  For anything high-risk, I'd find a better option.