Are there "secure" languages? Are there any programming languages that are designed to be robust against hacking?

In other words, an application can be hacked due to a broken implementation, even though the design is perfect.  I'm looking to reduce the risk of a developer incorrectly implementing a specification.

For example

Heartbleed would not have happened if the language used could guard against a Buffer Over-Read.
SQL Injections might not happen if there was a language enforced way to encode/decode HTML data
Sensitive data can be saved to Pagefiles in some languages where low-level controls of securely erasing memory aren't available.
Pointer issues/overflows occur more often in C when compared to managed code
Numerical rounding errors can occur when using the developer uses the wrong datatype for the wrong data
Denial Of Service attacks might be reduced if the app is correctly is multi-threaded
Code signing may reduce the threat of runtime security issues (link, link)

Question

Is there a language that addresses many or most of these issues?  It's acceptable for the language to be scoped for a particular use-case such as WebApps, Desktop, Mobile, or Server usages.

Edit:
A lot of people addressed the buffer-overflow issue, or say that the programmer is responsible for security. I'm just trying to get an idea if there exist languages whose main purpose was to lend itself to security as much as possible and reasonable. That is, do some languages have features that make them clearly more (or less) secure than most other languages?

Actually most languages are "secure" with regard to buffer overflows. What it takes for a language to be "secure" in that respect is the conjunction of: strict types, systematic array bound checks, and automatic memory management (a "garbage collector"). See this answer for details.

A few old languages are not "secure" in that sense, notably C (and C++), and also Forth, Fortran... and, of course, assembly. Technically, it is possible to write an implementation of C which would be "safe" and still formally conforms to the C standard, but at a steep price (for instance, you have to make free() a no-operation, so allocated memory is allocated "forever"). Nobody does that.

"Secure" languages (with regards to buffer overflows) include Java, C#, OCaml, Python, Perl, Go, even PHP. Some of these languages are more than efficient enough to implement SSL/TLS (even on embedded systems -- I speak from experience). While it is possible to write secure C code, it takes (a lot of) concentration and skill, and experience repeatedly shows that it is hard, and that even the best developers cannot pretend that they always apply the required levels of concentration and competence. This is a humbling experience. The assertion "don't use C, it is dangerous" is unpopular, not because it would be wrong, but, quite to the contrary, because it is true: it forces developers to face the idea that they might not be the demigods of programming that they believe to be, deep in the privacy of their souls.

Note, though, that these "secure" languages don't prevent the bug: a buffer overflow is still unwanted behaviour. But they contain the damage: the memory beyond the buffer is not actually read from or written to; instead, the offending thread triggers an exception, and is (usually) terminated. In the case of heartbleed, this would have avoided the bug from becoming a vulnerability and it might have helped to prevent the full-scale panic that we observed in the last few days (nobody really knows what makes a random vulnerability go viral like a Youtube video featuring a Korean invisible horse; but, "logically", if it not had been a vulnerability at all, then this ought to have avoided all this tragicomedy).

Edit: since it was abundantly discussed in the comments, I thought about the problem of safe memory management for C, and there is a kind-of solution which still allows free() to work, but there is a cheat.

One can imagine a C compiler which produces "fat pointers". For instance, on a 32-bit machine, make pointers 96-bit values. Each allocated block will be granted a unique 64-bit identifier (say, a counter), and an internal memory structure (hashtable, balanced tree...) is maintained which references all blocks by ID. For each block, its length is also recorded in the structure. A pointer value is then the concatenation of the block ID, and an offset within that block. When a pointer is followed, the block is located by ID, the offset is compared with the block length, and only then is the access performed. This setup solves double-free and use-after-free. It also detects most buffer overruns (but not all: a buffer may be a part of a bigger structure, and the malloc()/free() management only sees the outer blocks).

The "cheat" is the "unique 64-bit counter". This is true only as long as you don't run out of 64-bit integers; beyond that, you must reuse old values. 64 bits ought to avoid that issue in practice (it would take years to "wrap around"), but a smaller counter (e.g. 32 bits) could prove to be a problem.

Also, of course, the overhead for memory accesses may be non-negligible (quite a few physical reads for each access, although some cases may be optimized away), and doubling pointer size implies higher memory usage, too, for pointer-rich structures. I am not aware of any existing C compiler which applies such a strategy; it is purely theoretical right now.


The ".htaccess" file can be downloaded. Why? How to fix? Maybe a noob question. I've tried searching but maybe my search terms were too specific.

I've just conducted a pen test on a client's site. The site allowed me to download .htaccess just by simply browsing to directory where it was stored; www.example.com/dir/.htaccess

What causes this and how can it be remediated?

It depends on the type of the webserver in question.
If it's apache, it should contain something like this in the config file (usually in the "main" apache.conf):

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy all
</Files>

If it's missing, that can cause the problem you described.

The other typical cause of this is that the client have used apache in the past, but switched to something else (e.g. nginx) which does not use .htaccess and hence doesn't treat it in a special way. The solution in this case is webserver-specific, but it usually boils down to restricting access to files beginning with ".ht", or - if they are really not used - you can simply delete them.


Wine or sandboxie as sandboxes I'm looking for a sandbox for Windows. I've looked at sandboxie  but I don't know if it delivers what it promises. Is it actually safer to run programs inside sandboxie ?

I know a full-blown VM could kill the problem but I was interested in a more light-weight solution to this.

Also, I have another question related to Wine. Is Wine also a sandbox in terms of security or is it just an emulator ?

If these are not viable from a security point of view, what else could I use ?
I'm basically interested in helping someone who keeps opening unsafe powerpoint files and binaries on his Windows machine.

Thanks

Virtual Machine are not always foolproof although I do agree that they are pretty useful but there has been cases of whereby the "guest" vm can access to their "host" machine. Read up

For sandboxie, some malware will crash and it will omit an error message when you run it on a sandboxie but it won't when you run it on an environment without the sandboxie.

For someone who just wants to be totally secure, using another physical machine without any internet access and no private and confidential information are stored at that physical machine would be deemed good(although there can be cases whereby malware will spread through thumbdrive).

In your case in wanting to help your friend, I would recommend you to try Windows SteadyState(freeware) if you are on Windows XP or Windows Vista or you can try Deep Freeze (commercial). Basically, it creates a snapshot of your current system configuration, and you can do anything with your computer but when you reboot, the system will revert back to the previous snapshot so your computer will be the same as before you did anything to your computer. Do note that your computer needs to be in a clean state before you create a snapshot that will be restored after each reboot. Otherwise, your computer will still be infected.


Does the new Fedora package manager allow unauthorized installations? I just upgraded to Fedora 22. The biggest change from the previous version is that the yum package manager is now replaced with dnf. One change I've noticed is that if you try to execute a command that comes from a common package which is not yet installed, the terminal will prompt you to install that package. For example:

[wbarlow@wbarlow-thinkpad src]$ ar
bash: ar: command not found...
Install package 'binutils' to provide command 'ar'? [N/y] y

 * Waiting in queue...
 * Waiting in queue...
 * Waiting for authentication...
 * Waiting in queue...
 * Downloading packages...
 * Requesting data...
 * Testing changes...
 * Installing packages...
Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
       ar -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive
  r[ab][f][u]  - replace existing or insert new file(s) into the archive
  s            - act as ranlib
  t            - display contents of archive
  x[o]         - extract file(s) from the archive
 command specific modifiers:
  [a]          - put file(s) after [member-name]
  [b]          - put file(s) before [member-name] (same as [i])
  [D]          - use zero for timestamps and uids/gids (default)
  [U]          - use actual timestamps and uids/gids
  [N]          - use instance [count] of name
  [f]          - truncate inserted file names
  [P]          - use full path names when matching
  [o]          - preserve original dates
  [u]          - only replace files that are newer than current archive contents
 generic modifiers:
  [c]          - do not warn if the library had to be created
  [s]          - create an archive index (cf. ranlib)
  [S]          - do not build a symbol table
  [T]          - make a thin archive
  [v]          - be verbose
  [V]          - display the version number
  @<file>      - read options from <file>
  --target=BFDNAME - specify the target object format as BFDNAME
 optional:
  --plugin <p> - load the specified plugin
 emulation options:
  No emulation specific options
ar: supported targets: elf64-x86-64 elf32-i386 elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex

In this entire process, I was never asked for a password, and yet I would have had to use an elevated account in order to run dnf install binutils. What is the difference between the installation above and a dnf install installation? Why does one require an elevated permission and the other does not? Is this a security hole?

I would suggest that you try to reproduce this. Most likely, you already had an authenticated session and your system remembered it due to the keyring. A great way to test would be immediately after a reboot.

aditya@20:54:20:~$ nano
bash: nano: command not found...
Install package 'nano' to provide command 'nano'? [N/y] y

 * Waiting in queue...
 * Loading list of packages....
 * Downloading details about the software sources....
 * Loading list of packages....
 * Waiting in queue...
 * Waiting for authentication... Failed to install packages: Failed to obtain authentication.

Disclaimer: I am a Fedora user and contributor.


Securing Home Network using 3rd Party Firmware / Access Points I've been having some trouble on my home network and thought that having a router as an AP would help fix these attacks. At first it did, but now it seems the attackers have gotten through. For all I know, it COULD be a pesky script not necessarily an "Attacker" - just using that term as a general descriptor of a rogue device or worm on my network.

The most obvious signs of outside activity are inbound DHCP connection attempts when using OpenVPN with certain IPs and DNS being switched to an Indonesian server when using certain ports. Some questions along with a basic map of my connection below (using Ethernet):

