Why can't apple simply add the backdoor now and then remove it after the FBI is done? Summary of the current situation by @TTT

  Apple released an open letter to the public outlining their reasons
  for not complying with the FBI's demands to modify the iPhone's
  security mechanism.

  Here's a summary:

  The FBI has an iPhone in their possession which they would like to
  access data from. The phone is locked and fully encrypted. After
  failing to get into the phone, the FBI asked Apple to unlock the
  phone. Apple said since the phone is encrypted, they can't get into it
  either. The FBI asked Apple to modify the iPhone OS to enable brute
  force password attempts electronically. (Currently the passwords can
  only be entered in via the manual interface, and is limited to 10
  attempts.) Apple refused. They believe it would be too dangerous to
  make that change because in the wrong hands it would undermine the
  security of all iPhone users, even if they only used the software in
  this instance.

My question is, if the cracking takes seven minutes, why not just release the update, wait ten or so minutes (coordinate with the FBI on this) and then release another update rolling back the change.

The whole story is weird. Since the iPhone in question does not have a tamper-resistant device, the FBI should be able to open the case, read the whole Flash chip, and then run the exhaustive search themselves without even running the phone's firmware. Updates from Apple should have no effect at all.

(Edit: in fact it is a bit more complex; see below.)

Conversely, assuming that there was a technical impossibility in the description above (which would amount to claim that the FBI's level of incompetence is at least as large as their budget), and that an Apple firmware would solve the case, then it would be easy for Apple to make a firmware version that does the exhaustive search as the FBI wants, but only after having checked that the hardware serial number exactly matches some expected value, i.e. the exact phone from the San Bernardino case. Such a firmware would comply with the exact demand from the FBI without compromising the privacy of anybody else.

That the FBI claims to have tried decrypting the phone for one month and failed, is weird. That Apple refuses to help with the decryption with a firmware update limited to a single phone, is equally weird. What the whole thing seems to be is a political struggle about the right to privacy and the legality of non-judicial eavesdropping by law enforcement. The San Bernardino case is merely a pretext that is used to elicit reflex support from non-technical electorate. Apple found it expedient to play the role of the White Knight, from which they cannot now back away without alienating their consumer base.

Edit: the security system in an iPhone is a tower of elements, described (succinctly) in this document. An iPhone 5C runs on an Apple A6 chip, which the 5S and later models use an A7. The A6 has an onboard tamper-resistant device called the "UID"; the A7 has a second one called the "Secure Enclave". Since the iPhone in the San Bernardino case is a 5C, I won't talk any more of the Secure Enclave.

The UID contains an internal key that is unique to the device (let's call it Ku), and is unknown to anybody else, including Apple (whether the UID generates it itself, or it is generated externally and then injected in the UID on the processing chain, is unknown; I'll assume here that if reality matches the latter case, then Apple really did not keep the key). The UID never let that key out, but it can do an AES-based computation that uses that key.

The iPhone data is encrypted with AES, using a 256-bit key (Kd) that is derived from the combination of the user PIN and the UID key. Though Apple does not exactly detail that combination, it says it involves key wrapping, which is another name for encrypting a key with another key. We also know that a user can change his PIN, and it would be impractical to change the actual data encryption key Kd in that case, because it would involve reading, decrypting, re-encrypting and rewriting the gigabytes of user data. Thus, a plausible mechanism is the following:

The key Kd has been generated once.
When the phone is off, what is stored (in Flash, out of the UID) is an encryption of Kd by another key Kz.
Kz is itself the encrypting (wrapping) of the user PIN by Ku.

Thus, the unlocking entails obtaining the user PIN, submitting it to the UID, who returns Kz by encrypting the PIN with Ku. With Kz, the phone's firmware then recovers and decrypts Kd, and configures the crypto engine to use that key for all accesses to the user data.

While the actual scheme may differ in its details, the general outline must match that description. The salient point are that, although the tamper-resistant device (the UID) must be involved with each PIN try, it does not actually verify the PIN. The UID has no idea whether the PIN was correct or not. The wrong PIN counter, the delay on error, and the automatic deletion, are handled externally, by the firmware. This must be so because otherwise there would be no sense in Apple allowing the break to be performed with a firmware update.

Of course, one can imagine a kind of extended UID that would enforce the PIN verification and lock-out strategy, and could do so by running its own firmware that would be updatable by Apple. Such a device would really make Apple's help crucial. However, such a device would then be called a "Secure Enclave" because that's exactly what it is, and if it was added in the A7 CPU, it is precisely because it was lacking in the A6 and that absence was a vulnerability.

So what does it mean for a brute-force attack ? This implies that the UID must be invoked for each user PIN try. However, that's the UID -- not the phone's firmware. If you open the iPhone case, then the A6 CPU sub-packaging, the device UID can be accessed by connecting to it directly. It will involve some precision laser-based drilling and an electronic microscope to see what you are doing, so it certainly is not easy -- let's say it will cost a few thousands of dollars because that's the same kind of thing that is done (routinely !) by people who clone and resell satellite-TV access smart cards. Once connected, an external system can submit all possible user PIN for the UID to encrypt them all and provide the corresponding Kz keys (in my terminology above). Then the rest is done offline with a PC and a copy of the Flash storage. At no point is the phone's firmware invoked.

What the FBI currently asks for is an automatization of the process. They don't want to do precision drilling with lasers. They want to be able to plug something in the iPhone port without having to even open the case, so that the brute-forcing is done by the iPhone's CPU itself and the whole process can be done smoothly.

Thus, it is really not about the San Bernardino case. The FBI does not want a one-shot intervention from Apple; what they ask for is a tool that will be usable repeatedly on many phones. Apple is right in claiming that what the FBI asks for exceeds the specific case that serves as emotional pretext.

On the other hand, Apple could produce a firmware update that does as the FBI asks for, but only on the specific iPhone (identified through, for instance, the CPU serial number). And that firmware update would be specific to the 5C, and would not work on later models. There is no inevitability in Apple's producing a new firmware leading to a generic cracking tool for all phones of all models. But even if Apple complies with the a firmware that is specific to a single iPhone, the legal precedent will have been established, and Apple would find it hard to refuse other requests, from the FBI or from other countries where Apple has business interests (i.e. all of them).

A system which would ensure protection against user PIN cracking would need a tamper-resistant device that not only enforces the PIN failure counter and key erasure, but that device should also run a firmware that is not upgradable. The Secure Enclave has its own firmware, but it can be upgraded (firmware upgrades are signed by Apple, the Secure Enclave hardware verifies the signature). Even on an iPhone 6, Apple retains the ability to unlock arbitrary phones.


Reading php comments using php page that open text files, CTF There is a CTF Problem that it needs to see comments of a PHP file using some vulnerabilities of PHP; The Question is:
In the link bellow You must change lorem.php to read exact php comments of index.php file
http://web.ringzer0team.com:13371/index.php?page=lorem.php

I have tried index.php but it makes a infinite loop. And I now the permissions is wrong; e.g. /etc/passwd will show the passwd file and the flag in /etc/passwd is for another challenge

If you encounter a local file inclusion (LFI) vulnerability there is a special technique that enables you to read files from the target system by making use of a PHP wrapper. This will not work in every case but you might want to give it a try.

You can read more about the PHP wrapper on the official php.net site:
http://php.net/manual/en/wrappers.php.php

This technique basically lets you use PHPs input and output streams as well as apply different filters to them.  (http://php.net/manual/en/filters.php)

To read a resource you can use a payload in the form of:

php://filter/resource=/some/dir/secretfile.php

php://filter/resource=anothersecretfile.php

To apply a filter replace filtername with the name of the filter:

php://filter/filtername/resource=anothersecretfile.php

In some cases there will be errors depending on the specific implementation and surroundings of the LFI.
A good way do handle these can be to convert the output in a way that will not be interpreted by the target server.

On filter you might want to look at is the

convert.base64-encode

filter that converts the stream data to base64.


How to responsibly disclose a vulnerability in a widespread algorithm? Just to be clear, this is purely hypothetical.

Yesterday I got hit in the head with some bricks and, in the haze of concussions, discovered a perfect preimage attack on SHA2. For any given hash, I can immediately find some value that hashes to it. I want to disclose this responsibly.

Since this is an algorithm and not a program, there's nobody who can patch it in some grace period. And since it's a widespread algorithm, I can't just contact a few people and tell them to switch to another hash function. What should I do?

The grace period is proportional to the complexity and time it would take to remedy the vulnerability. For example, take this thread on reporting a security vulnerability about a trusted certificate authority, a pretty serious problem with far-reaching consequences. One poster explains the reporting protocol well:

  The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue certificates, publish security bulletins, etc, before you go public with your findings. The intention is that at the end of the negotiated period you get your public recognition, but your going public can't do any more harm - if the vendor has done their job properly.

I imagine, in your scenario, that the vulnerable vendor would (hopefully) relay the information to others. You could also contact CERT, who is trusted and has experience in dealing with such matters on a large scale. In a similar thread to the one I linked above, there's this:

  You should let the developer(s) know privately so that they have a chance to fix it. After that, if and when you go public with the vulnerability, you should allow the developer enough time to fix the problem and whoever is exposed to it enough time to upgrade their systems. Personally, I would allow the developer to make the announcement in a security bulletin in most cases rather than announcing it myself.

We can probably agree that it would be a bad idea to go public immediately, because that would leave the door open for exploitation. So privately notifying them is the best way to go. In the meantime, they would probably fix it, upgrade, or switch to something else. What other reasonable options are there?

Finally, there are real-world cases of cryptographic vulnerabilities, and those algorithms were widely used. One example is Dual_EC_DRBG, an elliptic curve based algorithm, which was used for quite some time before being revoked due to security issues. I got schooled on it in this thread.


Can you use RSA2048 to hash passwords? Assuming I'm working on an environment that currently uses MD5 to hash passwords, and I want to switch to something more secure.

I already heard of bcrypt, but I had another idea.

Would it be possible to use RSA2048 to hash passwords if I just threw away the private key of the key pair?

If so, is that less secure then using a dedicated hashing algorhitm like for instance bcrypt? (Assuming you use salt/pepper in both cases in addition):

I have following process in mind:

Every password gets its own public RSA2048 key, the private keys are discarded.
MD5 Hash the password
Encrypt the MD5 Hash using RSA2048 with that password's specific RSA2048 public key
Pepper the result with pepper of fixed lenght

Is this a secure password hashing scheme? On the same level as running a password through bcrypt or scrypt?

Assuming I'm working on an environment that currently uses MD5 to hash passwords, and I want to switch to something more secure.

If this is a practical question, then it deserves a practical answer:

Don't invent your own password storage schemes. Do it according to best practices.

There is no benefit to your scheme over using the standard options (pbkdf/bcrypt/scrypt/argon2). There are many potential security downsides, plus general bugs in the implementation (since you're constructing this yourself instead of using a commonly-used library). Implementing this in a production environment borders on professional negligence.

On the subject of its security: at the very least you suffer from it being easy to parallelize, so an attacker who has obtained a dump of the database can do the old "spin up a bunch of ec2 instances" attack to crack your hashes. This is the point behind bcypt, but you don't seem to have addressed that at all.


ssh-keygen: How to guarantee the uniqueness of serial numbers? (FYI: I'm using Ubuntu 18.04 Desktop although I don't think my question is platform-dependent.)
I read the article Scalable and secure access with SSH and it says:

... if you want to use revocation lists, unique serial numbers are a requirement.

But by reading ssh-keygen manual page, I didn't seem to find a way to guarantee the uniqueness of the serial numbers. It looks to me it's completely managed by the CA, i.e., the CA needs to figure out a way (either their own database or just a spreadsheet) to manage the serial numbers. I'm wondering if my understanding is correct or not.
My second question is: Why is it required to use unique serial numbers for revocation? I'm asking because the section "KEY REVOCATION LISTS" of ssh-keygen manual page says:

A KRL specification consists of lines containing ONE OF the following directives followed by a colon and some directive-specific information.

Then the manpage lists the directives that can be used:

serial: serial_number[-serial_number]
id: key_id
key: public_key
sha1: public_key

The words sound like that, if serial numbers are not unique, CA can still use other directives to revoke the certificates. The manual page says "ONE OF", not "ALL OF".
Thanks!

My testing showed that the serial numbers seem to be used to uniquely identify the certificates that are revoked. Therefore, if two certificates are using the same serial numbers, revoking one will cause the other to be "revoked", too, so the other certificate won't be able to authenticate the user.
Therefore, it's true that the serial numbers of certificates should be unique.
I haven't found a way to automatically guarantee the uniqueness of the serial numbers. Therefore, for manual management, a spreadsheet might be needed. When the certificates are generated automatically by some program, the program may simply increment the serial number by 1. The serial number in openssh is implemented as an unsigned 64-bit integer so it should be extremely unlikely to consume all of them.
UPDATE: I wrote an article with more details: SSH: Uniqueness of X509 Certificates Serial Numbers


An authentication protocol to prevent phishing & solve the problem of password reuse? When writing about best practices for authentication, I find that today's best practices still leave gaping holes in security, specifically not solving the problem of password reuse by users - websites are currently sent the user's input which means they could be storing it without them knowing. It also means that a user that is tricked into visiting a malicious site instantly gives away their credentials.

When I talk of passwords, I believe that any authentication key, whether it be generated via biometrics, a physical key or a password should be forced to use this protocol.

I have been unable to find any such protocols online for this purpose, the current idea would be something of the sort (I'm not a crypto expert, this is merely an example).

1) The LoginID is passed to the server, the server responds with a user-set reply to validate they are logging in at the genuine site.
2) The user's browser is sent a cryptographic key linked to their account, when the user inputs their password, the browser first encrypts this key with the users password & then hashes it, before sending it to the server. The server should then follow best practices for password storage as currently advised.

In sumarry, what is needed:
1) A mechanism when authenticating that is clear to users that they are logging in at the correct location that they believe they are.
2) The website must never receive the user's actual authentication key (i.e. their plaintext fingerprint).