[MODEM/ROUTER] -> [ROUTER/AP] -> [My Computer]

Would using OpenVPN on my router vs computer help deter these types of attacks?
Is there any benefit to using two routers vs one to help prevent traffic getting through? Does layering access points help in this situation? I was under the impression a DMZ would help isolate my machine from others... but it could be that I just dont have the DMZ setup strict enough.
Would setting up pFSense on a spare computer be more secure vs. using 3rd party firmware on a router? (e.g. Tomato, Gargoyle, OpenWRT, DD-WRT) I figured packages such as DNSCrypt/DNSMasq would help fix the DNS issues described above. I'm not quite sure how to harden DHCP beyond setting it as authoritative, etc.

stackexchange is only suited to one question at a time - you've asked more than one where the title matches a small one at the end, but the rest is 'how do i stop getting dhcp traffic when i'm on a vpn?' by my interpretation.

The answer for that question is to have a firewall on whatever you connect - be it a single host or a router.

There's no objectively good way to assess whether 3rd party firmware is better or worse, since the details matter, but these are moot and only pretty loosely related to your first question.   Out of the things you've suggested pfsense is probably the best setup, but only if properly configured, which I kind of get the impression you may not find easy.


How to communicate security expectations to users in an end-to-end encrypted chat app? I am developing a chat application that has end-to-end encryption, with no third party being able to eavesdrop on conversations. This is rather easy by simply deploying apps that people download and then use for chatting.

However, I also wish to give people an option to use a web client without installing anything. Obviously, this means that all the messages need to go through a web server, which could possibly eavesdrop on it. But if the provider is trusted not to eavesdrop, then it's still secure (The website uses HTTPS).

How should I inform users of the difference in security? The only thing I could think of is something like:

  Note on security: Using the web client provides less security than using the downloaded application. If we somehow turn evil, then we could eavesdrop on conversations on the web client, but conversations using the downloaded client are safe even from us.

but this seems very confusing, and most users would probably laugh at the service "turning evil".

NB: This is an open research problem, and there are several people currently doing research on communicating the security provided by end-to-end encrypted chat applications. So there is no research coming to our rescue here, only design thinking.

Another note: there is no such thing as a security / usability trade-off. There's design principles, constraints related to security, and to that add poor designers and good designers.

You should communicate to your users the level of security they should expect. In this case, a visual approach is what I would recommend.

When you advertise / install / run the app, showing a visualisation of two people communicating over a secure channel (and possibly third-parties failing to pierce through the channel) could help users conceptualise that they are talking peer-to-peer and securely.

When people switch to the Web view, it should be prominently displayed this time that the messages transit through a server that is branded with your company's brand identity, and you should show that this server is able to read / intercept messages (depending on what your solution actually does).

Why visualisations? The idea is to rely on the human ability to process spatial concepts without rationalising them. By showing the boundaries between users, the branded server, and external parties, you can communicate the provided security effortlessly. See Dourish's 'Where the Action is: The Foundations of Embodied Interaction' for a (long) explanation of why this might ease your users' task of sense-making.

You should also clearly communicate the risks associated with signing up / exchanging identities on your system if any. It seems from your succinct presentation of your product that there are many aspects that have not been thought out at all.

As the task is daunting, I extremely strongly recommend hiring designers. Specifically, an interaction / service / information experience designer to take care of the presentation of the tool's benefits and limits and the general security interactions; and a graphic or motion designer to work on whatever security visualisations you might end up wanting.


How to deal with WPE users I own a chat room and some users use a program Winsock Packet Editor, "WPE PRO".

With it they manage to bypass chat rules, like they can't be muted or kicked, and they can send messages fast bypassing the limit of the chat.

I was wondering if there is a way to end this?

About the software from the developer website:

  Winsock Packet Editor (WPE) Pro is a packet sniffing/editing tool which is generally used to hack multiplayer games. WPE Pro allows modification of data at TCP level. Using WPE Pro one can select a running process from the memory and modify the data sent by it before it reaches the destination. It can record packets from specific processes, then analyze the information. You can setup filters to modify the packets or even send them when you want in different intervals. WPE Pro could also be a useful tool for testing thick client applications or web applications which use applets to establish socket connections on non http ports.

Update:
Its called 123flashchat, its Java/Flash, unfortunately the company abandoned the project, no updates or fixes any more. and the issue is not kicking the user, there is a ban on the ip, but a user can change the ip and return and start spamming messages fast

If what you describe is true, your chat room is designed badly.

The view of the server and what packets it receives should be forwarded to other users should be independent from whatever packets are coming in or going out.

Manipulating the traffic on a client should only interfere with that client's view of the chat room, never with other clients.

If you designed that differently, you are trusting on the clients to behave correctly.

You should never do that.

Misbehaving clients (those not behaving according to your rules) may create even bigger problems for you than people not being kicked. Here are a few examples of things that may happen without proper input validation:

Users may impersonate other users, leading to massive trust and confidentiality breaches
Users may gain rights they otherwise wouldn't have, being able to hold your service for ransom

Side note here:

There are many web clients for IRC that are easy to deploy and many IRC networks that let you host channels for free. Have your pick and rely on a thorough platform for chats.


Should different web apps running on VDS each have their own user account? I deployed my second rails app on my VDS with capistrano. Should I configure that application server to run as a different user, or the same as the first application?

If I run applications as different users are they safer should one of the applications be compromised?

Yes.  These accounts let you limit the amount of damage that an app vulnerability that allows shell access can do.

Let's consider the things you might want to proactively protect:

Static files that are served with same-origin privileges like JavaScript.  These should not be writable by any app account since they need only be read and only by the user account for the particular app that serves them.
Log files.  These need to be written by a single app account, but not read.
Configuration files and scripts.  Some may be shared but they should not be writable by any app account, and unless you have good reason, make per-app config files only readable by that app user.

If your users are tied to database privileges, then any per-app tables should only be modifiable by that app's user, and schema change authority should be reserved to administrators.


Are Facebook, Yahoo, Google, etc. hackable? What I would consider to be hacking one of these services is something along the lines of cracking databases (or I think what would be databases). In reality, I have no idea how sites like these store passwords. From what I read a little bit ago, sites such as these with massive databases don't story every thing in one place, which is good for two reasons in my opinion. A) when millions of people are accessing these databases, it helps to spread out the load, and doesn't bottleneck the host of the database, and B) this provides a step of security so that if one database is compromised, not every one is, or it makes it more difficult to gather all of the data at the same time.

If someone attempts to look up how to hack facebook, they will only see things such as keyloggers. Why, though? I am sure that this is possible (even if highly impractical), and that someone somewhere would benefit from something like this. I know that these major companies have the money to sue anyone to death who did anything like this, but why hasn't it been done by a hacker yet? (If it has and I didn't realize it, I apologize).

In the end, what makes Facebook not hackable, or at least difficult? In reality it is not bulletproof, because nothing is ever 100% secure. I am sure some people could find this very profitable. Why hasn't this already happened, though? What kind of security measures are these companies taking to prevent things like this?

My answer might be a little less Paranoid Parrot than ThinkerThinker's, although I have to agree on some points. These companies invest a lot in security, they also have a lot of security installed. It would be quite embarrassing if anyone could just walk up to them and hack into their database. So the reason you don't find anything about in on google is either:

It's very secure and near to impossible (nothing is impossible, but it's not something you do with a simple howto guide)
Even if it happened, why would Facebook even publish it? It's bad publicity.

Spreading a keylogger and just waiting for it to return useful information is easier than trying to hack a facebook database. Plus it generates more passwords for more platforms (paypal,hotmail,gmail,tumblr,...) for one person.