Why?
I first thought of this when thinking about multifactor authentication and thinking it is rather a bad idea to transmit biometrics to anybody for any reason in plaintext, (over encrypted channels, it doesn't matter), as we have seen all too many times websites not taking adequate security measures, it is not so easy to change ones fingerprint. Included must be some form of mechanism to ensure the user does not transmit credentials to the wrong site. Hence I reccomend the two-stage login, the user login ID (which should not be a username or an email, it should be private), is entered, upon entry the user is sent the prompt they set, this could be an image or text or both, this acts as a way of preventing simple phishing attacks which aim to clone sites. THis is necessary to prevent phishing attacks else malicious sites will still mimick genuine ones, or unattentive users will fall victim. (I reccomend that the browsers flag login inputs as 'insecure', informing the user will be sent in plaintext, if websites choose not to adhere to this standard).

Again this is just an example. It just seems that it is not all too complex or costly to implement what would be a real advantage to user security. It would eliminate the need for a password manager & make password breaches a minor inconvenience. And as said earlier, it adresses the pressing issue of biometrics.

Again I'm no crypto expert, this is just a simple example protocol.

I have attempted to find information on protocols for this purpose but have failed. I have seen some answers on stackexchange reccomending such a thing, but not a dedicated post. I apoligise if this is a duplicate, the search terms on this matter predictably throw up irrelevant posts.

Welcome to the community.

What you've described is effectively a mashup of hash based authentication and TLS which isn't a bad idea in theory. However, this doesn't prevent phishing, it just prevents the discovery of the password. Your system would still be susceptible to reverse proxy attacks and pass the hash attacks just going off the top of my head.

Getting into identity management and protection, the root issue with passwords is not the interception process. We've built a lot of protocols around the protection of communications so even a clear text password transmitted through TLS is suffiently protected from MOST attacks. The issue with passwords is they are guessable, crackable, shareable, and don't do a sufficient job protecting the identities they are associated with. Everyone could use the same password.

So, knowing that passwords are inherently weak, the security industry is moving away from them as quickly as they reasonably can. As part of this, the Fido Alliance has been making major steps towards eliminating phishing and supporting the protection of authentication for users and services. In fact, using this frame work, Google has announced that they have totally eliminated phishing within their company. A pretty bold claim, but there is increasingly information backing it up.

For example, on January 1, 2019 there was a framework that used a reverse proxy solution to phish users with 2 Step authentication. It was literally a transparent layer between the user and actual service which passed through all information diligently between the user and the service. Using the custom reverse proxy, the solution builder was able to defeat multiple forms of Two Step authentication including SMS and email. The only authentication he couldn't defeat was FIDO through the use of U2F authentication.

I highly recommend studying more on the FIDO protocol here:

https://fidoalliance.org/

You can also see Google's two year study white paper on the U2F protocol here:

http://fc16.ifca.ai/preproceedings/25_Lang.pdf


Security of bluetooth tethering vs. wifi hotspot I'm using my cellphone to connect my laptop to the web.

I think connecting my cellphone to my laptop with a USB cable would be the safest connection but if I go wireless, is it safer to connect to my cellphone with bluetooth tethering or with wifi hotspot?

As mentioned in the comments, WiFi is most definitely more secure, as long as you use WPA2. Do not configure your phone hotspot to open, or to use WEP, as one is completely without encryption, and the WEP is completely broken and has been for a long time.

Also make your password some random combination of numbers and letters, as you can still crack WPA2, if the password can be easily guessed, for example a short word. Using 16 characters of random numbers, letters and symbols makes this very hard on the other hand, since you just need to test every single possible password instead of just going through a dictionary.


Could somebody explain how DNS poisoning might occur in this scenario? I read the following statement in a security blog

  using the same source port over and over again for dns queries instead of randomizing them is a vulnerability for dns poisoning

Could somebody elaborate on how this is a vulnerability and how it could possibly be exploited?

Since DNS usually runs over UDP, response packets can be readily spoofed. UDP  packets are identified by the combination of source and destination IP address and source and destination port numbers.

The classic DNS poisoning attack is to send a DNS server a query which you think will cause the server to do a recursive lookup, and then blast away at the server with spoofed response packets for the secondary request you expect the server to make. If you get the right IP/port combinations and transaction ID and your answer arrives first, your faked answer could be accepted and inserted into the cache.

Well, we know the source and destination IP address ahead of time, and we know that DNS runs on port 53, so that's one of the port numbers. Assuming DNS queries get sent FROM port 53 as well as being sent TO port 53, then we've got all 4. Then all we have to worry about is the transaction ID, which is a 16-bit number. That means each packet we send has a 1 in 65K chance of striking gold. We could easily spam out several thousand packets in just a second or so, which gives us a decent chance of poisoning the server's cache. If we push out 10K response packets before the "real" response comes in, that gives us about a 1 in 6 chance overall of success. And if it fails, we just wait for expiry and try again.

But, if the server uses a random outbound port number on recursive lookup queries, then that adds another 16 bits worth of material that we have to guess right for our response to be accepted. So that's a total of 32-bits, or about 4 billion possibilities. That means that our odds for each packet go from 1 in 65,536 to 1 in 4,294,967,296, which becomes a bit prohibitive.

So while you can't be 100% certain that a response isn't spoofed, the odds are weighted much more in the favor of the defender if he randomizes his source ports for his secondary lookups; enough so to dissuade most attackers from investing the resources to try the attack.


Can streaming services, movies, series, be used to infect my computer? I have been thinking about starting to Watch Movies and series online using streaming (legal). I was wondering if there are any vulnerabilitys in these services which can affect me as a user. I have noticed that most streaming services uses flash. Correct me, if I'm wrong, but my memory tells me that flash is very vulnerable and can be used to infect a computer. I would guess that the bigger the name of the provider of the streaming, the more secure it would be. But I'm actually interested in a provider who is not very common at this date. Therefor I want to know, before I start a subscription, if there is possibility that my computed can be infected when streaming for example a Movie online?

The short answer is : yes your computer can be infected by visiting a streaming site.

However, the risk is not necessarily unacceptable and this is not especially related to streaming : browsing the web in general always creates a small risk, notably of Drive-By Download

I would recommend to avoid any provider that is still relying on Flash, as HTML5 is doing the job perfectly for streaming and does not require you to expose your machine to Flash vulnerabilities.

There are a few things you can do to decrease the risks, like making sure that your software (browser, any plugin etc) are up to date, or, if you are paranoid, watch the streams in a VM that you rollback for each session ;)
Make sure that you do not download any third-party plug-in to watch whatever you are looking for.