There will always people be trying to get into your system, they use automated scripts. If an open my auth.log I get this from the past 3 minutes (I know I should change the ssh port, but I'm not the one that can decide that):

Apr  1 09:02:14 jugo sshd[15626]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:20 jugo sshd[15659]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:24 jugo sshd[15661]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:29 jugo sshd[15664]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:05:33 jugo sshd[16424]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:35 jugo sshd[16427]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:38 jugo sshd[16429]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:40 jugo sshd[16431]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:43 jugo sshd[16433]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root

They just try automatically to get into a system with some random passwords and users. In the end there will be a few servers they can get into.

Measures you can take to prevent these attacks:

make your code secure
white list instead of blacklist
least privileged principle
Use of firewalls, IDS and IPS.

They also hire penetration testers and security analysts to test their systems and go look for mistakes or problems. It's not impossible, but not it's very hard. There were companies people were able to get into that were published. You only need to have a look at all the companies Lulzsec was able to get into. But remember these guys are highly skilled.


How to setup a dedicated home machine (Linux) for secure transactions? I would like to set up a computer at home (preferably running Debian, or some other flavor of Linux) to be used only for secure financial transactions.

The idea is that, by strictly limiting what is done with this computer to a small set of operations it will be easier to keep it secure.

I imagine that this is something that many people would like to do but I have not found a good set up of instructions for implementing.  I can only find instructions/checklists for securing/hardening a general-purpose computer, which I figure should be more difficult than what I want to do, and maybe produce a less secure system.

Maybe I have not hit on the right search terms?

Any pointers would be appreciated.

In addition to the other answers, you might want to try to increase the security of your browser. Default levels are a compromise between security and ease of use.

For Firefox, there is a list of SSL related addons that may help. There are also instructions on improving the security of SSL connections.

There is also a web site that helps you understand whether you have the basics right for SSL connections.

Getting SSL connections right is one of the important things as it is your secure connection to your secure web sites.

I would actually recommend also that you put the whole secure setup on a large FLASH USB drive and boot from it when you want to securely go online. That way, you are not accidentally leaving traces behind on your normal partition. Keep the USB drive in the safe when not in use.

By the way, the reason you haven't hit on anybody recommending this way of doing things is simply that it is a pain and few people are that bothered.

UPDATE:

If you are keen to have a USB bootable, secure environment, you have some options.

Firstly, you might consider using BSD (see here and here) instead of Linux as this is generally considered more secure by design.

For Linux, there are some articles that explore what you are trying to do. Here for example, here.

You can add some additional security by ensuring that the USB drive is fully encrypted. This can be via a whole disk encryption (or here) or by using secure USB drives, for example the LOK-IT drive.

Be careful though if you travel with these devices since there are plenty of unenlightened corners of the world, including the USA, whose customs officials will assume that you are a bad guy, if not a terrorist, if you are "evil" enough to carry encrypted data with you. Ref: 1, 2, 3, 4, 5, ...


Preventing DDOS attacks without collecting personal data? Could anyone suggest a system to prevent DDOS attacks without collecting personal data like i.p. addresses  ( or using anonymized data ) and be not deny access to an innocent user ?

It's not possible.
DDoS is a layer 3 issue, which means that IPs are the primary piece of data. Blocking DDoS higher up the stack will not be effective, and it is not possible to go lower in the stack. So, at some point, DDoS defences rely on IPs.
And if IPs are the dependency, then other realities come into play, like the fact that innocent people might have the same IP as an attacker. This is true for different users behind the same NAT.
You also appear to be of the impression that identifying users is somehow a part of DDoS defence. It isn't. Since this is a networking issue, and not an application issue, the connection between IPs and any user accounts is not made. Defences occur before the application.
So, not only is this not possible, but your requirements are unnecessary.


How to securely connect to a database with PHP? Currently in PHP (in the file /var/www/website.com/public_html/functions.php). I am connecting to the database like this:

function connect(){
    $config = parse_ini_file('/var/www/website.com/db.ini');
    $con = mysqli_connect("localhost",$config['username'],$config['password'],$config['db']);
    if(!$con){
        die("Failed to connect to Database");
    }
    return $con;
}

Where the /var/www/website.com/db.ini is

username=user123
password=pass123
db=mydb

with permissions:

-rw-r--r-- 1 root root 84 /var/www/website.com/db.ini

The PHP will be run by either www-data or root.

The root of website.com is /var/www/website.com/public_html/.

Is this the best way to connect to a database using PHP from a security point of view? I am also making this code open source.

Your approach looks good.

You are storing the credentials in a separate configuration file instead of having them written inline in the source code. This makes it safe when sharing the code with others and protects the credentials in case a misconfiguration lets the plain PHP code be printed out (which happens quite often).
The config file is outside the public document root, therefore it cannot be directly accessed by a user of the web application, unless there is another vulnerability (e.g. a directory traversal flaw).
In any case you should avoid running the server as root. Otherwise the permission model is worthless, since root can read and write to any file.

Note that you don't have to deal with parsing the credentials in your code at all - you can instead specify them as PHP runtime settings in the server configuration, as explained here.

Also see:

How do I make my database connection secure?
How to secure database passwords in PHP?


Is there any such thing as an independent code vetting project which works for free to vet open source projects? I'm sure I'm not the only one who is scared to death to blindly trust random strangers with all my data. Which is the case in practice if, for example, I'm to use this library right now, which I'm about to: https://github.com/jfcherng/php-diff
It is impossible for me to know if this (or any other library) does only what it claims, and what kind of security the author has. Tomorrow, he could get compromised and his account uploads an update which adds malware behaviour to his originally clean library, and then Composer will pull it down.
I wouldn't mind using a slightly outdated version if that version was "verified" somehow by a third party. However, I've never encountered such a thing.
Is there really no group of security-aware people who go around and "vet" libraries such as the one I've linked to above, marking specific releases as "OK" so that I can use them without (as much) fear? Yes, I have to trust that group, but it's at least another entity that claims to have done some kind of real vetting.
I almost feel like I'm missing something important. As in, nobody in their right mind would be using these GitHub projects like this, or something. Yet I have to. It is impossible for me to go through others' code (unless very trivial), but others claim/seem to be able to, so it seems reasonable that they don't just do it locally for themselves, but report their trusted "seal of approval" somehow to the world.
There must be companies out there who use open source projects and do have some paid guy going through the code before they just put it into production on their enterprise mainframes, right? Wouldn't it be a great way for them to give something back without having to donate money or actual code, by simply sending a signal saying: "We, Entity X, believe that version Y of library Z is clean, and will be using this in production."?
If this were standardized in some way, GitHub (or others) could display a little list of gold stars/badges next to each version, showing which trusted companies/groups have vetted the code.
Is there something I'm missing? Why isn't this (apparently) a thing?

There is a major difference between "looks good for my own use case" and a more general code audit which can be applied to many use cases. And this difference has associated costs - why should companies bear these additional costs?
There are sometimes publicly financed or company sponsored real audits for some critical software, for example crypto libraries like OpenSSL or Botan. But don't expect any library you just like to use to undergo such a real audit. And many of these libraries would likely not survive such an audit anyway, because they are not designed with security as a major concern. Or a proper audit is simply not realistic because of a lack of proper documentation (i.e. code documentation, design documentation, ...) and a unwillingness or lack of time of the developers to invest a significant part of their own time to provide the assistance needed for a proper audit (i.e. creating documentation, design discussions, fixes ...).

We, Entity X, believe that version Y of library Z is clean, and will be using this in production."?

I guess the legal departments of many companies would block such a public statement because they fear backslash if a problem is found in these libraries and someone claims that they only used the library because they trusted this statement. And if a problem is found it will also shine a bad light on the capabilities of the auditing company, which might result in customers no longer trusting their products. Therefore companies are usually very careful before they make statements like these - which drives the cost of such an audit even higher.


What could happen if regex metacharacters using named capturing group are not encoded? Let's say that a web application take a specific input from the user (e.g., search form), apply a Java regex with named caputring groups on it and use the final output to do other stuff (e.g., look for the searched resource which name has been modified through the regex).

What if some regex metacharacters, especially $ which is used in named capturing group to refer to the specific groups (e.g., $1 refers to group 1), are not encoded and a user could alterate the regex flow injecting them?

A little code example:

"aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input" )

The user, instead of "user_input", could insert $1 and recall the first capturing group. But this is just a simple and mere example, there could be lots of other kind of uses.

I can't really see any concrete security threat, apart from trying to manipulate the regex flow, but I wish to know if someone could.

Technically yes, there is a very minor data leakage vulnerability here.

In your example:

"aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input")

if user_input contained $1 and the value of the above was output and the input string aaaaaafooNfooaaaaaaa was not user controlled, the user would be able to find out what the original "secret" string was (i.e. the N).

Practically the answer is really no, unless someone has been deliberately "unusual" with their coding.


When a user tries to register with an unactivated email again, should I tell user that the emails has not been activated? Suppose my site needs to register for a member account with email, and the email needs to be verified and activated. I forbid users to register with same email twice. When it does, should I remind the user to activate the email? Or just display the message 'This email has been used',same as trying to register with already activated email?

You should never reveal on the website, whether a specific e-mail address has been used to register. This allows a user enumeration attack and may likely be a privacy issue for your users.

Instead, in your case, send an informational e-mail to the address in question.


Disabling SHA-1 in TLS handshake in Linux As SHA-1 is not recommended, I want to disable the SHA-1 hash algorithm. I used OpenSSL API to set signature algorithm to SSL_CTX,

static INT32 signAlgoList[24] = { NID_sha512, EVP_PKEY_RSA, NID_sha512, EVP_PKEY_DSA, NID_sha512, EVP_PKEY_EC,NID_sha384, EVP_PKEY_RSA, NID_sha512, EVP_PKEY_DSA, NID_sha384, EVP_PKEY_EC, NID_sha256, EVP_PKEY_RSA, NID_sha256, EVP_PKEY_DSA, NID_sha256, EVP_PKEY_EC, NID_sha224, EVP_PKEY_RSA, NID_sha224, EVP_PKEY_DSA, NID_sha224, EVP_PKEY_EC };

Signature algorithm list:

(void)SSL_CTX_set1_client_sigalgs(sCtxMutualAuth, (int *)signAlgoList, 24);
(void)SSL_CTX_set1_sigalgs(sCtxMutualAuth, (int *)signAlgoList, 24);

After including these APIs in my program, SHA-1 is disabled in Windows (I am not seeing SHA-1 in Wireshark logs) but, still SHA-1 is not disabled in Linux (It is showing SHA-1 in Wireshark logs). Is there any other way to disable SHA-1 in Linux?

As SHA1 is not recommended, ...

This initial assumption is wrong. The only place where SHA-1 is not recommended is where collision resistance is needed, i.e. signatures (for example signatures on certificates). SHA-1 is still fine to be used as a HMAC, it is still (together with the even older MD5) an essential part of the TLS 1.1 protocol etc.


packets coming out of a 10.10 network with 192.168 source addresses Since there are only a few different source addresses and they are all within valid subnets for the types of routers on our network (mostly netgear & mikrotik), I assume this means that this traffic is coming from local networks and not the routers themselves (seems like if it was from hacked routers, we would see a larger variety of source addresses).

If this is the case, then how are packets with 192.168 source addresses leaving routers with 10.10 public IP addresses? Is there a way to set up the firewalls of the individual mikrotik routers to prevent this from happening?