How risky is to to use external DNS servers? My infrastructure doesn't have an internal DNS server, so I just forward any DNS request to external DNS servers by iptables rules.

I wonder how risk that can be, and how easy is it to spoof DNS or build an attack based on that?

Is there a better solution, if I don't want to setup an internal DNS server?

Here's what we can tell you:

Public DNS record is publicly accessible
Parts of the Public DNS systems can be subverted by sufficiently advanced attacker, unless measures like DNSSEC are taken and enforced

From these we can see several issues under the following scenario:

You have internal service but you used public DNS to map these names to your internal IPs.

an attacker could conceivably take over the external DNS to redirect traffic from your internal IP addresses to a server they control, possibly outside your internal network. This can be prevented by strong authentication between your internal servers or by network control to prevent most internal servers from connecting to external addresses or by requiring DNSSEC record. However, when you have thousands of different services, this may be unfeasible.

You have internal services with names that discloses who your partners are and what systems you internally have. This can be a business privacy issue, as your business may not want just anyone to be able to list who you worked with. There's nothing you can do about this, public DNS is public record, you should run internal DNS if you don't want your names to be used to infer what partners or internal systems you are running.

If these are a problem to you, then you probably should run your own internal DNS system.


Static code review approach My questions is related with static code analysis approach used by Veracode vs Fortify/AppScan.

Veracode – Finds security flaws in application binaries and bytecode without requiring source
Fortify/AppScan - Analyzes actual source code to identify security vulnerabilities.

A) Is there an advantage/disadvantage of conducting reviews of binaries over source-code?
B) Which one provides more coverage/vulnerabilities.
C) Any examples would be great.

Thanks,

A) Is there an advantage/disadvantage of conducting reviews of
  binaries over source-code?

Compilers often DO NOT write code expressly as intended in the source.  For example, Return Oriented Programming exploits the fact that compilers will insert many more RET opcodes than the programmer is aware of.  Due to pipelining and other optimization tricks, compilers essentially rewrite your code and can possibly add vulnerabilities of their own.  This means that some constructs in the source code may not be expressed in the binary at all!

This is a class of error that is essentially impossible to catch through manual code analysis... and I suspect the risk would still be there for Java/C# JIT code as well, but this would be obfuscated from a static analysis tool.

Manual source code analysis can help by the fact that most common vulnerabilities can be caught by visual inspection.  And it has other benefits as well, most notably in just decreasing the number of prod bugs in general.  (And thus cost.)  And it helps the social aspect as well:  source reviews encourage people to write as if someone else is watching.  A major disadvantage is that if you're dealing with a dynamically typed language, such as PERL, Groovy, LISP and its derivatives... most data won't be looked at until runtime which means neither static analysis or source code analysis is sufficient.

You can even fool static analysis tools by converting statically typed code into instructions at runtime.  Veracode doesn't like your java construct?  Rewrite it using reflection, and the Veracode bug disappears and no one is the wiser.  As a security expert you also need to assume that the programmers working in your own company are a potential threat.

So in short, there's no way to escape Source code analysis, static analysis, and dynamic analysis in any given application if your hope is an acceptably secure code base.*

  B) Which one provides more coverage/vulnerabilities.

Source-code analysis depends on the reviewers having excellent security skills and since they're human beings, you can't reasonably expect perfect performance.  That's why static analysis tools come in handy.  My preference is to run static analysis tools first and then do the secure code reviews after the discoveries are mitigated, I prefer using STRIDE but there are other frameworks to consider.  This lets humans concentrate on the less mundane security problems that are more logic-related.  But a smart human will beat a dumb static analysis tool any day of the week.

Source-code analysis can help you find where a programmer left behind a back door... static analysis tools aren't equipped to handle that.

So the answer to this question is... "it depends."  What kinds of threats do you want to go unchecked?

*Unless "acceptably secure" is defined as leaving the windows open and the front door unlocked.


HTTPS IP devices and certificate best practices, why can't I sign a certificate for my local ip device? I have a IPv4 network behind a pfSense firewall at my small business. We have around 200 IP devices on the network. We have about 30 Axis IP cameras which have MJPG streams embedded into webpages as img tags. The webserver is internal and external facing, but we don't have a proxy for the cameras and thus only use the MJPG streams on the internal part of the network. If my provider allowed IPv6 I would use that instead and have them routable.
This worked fine for the last 10 years. Recently Chrome changed and now throws NET::ERR_CERT_AUTHORITY_INVALID errors because it doesn't like the certificates on the device from Axis Communications, I assume because they expire in 2023.
I don't understand why Google cares what my certificates are on non-routable (192.168..) IPv4 addresses?
One solution is to change a setting on each client Chrome browser to basically ignore the problem. chrome://flags/#legacy-tls-enforced
I took the route of trying to get a valid certificate on each device. I first looked at LetsEncrypt because of the cost, the 3 month renewal window and needing to have TXT DNS record changes for every renewal to get a domain wildcard certificate made this untenable. With the right DNS provider this would probably work, my current DNS provider does not support LetsEncrypt.
I then purchased a commercial wildcard certificate for my domain. If I upload this certificate to the IP cameras and use a FQDN instead of the internal IP address it works. I have two issues with this:

Every 398 days I will have to upload new certificates to the cameras. If this could be automated through a script it wouldn't be too bad, but that doesn't look to be possible, in my case.
If one device gets compromised, they all run the same certificate. This is unlikely to happen in my case, but the ideal solution would have a unique certificate for each device.

Indeed that is the direction the Axis camera management software pushes you, it runs a certificate authority (CA) that can then distribute certificates to all the cameras. Unfortunately the certificates are not valid from Chrome's point of view, these are self signed certificates. I would have to be able to sign them with the certificate I bought, but this is not allowed.
I did think this is not allowed for a very good reason, and if it was allowed the trust chain would be corrupted. But the more I think about this I can't see that as correct. I have a wildcard certificate for my domain name (example.com). Should I not "own" or be responsible for everything down from the domain I own? Or is this because certificate revocation is broken? It seems name constraints extension is the answer, but the browsers don't support it.
Solutions have been suggested, but not implemented.
In a corporate environment you distribute your own self-signed certificate and place on every employees device. If there is some way to do this easily through just a http link on our internal website, this might be a solution. I do not want to manage every device and frankly having the client have to do anything is not really a solution, it's a band-aid.
Questions:
Why can't I sign certificates that are below what I own, ie xx.yy.example.com?
I can't find anywhere to purchase a certificate I can add to my CA that will then give out valid certificates from Chromes point of view. Is this correct?
It seems the standards are all written correctly, Google/Apple tighten the screws and only implement half the standard which then causes problems, is that correct?