It's very simple to block or allow the relevant traffic on MikroTik RouterOS device.
I am pretty sure it's not hacked routers, maybe they are not configured properly.
You can use an Address link like LAN_Networks and allow only them.
The example at their wiki site is pretty simple:
https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Address_list


Security risks with JSONP? What are the security risks with JSONP?  Is using JSONP in a new web application reasonable, from a security perspective, or is it better to use a different method for cross-origin web mashups?

If using JSONP is reasonable, what steps should I take to make sure I'm using it securely?  If it's better to use something else, what would you recommend instead?  (CORS?)

JSONP is a bit dodgy, from a security perspective:

Requires excessive trust.  Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org.  This involves placing 100% trust in b.org.  If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin.  This kind of excess trust is dangerous from a security perspective: it makes your application fragile.
To put it another way: JSONP is basically a self-inflicted XSS.  Yes, OK, I know it's a feature, not a bug, but still...

CSRF vulnerabilities.  You have to remember to defend against CSRF vulnerabilities, and with JSONP, that gets a bit tricky.  Standard advice is to ensure that only POST requests can trigger a side-effect, and to include a CSRF token in all POST requests; but JSONP involves sending a GET request to trigger a side-effect, which ain't exactly the cleanest solution you've ever seen.  So this means that the host that provides JSONP service needs to remember to check CSRF tokens even on GET requests.  Also, it requires a bit of a tricky protocol for the embedding page (a.com) to obtain the proper CSRF token from the JSONP service (b.org).  It gets messy.

Causes mixed-content warnings. Suppose we have a page hosted on https://a.com and it accesses a JSONP service on http://b.org.  Then this will inevitably trigger a scary-looking mixed-content warning (since JSONP involving loading a script from http://b.org).

User authentication gets ugly. If b.org wants to authenticate the user, that gets tricky to do when using JSONP.  The embedding page (a.com) needs to first somehow give the user an opportunity to log into b.org in advance, before accessing b.org's JSONP service.  Both sites need to coordinate.

I don't know whether web developers should be recommended to avoid JSONP for new web applications or not, but these aspects make CORS look pretty tempting.
See also What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains?


Enterprise Standard for Linux server Penetration Testing Is there any enterprise or global standard like "OWASP" which can be followed while doing penetration testing on Linux servers?
I want to know if there are any most common/important vulnerabilities that must be covered while doing Linux server penetration testing?
OWASP has a top 10 vulnerability list that can be followed while doing Application vulnerability testing.

There are actually multiple methodologies that you can use as a guideline to do penetration testing. For example, you have PTES, which is used by some commercial pentesters.

However, the PTES is more than "OWASP Top 10 but for Linux", as it defines communication with the customer, threat modeling, etc. as well.


Cookie+session based CSRF protection Consider the following scenario:

1. When user visits a webapp, server:
    a) initialize the session;
    b) generates CSRF token;
    c) saves token to session;
    d) saves token to client's cookie via Set-Cookie header.
2. On each POST request server compares cookie token (which comes automatically with Cookie header) with session token, and if not equal - return 403.
3. On each request (POST, GET - no matter) server regenerates the token and saves it to session and cookie.

By doing this way we:

1) perform rapidly expiring token, which makes harder for attacker to exploit the webapp;
2) ensure that browser tabbing and clicking "back" button will not break the session. This is because every time the server regenerates the token it reflects in client's cookie.

My questions is: can I use this approach in production webapp, or it has vulnerabilities?

Thank you.

You need the token to be sent in the request outside of the cookie mechanism (e.g. POST data). If sessions are managed via a session ID contained within a cookie, your approach doesn't prevent CSRF.

In your current implementation:

  save token to session;
  save token to client's cookie via Set-Cookie header.

This will have the effect of the token being saved in two locations, but both locations will be identified by cookie values.

e.g. if the token is "12345678" it will be saved in session (pseudocode):

Session["SessionCSRFToken"] = "12345678";

and in cookies

Cookies.Add("CSRFToken", "12345678");

However, in order to save the value in session, the web application framework will create a cookie to identify the session, so you will get two cookies set:

Set-Cookie: CSRFToken=12345678;
Set-Cookie: SessionID=987654321;

If a user is logged into your website at www.foo.com and then the user visits www.evil.com, there could be a hidden form tag embedded into the page of www.evil.com (possibly within a hidden IFrame) which is automatically submitted by JavaScript:

<form method="post" action="https://www.foo.com/Account/DeleteAccount">
</form>

When the browser automatically submits the form, both cookies will be sent with the request
(CSRFToken=12345678, SessionID=987654321) and your cookie token (CSRFToken) and session token (SessionCSRFToken) will match and the effect will be that the user's account is closed on your system without their knowledge.

To prevent this, you need to store a CSRF token in the page itself (e.g. within a hidden input). This way your form could only be submitted as follows:

<form method="post" action="/Account/DeleteAccount">
    <input type="hidden" name="CSRFToken" value="12345678" />
</form>

Now www.evil.com has no way of including the hidden input within their own HTML as they have no way of knowing the value of the CSRFToken. The value of CSRFToken can be the same as the cookie (the session value is now no longer needed), but it only needs to be generated once pre user session (there is no need to constantly regenerate the value).

For each POST you simply need to make sure that Request.Form["CSRFToken"] == Request.Cookies("CSRFToken").


Internal Update Server in PCI environment I am curious to know if we require separate update server in our cloud based PCI environment. In our current setup webserver, appserver, dbserver, logserver, and jump server are independent instance. I am not sure if we can directly update (packages) of these Centos Linux servers from yum or we need local update server(Spacewalk) which sync from outside software repos and then sync packages internally.

PCI requires, among other things, separation of production and test environments; change controls; and patch management/rollout policies. Patch your test environment first, and place the patch(es)/updates into production in accordance with your shop's change control and patch management policies. Document everything including the URLs or IP addresses at which you obtained your update packages.


Black Box penetration testing in private network I came across a scenario where an organization is using micro-service architecture. They are using Amazon AWS as a web service and Kubernetes to maintain micro-services. All the EC2 instances are in private subnet. You have to connect with a VPN to access them. My approach is Black Box testing. We can just access the public domain (xyz.com), subdomains (abc.xyz.com) and publicly exposing APIs. I have just started in this field. What should be my approach to start the testing ? Also, if they are using any vulnerable applications (like outdated Jenkins etc) within the private network, can it be exploited from the outside of the box ?

If you have just started in this field, I would suggest that you first get fundamental idea of black box penetration testing. You might also want to look into the scope of your testing. (This is the most important thing to do before you start testing)

There are various approaches you will find on the web. Traditional approach for such kind of testing is:

Information Gathering and Analysis:

After doing the necessary planning and preparation with the organization (or target) the next step is to gather as much information as possible about the targeted systems or networks. There are lot of tools and online resources available to do the necessary information gathering.

Vulnerability Assessment:

With so many targets in hand, it is important that you carefully analyze the weaker targets and attack them. At this stage, you start the vulnerability assessment on these systems to evaluate potential vulnerabilities which are exploited. You can perform the vulnerability assessment using well-known tools like Nessus, Nexpose, Open VAS etc. During the vulnerability assessment, you will also notice that many of these systems would be running outdated third party software’s and operating systems which could become easy victims of targeted attacks.

The example you gave about "outdated Jenkins etc" fall in this category.

Exploitation:

Once you find out some of the outdated software, you find the well-known vulnerabilities into it and try to find how can you exploit it. After multiple attempts, you might manage to exploit the vulnerability successfully and might get a command shell with Local Administrator privileges.

Post-Exploitation:

Now that you have broken into a domain system and added a backdoor user, you can use post-exploitation on this system. Your aim will be to get the local administrator password of the system and then check if you can login to other domain systems with these credentials.

Escalating our Privileges:

If you have access to numerous other systems with these credentials, you can use the tools like netscan to look up logged-on users with the Local Administrator Credentials.

Accessing High-Value Targets:

You can target the high value targets of the network to expose the gravity of the attack.

References:
Infosec Institute


Which parts of a credit card can I obfuscate and still have it be valid I was recently the victim of credit card fraud and I suspect it is from a merchant somewhere keeping track of my credit card details.

I cancelled the card and received a new one, but I would like to make it as difficult as possible for criminals in brick-and-mortar stores to copy my card details.

What parts of the credit card can I save to a password vault and obscure by scratching over/off and still have it be valid?

If you deface a credit card, you are likely to find it will be rejected for all transactions. The merchant really needs all the info on the card to be valid - it's part of how they protect themselves from fraud.

So my answer would be: none!

Instead of worrying about that, concern yourself more with how the merchants handle your card. In the UK, for example, a customer never needs to let go of the card in most stores now, as contactless is almost ubiquitous. But if you have to hand over your card, watch it like a hawk. Handheld terminals brought to you are safer than letting someone take your card away.

And remember, if the merchant commits fraud, your bank will reimburse you so it's not the end of the world.


SSL/TLS : Authentication mechanism I have these doubts regarding authentication in SSL/TLS :

Will there be an authentication involved for all SSL connections ? For eg. when I browse the internet, using the most up-to-date browser, can I assume that there is always authentication involved ? From other questions I learnt that they are mostly to avoid a MITM. But is it optional/mandatory ? RFC says,

  This authentication can be made optional, but is generally required
  for at least one of the peers.