Here some ideas and options for your network.  Hopefully, they can help you manage SSL / TLS with your cameras and devices. The options focus on your Axis cameras but may apply more broadly. However, without specific details on your network certain assumptions may not be accurate.  I have no experience with pfsense firewall.
Issue #1: you can automate uploading ssl certificate to Axis cameras via sftp, scp or ftp. Axis stores the ‘in-use’ certificate in /etc/certs/web/server/http/0/server.pem.  Older cameras (ie: P5512) use boa/stunnel for http/https.  Newer cameras (ie: Q6115) use apache for http/https.  The server.pem certificate file contains the private key (unencrypted) and certificate in pem text format.  You can replace this file and the Axis camera will not know the difference.  You must first have any certificate uploaded via Axis setup (self-signed works) and HTTPS configured for use and then replace the server.pem file leaving Axis https configuration alone.  Axis will overwrite or delete /etc/certs/web/server/http/0/server.pem if Axis HTTPS certificate setup is changed.
NOTE: you must reboot camera or restart apache or stunnel to load the new server.pem file you upload. If the server.pem file is missing on boot, it will be generated from active certificate set through the Axis setup HTTPS page.
So, if you have the private key file and certificate file for domain.com, you can manually create the server.pem from a command line $ cat domain.key domain.crt > server.pem or similar means and upload it.
Issue #2: Separate certs for each device might be a lot to manage. A wildcard cert would be best if you require different domains/sub-domains on each camera or device. Also, I am not sure wildcard compromise any risk, depending on what you mean here, if devices have unique or same certs.
Here are some options.  Other options exist, but I feel these best fit your case.
Option A: Depending on how your Cameras are setup, the following option may be viable but may require changing camera http ports. If all your cameras are behind a single global IP, that may be to your benefit.  As I am sure you know, Axis cameras default to port 80/443, but those are typically changed to keep unintended traffic down especially on public facing cameras.
Whatever domain you own, let us call it domain.com, you may be able to use that certificate on all your cameras and using port-forwarding with each camera having a unique port for http/https. Each camera mjpg would be accessible at https://domain.com:port/mjpg/video.mjpg.  Your HTML  tag would use domain.com:port (https port) and your router/firewall would forward it to the internal IP address:port. Since SSL certs are not port specific, a single certificate for domain.com (which you probably already own) would work on each camera.
I have 2 Axis cameras that I use for testing behind a router which use same certificate where the router port-forwards to each device.  All requests (internal and external), ie: your  tag, would use domain.com.
Option B: Albeit probably not ideal depending on bandwidth (fps and resolution) and number of concurrent  views. If you have Apache server, you can use ProxyPass setup to translate insecure http mjpg to https. It sounds like your server is on-site, so this might be an option if bandwidth is not too much for server.  Not ideal, but it does work, and you would not need certificate on cameras except on the web server itself at domain.com.
Also, assuming Apache server, the RewriteMap directive can help to map url to host (camera) which may help management as your web pages can use same img URL even if cameras change IP address, port, etc. If not Apache, other servers may implement similar.
Lastly, Axis Technical Support has been excellent when we have needed them.
Hopefully, this gives you some ideas.  I would pursue using your domain.com certificate on all cameras (devices). If it works, maybe buy for longer term to minimize management.  I also recommend testing manually before automating as there are always some surprises, but once you get a working solution, automate as needed.
If anything isn't accurate or doesn't work in your scenario, please let me know. I have quite a bit of experience with Axis Cameras, as they are complex and the state-of-SSL today has made things more difficult.
Best Wishes


I woke up and my email has been signed up to hundreds of online services. How can I fix this? I woke up this morning to over 900 emails of several online services asking to confirm I’ve made an account. Last month my email had been compromised and they managed to get into my eBay and Amazon accounts. I managed to remedy the situation, and changed my passwords on everything. My password on my email is different from all my other accounts and is a fairly strong one. But today it seems to have been compromised again.

How can I fix this so I stop getting signed up for accounts?

Is that email address far gone and I just need to get a new one?

How could this happen, so I can better prevent it in the future?

Could this somehow be related to my last breach, or is it just a coincidence?

What’s the point of breaching an email to sign up for hundreds of accounts in one night?

1.How can I fix this so I stop getting signed up for accounts?

You can't - anyone who knows your email address can do this. Anyone whom you ever emailed or anyone who read an email they forwarded has your mail address; it could be nothing to do with the breach

2.Is that email address far gone and I just need to get a new one?

Maybe, but you need to balance inconvenience of changing email, and be aware that it could simply happen again at some point right after you send you first email or someone CCs you into an email; both these actions put your email address out there

3.How could this happen, so I can better prevent it in the future?

Software exists to register your email with a massive number of companies; effectively everyone who sets up a "register your account with us, we just need to confirm your email" with no barrier such as captcha or having to pay them first effectively creates a robot that can be manipulated into flooding your mailbox with junk. The real question is why was it flooded; it's less likely that the person who broke in last time is doing it just to annoy, and more likely that this flood of emails contains in the center a couple of confirmations of things they bought as you etc. The hope being that you just select all 900 and hit delete

4.Could this somehow be related to my last breach, or is it just a coincidence?

I think it's highly likely, and you should carefully examine the extent to which you were compromised; they'll have been able to comb your entire email history and find all the sites you've purchased from that may still be holding your credit card details, and possibly made purchases from those sites, not just eBay and amazon

5.What’s the point of breaching an email to sign up for hundreds of accounts in one night?

You don't need access to an email address to sign up for an account, even if they just reach "confirm your email" stage with some company, then the company still sent you an email. These emails aren't of any concern unless they're actually completing signup (indicating the third party still has access to your email). Bear in mind that if someone does have access to your email then the follow up "you're fully signed up!" could be erased, though it might be curious that the "verify your email" emails remain. The read/unread status isn't much help either as that can be toggled - what you need is a log of activity as to what IP addresses have signed into your mail and when, and review them carefully


Encrypting user details This isn't really language specific, but I'm wondering if anyone has any suggestions for a security model securely storing some user details in a way that could be accessed in an automated fashion.

i.e. I want to be able to send users automated emails when certain events happen but I don't want to store that email address or the event description in plain text.

If it wasn't an automated system then I would use some of the users credentials to salt the encryption but as it is, the application needs to be able to access it in some way but not an "intruder".

A solution can involve a second server instance (or separate physical server) but I still see myself presented with the same problems.

To make a system like this work you're going to need to either store the users e-mail in plain text somewhere, or store it in encrypted format and then store the key for that in plain text somewhere.

It's inescapable that in an automated system sometimes somewhere the server has to be able to decrypt the data and send it.

If you're interested in "high security" options, you could look at storing the users information in encrypted format on disk and then make use of an HSM to handle the decryption in a more secure manner than just having the key on disk.


How can SSL vendors limit the amount of servers they can be installed on? I've recently purchased an SSL certificate, and it says that it's limited to three servers. Surely if I have the key and certificate on multiple servers (more than 3), the SSL will still be valid? Can someone clarify why/how vendors can limit this? An example of one is 123-reg's 123-SSL (which is a resell of AlphaSSL).

There are no technical reasons for such a limit, it's purely licensing (i.e. revenue, and maintaining market segmentation). There are some considerations relating to the secure transfer of the key between systems when you do this, but this is easily addressed.

If you violate the license or terms of an agreement you risk (at least) getting your certificate revoked.

They (the CA/reseller) might be able to tell how many servers you have by:

inspecting your site for signs of load-balancing (e.g. different server signatures or E-Tag headers), or even just multiple DNS A records
monitoring OCSP stapling requests and recording the source IPs and frequency of requests, in the unlikely event you have this configured

Neither method is reliable and conclusive however.