If yes, does it always depend on the server certificate key size ? Say for eg: RSA public key size 2048, DSA key size 256.
When referring to the cipher suite used for SSL - is it okay to say the authentication happened with the <Auth> algorithm with <server_cert_key_size>  ? ( Considering I'm using cipher suite : TLS_<Keyexchange>_<Auth>_<EncCipher>_<MAC>  ). I know the authentication mechanism differs by the type of key exchange (DHE vs. RSA), but is the usage of <server_cert_key_size> consistent ?

Sorry for asking 3 questions in one. But they are very much related.

EDIT: To rephrase, and to be precise - is SSL/TLS authentication only as strong as the server certificate key size ?

Your Web browser will always try to authenticate the server's certificate; it will complain loudly when it cannot. The point about optional authentication is for the "DH_anon" cipher suites in which there is no authentication at all. Such cipher suites are, by definition, insecure against active attackers, and thus should not be used. Web browsers don't support them by default, or even at all.

Some servers may also require some certificate from the client, but this is pretty rare because client certificates are a rarity, and most people don't have any. This mostly occurs with some bank sites, and if that's your case then you should already know it.

Key size does not impact whether authentication occurs or not. Of course, if the server uses a pathetically small key, this may endanger the safety of communications -- but your up-to-date browser should warn you in that case.

The key size as indicated in the cipher suite name (as the "128" in "TLS_RSA_WITH_RC4_128_SHA") does not relate to the RSA / DSA / whatever key used for the asymmetric encryption, but to the symmetric encryption algorithm used afterwards to actually encrypt the bulk of the data.

More generally, you seem a bit confused about what "authentication" means. In usual SSL connections, between a Web browser (the client) and a Web server, along the HTTPS protocol, there are two "authentications" which take place:

During the initial establishment of the connection (the "handshake"), the server shows his asymmetric public key to the client as part of its certificate, and the client validates that certificate. The validation process is the method by which the client makes sure that the public key it sees is indeed owned by the intended server. Once the client has obtained some guarantee that the public key is correct, it accepts to use it for the cryptographic elements of the handshake, which indirectly authenticates the server for the whole subsequent data exchanges.
Once the handshake has been done and the SSL/TLS tunnel established, the server may require some sort of authentication from the client (password, cookie...). This happens at the HTTP level, not at the SSL level; this is completely unrelated to SSL, except that most client-to-server authentication mechanisms can be deemed "safe" only when they occur within a secured tunnel, e.g. some established SSL connection.

The relationship between the cipher suite and the authentications is the following:

The cipher suite may mandate a specific key type (e.g. RSA or DSA), and things will work only if the public key, as found in the server's certificate, is of that type.
The client-to-server authentication is secure only insofar as the SSL/TLS tunnel ensures confidentiality and integrity; there are weak cipher suites which do not do that well. Fortunately, these cipher suites were defined to comply with old US export regulations and are no longer activated by default or even supported by modern Web browsers (except maybe in some countries, which may insist on their citizens using weak cipher suites).


PGP vs Hash functions What is the difference (in terms of security strength) between checking a package' integrity using pgp and hashing functions (i.e. sha256)?

Isn't pgp less secure as the verifier must trust the public key advertised by the public key directory (thus being prone to mitm attacks)?

OpenPGP also hashes the package content's, but additionally cryptographically signs the hash.

A simply hash sum only allows to detect transmission problems. It does not allow to detect attacks, at least not as long as the hash is not verified through some secure channel.

Given the signer's key was validated and is trusted, OpenPGP provides such a secure channel and allows to verify the package's origin in addition to detecting transmission errors. There are different ways to validate an OpenPGP key, but simply fetching a key from a key server should never be considered one.


How to Stop DDoS Attacks by simple function on web server? I have an overview ideas of the preventing ddos attacks, in a simple way. Please clarify me, if my thinking is wrong.

Option 1

From the basic understanding of the DDOS attacks is that the attacker is sending a lot of data to the web server. So what about the website that offer big data uploading to their website? Aren't they not also receiving a lot of data at the same time from many uploading users?

Can't the web server treat the ddos attacks like a many users uploading data?

Option 2

What about a website offer, everyone who visit the website temporary key? With that temporary key insert into the website, the only one (PC/IP) can access that website, so bot-net can't attack the website (bot-net doesn't have the temporary key).
Can bot-net note the key and insert into the website?

P.S.

This is the similar question
DDoS - Impossible to stop?

Option 1

  From the basic understanding of the DDOS attacks is that the attacker
  is sending a lot of data to the web server.

Not in every case, the slowloris and SYN flood attacks do not send tons of data yet they are classified as DDoS. Each host attacking the target sends just a little information, enough to clog the victim's network and prevent it from opening more connections and accept valid requests. For this reason, it is not possible to treat the ddos attacks like many users uploading data, they are attacking the entry point of the web server, not the application.

What the sites that take large amounts of data do is a combination of redundant servers, finely tuned web servers and other techniques, all of them come with a cost, both in management and money, and still, they know that a DDoS can only be mitigated but not avoided (remember github)

  Option 2

  What about a website offer, everyone who visit the website temporary
  key? With that temporary key insert into the website

You are thinking about the application managing the requests but DDoS attacks can also target the lower layers of the stack. In general there are (arguably) 3 categories of DDoS attacks:

Volume based: ICMP flood, UDP floods,...
Protocol Attacks: Ping of Death, Smurf, SYN floods...
Application Attacks: Slowloris, Apache specific attacks...

Your idea would work for the application attacks but not for the others.


Tor Exit Node Security & https website Sometimes I need to make multiple transactions on some websites which only allow 1 transaction per hour per IP address. So to avoid IP address problem I sometimes use TOR browser. I know tor keeps us anonymous but what about our credit card or others details, can they be monitored on tor exit node on websites which use https ?

How secure is my transaction ?

Correct me if i am wrong : I don't think VPN + Tor will help either because VPN will just avoid my ISP getting to know I am using TOR & my traffic will still be unencrypted at Tor Exit nodes.

Only VPN option was not considered because I have seen VPN to be slow (sometimes speed drops to zero) and have read that there are chances of IP leaking while using VPN, & in my case if IP address is leaked my transaction will fail.

I need a fast, secure & IP changing solution.

but what about our credit card or others details, can they be
  monitored on tor exit node on websites which use https ?

No, they cannot be monitored UNLESS the exit node is malicious and actively interferes with your traffic by performing various attacks. Notably:

"downgrade" attack, by redirecting your https://example.com request to http://example.com. This is trivial to do, but also trivial to spot if you look at your address bar at all (and if the server is set correctly, .
MitM attacks with self-signed certificates. This is also trivial to do, but also hard to miss because your browser would show a big warning about certificate not being trusted.
MitM attacks with the valid certificates signed by a shady/government-controlled CA. This is generally only possible for state actors. You can protect against this by using certificate pinning.
SSL protocol attacks. Generally also only useful for state actors; you can protect by using up-to-date browser and hope the server is up-to-date too.

So if everything looks right, and you're not dealing with state secrets, your transaction is most likely secure - although you're definitely taking larger risks using Tor (a chance an exit node is malicious is much higher than a chance your ISP or some other ISP in between is malicious).

VPN+Tor in combination "Tor over VPN" would work as you described.

The best solution for you would be to rent a number of servers across the globe, and run VPN software there. This way you're in full control of the speed. A cheaper, but worse, solution would be to use multiple commercial VPNs - the situation you describe with connection speed is typical for free VPNs.

Before going into details, please note that it is very easy for the website owner to block all transactions coming from Tor exit nodes, shall they decide so. So your solution might stop working anytime if the website really wants to block it.


Using encryption inside of SSL connection We are using SSL to make our connection between clients and backbone servers safer. Does it really make sense if also we use another encryption mechanism to encrypt transmitted data twice? For example, encrypt data by AES and then transmit data on an SSL connection?

It really depends on what you're trying to protect.

SSL only protects data in transit, and between the two set points.  It doesn't protect data at rest, and it doesn't offer any guarantee that the data came from the person claimed.

So if you need to protect the data while it's stored at either of the endpoints, then encrypting it might make sense.  Or if you need to provide assurances that the data came from a certain party, then signing it might make sense.

On the other hand, if you're simply decrypting the data and storing it at the endpoint, and not doing any authentication, then it wouldn't make a lot of sense to add another transportation layer.

Security often works in layers, so it's important to understand what each layer provides.  SSL is merely a transport layer, and only provides assurances that the data sent wasn't intercepted along the way, or replaced with something by an attacker in the middle.


Is it good idea to rely on Mifare UID for security/authorization reasons? Several systems rely on using UID of smart card for identification/authorization.
For example database stores list of smart card UIDs and corresponding
privileges.

Given that today there exist cards where you can write any UID you want
and thus emulate say Mifare classic UID for example, what are practices
of using smart card UID for authorization?

In other word fear is if I use Mifare Classic UID for authorization,
someone may purchase some Chinese card, where you can assign any UID
you want - and hence holder of such card, can impersonate original holder
of my Mifare Classic.

Are there ways to overcome this? How (or do at all?) people use smart card UID for authorization?

The Mifare Classic has been broken several years ago (their weak, obscure and proprietary encryption got broken) and so was the Mifare DESfire v1.
You should rely on stronger algorithms (preferentially open strong ones) and also have a monitoring system that detects abnormal behavior to detect cloning or tampering. It just depends on the level of security you need.