It is possible to put public IP addresses in certificates, though some CAs do not support this (e.g. GoDaddy). This is not commonly used in for standard "web" certificates. Such a "name" is only checked by browsers if the URL contains an IP address in the host part (i.e. the browser doesn't check both IP and DNS for URLs containing DNS names). Web servers don't tend to check the certificates they are presenting as thoroughly as a browser, and assume the administrator knows what they are doing. Even if this worked as a method of limiting concurrent use by causing (user-visible) browser errors, it would only be effective if all servers had public IP addresses (no NAT or front-end proxy/load-balancer).


Why can GPG sign messages but not keys? I am trying to add local signatures to a few of the public keys I have in my keyring, but using gpg --lsign-key fails with the message "no secret key" despite the fact that gpg --sign works. I am using a Yubikey as a smart card.

GPG shows that the secret key is not available, but there is a signing key on the attached smart card:

$ gpg --list-secret-keys
sec#  rsa4096/0xDEADBEEFDEADBEEF 2000-01-01 [SC]
      Key fingerprint = DEAD BEEF DEAD BEEF DEAD  BEEF DEAD BEEF DEAD BEEF
uid                   [ultimate] My Name <me@example.com>
ssb>  rsa4096/0x8BADF00D8BADF00D 2000-01-01 [E] [expires: 2020-12-31]
ssb>  rsa4096/0xBADDCAFEBADDCAFE 2000-01-01 [S] [expires: 2020-12-31]
ssb>  rsa4096/0xFACEFEEDFACEFEED 2000-01-01 [A] [expires: 2020-12-31]

I can sign a message:

$ echo "test" | gpg --sign --armor
gpg: using "DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF" as default secret key for signing
-----BEGIN PGP MESSAGE-----

[snipped signature]
-----END PGP MESSAGE-----

But I cannot --lsign-key:

$ gpg --lsign-key product-security@apple.com

pub  rsa4096/0x782F6D86DED32B71
     created: 2018-08-20  expires: 2019-08-20  usage: SC
     trust: marginal      validity: unknown
sub  rsa4096/0x1C3F44E9CB9F9E3A
     created: 2018-08-20  expires: 2019-08-20  usage: E
[ unknown] (1). Apple Product Security <product-security@apple.com>
[ unknown] (2)  Apple Product Security Notifications <product-security-noreply@lists.apple.com>

Really sign all user IDs? (y/N) y
gpg: using "DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF" as default secret key for signing

pub  rsa4096/0x782F6D86DED32B71
     created: 2018-08-20  expires: 2019-08-20  usage: SC
     trust: marginal      validity: unknown
 Primary key fingerprint: 0CD5 C954 D089 2440 1598  9759 782F 6D86 DED3 2B71

     Apple Product Security <product-security@apple.com>
     Apple Product Security Notifications <product-security-noreply@lists.apple.com>

This key is due to expire on 2019-08-20.
Are you sure that you want to sign this key with your
key "My Name <me@example.com>" (0xDEADBEEFDEADBEEF)

The signature will be marked as non-exportable.

Really sign? (y/N) y
gpg: signing failed: No secret key
gpg: signing failed: No secret key

Key not changed so no update needed.

How can I add a signature to this key to validate it?

Signing and key signing is done by different subkeys. You have:

$ gpg --list-secret-keys
sec#  rsa4096/0xDEADBEEFDEADBEEF 2000-01-01 [SC]
      Key fingerprint = DEAD BEEF DEAD BEEF DEAD  BEEF DEAD BEEF DEAD BEEF
uid                   [ultimate] My Name <me@example.com>
ssb>  rsa4096/0x8BADF00D8BADF00D 2000-01-01 [E] [expires: 2020-12-31]
ssb>  rsa4096/0xBADDCAFEBADDCAFE 2000-01-01 [S] [expires: 2020-12-31]
ssb>  rsa4096/0xFACEFEEDFACEFEED 2000-01-01 [A] [expires: 2020-12-31]

Here, DEADBEEF is the key of the whole PGP key, valid for Signing and Certifying.

Then you have three subkeys (ssb = Secret SuBkeys), valid for Encryption, Signing and Authentication respectively (you could eg. have a single subkey valid for both Signing and Authentication, but these are all on different keys for you).

When you gpg --sign, you are using BADDCAFE, whereas for a gpg --lsign-key you would need DEADBEEF. That's why one works while the other doesn't.

Now, I'm not sure why it is failing, it may be that DEADBEEF is not there at all (do you have an offline backup of the full key?), or perhaps it's a bug when interacting with the smartcard, and it is "not finding it", although it is really stored there.
An easy thing to review would be the number of slots that are supported by your smartcard, as on some of them you wouldn't even have enough slots for those four keys.


Why won't ossec block SSH connections when it seems to be configured correctly? Why won't ossec block connections from another server?

I installed ossec version 2.9.3 on Ubuntu 16.04.  In the ossec.conf file I have these lines where x.x.x.x is the IP address of a second Linux server:

<command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <expect>x.x.x.x</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
    <command>firewall-drop</command>
    <location>all</location>
    <rules_id>5712</rules_id>
    <timeout>1800</timeout>
</active-response>

I restarted ossec.  Running a ps -ef | grep ossec showed it was running.  I have a firewall rule that allows the Linux server at x.x.x.x to SSH to the Ubuntu server with ossec.  I can still SSH from the second server to the ossec server.

I changed the timeout to 20.  I made sure it took me 25 seconds to type in the password.  I can still SSH from the second server to the ossec server. I expected the above to block SSH connections.  I tried turning off the firewall, but that did not have any effect.  What am I doing wrong?

The timeout in the OSSEC <active-response> block is after what time the response will be rolled back: in other words, after 1800 seconds (or 20 seconds, when you changed it), the IP will be allowed again.

Rule 5712 in the default configuration detects SSH brute force -- try connecting a number of times.  You can also look in the file /var/ossec/logs/alerts/alerts.log to see when alerts are fired.


What are some reasons a company should not go with single sign on? A company I am working for is advocating for single sign on for their Ecommerce site and an Online clinical testing platform that contain sensitive patient information.

My concern is the sensitive information on the patient testing site.
Users of the ecommerce site does not always use the testing platform and vice versa, but there are some users who use both.

Unless the question is about a specific SSO provider, the answer is pretty simple. If SSO is implemented for your E-Commerce(EC) and Online Clinical Test (OCT), it only implies that both applications use the same identifying mechanism to identify a user. It does not imply that users would be given access to both sites by default. You should be having authorization controls which restricts users from accessing systems.


What is the difference between ATT&CK and CAPEC? My question is on Cyber Threat Intelligence (CTI). I want to know the difference between Attack Patterns (as in MITRE CAPEC) and Tactics, Techniques and Procedures (as in MITRE ATT&CK). They both seem to describe the behaviour and modus operandi of the adversary, so what is the difference really?
What is the difference between Tactics, Techniques and Procedures in the first place? I have heard that techniques and tactics don't belong to the same Threat Intelligence type. Technical CTI is at the same level as indicators of compromise (IoC) for example, whereas Tactical CTI refer to an higher analysis level, the "attack phase" (whatever it means). But then why do we only see "techniques" on MITRE ATT&CK webpage? Why is it called Tactics, Techniques and Procedures if there are only Techniques? And what are Procedures?

MITRE actually maintains a page describing the differences between the two and another page defining "tactics", "techniques", and "procedures".  The rest of this answer is a series of direct quotes from the first page since this appears to be the primary focus of your question. I've avoided putting it all in block quotes to make it more readable with our formatting options.

CAPEC is focused on application security and describes the common attributes and techniques employed by adversaries to exploit known weaknesses in cyber-enabled capabilities. (e.g., SQL Injection, XSS, Session Fixation, Clickjacking)

Focus on application security
Enumerates exploits against vulnerable systems
Includes social engineering / supply chain
Associated with Common Weakness Enumeration (CWE)

ATT&CK is focused on network defense and describes the operational phases in an adversary’s lifecycle, pre and post-exploit (e.g., Persistence, Lateral Movement, Exfiltration), and details the specific tactics, techniques, and procedures (TTPs) that advanced persistent threats (APT) use to execute their objectives while targeting, compromising, and operating inside a network.

Focus on network defense
Based on threat intelligence and red team research
Provides contextual understanding of malicious behavior
Supports testing and analysis of defense options

How they are related ...

Many attack patterns enumerated by CAPEC are employed by adversaries through specific techniques described by ATT&CK. This enables contextual understanding of the attack patterns within an adversary’s operational lifecycle. CAPEC attack patterns and related ATT&CK techniques are cross referenced when appropriate between the two efforts.

Use CAPEC for:

Application threat modeling
Developer training and education
Penetration testing

Use ATT&CK for:

Comparing computer network defense capabilities
Defending against the Advanced Persistent Threat
Hunting for new threats
Enhancing threat intelligence
Adversary emulation exercises


Is promiscuous mode sufficient to sniff packets in a wifi network? I'm connected to my WiFi network and I want to capture and analyze packets that other clients are exchanging with the gateway. I don't want to modify the content of these packets and I don't need to read the content of every packet.

Actually, the wlan configuration is the following:

a router 192.168.1.1
the laptop that I'm using to sniff traffic 192.168.1.9
my smartphone 192.168.1.2

so I want to be able to see (part of) the traffic between my smartphone and the router.

To achieve the goal I set the wireless interface in promiscuous mode with sudo ip link wlo1 promiscuous on and I check if it is enabled with netstat -i:

Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
enp8s0     1500 0     28962      0      1 0         22923      0      0      0 BMU
lo        65536 0      7294      0      0 0          7294      0      0      0 LRU
wlo1       1500 0     29469      0      0 0         12236      0      0      0 BMPRU

The P on the flag column indicates the promiscuous mode, so I'm assuming it is enabled. Since the promiscuous mode is on, I should see all the traffic that my NIC can capture. Then I open wireshark and I start to capture traffic on wlo1 interface but I don't see any packets from source 192.168.1.2 and I'm surfing the net with my smartphone (so, I'm generating traffic).

What am I doing wrong?

EDIT: I found the issue.

The interface is still in managed mode. I tried to add manually a new interface. iw phy phy0 info tells that my NIC supports the monitor mode but if I try to add a new interface with sudo iw phy phy0 interface add mon0 type monitor I get the following:

blackbrain@blackbrain-host:~$ iw dev
phy#0
    Interface mon0
        ifindex 5
        wdev 0x3
        addr 34:68:95:03:48:17
        type managed
    Interface wlo1
        ifindex 3
        wdev 0x1
        addr 34:68:95:03:48:17
        type managed
        channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz

both interface are in managed mode.

Any idea?

To answer the subject line question, "Is promiscuous mode sufficient to sniff packets in a wifi network?", the answer is yes, catching the packets just requires a network adapter that can be put into "monitor" or "promiscuous" mode, ie both modes work...that part isn't that hard. (You mentioned both modes in your edit) This is assuming you are using a NAT router in conjunction with a DHCP server... and you are, right?

I admit all I've learned about networking has not been through school but, this being the scenario, I have a feeling the network switch might be an issue?

I've been drinking wine too, lol, but at my old place in Victoria, if you plugged into a port on my router, you would see NO traffic that I sent to the Internet. That is because the network switch knew where to send the traffic, and it only sent the traffic between the ports that needed to see it.

Alternatively, but more towards your question, if you looked at my wireless you would have no idea what I'm doing.. the switch only passes on Broadcast Traffic or Traffic to where it doesn't know the destination to all ports. Then the Wireless, which is a Bridge, will only pass on to Wireless what NEEDS to be sent to the Wireless part of the bridge.

That being said there are several methods of SNIFFING a switch, using either a Man-in-the-middle attack or port flooding.

Anyway, it's not sniffing the packets but more about deciphering, understanding, and making use of the traffic that is intercepted, which is an art form in and of itself. You mentioned you wanted to analyze the packets, too... Its rather difficult, and in a few cases, it just isn't practical to be done. I mean, to really analyze, it's beyond the skill level of the majority of users, although I'm sure there are some geniuses on Stack Exchange you should be having a beer with..

Best of luck in your learning experiences!


How to browse the Internet safely? What is the best way to browse the Internet safely? By safely I mean:

anonymously
having encrypted communication

Extra bonus for:

being able to do it with little or no performance impact
cheaply (without spending too much money on the connection)

I know about VPN which encrypts the whole communication (but which requires the purchase of a service and trust in the provider) and SSL (which not all Internet services support).

What other options are there?

What is the best way to browse the Internet anonymously?

Best is difficult when you havn't given the parameters of interest.

Get cash.
Get a deck of standard playing cards.
Shuffle the deck of cards at least seven times.
Remove everything from your person except locally acceptable clothing, the playing cards, and the cash.
Walk to the nearest public transit.
Board the first public transit vehicle that arrives.
After boarding the vehicle draw a card from the deck. Use the value of the card to determine how many stops to wait before exiting the vehicle. If the value of the card is greater than the number of stops remaining, then modulo the value by the number of stops remaining.
Exit at the stop determined in step 7.
Board the next public transit vehicle that arrives.
repeat step 7.
When you exit at the stop draw another card.
Ask someone where the nearest internet cafe is. If they don't know or are unhelpful continue asking until you have asked as many people as are indicated by the card drawn in step 11.
If you asked the number of people indicated by the card drawn in step 10 and dont recieve a satisfactory answer go back to step 9.
Walk to the internet cafe.
When you reach the internet cafe draw a card from the deck.
Look for someone who is leaving, offer them cash from the reaminder of their time.
If you don't see anyone leaving wait the number of minutes represented by the card drawn in step 14.
If you wait the number of minutes and do not spot someone leaving, pay for your own session.
Don't use any existing accounts. Don't chat with or email any aquaintences. Don't use any personally identifing information. Use the deck of card to generate usernames and passwords. Use the internet cafe's address and phone number for registration information.
Go home. Do not take anything physical back from the internet cafe. Never reuse the accounts, usernames, or passwords from your session at the internet cafe.


Spoof another IP address in the same network,will the spoofing source get the response? I have read some articles about IP spoofing. Briefly speaking, IP-spoofing means the attacker uses a fake IP address in the IP header, to pretend this IP packet is sent by another machine.

The attacker can use it to do something like Denial-of-Service attack (with other advance tech) ... and hide the real source IP address.

In those articles, it also mentioned that the attacker can't see any reply packet, because those reply packages will be sent to the spoofed IP address.

My question is, if the fake IP address is in the same network (under the same collision domain) where the the attacker sends spoofed packets, will the attacker get the reply packets?

Thank you.

It relies on how far you go in spoofing. When you only spoof the ip address but not the mac address the original host will get the answer.

If you did not only spoof the ip address but also the mac address it can happen that you also receive the answer. This is because the switch(es) on your LAN do map mac addresses to physical ports. This means you can "by accident" cause what is called port stealing by also spoofing the mac address. This happens when the switch sees that the mac address which is assigned to the spoofed ip address appears on your port. The switch then changes its CAM table and assigns the spoofed mac address to your port.

Port stealing will only work on when you send spoofed packets continously which does not seem to be the case. So when it happens it will only work for a very short time until the mac address is assigned back to the right port in the CAM table.


Protecting Database Content against leaks Threat Model / Scenario
I am concerned with a Thread Model, where certain sensitive data is stored in a database. Its not as sensitive as Credit Card information or passwords, but telephone numbers, email addresses and the like. Lets assume I fear a database leak, where an attacker somehow can read more information than allowed to him from the database. What can one as administrator do against that?

What I considered
Lets assume that we keep the software which organizes and dispenses the data up to date and patch every vulnerability as fast as a patch is available.

I considered that we may encrypt the sensitive data with for example the users password. (Not the stored hash in the database). The consensus however is that its not good practice to save encrypted data in a database. Furthermore the data would be lost if a user forgets her password.

I also considered encrypting all data with a key that is stored in the OS environment, but this would probably not help against leaks in the form of e.g. SQL-Injections, unless one keeps the data encrypted until a user logs in and then decrypts only the users portion of the data until she logs out again.

So my question is, what would be a sensible way to go about in the aforementioned scenario?

The only reason not to encrypt data inside the database columns that I am aware of  is performance/data duplication concerns. Are you going to be doing joins or lookups from the database based on the data in question?  If you don't need to do that, feel free to encrypt the data in the database columns

I believe the proper way to do it would be to encrypt the columns in the database, and store the encryption key in a separate datastore, such in a file in the filesystem.  The decryption should happen on the fly in the web application whenever the data is requested.  That way if the database is ever compromised via SQL injection, the attacker will be able to retrieve encrypted data.  Keep in mind that you if you do not have a unique key per user, it's possible for an attacker to determine two users which have the same phone number since the same plain text ciphered with the same encryption key will give the same cyphertext.  Please keep proper key rotation in mind as well.


WPA2 with 802.1x - how is the server certificate validated? I want to replace my current WPA2/PSK Setup with WPA2+802.1x with RADIUS authentication. There are various algorithms which can be used for that, roughly divided in two groups:

The user uses a certificate to authenticate to the server.
The user has a username and password for authentication.

Since (1) requires distributing a certificate to the users, I want to go with option (2).

Now the question is: how can I mitigate the rogue AP attack?

I could distribute the RADIUS' server certificate to all clients. But this would counteract the whole reason I want to implement option (2).

If I use a self-signed certificate, the user has to manually accept this self signed certificate. An attacker can easily set up a rogue AP with his own self signed certificate and therefore steal a users' credentials quite easily (no user checks fingerprints).