We have at work an RFID payment system for the coffee machines. Setting up a bio metric+code+network scrutiny on those cards would be overkill. Since they rely on Mifare classic, it's possible with the Proxmark device (i personally never tested, but others did, just google cloning mifare classic proxmark) to set whatever amount of money on the card and get unlimited coffee. But the Proxmark device costs around 300$ so it's not cost-effective if you are not a coffee addict (and it's morally wrong, but perfectly doable).

But if you are talking access authorization, this card is a big no-no. (you could use Mifare DESfire v2 if you want to stay with Mifare for example, but again, look for the level of security each offers, and if it fits your needs).

  "We do not recommend the use of Mifare Classic for new installations. We are working with customers to review their security."
  source: http://news.bbc.co.uk/2/hi/programmes/click_online/7655292.stm

edit:
to have a broader view of the risks you are facing by using an RFID authorization system, check http://www.oecd.org/sti/ieconomy/40892347.pdf, at "2.1.1. Typology of risks", you'll be able to confront this knowledge with the security solutions vendors propose.


Understanding Shake on IT key exchange Shot paper

I am reading a paper about key exchange and trying to understand the protocol described in Figure 4 on page 6 in the above paper. I understand the majority of the notation but am having a hard time understanding steps 7 and 11.

It states that PE (device 1) signs some data using its own private key in step 7, and later PV (device 2) verifies this data. How does PV verify the data if it had been signed with PE's private key? Wouldn't it need to be signed with PV's public key, so PV could verify the content with its own private key?

I just do not understand why the signed data is useful to PV.

Sorry if this is a novice question and thanks for any clarifications.

Public Key Cryptography has two basic primitives -

Encryption - data encoded using the Public Key can only be read using the Private Key

Signing - data that can be decoded using the Public Key must have been written using the Private Key

As you can see, these are really just two sides of the same coin, both depending on the Private Key being Private and the availability of the Public Key to other parties.

  How does PV verify the data if it had been signed with PE's private key?

If the data decodes using PE's Public Key, than it can only have been encoded using PE's Private Key, therefore verifying that it "came from" PE.


How can I get infected by computer viruses? I would call my self a security aware computers professional, and I was asking my self for a long time now allready. How can it be that male-ware gets onto my computer wihtout me actively playing it or accepting an information about it?

I reinstalled some weeks ago my windows and did the following things in this order(given that all download were done from their official webpage):

installed win7
upgraded it to win10
installed mozilla
downloaded and installed kaspersky (with pre-existing license, if matters for features)
isntalled putty, winscp, tortoise, steam, battle.net and teamspeak, and downloaded software I own on those platforms.
did some ssh stuff between my server and my personal pc to get backups of important projects.
installed flash and adobe and surfed a bit through the web. (watched southpark streams on the german offical southpark site)

especially the last point probably is what caused the trouble, naimingly kaspersky detected 2 days ago 3 trojaners and 2 adwares on my computer.

that page was until some days ago hsoted by comedycentral, but that seemed to have been changed. And it now appears pretty harmfull. My pc is since I watched the streams pretty slow and so on.

But now my actuall question is:

In case I'm right in the assumption that all the previous steps won't have been able to inject harmfull software to my pc, then I'm concluding that there are ways (with java script?!) that are parsed by the browser into creating files on my computer and doing additional changes on my pc making it possible that those files are executed at some point automatically.

But why should browsers implement such features?
And even if they were so important and required, why am I not even informed or asked by my browser about possibly harmfull executes?

I mean for making a just created file beeing at some point automatically executed, there would have to be taken changes on my computer that shouldn't be that common for website applications, or am I wrong and it isn't that common that websites need to acces i.e. my registrys?

So from that point, why does it happen, that js features are supported from a browser that do such config changes on my pc, and why is the rbowser not even asking me about me beeing fine with it?

And for the future, are there other ways to protect against it, except deactivating js?

Or could it be something entirely different?

Drive-by downloads are a real threat. These enable a website to exploit a 0-day vulnerability in your browswer to execute malicious code on your system. Note that sometimes websites are hacked to behave maliciously without the website's owners being malicious.

While browser manufacturers work to fix security problems quickly, the 1534 publicly announced Firefox vulnerabilities are proof that this is a difficult task. Flash is also another well-known source of security problems (currently 1039).

It is also possible that one of your downloads came with malicious files in it. Sites such as CNET are notorious for this.


Policy implications of changing passwords versus disabling accounts in Active Directory Is there any guidance stating that the best way to handle leavers is to disable accounts (at least initially) instead of changing passwords? Given that AD supports this option I would assume this is the only supported way to disable a user, but other hacks seem to be prevalent to support legacy apps or processes.

I ask because I believe this is the only secure way, but many guides and companies tend to follow an approach which changes the password for the user to something they don't know. I think other methods such as moving an account to an OU which cannot log in are even more flawed.

Historically this might have been a good practice when all applications where on-premises, but with cloud applications using many sync tools it seems like an AD account being disabled is the only safe indicator for upstream applications.

It seems like some applications like the latest versions of Outlook with O365 support invalidation of credentials with ADAL following a password reset, but I doubt this is universal.

You are correct, the ideal off-boarding process would be to disable the user. However there are situations where the user has company data that is located on his personal profile, be it on premise or in the cloud.
Since cloud and on-premise services usually could have some kind disabled user data purging configured. You'd rather be on the safe side and change the password instead of disabling the user.
Also even with cloud services you sometimes have glitches and can't change the user that is in charge of a certain process or task and you'd rather ride it out. In many organizations the IT manager is asked to take ownership of the user's account and to copy files that were left on the profile.


What type of attack is this? Attacker purchasing something from e-store when attempting to tamper with requests and change the transaction amount value. What type of attack is this? How to prevent this kind of attack as the bank and merchants?

This is a Parameter Tampering attack. Emphasis mine:

  The Web Parameter Tampering attack is based on the manipulation of
  parameters exchanged between client and server in order to modify
  application data, such as user credentials and permissions, price and
  quantity of products, etc. Usually, this information is stored in
  cookies, hidden form fields, or URL Query Strings, and is used to
  increase application functionality and control.

You can prevent this type of attack by not storing sensitive information client side. For example, you could calculate the price server side each time it is displayed or used. Any attempt at altering quantities would result in the new price calculation remaining accurate.

If you want to validate quantity too, for example if you are limiting the number of products a user can buy, then you should also validate this server side.


Why use Linux instead of Windows for Pentesting? Nowadays we can find all sorts of tools i.e. Aircrack Suite, Metasploit, Burpsuite etc. for Windows too!

So why use Linux?
e.g. I am using aircrack on Windows what will be my disadvantage?

My laptop "Asus x205ta" doesn't support Linux out of the box, and even if I install Linux somehow, not all hardware is supported.

Overall, this question is rather broad, and will likely have an issue with opinions obscuring facts, so I'll try to keep this answer purely-factual.

say e.g. am using aircrack in windows what will be my disadvantage ?

We can answer that right from the developers of Aircrack:
From Tutorial: Getting Started:

This tutorial is focused on linux. Yes, I realize that linux is a problem for many people. Unfortunately Microsoft Windows simply does a poor job supporting the aircrack-ng suite. This is primarily due to the proprietary nature of the operating system and wireless card drivers. See Tutorial: Aircrack-ng Suite under Windows for Dummies for more details. Bottom line, don't use the aircrack-ng suite under Windows. There is little or no support for it.

And from Tutorial: Aircrack-ng Suite under Windows for Dummies:

First and foremost, Windows is virtually useless for wireless activities due to the huge number of restrictions. The restrictions do not come from the aircrack-ng suite so please don't ask for enhancements.
Here is a quick recap of the limitations:

Very few supported wireless cards: There are very few wireless cards which will work with the aircrack-ng suite. Most laptops come with Intel-based cards and none of these are supported. See the following links: Compatibility, Drivers, Which Card to Purchase and Tutorial: Is My Wireless Card Compatible? for more information. It is also important to note that there is little or no documentation accurately describing which version of the third party drivers you require for each card.

Dependency on third parties: The Windows world is highly proprietary and thus the source code for the drivers is not available publicly. As a result, no troubleshooting or fixes are available from the aircrack-ng team for these third party drivers. If there is a problem, you are on your own.

Limited operating system support: The Windows version works best with WinXP. It does not support Win98, some people have reported success with Win2000 but many have been unsuccessful with it and Vista is not supported. There is some evidence that a few people have aircrack-ng working under Vista but most people report failures. So basically, your best chance of success is under WinXP.

Passive capture of packets: Most people want to test the WEP security on their own access point. In order to do this, you must capture in the order of 250,000 to 2,000,000 WEP data packets. This is a lot of packets. With Windows, you can only capture packets passively. Meaning, you just sit back and wait for the packets to arrive. There is no way to speed things up like in the linux version. In the end, it could take you days, weeks, months or forever to capture sufficient packets to crack a WEP key.

Limited GUI: Most of the aircrack-ng suite tools are oriented towards command line utilization. There is only a very limited GUI available to assist you. So you must be more technically literate to successfully use these tools. Thus, if you are used to running a Windows installer then clicking your way to happiness, you are going to be exceedingly unhappy and lost with aircrack-ng.

Technical Orientation: Dealing with wireless requires a fair amount of operating system, basic wireless and networking knowledge. If you don't have this or are not prepared to do your own research, then you will find the tools and techniques bewildering. Do not expect people on the forums or IRC to answer basic knowledge questions. It is up to you to have these skills before starting out.

If you truly want to explore the world of wireless then you need to make the commitment to learn and use linux plus the aircrack-ng suite linux version. An easy way to start is to utilize the Backtrack live distribution. This distribution has the aircrack-ng suite plus patched drivers already installed which jumpstarts your learning process. BackTrack information can be found here.

So as a quick overview, the developers of Aircrack state that support for Windows is very limited, not because they haven't developed full support, but because the platform itself limits what they can do.


Why is IP spoofing still possible? What are valid usages?
Why don't ISPs prevent this by default? Do any major ISPs do this already?

There is a proposal known as BCP38 that has existed for a while (http://www.bcp38.info/index.php/Main_Page) which is based on RFC 2827 (https://tools.ietf.org/html/rfc2827)

The RFC proposes that ISPs block traffic coming into their network with source IPs that are not registered to come from the devices passing the traffic along. There are a lot of details to this, but in short there's a protocol known as Border Gateway Protocol (BGP) which has routers on the edge of an ISPs network broadcast which IP ranges they can route traffic for. When one ISP connects their network to another ISP (known as peering) they share this routing information. Because this information is known and shared, it's easy to detect when traffic contains spoofed IPs because that connected network doesn't advertise that they route traffic for those IPs, hence it can be blocked.

The problem is that ISPs don't generally implement this because (they claim) it costs them too much in resources to perform the extra analysis of the packets to determine whether it's spoofed. This is why it's still possible to spoof IPs. I believe there are some ISPs that do implement but not all do.

Even if ISPs implemented it, you can still spoof IPs as long as they are in the proper IP ranges for which the ISP broadcasts that it can route for. While it's more limited, that range can still be quite large.


DNS Cache Poisoning and Snooping I'm trying to do two things here.
The first is poison the cache of a target DNS server. A scan has suggested the network I'm attacking is vulnerable to CVE-1999-0024.
My understanding of this vulnerability is that it allows me to to 'tell' the DNS server on the target network that: myevilsite1.com = 1.2.3.4 and that as a result any clients internally requesting the site myevilsite1.com from the internal side of the DNS server will receive whatever IP I tell the DNS server to cache.
I don't understand exactly how this attack works and i'd like to also test it (and validate it if below is a suitable test). Could someone please explain how i can conduct an attack like this?

The second is to confirm that it has worked by using DNS Server Cache Snooping:
To do this i'm using the following command in nmap (I just want to double check this is a valid way to test):

  nmap -sU -p 53 --script dns-cache-snoop.nse --script-args
  'dns-cache-snoop.mode=timed,dns-cache-snoop.domains={myevilsite1.com,google.com,bing.com}'
  1.2.3.4

Hope someone can help!
Thanks!

The nmap plugin that you are using only tests against snooping, you can see if a user (using this DNS server) has performed a DNS request.

This is tested, using nmap, in 2 possible scnearios:

Timed: it will measure the time difference between a cached request (faster), compared to a normal DNS request (slower).  This way, it knows if the domain has been cached and thus "visited" before.
Recursive: If your DNS support this, a DNS request with the RD flag set to 0 will only be responded to if the domain is cached on your DNS server (and thus, visited before).

The best test is to test against domains that are probably used by the target domain.  Nmap by default tries the top 50 most popular domains, so that might be a good bet.

From a command point of view, the map page says that the timed attack can only work once reliably, since it inserts data into the DNS cache.  I'd say try with the default settings

nmap -sU -p 53 --script dns-cache-snoop.nse --script-args 'dns-cache-snoop.mode=nonrecursive' 1.2.3.4

Hope this helps!


Replacing weak SSH fingerprint algorithms Even though MD5 has been broken for years and its vulnerabilities have been used to create real-world rogue X.509 CAs and other horrible things, OpenSSH and PuTTY still use MD5 as the default public key fingerprint algorithm.

Is there a way to switch to something more secure for this purpose? Even SHA-1 would be somewhat better, although I would not prefer it.

Notice that for the validation of public keys via SSHFP DNS records, SHA-1 is already in use (and in a proposed extension also SHA-256)

Collisions are not an issue for key fingerprinting. Key fingerprinting relies on resistance to second preimages. To say things simply:

In a collision attack, the attacker tries to build two distinct messages m and m', which hash to the same value.
In a second preimage attack, the attacker tries to build a message m', distinct from a fixed, imposed message m, such that both messages hash to the same value.

The difference is quite crucial. While MD5 is thoroughly broken with respect to collisions, it is not for second preimages. As such, there is no urgency to replace it. New protocols should rely on better hash functions (like SHA-256), but there is no use in breaking existing protocol by evicting a still serviceable MD5.


Blocking mimikatz on the OS level? I want to know under which case would Mimikatz still run despite disabling WDigest?

Whether wdigest is set to 1 or 0, mimikatz still worked. (tested on Windows 7, 8, 2012)

Is there a better way to block it specifically on the OS level?

WDigest isn't a setting which disables Mimikatz, it's a form of encryption supported by Windows, which when enabled, allows Mimikatz to very easily dump plaintext passwords.

Disabling WDigest removes that one type of credential from memory, but a user with Administrator-level privileges can still dump other forms of interesting credentials. Mimikatz has plenty of additional capabilities which don't rely on WDigest!

So what you're really asking looks like a meta-question: How do I stop unwanted software running on my computers?

And in short, the answer is to either enable security features available to you:

Application whitelisting (AppLocker)
Antivirus software which detects potentially unwanted applications
Device hardening (particularly BitLocker (to prevent access to offline file systems) and if you can use Windows 10, Credential Guard)
Reduction in user privileges (don't let users be Admins)

Or potentially require use of Windows 10 S Mode or a device which can only run Store-derived software (and lock the selection down).

Preventing any kind of unwanted software (like malware) requires a holistic approach.


"WICKED" entries in the default nginx vhost's logs I have a small VPS running nginx, and for a long time now (several months, since I rented it) it has been collecting weird entries in its default (listen  80 default;) vhost's logs:

109.x.x.121 - - [07/Dec/2012:07:42:43 +0100] "GET /webpanel/gate.php HTTP/1.1" 404 168 "-" "WICKED"

there is a lot of those, from a few different IPs

# grep WICKED /var/log/nginx/x.access.log | awk '{print $1}' | sort | uniq | wc -l
18

There are also recurring ones, like this one which polls the server every minute

95.x.x.4 - - [07/Dec/2012:08:17:35 +0100] "-" 400 0 "-" "-"
95.x.x.4 - - [07/Dec/2012:08:18:37 +0100] "-" 400 0 "-" "-"
95.x.x.4 - - [07/Dec/2012:08:19:39 +0100] "-" 400 0 "-" "-"

until it stops. According to its PTR and whois information, this particular IP belongs to a dynip range of some German cable company so it's probably not a monitoring service.

Now, here's my question, what am I looking at?

Was the IP being used in some sort of bot herding before I got it? Or maybe my server was compromised? Those entries were showing up when I only had sshd and nginx serving static sites so pretty much nothing to exploit.

EDIT: yeah, I inflated the numbers unwittingly because I forgot to sort, fixed.

The last two fields by default are the referrer and user agent fields (nginx reference). Normally you'd see something there like a browser (Mozilla), search bot (Googlebot), command line program ("Wget", "curl") etc. there. Whoever is running something against your server is using "WICKED" as a user agent string.


csh http shellshock on a windows 2008 server My company's McAfee system detected many "http CSH bash ShellShock code injection attacks" attempts on a Windows 2008 server running Apache Tomcat Coyote. Does this config present a potential attack on the  server or is it just an attempt that could not harm the system while it is on a Windows machine ?

Shellshock is a vulnerability in the bash interpreter which is mostly used on Unix-like systems but has been ported to Windows.

However, Apache Tomcat, when running on windows, does not include bash by default and doesn't have CGI enabled by default either.

So, generally speaking, no, Apache Tomcat running under windows is not vulnerable. To be sure, however, you have to verify that bash hasn't been installed and used as the interpreter for CGI programs (which is sometimes done by third parties to deploy Unix software on Windows).


Why can't I MitM a Diffie-Hellman key exchange? After reading the selected answer of "Diffie-Hellman Key Exchange" in plain English 5 times I can't, for the life of me, understand how it protects me from a MitM attack.

Given the following excerpt (from tylerl's answer):

  I come up with two prime numbers g and p and tell you what they are.
  You then pick a secret number (a), but you don't tell anyone. Instead you compute ga mod p and send that result back to me. (We'll call that A since it came from a).
  I do the same thing, but we'll call my secret number b and the computed number B. So I compute gb mod p and send you the result (called "B")
  Now, you take the number I sent you and do the exact same operation with it. So that's Ba mod p.
  I do the same operation with the result you sent me, so: Ab mod p.

Here are the same 5 steps with Alpha controlling the network:

You attempt to send me g and p, but Alpha intercepts and learns g and p
You come up with a and attempt to send me the result of ga mod p (A), but Alpha intercepts and learns A
Alpha comes up with b and sends you the result of gb mod p (B)
You run Ba mod p
Alpha runs Ab mod p

During this whole process Alpha pretends to be you and creates a shared secret with me using the same method.

Now, both you and Alpha, and Alpha and me  each have pairs of shared secrets.

You now think it's safe to talk to me in secret, because when you send me messages encrypted with your secret Alpha decrypts them using the secret created by you and Alpha, encrypts them using the secret created by Alpha and me, then sends them to me. When I reply to you, Alpha does the same thing in reverse.

Am I missing something here?

Diffie-Hellman is a key exchange protocol but does nothing about authentication.

There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, user "Bob" is really defined only by his ability to compute things that non-Bobs cannot compute. Since everybody can buy the same computers, Bob can be Bob only by his knowledge of some value that only Bob knows.

In the raw Diffie-Hellman exchange that you present, you talk to some entity that is supposed to generate a random secret value on-the-fly, and use that. Everybody can do such random generation. At no place in the protocol is there any operation that only a specific Bob can do. Thus, the protocol cannot achieve any kind of authentication -- you don't know who you are talking to. Without authentication, impersonation is feasible, and that includes simultaneous double impersonation, better known as Man-in-the-Middle. At best, raw Diffie-Hellman provides a weaker feature: though you do not know who you are talking to, you still know that you are talking to the same entity throughout the session.

A single cryptographic algorithm won't get you far; any significant communication protocol will assemble several algorithms so that some definite security characteristics are achieved. A prime example is SSL/TLS; another is SSH. In SSH, a Diffie-Hellman key exchange is used, but the server's public part (its gb mod p) is signed by the server. The client knows that it talks to the right server because the client remembers (from a previous initialization step) the server's public key (usually of type RSA or DSA); in the model explained above, the rightful servers is defined and distinguished from imitators by its knowledge of the signature private key corresponding to the public key remembered by the client. That signature provides the authentication; the Diffie-Hellman then produces a shared secret that will be used to encrypt and protect all the data exchanges for that connection (using some symmetric encryption and MAC algorithms).

Thus, while Diffie-Hellman does not do everything you need by itself, it still provides a useful feature, namely a key exchange, that you would not obtain from digital signatures, and that provides the temporary shared secret needed to encrypt the actually exchanged data.


My Home WiFi Password was given away to a plumber who said he needed it, it then unusually went down for no apparent reason, is this suspicious? My home WiFi password was given away by my dad to a plumber who came in saying that he needed the WiFi password for his phone. As soon as he told him the WiFi went down for a few minutes, which I found suspicious. Does the WiFi going down indeed suggest anything suspicious or malicious, and what are the security implications of this?
Finally, I would like to ask, if something malicious were to have happened, what action should I take? Would changing the WiFi password be enough?

We will have no idea if the disruption is malicious or not; we'd be guessing.
If you feel that something malicious happened:

change the wifi password immediately
change the router's admin password
check all router settings, especially open ports, allowed devices, remote access
use an app on your phone to physically trace any wifi transmitting device in your home to look for devices that are not your own (these apps are tricky and are not always easy to use)


POODLE vulnerability in major social networking Social networking is a corner stone for a majority of our daily lives, be it communicating with friends, sharing photos or even using social networking for advertising and business promotion. Whilst reading up about this newly discovered complication.  It's apparent that websites use a range of SSL/TLS type certificates.  If the connection to one fails then browsers are equipped for a fall back protocol, which will use an alternative certificate for encryption. I have found this piece of text:

  Any website that supports SSLv3 is vulnerable to POODLE, even if it
  also supports more recent versions of TLS. In particular, these
  servers are subject to a downgrade attack, in which the attacker
  tricks the browser into connecting with SSLv3. This relies on a
  behavior of browsers called insecure fallback, where browsers attempt
  to negotiate lower versions of TLS or SSL when connections fail.

Source

With this in mind. Since this has been made a public statement that SSLv3 is not secure, it'll attract the more malicious users to exploit it (tons more than previously). Which sparks the question:

In the time it takes for major/popular websites and browsers to switch out/disable SSLv3, currently (day 1 of the vulnerability's public release), how at risk are current social networking websites such as Twitter and Facebook. Which are  currently using TLS 1.2, twitter being issued by Symantic and Facebook being issued by Digicert, with the server configurations (by assumption) to fall back to any encryption method which is not TLS1.0, but SSLv1 may be an alternative to not being completely dead?

Some portions of your question need to be clarified.  The SSL/TLS encryption is based upon the cipher suites supported by both the client and the server.  Not the certificates issued to each social networking site.  The certificates issued do not have a bearing on a website's vulnerability to POODLE.

The fallback to another SSL version is only performed if both sides don't agree on a cipher suite.  SSLv1 was never released.  The only browser I know of that supports SSLv2 is IE (at least up through IE9 this was true).  These versions of the protocol would still have to be supported by the server.  Server's do have SSLv2 support, but rarely enabled by default.

All that being said, social networking sites aren't "at risk".  The clients are at risk because its their credentials that can be decrypted.  Facebook will roll out patches/updates to their servers so that SSLv3 is disabled to protect their users, but the servers themselves aren't being actively compromised.


Possible to use both private key and password authentication for ssh login? It seems that they are mutually exclusive, as disabling one gives me the other, and vice versa.  Two-factor auth for my ssh servers sounds really nice, so is there any way to accomplish this?

With recent Fedora and RHEL 6 releases, you can use RequiredAuthentications2 pubkey,password to require both pubkey and password authentication. Usually this is done to require pubkey and 2-factor authentication token, not the user's password.

Update: Now on RHEL / CentOS 7, and any system with a recent version of OpenSSH, you can use:

AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"

It's also possible to use the Match directive to exclude IPs or Users.


What are the benefits to a two-page login system for a webapp? I have noticed many website going to a two-page (not two-factor) login system - where you enter your username on page 1 and click submit, and then enter your password on page two and click submit.

What are the benefits to doing this vs having username and password on one page and clicking submit? Is it only to avoid passwords from accidentally being put into the username field?

From a pure functional perspective, the 2 page system sometimes allows for home realm discovery (where the user has accounts in more than one system)

For example, Microsoft has something called the Microsoft Account and the Organizational Account.  The username feature allows HRD to redirect to the correct authenticating server.  This feature is live and active for all Azure, O365, and related sites.

For clarification:

LiveID, or Passport is now known as the Microsoft Account
Azure Active Directory, Office 365, WAAD, and possibly ADFS all use "Organizational Accounts"

It is possible to have an account in the form of user@company.com at one or both directories. You can test for the presence of an account in one or the other directory by checking the JSON available here

 https://login.microsoftonline.com/GetUserRealmExtended.srf?login=EMAIL@COMPANY.com

or

 http://odc.officeapps.live.com/odc/emailhrd/getidp?hm=0&emailAddress=USER%COMPANY.com


'confirm old password' OAuth equivalent I want to allow users to link/unlink several OAuth providers to their account.

How can I mitigate 'office prank' attacks, when someone can access my computer while I am away?

My account: OAuth with Facebook.

Attack 1: Attacker logins with his Google account, and links to mine.

Attack 2: Attacker clicks 'unlink' my Facebook account.

Revoking tokens as a form of 'Time-of-check to time-of-use' does not work, since the computer is already logged in with Facebook (attacker can click allow again).

Maybe fallback to using associated OAuth email (assuming there is one), and generating OTP tokens?

It looks like you want to achieve re-authentication of a user before an account linking/unlinking operation.
In your example a user would be authenticated with her Facebook login at an application. When the user (or attacker) tries to link a second social login the application would request re-authentication from Facebook. It is described here: https://developers.facebook.com/docs/facebook-login/reauthentication/
After re-authentication the app can start the account linking  process.


how to capture and decrypt packets sent over TLS I have been using MITM for decrypting https traffic , using tools like fiddler and burpsuite . Is there a way to decrypt packet sent over TLS, any guidance would be a real help.

Capture

--> Open Fiddler
--> Tools
--> Fiddler Options
Set the option boxes as shown in the image below:

Source: How do I use Fiddler to capture HTTP/HTTPS sessions for debugging?

Decrypt

If you haven't already, enable the Decrypt HTTPS traffic option, shown in the image above. You can read how to decrypt TLS traffic with Fiddler in the How come I can see full HTTPS requests via Fiddler? thread, which links to a set of instructions.


Self-signed vs. authority issued certificate for internal web services From an information security perspective, which is best for private (on-premise) micro-services (web services) accessed via HTTPS?

Are there an advantages in using certificates signed by a Third Party instead of Self-Signed certificates in such a scenario?

A third option might be to consider using an internal CA that you trust.
Remember, signing a certificate is a method of vouching for the authenticity of the host using it. A Defense-in-depth approach would dictate that self-signing not be used, particularly for microservices that might be processing production information. Self-signed essentially means the only control that needs to be compromised is the host using it.
This is similar to the idea that 'if it's on my internal network its trustworthy'. The numerous APTs have demonstrated this to be an unwise strategy.


List of notable security breaches Is there a list of notable  (i.e. those reported in the mainstream media) security issues such as hacks, viruses, worms and any other unauthorized or improper access or use of computers for malicious purpose?

A Wiki to keep track for posterity would be ideal.

A good source focused on publicly announced data loss is - http://datalossdb.org/


Is it possible for a company such as Apple to encrypt users' data such that they cannot trace identities? More precisely: is it possible for a company such as Apple to encrypt users' data such that neither they nor anyone else can trace identities while still being able to monetize demographic data?

If technology and social media companies do not want to assist governments in tracking individuals' behavior why can't the demographic data sold for advertising be encrypted such that no external source can access individual identifiers? Some thing like the key identifier would self destruct if accessed, and advertisers would be sold only access to the system.

Why doesn't Apple encrypt users data such that they cannot trace identities?

Well, if they're not supposed to be able to trace the identity of their users, the simplest solution would be to not store any user identifier with the data they collect. No encryption would be necessary.

OTOH, if they do store said identifier, then it's impossible to design a system that will allow Apple to access it, and deny legal access by government institutions such as the FBI, because Apple is bound by law to assist when lawful requests are made. They might fight such a request in court, but if they lose, then they must comply or face the consequences.

So what you're really asking is why they store personally identifyable information at all, and the answer to that is probably the one @Limit gave in his comment - it's valuable to them.