But what if I use a certificate signed by a CA (like Let's Encrypt, or any other CA which can be found on most devices) for the RADIUS server? Will the client accept it automatically?

What stops an attacker from going to the same public CA and obtaining a valid certificate for himself? (Is there a way to specify to accept only certificates for a certain domain?)

Are the answers to the previous questions valid for all 802.1x methods that provide server authentication?

Additional considerations:

I am aware that there could be attacks within my own network, e.g., attacks to capture and/or spoof the communication between the WiFi-AP and the RADIUS server. For my setup, these kind of attacks can be ignored since they are either directly connected (physically) or have a direct IPSec VPN connection.

I could distribute the RADIUS' server certificate to all clients. But this would counteract the whole reason I want to implement option B.

Let me start by saying it isn't the RADIUS server's certificates you need to distribute, it is the certificate of the CA that signed the RADIUS server certificate. I will get back to this a bit later in the answer.

  if I use a self-signed certificate, the user has to manually accept this self signed certificate

Some supplicants won't even accept a self signed server certificate, unless certificate validation is disabled.

  But what if I use a certificate signed by a CA (like Let's Encrypt, or any other CA which can be found on most devices) for the RADIUS server? Will the client accept it automatically?

Depends on the supplicant. Some will, others won't. Without some sort of additional configuration (manual, GPO, MDM, etc), I would even go out on a limb to say that vast majority of them will still prompt the user to accept the certificate.

  What stops an attacker to go to the same public CA and obtain a valid certificate for himself? (Is there a way to specify to accept only certificates for a certain domain?)

Same public CA? Pick one that does a reasonable attempt to validate you are the domain owner before generating a certificate.

However, that is beside the point as a valid certificate from any major CA will often provide the same "assurance" (if the EAP supplicant uses any known valid CA) and it may be easier for an attacker to get a valid certificate from a different CA from the one where you get yours (if your CA already has legitimate contacts for your organization, it is likely they will use those to validate the request).

  Are the answers to the previous questions valid for all 802.1x methods that provide server authentication?

It sounds like a brief primer on what is taking place with 802.1X could be helpful.

Generally speaking, the EAP supplicant (no matter the EAP method chosen) must make a decision on whether it will send your username/password or other credentials to the authentication server without being connected to the network. This means it is only able to work with information it has prior to the connection and information it is given by the authentication server. The EAP supplicant can't go out on the Internet to check another source until after it has authenticated and it is too late to withhold your credentials.

The EAP supplicant does this primarily by checking two things (with a couple options present in many EAP supplicants like the Windows and OSX native supplicants, but often not on mobile devices like tablets and phones):

Is the certificate provided by the authentication server a valid certificate issued from a CA trusted by the client device?
(Optional) Is the certificate issued from the designated CA(s) in the EAP supplicant?
Does the hostname listed on the certificate match the hostname given by the authentication server?
(Optional) Is the hostname given by the authentication server one of the hostnames allowed in the configuration of the EAP supplicant?

The supplicant may also prompt the user to approve the certificate if it passes 1 and 3 above. Or the EAP supplicant may skip the above and have the OS prompt the user to "check and approve" the certificate (bad idea), or it may be configured to not validate the certificate at all (worse idea) before sending your credentials.

  Since a) requires distributing a certificate to the users, I want to go with option B.

Distributing some sort of certificate may be unavoidable. Often it is simply a matter of if you are distributing client certificates as well. (If you do choose an EAP method with client certificates, such as EAP-TLS, I highly recommend individual client certificates per user/device rather than a shared client certificate.)

Many organizations will set up their own CA to generate their RADIUS server certificates (and client certificates where applicable). This does require installing the CA certificate on the clients as well.

Why would they do this? Here are a few reasons:

Cost - getting certificates that provide for authentication service (not just HTTPS web traffic) could be expensive, especially if the organization runs a large number of authentication servers (as generally you need a certificate per server).
Reduced end user impact - most CAs will only issue certificates for a maximum of three years (and some now only two). When the certificate on a wireless authentication server changes, at the very least the end user will be notified of the change and prompted to accept the new certificate. In some cases, the EAP supplicant will simply fail to connect to the wireless network until reconfigured. Organizations that run their own CA can choose to issue certificates with expiration further out than 3 years, reducing how often their end users are impacted by a certificate change.
Increased security - if the organization uses a public CA to issue their authentication certificates, then an "attacker" will find it easier to "impersonate" the organization's network. It is trivial (and in some cases entirely free) for an attacker to get a valid certificate from a public CA that can match the hostname of the attacker's own "authentication server." If specific hostnames for the authentication servers are not configured in the EAP supplicant (and they often are not or can't be), then even if the designated CA is configured and is a public CA, the attack just needs to get their certificate from the same public CA. If only the organization's CA is configured, the attacker would have to compromise the CA and generate a certificate there as no other certificate would be accepted.

  how can I mitigate the rouge AP attack?

No matter how your approach it, while 802.1X adds a higher level of security to your wireless connections, it does so at the cost of making secure configuration of the client devices more difficult.

If you are only concerned about Windows in an Active Directory environment, then you can simply use group policies to enforce the correct configuration and install any certificates.

Otherwise (and who worries only about Windows today?), the best methods for approaching this issue are to use one of many 802.1X on-boarding solutions that can configure the majority of your clients for the best level of security. These do however cost to acquire and/or operate and most on the products on the market are now bundled as part of a CA, NAC and/or RADIUS solution.

Solutions such as Cisco ISE, SecureW2, Ruckus Cloudpath, Aruba Clearpath/QuickConnect, and Impulse SafeConnect are some of the solutions I have seen deployed for this purpose. Or simply use your search engine of choice to look for "802.1X onboarding" or "BYOD onboarding."

Note: portions of this answer were derived from my own answers elsewhere on this or other sites.


store a Certificate in a TPM? Is there any point to store a Certificate in a TPM?

From what I understand a certificate is public knowledge.  The only concern about certificates is accepting a rogue certificate.

There are a few certificates that make sense to store in a TPM, and each of them is a certificate for, or relating to the TPM. The endorsement key (EK) certificate, often issued by the TPM manufacturer can be stored on the TPM. Platform certificates, conformance certificates, and platform conformance certificates can also be stored on the TPM. Each of those certs I listed have a designated index to store in TPM NV storage, however, any blob of data--certificate or otherwise--can be stored on the TPM, as long as there is available space.

The reason to store anything in the TPM is that the storage can be persistent on the computer. It's not on the hard drive, and not managed by an operating system. The TPM and platform manufacturers put TPM certificates on the TPM so that they are available when the end user partitions the drives and loads an operating system. Depending on the situation, an end user might want to store other data there for the same reasons. For example, dual booting to encrypted volumes, or swapping drives between OSes, if you want to store some bit of data. That data might even be an encrypted identity key blob.

The TPM's NV storage is limited, somewhat slow, and difficult to manage. It should not be used except for situations where the advantages outweigh the drawbacks. That is very few situations.

TPM certs are, for the most part, just like any other certificate. The EK certificate is a public key certificate, holding the public portion of the TPM's life-long identity/storage key. It is generally signed by the TPM manufacturer. You must still validate it using a cert chain which can be obtained from the manufacturer's web site. To know that the TPM holds the private portion of that key, you will need to perform one of the few actions that force the TPM to decrypt something that you encrypted with the public key found in the certificate. After you have done these tasks, you should have a high assurance that the certificate is valid. The platform certificate is an attribute certificate, and does not hold a public key. It is signed by the platform manufacturer, and should be validated against the manufacturer's certificate chain. The platform certificate holds the EK certificate's serial number in the signed portion, so that you have assurance that the platform manufacturer meant the two certificates to be paired.


Web application set cookie based on a GET paramater. Is it vulnerable? In my web application I take the GET paramater x and I store it in a cookie after URL-encoding it (so there is no HTTP response splitting). Some people say that this can be abused to cause DOS, but I can't find any explanaition in the Internet. Is my web application vulnerable to any attack vector?

It depends, there isn't really enough information to make an informed decision.

The DOS issue in the past was usually described as allowing attackers to overflow cookie space limits for a domain, which can have interesting security ramifications. This is much less of an issue now, though.

There can be larger contextual and system evolution concerns. I saw a case once where an application blindly wrote cookies in this way as a cheap data sharing scheme with related applications on other subdomains. Then the suite was whitelabeled, so the root domain the application was running under was no longer the provider but the client's. Then suddenly other applications under the client domain could have their cookies rewritten. That's fun.

Generally speaking, plenty of applications do just this, and it's fine, but always consider ways to restrict and constrain what gets written (does it have to just be any data, or is there some structure that can be imposed upon it), and always consider the data untrustworthy without validation (e.g. consider adding a signature to ensure what is read is what was written.)


plugins to lengthen short urls for security purposes Came across this question

What browser plugins can help us to see the actual destination of such shortened URLs?

I prefer a different Firefox add-on called RequestPolicy. It's a much more general purpose security tool in that it enables you to control all requests to external URLs. Along the way it converts shortened URLs to the real URL and let's you decide if you want to go there.

It exposes all the external links of a web page and let's you decide which to allow.

At first you might find RequestPolicy annoying because many sites won't function as you would expect until you allow external links. Now that I am used to it, I like it a lot.


When someone clicks on a link that downloads the virus what makes the virus run? Say for example a person gets an email with a link. That link turns out to be a download link for a virus and once the user clicks on it the virus is installed on his computer. Sure the virus is on his computer but what makes it run. If the user doesn't open the virus file there is nothing to run it? So how do hackers take over your computer if you never even ran their virus?

In addition to @mentallurg ‘s answer there’s another way of executing the virus code. Sometimes virus code is packaged within an exploit for existing software.

For example there could be a vulnerability in your browser that allows constructing a malicious web page in such way that a part of that web page would be interpreted as code and executed on your cpu. Depending on vulnerability used that could happen right after you open the page, or when you perform specific actions (like clicking something) within the document.

The best way to defend against these attacks is to regularly update software. In addition - minimize usage of weird browser extensions (flash, silverlight, etc). Browsers are pretty secure pieces of software, but flash is regularly used as a target. Nobody should use it in 2020...


Why aren't application downloads routinely done over HTTPS? We all know we should be using SSL whenever we collect passwords or other sensitive information. SSL provides two main benefits:

Encryption: The data can't be read by a middle-man while in transit.
Protection against MITM attacks: A man in the middle can't pretend to be a server, since they can't produce a CA-signed certificate for the server.

If I'm downloading an application, I'm probably going to run it at some point, maybe even as root. Some programs will be signed, but many aren't. Shouldn't downloads be done over SSL so that I know that it hasn't been tampered with during transit?

If somebody steals my password, that's bad. But if somebody plants a keylogger on my computer, that's way, way worse.

Because HTTPS is not very well suited to securing downloads of large public files. For this use case, it's slow and not that useful. There are reasons for not using HTTPS well beyond incompetence or unawareness.

HTTPS doesn't fully solve the problem. This If you're getting your application straight from the vendor's website, HTTPS does ensure the authenticity of the application. But if you're getting your application from a third party (e.g. mirrors of free software), HTTPS only protects the connection with the third party. A package signature scheme works better: it can protect the whole chain from the vendor. Application distribution requires end-to-end protection and HTTPS doesn't provide that.

HTTPS uses more bandwidth. The overhead per download is minimal if you don't take caching into account. This is the spherical cow of “HTTPS doesn't cost more”: if you use SSL, you can't cache data except at the SSL endpoints. Application downloads are cachable in the extreme: they're large files that many people download.

HTTPS is overkill. The confidentiality of an application download is rarely an issue, all we need is authenticity. Sadly, HTTPS doesn't provide authenticity without also providing confidentiality. Authenticity is compatible with caching, but confidentiality isn't.

HTTPS requires more resources on the server. Google mail got it down to a 1% overhead and a 2% bandwidth overhead, but this is for a very different use case. The Gmail frontend servers do more than mindlessly serve files; a file server doesn't need a powerful CPU in the first place (it's very strongly IO-bound), so the overhead is likely to be significantly larger. The same goes for memory overhead: a file server needs very little memory per session in the first place, almost all of its memory is a disk cache. Getting the resource usage down requires a serious amount of work.

HTTPS wouldn't help many people. The security-conscious will check the hash provided by the vendor (that should be over HTTPS). The non-security-conscious will blithely click through the “this connection is insecure” message (there are so many badly configured servers out there that many users are trained to ignore HTTPS errors). And that's not to mention dodgy CAs who grant certificates that they shouldn't.

If you want to make sure that you're getting the genuine application, check its signature, or check its hash against a reference value that you obtain with a signature (for example over HTTPS).

Good vendors make this automatic. For example, Ubuntu provides GPG signatures of its installation media. It also provides the hashes over HTTPS (sadly not linked from anywhere near the download page as far as I can see). After that, the software installation tool automatically checks that packages come with a valid signature. See How to use https with apt-get?

Note: if you're getting the application directly from the vendor (as opposed to via some package repository or application marketplace), then HTTPS does provide protection. So if you're a vendor providing your application directly for download on your website, do protect it with HTTPS!


Privacy Policy(ies). Does the cookie “collect” browser data or “request” browser data? I'm working on legal portion of my site, Privacy Policy in particular. I've done the research and found that nearly all the answers to my question (below), is generalized.

Question: Do cookies "collect" data from user browsers, or do cookies "request" then receive data from user browsers?

This seems to be a very important distinction. Do I put into my privacy policy that my site "collects" data from my users or do I "request" data from my users.

My understanding of the core functionality is that cookies request data of user browser or browser activity. Users control how their browser will respond (or handle cookies) in their browser settings. If users have the ultimate control of handling "responses" to cookies is it proper for website privacy policies to state that they use cookies to collect browser data? Isn't it more accurate to state something like: "We use cookies to request data from your browser. Depending on you have your settings, your response to our request my impact your experience." Or something along those lines.

For years the way I understood the phrase "cookies collect browser data" is that we (websites) force code (the cookie), onto your browser that opens a siv for all your activity to flow back to us. But this isn't the case at all. Cookies actually make a "request" (i.e., asks) for the user's permission first, and depending on how the user has set up their browser settings, the cookie request is honored or denied.

I'm trying to stay away from the term "collect" as a general matter. I think it's improperly used and leaves the wrong impression on users.

Has anyone else thought about this? Am I missing something?

UPDATE: Thank you for all the good responses below. I've concluded that my Privacy Policy will NOT state "We use cookies to collect info...," but rather: "We use cookies to request info..." because the former implies no consent required, whereas the latter implies consent required, and IS the more accurate case.

Cookies neither collect nor request data. Cookies are just boxes you can store information in the client side that may be later retrieved when the client enters the site after setting the cookie.


Prevent download of an angular website by unauthenticated users I have an app using angular and when deployed to a server, everyone can ofc download the source codes, obfuscated or not.

Yet, I would like to prevent user that are not authenticated to see the source code of the core application. Since right now, the login is made on the real app, they have access to everything.

I was planning on making a static page that serve as a portal, where user authenticate, and separated from the main app.

After login, you would receive an email with an url (would be hosted on the same server) and a token, that would bring you to the main app.

The server would verify the token (is this possible with nginx?) BEFORE serving any file from the main application.

Then, when an user is connected, since he is server the real app, but he is connected, I would not care if he as the source code access.

Is this secured enough? Is this doable using nginx?

There is no practical or effective solution to this problem. The site is fundamentally run on the client side so whoever accesses it, will have to be able to pull the code to run it (as you mentioned) and will be able to distribute the content.

Yes you can use techniques such as that which you described. There's simpler ways though, a simple authentication portal written in a different platform or served as a different pre-authentication site that would either enable access to the angular site or not depending on the user having a valid session or not. Enabling access in this case would require validating authentication, so it would not be a plain redirect to a previously undisclosed URL - instead a piece of code could act as a reverse proxy and pass access to the angular site. Or conversely whichever control is in place, it should never rely on the URL for the angular site being unknown to unauthenticated users; This is not effective.

nginx would be able to validate authentication headers and things like that, but you really want all that to be implemented by application code and not the serving platform if at all possible.


Is it more secure to set a DNS CAA record to a non-existing CA? A CAA allows specifying which Certificate Authorities are authorized to issue a certificate for my domain. For example

  example.com.   CAA 0 issue "symantec.com"

will only allow Symantec to issue certificates for example.com.
However as explained in Why don't browsers check CAA records to help ensure a certificate is valid? this is not verified or enforced by browsers. There is no reason to set it to the CA that issued the current certificate.

With that in mind: would it not be more secure to set the CAA-record to an invalid CA like this:

  example.com.   CAA 0 issue "doesnotexist.com"

That way nobody can issue a certificate.

My certificate is still valid for several years from now and I will not need any CA to issue a certificate right now. When time comes I will temporarily change the CAA record to the specific CA to allow it.

In short, no.

And here it is why.

1. Do not use made up names

Whatever you do on the Internet, when you really need fake/obfuscated name, do not just invent some and hope that it will be fine in the future for everyone. By that reasoning, .MAIL has become a TLD that will never exist because it has been abused by so many documentations.

RFC 2606 provides you with a set of correct values for such a case, basically, example.com, example.net and .example TLD.

2. Empty CAA records

But using "fake" names is not even necessary for CAA records.
The RFC 6844 gives this example:

  For example, the following CAA record set requests that no
  certificates be issued for the domain 'nocerts.example.com' by any
  certificate issuer.

nocerts.example.com       CAA 0 issue ";"

So just do that, do not invent a fake name.

3. DNSSEC?

Is your domain DNSSEC-enabled?

If not, CAA records can be spoofed or dropped

4. Use of CAA records: issuance time vs use time

  "this is not verified or enforced by browsers."

They do not need to. Per CAB Forum requirements (section 3.2.2.8 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf), nowadays all CAs are required to check for CAA records at certificate issuance time.

This is when it matters because the certificate will be valid for let us say 1 year; and during this timeframe the DNS CAA record can be changed to many things, so at use (connect) time the browser may get a completely different answer than the one at certificate issuance time.

And Crypt32 said it in the comment, as written in the requirements: "This stipulation does not prevent the CA from checking CAA records at any other time."

But feature wise, you are probably more thinking about DANE and its TLSA records, see RFC 6698 and 7671.

They would provide to clients the insurance, at connect time, for any given service, that the server indeed should be using either the certificate or public key exposed in the TLSA records or a certificate signed by a specific authority whose certificate is in a TLSA record.

Of course:

you need a DNSSEC enabled zone for them to be useful, otherwise trivial downgrade attacks are possible, and
clients need to use these records, otherwise they can not enforce the rules you put in place; unfortunately for now for browsers it is at most an add-on and certainly not a base feature.


How safe is my contactless bank card? In the past few years Contactless Payment cards have been introduced and I have been reading some articles surrounding security of these cards. The following article "Stealing data from contactless cards is easy, experts warn" states

  A Which? spokesman said: 'By touching volunteers' cards to our
  card reader, we got enough details to allow us to go on an internet
  shopping spree.  'With these card details, the contactless transaction
  limit is irrelevant, because online transactions aren't contactless.'

This article seems to suggest stealing contactless card is easy but the same article also states:

  Figures from the UK Cards Association show that in 2014, the total
  annual contactless fraud loss was £153,000 compared with total
  spending of £2.32billion.

Which seems a relatively small percentage.

Looking at the Visa FAQ website it states the following:

  Can a fraudster with a bogus contactless terminal steal money from my card by brushing up against me?

  Today’s fraudsters are on the hunt for full card details. The only
  information that could possibly be read from a contactless card is the
  card number, the expiry date and in some instances, the cardholder
  name – the same information that’s available on the front of your
  card.

  On its own this information is simply not useful for today’s
  fraudsters – who also need to get their hands on the really sensitive
  information, such as the CVV code (the three digit security code on
  the back of your card), PIN numbers, Verified by Visa passcodes, card
  security codes, billing addresses and other hidden security data. None
  of these essential details can be read from a contactless card.

But according to the other article, card number, card holders name and expiry date is enough to purchase things online on certain websites contradicting the VISA statement.

So how safe is my contactless payment card?

What are the risks should I be aware of?

What can I do to protect myself against potential risks?

Can an attacker get information off the card?
Yes, at least some can, and the UK consumer group Which? mentioned in the question did it:

Our researchers tested 10 cards (six debit and four credit, from volunteers) to assess security risks.
Contactless cards are coded to 'mask' personal data, but using an easily obtainable reader and free software to decode data, we were able to read the card number and expiry date from all 10 cards.
We were also able to read limited details of the last 10 transactions, although no cards revealed the CVV security code (the number on the back).

Can the info be used to buy stuff?
While most online shops will not let you pay without the CVV, some do. So while the fraudsters might have limited shopping to choose from, they can still spend your money:

We ordered two items - one a £3,000 TV - from a mainstream online shop using 'stolen' card details, combined with a false name and address. We've alerted the store involved.

Your card could also be copied and used for other contactless transactions. Which? estimates that limits on those would limit the theft to £45 - £100.
Note how the qoute from the Visa FAQ is carefully worded not to say that this isn't possible, just that it is not what fraudsters are looking for nowadays.
How close would the attacker need to be?
Edit: See ewanm89's comment - this might not be true.
To pull this off and be able to read a card you have to get quite close. The Guardian interviews a privacy standard expert at the National Consumers Federation:

He said that while industry standards specify a maximum magnetic-field strength for card readers of 5cm, some may be able to read cards at greater distances.
“It may be possible for a small percentage of cards to be read 15 to 20cm from the reader,” he said. “Even if this was to occur in 0.1% of cases, with more than 300m transactions taking place last year, many consumers could be affected.”

Is this a problem for you?
The bank or the merchant will be liabel for most of your monetary loss, so you will not end up in the poor house just because someone steals your credit card number.
Which? reports on the rules, but they might be different outside the UK or EU:

Fraudulent transactions on contactless cards are protected by the same rules that apply to other card payments. This means that if you're a victim of fraud, your bank will refund you the money, provided it’s not a result of your own negligence. However, you will have to pay the first £50 of the total amount of fraudulent transactions made on your card.

That the banks takes most of the financial hit does not mean this is without impact on you:

You might loose £50.
You will have to go through the hassle or reclaiming money from your bank if your card is abused. Maybe just an annoyance, but still.
If the attackers only steal small amounts, you might not even notice and hence not be able to report it.
It is hard to be completely anonymous if you carry around a radio tag broadcasting your name. It is easy to think of situations where you would not want to wear a name tag...
Some cards broadcast recent transaction history. This has obvious privacy implications.
Credit card numbers could be used in phishing attacks. A cold caller who knows your card number is more likely to fool you.
A card number could be used to impersonate you. It is not uncommon for a customer support to use some digits from your card as a security question to verify your identity. You can get a lot of private information, like order history, from a customer support. In some places you can even get them to do a password reset.
Buying things in your name with your credit card can make you look pretty bad. Your significant other might not be so happy to find big payments for porn sites in your credit card history... This could be used to mess with people.

In the end, you will have to decide if it is worth the risk or not. I would not worry about the money, but if I lived in a dictortorship I would not bring my credit card when attending a protest.
What can you do to protect yourself?
I see three solutions:

Try to convince your bank to give you a card without this capability.
If they don't want to do that, you can try to physically destroy the antenna. A bit risky, since you could acidentally destroy the card.
Carry the card in a faradays cage wallet. Either buy one or if you feel handy, make one yourself. (Either way, make sure to test it so you know that it actually works.)


Can you still be tracked when using a VPN? If I am using a VPN to connect to Twitter, can an organisation like Anonymous or Lulzec track me and find out my identity?

Using a VPN in and of itself isn't going to stop people who want to trace specific activities on-line.  A VPN encrypts the traffic from your machine to the exit point of the VPN network.

So what it protects you from is someone trying to look at your network traffic if they sit between you and your VPN provider (for example a correctly set-up VPN should prevent someone on the same wireless network as you from reading your traffic)

A VPN isn't therefore likely to protect you from an adversary like "Anonymous" unless they happen to be on the same local LAN as you.