Access control allow origin browser protection efficiency I was building a website as an experiment, and tried using few ajax requests to different sites. On some sites I will get an error:

  XMLHttpRequest cannot load http://example.com/path No
  'Access-Control-Allow-Origin' header is present on the requested
  resource. Origin 'null' is therefore not allowed access.

When I opened Wireshark and seen what was going through the network, I could see that even on the sites that produced the error (meaning didn't have Access-Control-Allow-Origin in the response) the request was sent to the site. If I changed the response to include the Access-control-allow-origin: * header, the response will process as needed in my site.

My question is: If I was trying to do CSRF to the requested site, the response does not matter as much as the request does. As long the request was processed at example.com it doesn't matter if the response didn't have Access-Control-Allow-Origin header on it or not (assuming I don't care about the response, I just wanted the action to take place).

Am I correct and the protection is useless or I'm missing something?

It is important to notice that CORS is not around to solve all security issues but rather a specific one which is being able to read data from a third party resource (I am on google.com but I try to read facebook.com cookies).

Take a look here:

  The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser.

Due to the fact that CORS exists just to just protect the reading of a third party website, and a CSRF attack is submitting data, the CSRF attack being launched will probably work but you will not get any response (Again because of the restricted reading).

Note: There is nothing special here since you can launch the CSRF attack even if this was not possible via CORS. Instead of sending it via AJAX you can just redirect the user to the specific url using location.href = www.example.com/csrfhack=some_hack


How risky is using e-mail to manage passwords? No doubt there are better ways and more secure ways to manage passwords, but I'd like to make an informed decision to determine if this is just too risky.

Briefly, when I receive a "welcome new user" message, I forward that message to myself and include the password.  I know, this is basically an electronic version of post-it notes but I have a couple of good reasons for using it.  I need your help to see if these are good enough or if these are even valid.

So, the main reasons I think this way may be "ok" are:

The messages are stored only on my local machine.  After receiving
them, I make sure that all copies are removed from the server.
The (corporate) e-mail system I use is encrypted and "safe"
To gain access to the passwords, a hacker would need to be granted
    access to my machine which is less likely as it is on a corporate
    network.
If a hacker did happen to gain access, he would not likely think to
    look in archived e-mail messages stored on the local machine

So, am I just asking to have all of my passwords compromised?  Is there any way to quantify this risk?

... I make sure that all copies are removed from the server.

No, you don't. Copies may exist in backups, swapfiles, wear-leveled Flash memory, and elsewhere.

  If a hacker did happen to gain access, he would not likely think to look ...

Now he would.

Just use one of the well-reviewed password manager programs. Re-inventing the square wheel is a poor use of your time.


CSRF Bypass using User-Agent This is an unconventional approach of CSRF that I came across while doing the pentest for an Android mobile application. The original request is as follows (NB: Values have been edited):
POST /edit/ HTTP/1.1
User-Agent: example Android (22/5.1.1; 320dpi; 720x1280;
Accept-Language: en-US
Cookie: cookies
Authorization: Bearer LPT:2:bearertoken
LP-U-DS-USER-ID: 69837
LP-U-RUR: VLL
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: edit.example.com
Connection: close
Content-Length: 484

sLPned_body=SLPNATURE.{"_csrftoken":"KpQCVh7TYsfcSFS0PHP1zsiV1hxkjk3B","username":"tester123","first_name":"tester123+tester","userid":"69837","device_id":"android-456b04ea5a32050d","biography":"#tester\n#testing","_uuid":"2da6821d-c609 t-900c-9f6e-51as443280f5","email":"tester123@mailservice.com"}

When performing a CSRF an attacker can't predict the values for CSRF token, since it is validated in the request and it is rejected with an error 'token missing' even if the token was present in the request. At this point I started playing with the headers and came to know that instead of the token it is validating the user-agent. At the time of CSRF request the user agent is as shown below:
Mozilla/5.0 (Linux; Android 5.1.1; LS-5014 Build/LMY47V; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/46.0.2490.76 Mobile Safari/537.36 example Android (22/5.1.1; 320dpi; 720x1280;

But if I change the User Agent as in the original request which is the user agent of the respective application,
Example Android (22/5.1.1; 320dpi; 720x1280;

The token will accept any value and the request is returned with 200 response.
Is there any way so that I can override the user agent while I am performing CSRF?
I have never seen such a scenario anywhere else or read about it.

No it's not possible to circumvent this CSRF-protection in a classical CSRF attack.
Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection.
An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such a case the attacker wouldn't have to use a CSRF-attack to do what he wants, because XSS > CSRF.
I also found a related answer from 2016: How do defend CSRF against requests that pretend not to be browsers?
Which concluded:

"The attacker can not succesfully modify the User-Agent header unless
you allow her to do so."


Use case where MAC and DAC complement each other We can implement MAC and DAC together and they can complement each other. My understanding is when MAC is there it overrides everything. Can anyone help me understand how they can work together?

SELinux policy rules are checked after DAC rules.
SELinux policy rules are not used if DAC rules deny access first.


Security of o=rwx with classical Unix permissions Is it in anyway insecure to go o=rw or o=rwx on files and directories
confined to directories that are marked o=?

In other words, given private (g=,o=) home directory, is it perfectly safe to write everything with o=rw or o=rwx as long as all those files reliable stay within my home?

(I'm not trying to set umask 0000 -- I realize that that would open  up my /tmp files etc, but I'm writing a program that wants to do this so I'd like to know if I'm doing something stupid.)

This is not directly insecure, as long as these files and directories have the same owner than the parent directory, that there is no hard-link allowing to bypass the parent directory permissions and that there is no exception put on the parent directory permissions (like some ACL for instance).

However, I would still classify this as not prudent and not clean, as this is playing with fire. At some point in the future, most probably because of an unrelated modification linked to an unrelated software or project, the above conditions will not be met anymore opening wide the security vulnerability (and thanks to Murphy's law you can assume this will happen at the worst moment).

When writing software, you must never write unsecure code based on the assumption that it will remain protected by outer protection layers and therefore never be exploitable because being "out-of-reach". Security must be conceived as a whole where every component has to play its role to ensure a good general security posture.

So, my answer is:

For some occasional tests, most chances are this is fine and there will be no problem with this,
For some real development, please don't do this and use proper rights!


SMB/CIFS shares on HP-UX vulnerabilities So, I've run an unauthenticated Nessus scan against a critical piece of infrastructure as part of a pen-test but I'm getting back some weird stuff and i can't seem to re-create the issue to demonstrate it to the client.

The machine i'm testing is a HP-UX machine but Nessus is flagging that a specific share 'backup' can be accessed using a NULL session (Nessus pluginID 42411) and that the contents of the share are read/write (it goes on to list the correct contents of the share (confirmed with the admin)). This is exploiting the service on TCP 445.

Now generally, if I'm trying to establish a NULL session from a Windows-based machine to a windows based machine which is vulnerable I'll run the following command

C:\> net use \\hostname\IPC$ "" /USER:""

Then I can simply browse shares by simply opening up a run dialogue and going \hostname\ and I see a nice listing. Not so in this case. I can't see the contents of the share or even open it.

So, obviously this is a HP-UX machine which means that this finding is already a bit off, but none-the-less, it's still seeing stuff it shouldn't be and I don't know how to re-create this. The associated CVEs (1999-0520 and 1999-0519) do not appear to contain any useful information regarding exploiting this.
Are NULL sessions a Windows only issue or is that any Samba client?
How can I reproduce this issue either on a Linux test machine or on my Windows test machine to demonstrate the vulnerability to the client?

The other vulnerability identified by Nessus is 'Samba Symlink Traversal Arbitrary File access' (Plugin ID 44406).
It shows that it is able to read the contents of /etc/passwd and the contents are again, confirmed to be correct, however I'm not entirely sure about how to reproduce this again. According to the Samba advisory the problem occurs when a client is allowed to write to a directory (presumably the above mentioned 'backup' share) and create symlinks to local resources. It appears that this code will demonstrate the issue.

Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers)?

Make sure you are using the correct account for accessing the NULL share. This could be nobody or smbnull. (Check your smb.conf file.)

C:\> net use \\hostname\backup "" /USER:nobody

C:\> net use \\hostname\backup "" /USER:smbnull

Also try the backup share instead of IPC$ with your empty user:

C:\> net use \\hostname\backup "" /USER:""

  Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers?).

Yes, it will fix it for unauthenticated attackers. To fix it for all users, you should set wide links to no.


Inversed Data Direction on the Stack As I remember from my micro controller course, the stack is at the end of the memory, while at the begin are some interrupt pointers, program code and later data. Since the stack is at the end of the memory it grows in the direction to smaller addresses. And at every function call a new stack frame is pushed onto it. Which contains the following items, among others, in the following direction (from small address to high address)

local variables
return pointer
parameters

And as far as I know most buffer overflows, try to overflow the available space in a local variable to overwrite for example the return pointer.

So one thought of mine was, that one fundamental problem is, that data on the stack is addressed the same way, then else where in the memory. If a pointer to a buffer points to the highest address of the buffer, and the buffer's last element has the smallest address (hence in reverse order), wouldn't that help?

So my questions are:

Is this a valid thought?
Has there been similar thoughts?
What are the drawbacks thereof?

There are some architectures which use a "growing up" stack. Generally speaking, this makes porting of operating systems a bit harder; it does not seem to be that much of a gain security-wise. The convention of making stacks grow down comes from the era before the advent of MMU (without MMU, RAM is a block; the stack grows down from the end of the block, the data elements are allocated upwards, and memory is exhausted when heap and stack meet).

In the case of buffer overflows, it so happens, empirically, that most occur "on high addresses": the buffer has size 1000 but the buggy code tries to write into the 1001th, 1002nd... slots. This is related to how most programmer implement a loop: when they want to loop over the 1000 elements of an array, they loop up, with index from 0 to 999, instead of looping from 999 down to 0. For the machine, both are equivalent (in fact, in some old 8-bit computers, looping down was slightly faster); but programmers are humans with human habits, and this includes counting up instead of down, when given the choice.

This matters with stack direction because with a "downward" stack, the juicy slots that the attacker wants to rewrite (in particular the return address) are in range of "high" overflows, which are more common than "low" overflows. However, "low" overflows (also called "underruns": code tries to access slots -1, -2...) are just infrequent, not unheard of. Reversing the stack direction just swaps the roles: now, low overflow become critical.

Also, as @Polynomial explains, low overflows can also be interesting. The function return address is just one among many slots that the attacker would like to overwrite.

In my opinion, the main problem with a buffer overflow is that it occurred: the code does nonsensical things, and is allowed to proceed unabated. It is like a rhinoceros evaded from a zoo and rampaging through the town centre; reversing the stack is like: "let's move the whole town, so that the rhinoceros is more likely to run toward countryside, where it will make less damage". It is hardly a "reasonable" safety mechanism. It would be a much better idea to concentrate on not letting the rhinoceros go loose.


Malware or viruses by browser redirects? Recently was browsing and clicked on a link to the following address:

(In code blocks so you cant accidently click it)

http://paycheck-calculator.org/

Clicking on this quickly loaded 2-3 different sites before I closed the tab. Looking through the history, theres some strange urls it redirected to:

https://pc1.dntrax.com/tr?id=e9df99c1378f40ec7d84901dba2d021096c5e011.r&tk=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJwdWIiOiI1MDVjNmI4MTcxMzIwNDAyNTc1YjFkNmUiLCJ0cyI6IjA0MDcxNTE2IiwiZCI6InBheWNoZWNrLWNhbGN1bGF0b3Iub3JnIn0._2CC_feJ3B4SpjbaOzX7wv5XvMhpW5eoAU8zVikW21s

and

http://defender.error.com-dxnxcsuhcz.in.net/1/index.html?a=JCD&os=Windows&browser=Chrome&isp=Comcast%20Ip%20Services%20l.l.c.&ip=MY IP HERE&r_src=56cfd578fa7ddb7749c3f499&r_src2=&r_src3=&r_src4=&r_src5=&vcid=1b24ec59-8032-43d0-91e1-3e17a4c5bd56&r_os=&r_browser=&dfn=(877)%20429-9679&dn=%2B18774299679&clickid=d50HCFQ8A1S23FURGFRNQK7K

as well as others like:

http://www.las-vegas-attractions.com/top-10-hotels-in-las-vegas

My question is, these redirects seem purposely malicious. Without clicking on any of the content in the urls that were loaded, could malware/virus or other malicious code infected my computer or browser session?

Environment:
Win 7 64bit
Chrome browser

I'm often very cautious on what I click on because of redirects like this, so I'd like to know if my cautiousness has any logical grounds.

Existence if such redirects by itself does not mean malware in all cases, but it can be.

Very often you will find such redirects when ads gets served because ad-delivery is today usually a multi-step process with several parties involved. This is especially true with targeted ads and real-time ad-bidding networks. In such delivery chains each of the party needs to get some information about the referring party and about the original user to decide which ad to serve or which next part of the chain should take over. Because control from one party to the next party is handled through redirects these information will be encoded in the URL and that's why you'll see this long URL's with various encoded information.

The same kind of delivery chains are used with malware because here you also have the parties which provide the victims through ads or through hacked sites. And you have the parties which serve the well tested latest version of the exploit, sometimes as payed service (see also malware as a service). It is not always clear from looking at the chain if this is pure ad-delivery, pure malware-delivery or malware delivery triggered by ads (i.e. malvertisement).

While these are the main purposes for such redirect chains you will also find (usually shorter chains) for more pleasing use cases or for user tracking.


Writing exploit code that bypasses IPS detection Suppose that Network IPS/IDS can detect an exploit, however, the application server itself is still vulnerable to that exploit.

If I modify the exploit code, are there IPS/IDS which will still detect this attack?

It depends.  An IDS might detect the vulnerability, or it might not, depending upon whether it has the ability to detect exploitation of the vulnerability itself independent of the exploit payload.

In general, IDS systems can try to detect attacks either by trying to recognize the payload of an attack ("exploit code"), or by trying to recognize the exploitation of the vulnerability (the vector itself).  If you modify the payload, then you might avoid detection by the former style of signature, but not the latter.

You asked us to assume IDSs work by detecting only the former, but this is not an accurate representation of how IDSs actually work in real life.  In other words, you asked to make an assumption that is not actually accurate.

You might want to read about IDS evasion attacks.  See, e.g., the classic research papers:

Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection, Ptacek and Newsham, 1998.
Bro: A System for Detecting Network Intruders in Real-Time, Paxson.  Computer Networks 31(23-24).  Originally published in Usenix Security 1998.  See especially Section 5.3.
Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics, Handley, Kreibich, and Paxson.  Usenix Security 2001.

Finally, in general, please remember that no IDS ever guarantees to detect all attacks.  They detect some attacks, but not all.  They are far from a perfect defense.  As always, if you have the option to fix the vulnerability itself, that is a more reliable defense than relying upon an IDS to detect exploitation of the vulnerability.

These comments all apply to IPS systems as well (thanks to @Everett for pointing this out).


How to set basic defense on Nginx-CMS? As an Information Security amateur I did all in my might to protect my Ubuntu-Nginx-CMS (WordPress) environment from BFAs, MITMs, and database injections.

sudo add-apt-repository ppa:certbot/certbot -y && apt-get update -y && apt-get upgrade -y
sudo apt-get install zip unzip tree unattended-upgrades sshguard postfix \
nginx python-certbot-nginx mysql-server php-fpm php-mysql php-mbstring php-mcrypt -y
sudo ufw enable && ufw allow 22/tcp 25/tcp 80/tcp 443/tcp 9000/tcp

To prevent MITM attacks, generally all data transmission of all sites is via TLS, via a Let'sEncrypt SSL certificate (Green padlock in browser for all pages).

To prevent CMS DB injections I've enabled frequent updates via *nix cron (and kept forms minimal):

0 1 * * * for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp plugin update --all --allow-root; done
0 2 * * * for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp core update --allow-root; done
0 3 * * * for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp theme update --all --allow-root; done

But it seems I didn't do anything against DDoS. What can I do against someone who sends a robot to load my webpages about 50,000 times per hour (or something of that sort)?

Is there something that can be done directly form Ubuntu/Nginx/WordPress or by some Linux software?

Notes:

AFAIK, BFA, DBI and DDoS are the 3 most common types of attacks DoS attacks (to be distinguished from MITM which isn't a DoS attack). Sorry if I missed anything.
I ran a search here in Information Security StackExchange with the phrase Nginx Ubuntu DDOS but didn't find a thread session this.

I think your conclusion that brute force, SQL injection, and DDoS are the most common types of attacks doesn't include some of the other significant attacks.  XSS and CSRF are also notable, (see the OWASP top 10) and without doing detailed research into each type, it would be hard to know which is most prevalent.

General system hardening makes sense first:

Only allow public-key based SSH into the system.
Limit the inbound connections (as you've done with firewall rules)
Ensure each service runs as an isolated user.
Limit Unix permissions to the minimum necessary (0700 on directories, 0600 on files).
Where possible, remove write permissions to folders (limits possibilities for uploading malicious code)

Note that, since you're using nginx instead of Apache, some of the directives from the .htaccess file supplied by Wordpress should be enacted as equivalent nginx directives: e.g., preventing PHP execution anywhere user files are uploaded, limiting access to sensitive files.

For Wordpress specifically, I would review the Wordpress Hardening Guide.  Some specifics come to mind:

Use as few plugins as possible, and (if possible) review them for vulnerabilities.
Ensure that custom theming does not introduce XSS vulnerabilities.
If it's very important, consider a 2FA plugin for Wordpress to minimize the risk from brute force or password reuse.

If you're concerned about application-level DoS attacks, you can rate limit in Nginx.

Without more infrastructure (Cloudflare, Loud Balancers, etc.), you'll be unable to mitigate pure volumetric DDoS -- it's just a fact of the internet that if your attacker has more bandwidth than you do, you will lose.  These include attacks like reflected DNS/NTP DDoS, IoT botnets, etc.  Basically, any attack that allows the attacker to send more traffic than the internet connection of your host (all the way to the virtual interface on your VPS) can handle.  While Digital Ocean and other hosts have considerable bandwidth, your single VPS will quickly be saturated around (or before) 1 Gbps.


Securing clients side scripts Most browsers allow users to view the source of a web-page quite easily and modern even provided detailed analysis. Often this code includes critical client side scripts in the form of JS/jQuery, which now days often contain methods and structures which can expose the internal architecture of the a web-service to a possible user with mala-fide intentions.

In such a situation, is it possible to protect your clients side scripts from user views?
Also, why haven't browser developers considered offering some security tools on this front?

Thanks!

Any protection that is implemented in user-level can be relatively easy defeated. Most often is used so called "obfuscation". It can be time consuming to deobfuscate such script if to do it by hand. However, there are several tools that automates this process, example - https://addons.mozilla.org/en-US/firefox/addon/javascript-deobfuscator/ Best solution is to implement protection in interpreter itself, at bytecode level, like Zend Guardian for PHP (even it is bypassable). I suppose, for JavaScript this cannot be done due to many JS engines implementations, parser engines differences, etc. Additionally, it would require loading modules that have to be distributed by protection vendor. This is hard and not transparent process.

I have seen interesting protection in malware, in that case JavaScript code was protected with RSA and used key from the server. But again, it is headache for developer to support such process. Probably for malware writers it was worth to protect their exploits against AV's, lurking users, researchers.

Additionally, you can read related topic here: https://stackoverflow.com/questions/964652/javascript-protection


Pictures saved to computer without owners knowledge and/or use of comp in a week How can images be saved to someone's computer - in their pictures folder - without the owner's knowledge or use of the computer in over a week?

I cannot find anything about this happening anywhere or how it could happen. The only people who have access are me and my fiancee, and I don't use his computer since I have my own. So, how is it that an image can be saved into the pictures folder on the computer without my fiancee knowing about it?

A simple explanation is that a cloud backup app is set up on the PC and will sync files which are loaded to the cloud (such as dropbox, box, onedrive, google drive, etcetc) by also copying files down to the PC.  If you want a more detailed answer you are going to have to provide more info, though.  Was the PC turned on or off? Why do you suspect it wasn't him? What is the source of the proof that the files were placed without his intervention?


Are firefox bugs cross platform? I use Ubuntu and last firefox version.

I opened an image with firefox, and a crash occurred.

Let's assume it's a crafted jpg to run an exploit, and execute arbitrary code.

To sum up:
(1) Firefox opens a crafted JPG ->(2) Firefox crashes ->(3) Arbitrary code try to run

--

Step 3:
According to Are exploits platform dependent?,
exploits are platform dependent.

My question is about step 2:
A bug is the origin of the crash. The crafted jpg uses this bug.

Can crash occurs on every platform ?
If yes, so it will be harmful only for one OS ?

Thank you

Exploits are typically platform dependent, although the vulnerability might not be.

In this case it depends on whether the crash is in firefox, or some underlying library.  If we're talking about a JPG for instance, the crash may be resulting from an error in libjpg, in which case it is probably not going to be cross platform.

However, if the crash is in some firefox specific code that is cross platform, there is a chance that the vulnerability will exist on multiple platforms.  Whether or not the vulnerability can be exercised to produce RCE is another question though.  There are a lot of variables in this case, including the compiler, the optimizations done by the compiler, stack layout, possible calling convention differences, the heap allocation algorithm used by the OS and many other elements.  The crash may exist on both systems, but it is possible that only one is reliably exploitable.  It may also be the case that one operating system is exploitable by this single vulnerability, while the other might be vulnerable when another vulnerability is exercised in conjunction with the original bug (think memory disclosure or arbitrary write bug).

In the case that the vulnerability exists on both platforms and can be exercised, the exploit code and shell-code will likely be very different.  Assuming at least one of the operating systems uses DEP, your ROP chain is going to be very different, as are the locations of the ROP gadgets.  If exercising the vulnerability requires any kind of heap grooming, you are going to find that heaps vary greatly between different operating systems, and even between different versions of the same OS.

There is not simple answer to this question, as it is highly situation dependent.  In theory though, it is possible for cross platform code to contain a bug that is vulnerable to exploitation on multiple different platforms.  It is much less likely though that the procedure used to exercise the vulnerability will be the same.


Does plaintext reach protonmail server? I am quite happy with, indeed grateful for, protonmail.  There is one point I'd like to understand better regarding end-to-end encryption.  I asked this twice at protonmail.com, and twice it was removed by the moderator. I hope someone here can answer.

I infer that an outgoing message is transmitted via https to the protonmail server where it is pgp-encrypted and the plaintext discarded; the reverse for incoming messages. Is this basically correct?

If so, then "end-to-end encryption" doesn't mean quite what I thought, and I would like to know a little more about how the plaintext is handled by the server.

I don't distrust protonmail.  I understand that if I felt the need I could  download public and private keys and encrypt locally, but then I might as well use gmail.

Server never receives plain text, which is very easy to verify. Log int to your protonmail and observe all communication which browser does with server.
at some stage you will see message like that

{
   "Message":{
      "ToList":[ ...],
      "CCList":[ ...],
      "BCCList":[...],
      "Subject":"test",
      "Unread":0,
      "MIMEType":"text/html",
      "Flags":0,
      "Sender":{...  },
      "AddressID":"pzS3cXCi2Aky0EgfL89rRoI6W2t1RyhlMiIP6_4lVQCtRA4f2yj6ULUB7bJ9KAvoW6Ql1plW1sBtgf1XKZryXQ==",
      "Body":"-----BEGIN PGP MESSAGE-----\r\nVersion: OpenPGP.js v4.6.2\r\nComment: https://openpgpjs.org\r\n\r\nwcBMA+jYaqQbPJMUAQf+PsXHCJBAW44WqhzMWXjH0iwgDoCIstEmlm66OLZX\r\nCBHNtnLRR1lKxUiXyJNu3lHg3Z6XonawnHbM8vlDG7F6h/Iam7VujbeXjh3d\r\ndr9IdpRzE0ONA9vET04+qDCR+49ESG3tXI94qFYqh36BHi81+ro426JVz8Z4\r\nPoxu6PRpZWMvtYikDOayM25fQooDVH9AOu6qxncMY2DSKMjsS/RxLzB7iYSC\r\nCOPgdjbGWXQWcOW4UKwn24btRadyQc+7JzF93wn1aH3YFN5fVD1hQzSiYNnZ\r\n4T2+aV4RxM1cv8Rbvc3JpYNfzg+zbgQoI82mfQuyLLU3A82ap2T9YefXi/T0\r\nvdLpAVWTcy3DJOlSKNpOE6Xp711wUcey7Uaaw1b9sXaiwhLLR8LdRoE9HIsw\r\nas/z7Gh8gzH1RawavsIOBntN5H72FpddNtxLo18/B0dna38NeDLaM4zMmXj5\r\nytR5yqHZopbftDaWXxG8p1aP7CnEQyEusU9/yUH4Ah1mxlYDDEJDGZhl0ECv\r\n8ipBYzo4iewygpA7yLCf6fEXh0PgbXq3I0TD7Lr6WRodHGRO8b2X0RyawY94\r\n8h2kaxw0awXf1DqR4CIqS99wOmQIUGugrOfEHTaXxHKdFmxJL3z6NbgEbMvs\r\nq9ZJfeOgnxhcpg79CvetohnRW91z9XospN4IwJfUcHQZk3TPqzTVJy13Vs+P\r\n0Cw+OHK6Vej/FkiubRAVguJmmF4STy5z/0AecR1ZPsxFrjX/InvbOPaMdsCw\r\nezcCD8tHvkc1oTpGTZ6ktCDOhR17w5qru5xWtBPJFtdWi3Sk5Ux94yYR3rpU\r\nx+dAU9v9+LK0PumzMQqrWmpnbZyw4yp4jTB0VmQ4YtQGmXEr/t5iI3BnNhV9\r\nwZuqK7zA1EKJGe+76URE1OGsJwkldfL4Q/0u5FJbpGnfSZsMlwbHJOj5VkVe\r\nFPtJOCsOxBtpk/aKP+jm0OmZDNyDuYtfGHU9X3hPJDTom5lcL4B0ml433lvS\r\nZJ4jnnZxKPo+hT9DzpxeIbnPeJQjRsRDfowRsPb2KGIFQxeyHagmDNcVBK1L\r\n4A0KdpvKh2Yo16E=\r\n=he+D\r\n-----END PGP MESSAGE-----\r\n"
   },
   "id":"harAqr3eDuzKm0qAFFI3fDrbtU4F_kvPxKRzPfEHTJfl5duG6e8huhP7VyhopXX-gHZx1nclEP6RXMzT4oDbRA==",
   "AttachmentKeyPackets":{}
}

If you look at section Body you will noticed it is encrypted using PGP before send to server.

Yes, if you have keys, then you could decrypt this message on your own.

Using Gmail instead proton mail will not give you key benefit which proton mail does. This message is passed to back end encrypted which indicates, it will be stored in drafts as encrypted, which won't necessary happened in case of Gmail.


Why do administrators create passwords vulnerable to kerberoasting? I was researching a kerberoasting attack on the Active Directory domain. To create the stand, I used a Domain Controller on Windows Server 2016 and one client machine on Windows 10. SQL Server was installed on the Domain Controller which was launched from a sqladministrator account with Domain Administrator rights. The sqladministrator was given a simple password that can be easily attacked by brute force. But by default, the installer of MSSQL Server 2014 offers to create special accounts that cannot be attacked by kerberoasting.
Why do administrators continue to create such vulnerable passwords, even if the default installation of the SQL server avoids it?

What is the motivation for administrators to launch services with SPN
from domain user accounts?

There are five ways you can set these things up:

Local service on a workgroup machine
Local user on a workgroup machine
Local service on a domain joined machine
Domain user on a domain joined machine
(g)MSA on a domain joined machine

There is a collective belief that running things as local service accounts (SYSTEM, NETWORK SERVICE, etc.) are bad security practices. This is misguided in some ways and accurate in others. It forces the service to operate as the machine account on the network and rightfully gives the service full control over the machine. If it's a single-use machine then having it operate as SYSTEM is actually more secure because you only have to worry about the machine identity on the network, not machine plus service account. Incidentally machine accounts tend to de facto have fewer permissions on a network because no one every really thinks to grant special privileges to machines.
Conversely if it's a multi-use machine then running it as SYSTEM puts you in a tricky spot because attacking the one thing can cause an attacker to take full control and then easily take over the other things running on the system. Multi-use machines used to be quite normal back in the day, and still are in smaller environments.
This is applicable in both workgroup and domain scenarios but obviously the machine doesn't have an identity on the network in workgroup so that's one less thing (at the loss of manageability).
Given the above belief people tend to just say screw it and make a dedicated service account. Someone makes a claim about SYSTEM, someone else believes them, yet another someone else writes it down, one more takes it as gospel and the cycle viciously repeats itself. See Monkeys, bananas, ladder, spray as a fake and contrived, but convincing, example of how this works in life.
As for why people then give weak passwords for these things? Because they a) don't know any better, or b) don't care, or c) both. Getting people to use good passwords is hard. Like really really really hard.
And for why people don't use managed accounts: because they're poorly documented, people don't understand how they work, only a handful of things support them natively, and most of all people just don't know they even exist.


How do I stop attack on my email id from hackers? We have an email id, info@<ourdomain>.com This email id is being hacked frequently and mails are sent from this email id, Following is the example of one such email.

From: info@<ourdomain>.com [mailto:info@<ourdomain>.com]
Sent: 20 October 2014 03:00
To: info@<ourdomain>.com
Subject: Starten Sie Ihre Karriere mit unserem Unternehmen!

Wir begrüssen Sie und möchten ihnen die Zusammenarbeit mit unserem Team anzubieten und erzählen über unsere Arbeitsbedingungen.

Erstens sollen Sie keine Beitrage einrichten um bei uns zu arbeiten.

Das ist eine gute Gelegenheit für die Rentner, Frauen im Schwangerschaftsurlaub,oder für diejenigen, die von den Stressen,
der Hektik und der Konkurrenz loskommen möchten,
oder für diejenigen, die eine Möglichkeit suchen, Teilzeit zu arbeiten und zusätzliches Geld zu verdienen.
Sie können ihre Arbeitszeit von 2 bis 8 Uhr variieren.

Ihr Gehalt beträgt 3500 Euro und Bonus.( Es hängt von den Arbeitsstunden ab)

Wir arbeiten von Montag bis Freitag von 09.00 Uhr bis 18.00 Uhr.

Für weitere Information schreiben Sie bitte uns per E-MAil:Laurenz@bamfde.com.

Translation given by Google Translate is,

Subject: Start your career with our company!

We welcome you and want to offer them the cooperation with our team and tell about our working conditions.

First, you should set up no contributions to work with us.

This is a good opportunity for the pensioners, women on maternity leave,
or for those who want to get away from the stressing, the bustle and competition,
or for those looking for a way to work part time and earn extra money.
You can vary their working hours 2-8 clock.

Your salary is 3500 euros and bonus. (It depends on the working hours from)

We work from Monday to Friday from 09.00 bis 18.00 clock clock.

For more information please send us an e-MAil: Laurenz@bamfde.com.

How to stop these kind of frauds? How to secure our email ids from these kind of fraudsters. We have hosted our website in justhost

Update

Following is the raw email header,

Return-Path: <info@<ourdomain>.com>
Envelope-to: info@<ourdomain>.com
Delivery-date: Sun, 19 Oct 2014 14:07:51 -0600
Received: from [78.41.168.158] (port=28228 helo=rev-78-41-168-158.radiolan.sk) by just68.justhost.com with esmtp (Exim 4.82) (envelope-from <info@<ourdomain>.com>) id 1XfwlZ-0001B6-Re for info@<ourdomain>.com; Sun, 19 Oct 2014 14:07:51 -0600
Message-ID: <7B28D9A1FC8A5084D7265E0375AF7B28@KJAK166XR7>
From: <info@<ourdomain>.com>
To: <info@<ourdomain>.com>

Subject: Starten Sie Ihre Karriere mit unserem Unternehmen!

Date: 19 Oct 2014 22:29:44 +0100
X-SpamFlt-Status: Not Detected
X-KASFlt-Status: Status: trusted
X-KASFlt-Status: Rate: 0
X-KASFlt-Status: Lua profiles 67777 [Oct 15 2014]
X-KASFlt-Status: Method: white email list
X-KASFlt-Status: {received from trusted sender <info@<ourdomain>.com>: white list}
X-KASFlt-Status: {RECEIVED: dynamic ip detected}
X-KASFlt-Status: Version: 5.2.1
X-KASFlt-Status: {Bot: susp-dmspammer}
MIME-Version: 1.0
X-SpamFlt-Phishing: Not Detected
Content-Type: multipart/alternative;
                boundary="----=_NextPart_000_01A0_01CFEC48.7E068270"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16807
X-Identified-User: {0000:just68.justhost.com:local:local} {sentby:Delivered locally}

Update 2:

Because of lot of spam mails sent from our email id, info@<ourdomain>.com, our email ids from this domain and our domain gets blacklisted. How to stop this?

This is because SMTP does not offer great spoofing protection, so typically you can connect to a server and claim to be someone else. The best way to fix this would be to set up an SPF record with a hard fail, which is expressed using a- and typically is at the end of the record as -all. You would have to be certain of where your emails are coming from. You can use other domain names or IP addresses for this. Below is an example of the TXT record you'd need for SPF. There are many how-tos available. If you are concerned legitimate messages will be dropped, you could also enable DMARC reports before actually turning on a hard fail, and instead using the soft fail which is expressed as  ~.

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"


How Honeypot and Greynet are different? From what I have read about Greynet is, when we are talking about greynet, we are simply placing darknet inside network to monitor if someone is performing network scanning inside our network.

These are the photos that I found for Greynet implementation,

Source: Greynet and Darknet

Now, If I talk about honeypots, and as far as I understand, they are kind of a same thing. We place fake virtual hosts in our network to monitor if someone is performing any sort of network scanning.

So, what make honeypots and greynet different from each other ?

The difference between a honeypot and a greynet is in the level of realism and interaction that they present and also the type of network element they present. A honeypot such as Honeyd will typically present a greater level of realism than a greynet since it could really act like a host would. Different ports open, OS faking etc that accommodates a greater interaction with the potential attacker. A greynet will simply be an available range of IPs than should receive no traffic and will offer very little interaction to the attacker. The admin knows there should be no traffic on that IP and thus knows there is either a misconfiguration in the network or a malicious entity at work. In summary

A honeypot is typically:

A single IP on a network representing one host
Can offer a great level of interaction to the attacker

A greynet:

Is a collection of IPs on a network
Can offer limited interaction
with the attacker but not to the extent of a honeypot

If you would like to know more on how greynets fits into the field of network telescopes and network monitoring I suggest you read Section 2.5 of Professor Barry Irwin's work PhD thesis. He presents a small taxonomy of the different types of network telescopes such as darknets, dimnets, greynets, black-holes and sinks.

It is available here: http://www.researchgate.net/publication/265121255_A_framework_for_the_application_of_network_telescope_sensors_in_a_global_IP_network

Please bear in mind that my answer is based on normal interpretation of the terminology. Someone can implement honeypots on each node in their greynet or customise their greynet with additional functionality.


What security resources should a white-hat *developer* follow these days? What sites, twitter accounts, FOSS software should a white-hat code 'hacker' follow these days?

Do Include:

Late breaking information on new security issues (RSS, Twitter, etc)
A website that tracks unpatched security issues per vendor
Twitter accounts, blogs, etc from well known people in the information security world.

Who are these people?
What are they known for?

Communities that publish information regarding zero day exploits

Blogs, twitter, conferences, chat rooms (irc)

A subject matter expert that provides up to date guidance on Cryptology (algorithm, key length, etc.), and up to date information on how secure each one
Open Source Software & tools that assist developers interested in the security space
Information regarding bills and laws that apply computer hacking in the US and abroad (preferably in language a programmer would understand).

Would probably include CAN-SPAM act, and per-state privacy legislation

A site that publishes an exhaustive list of XSS techniques and permutations; and hopefully code that you can use to protect yourself

Please, Do NOT include:

Guidance that is common among the infrastructure and network support groups

An exception would be the recent ASP.NET security issue.
Any list or notification that doesn't focus on code or programming.

Software and tools that aren't open source
Deployment checklists (especially if there is no code associated with it)
General forums and discussion lists, unless they are well known and trusted by the security community

Since readers are likely not an expert in all these areas, please let us know a little about each link and not create a "dumping ground" of links.  Do make an earnest attempt to not post duplicate links.

Since this is "security".stackexchange.com I hope to get a more diverse range of responses than the typical sysadmin site.  In my experience, sysadmins stay away from code, and developers really have no fear when it comes down to the wire.

For conciseness, I'll only add two:

OWASP's moderated blog - they aggregate quality posts from a lot of diverse security feeds, mostly around new attacks, vectors, etc.
Microsoft's SDL blog, mostly focusing on remediation strategies, mitigation, threat modeling etc, and also once in a while a very open, honest analysis of discovered security flaws and the effect (or lack thereof) of the SDL.
(Soon I hope that http://security.stackexchange.com will be considered a top offering... :) )


Encrypt Text Message as Image Is this a good idea to make the following text message encryption:

accept text from the user 1
store the text into a document in the form of some handwritten font
convert the document into an image
apply noise to the image
encrypt the image somehow (hide the fact it is image)
send the image to the user 2
show the image to the user 2 as image

EDIT. My purposes:

Avoid existing widely used smartphone messaging apps, which could be which can be monitored by law enforcement agencies.
Make a simple own secure messaging application to just text exchange p2p
Be sure (as far as possible) that our messages will not be automatically intercepted by standard means used by law enforcement agencies. I don't know that standard means, and also can never know for sure
Provide greater resistance to interception than existing widely used smartphone messaging apps at the expense of some inconvenience

example:

The cryptography in existing apps is usually strong enough. This means that the focus of attackers (including law enforcement) is not to break the cryptography but to compromise the endpoints to get access to the messages before encryption or after decryption.
Your approach does not actually protect against this main attack vector. Instead you add some obfuscation by using an image and some noise. But this isn't actually sufficient to hide the message against someone who compromised the endpoint - especially if the message is intercepted already before obfuscation or after deobfuscation.
The only other obfuscation is to use an atypical application for communication. But if you are the target of an attacker who was able to compromise your endpoint, then this does not help much either. It is simple to check what applications are installed and then have a closer look at suspicious applications and their activity. This is assuming that your device was compromised since you were an explicit target, this means the attacker is actively looking for something interesting on your device.
In other words: it is probably not a good idea. At least it does not really help you to achieve your ultimate goal, which is to protect your communication from a highly capable attacker like law enforcement.


How to prevent user's mobile phone position tracked Trying to follow up this post How to trace a (mobile) phone? , the answers on how to prevent being tracked while you own a mobile phone are: You cant. (even if you use disposable phones etc)

1) Why a similar concept as Tor project wont work in this scenario? (all the nodes /towers are controlled by people/ a company that does not want to participate?)

2) Few start ups will start selling mobile phone subscriptions by utilizing Wifi connections. Will this be a way finally , a way to protect against tracking ? (At least in towns , and assuming different people control the AP)

My question comes as it is difficult to believe that so many billions are spent for online privacy , creating new encryption algorithms etc etc, but with a few hundred dollars equipment you can intercept calls , and all companies can track you down.

Your question presents a number of interesting issues. I hope you are asking this question out of general concern for your privacy and not for an illegal purpose.

First and foremost, what countermeasures (if any) you would use depend on your security requirements. Your level of paranoia/fear will vary according to whether you are seeking to avoid detection for activities that are merely embarassing (i.e. cheating on your spouse), or mildly criminal (you sell bags of weed to your classmates) or very criminal (you are a member of the Mexican drug cartel). An adversary in a civil lawsuit might be able to subpoena your cell tower records; it would be trivial for a government agency such as the DEA or NSA to get these records if you were of interest to them.

Phones that connect to the cell phone network must connect through a cell site, and the location of the site is recorded and correlated with the serial number of the phone. Many phones can be used without connecting to the cell phone network by using only public wi-fi connections. Telephony apps exist for phones having only wi-fi connections. However, your phone might generate and transmit GPS coordinates (attached to Tweets or Facebook posts) and the phone's location would be somewhat trackable by IP address.

The DEA and NSA are known to be able to detect the use of a newly acquired "burner" phone by correlating metadata among the people you regularly contact. If you are in contact with the same phone numbers as with your old phone, for example your fellow gang members or dope dealers, it is trivial for a law enforcement or intelligence agency to discover your new phone. A CIA official recently gave a presentation in which he stated that phones can be tracked if turned off provided the battery is still attached; and that some phones having kinetic input can be tracked according to the user's gait as she walks down the street!

The key question here is whether it would be worth your while, or that of your associates, to use unusual or "tinfoil hat" methods of attempting to mask your location or the phone's serial number. Unless you are doing something that is certain to attract serious law enforcement interest, and even if you are, you are probably better off not attempting to use methods such as using and repeatedly switching "burner" phones. You might well become more visible than if you did nothing.

Finally, don't forget that your movements can also be tracked through fixed and mobile license-plate recording cameras, and GPS-based vehicle systems such as OnStar. It sucks to be a criminal, or to value one's privacy, these days.

For legal advice consult a licensed attorney.


Replace PATH space with random string I came across
http://test.co.uk/img/rOTJwSOqWzHaDsEUcHhI.

If we take a look at it the directory space is protected against bruteforcing of the whole directory to explore private images.

I don't know the official name for this and want to implement it on my own domain, is there an official paper for to do this?

Depending on your server, you might be able to disable "directory indexing", which means a person can't list out the contents of the directory. Alternatively, you can place the private images outside the document root. Create the url with a token. For the image request, use the token to look up the real image location and provide the real image.

If the token is something easily guessed, your attacker can still find the images. For example, if you use simple number like 1, 2, 3, 4, 5, I could easily guess that 6 might be a valid token.

If you use a hard-to-guess directory name, but include that in the url, that hard-to-guess name is now known.


is browser the only app that can set supercookies? I'm trying to identify a if a website uses tracking cookies beyond ordinary cookies, that get deleted when I click "Delete cookies".

The work plan is to run a clean virtual machine, use a software that monitors system activity and visit website. The activities in question are all write activities issued by the browser I am using.

This leads to a question. Is the browser the only app in my computer that can store supercookies and is therefore the only app that should be monitored if I have Flash,Silverlight,Java Applet disabled or should I also monitor some other apps? Thanks

I'm not sure how well defined app is in this case. Depending on which browser you are using, it is a collection of one or more processes. Browser plugins and extensions may or may not be running in their own processes.

If you assume that a supercookie isn't utilizing an unpublished browser vulnerability, then only the browser process, and processes that it communicates with, can store supercookies locally.

Regarding plugins and extensions, many of them make network calls so it is theoretically possible that they are tracking your information remotely. In that scenario, they would use some unique ID for your computer (maybe your MAC address) as the key into the remote database.

Generally, the best way to avoid tracking is to run in the browser's incognito or private mode. These modes are designed to prevent tracking of all types.


Track lost Android phone, if the thief is using it to access internet I had a Samsung Galaxy S3, which got stolen recently but didn't have any built-in tracking software.

But since the theft my friends often see 'me' on many online mobile chat applications. I conclude from this that the thief is using it to access internet.

Is there any way to track my phone from this information?

Is the thief using your SIM card? If so, then you know the number and can inform your mobile service provider / local law enforcement, who will be able to track the phone based on cell tower proximity provided it is switched on.

If you want to track the phone based on IP, then you need access to the server logs for the chat services your phone is automatically logging into. From there you will be able to get an IP Address for your user account, which can be used (again via the mobile service provider) to identify the device and track its location.

Both approaches involve law enforcement. So the bottom line is: call the police.


Why does DNSSEC have a ridiculous keysigning ceremony? Every three months, 7 people fly to a secure ICANN server building and go through an elaborate ceremony to generate a new signing key for DNSSEC.  The entire affair appears to be based on politics and not any real security model.  If the private keys have not been compromised then no-one else can sign any records, regardless of their control of equipment external to the signing server.

If you are front-loading all of your trust in having the private keys protected, why wouldn't they just ensure that the signing server itself would self-destruct if it was tampered with?  You can protect against anyone fiddling with the inputs/outputs by placing 3 of these tamper-proof boxes in different locations world and synchronizing their output.  They could be housed in a UN base or a location where the security is jointly handled by countries with semi-adversarial relations (like China and the US) and monitored via a webcam.

Keys would only need to be refreshed if one of the servers goes offline for any reason or if hardware upgrades are needed.

In theory, you're probably right.

In practice, you need to test all the policies, processes and tools regularly, else you don't know if the members involved are capable of executing the procedure.

From personal experience, there's a serious problem with authority and capability in key management.  People who have the authority don't have the capability, and people with the capability are in high demand and don't stay around long enough to be depended upon.  Even people with the capability and authority often don't have the diligence to keep up with the requirements.

Try handing your boss a USB key and tell him "you have to put this in your home safe, safety deposit box, or whatever.  You have to make sure that it doesn't corrupt over time, but that it's offline.  It's vital that you pass it on to whomever replaces you."  Don't ask him for that key or talk about that key for two years.  Then after two years, in an emergency, ask him to fly out to some datacenter with the key.  Or worse, ask the guy who replaced him.

Now you need 5 of 7 similar bosses around the world to show up and provide their keys.

By executing procedures periodically, you ensure that the processes are at least on people's calendars and on people's minds.  There's logs in the audit books and mistakes in procedures can be corrected.

N.b., I don't know much about the DNSSEC key signing ceremony, only skimmed the docs a couple times, but I do have experience managing key signing ceremonies and in security policies.


Is reflected XSS still relevant today? I've been learning more about XSS (for the unfamiliar, Excess XSS is a great resource). I opted to get my hands dirty and give Reflected XSS a try on a local environment. I set up a very simple vulnerable PHP page running on Apache2 which takes a URL parameter and dumps the contents into the page:

<!DOCTYPE html>

    <title>VULNERABLE WEBSITE</title>

VULNERABLE WEBSITE

Search results for <?php echo $_GET['query']; ?>:

Then, I attempted to get 'malicious' JavaScript embedded into the page using a URL such as the following:

http://localhost:8082/?query=

I found that the browsers themselves prevented this from happening. In Firefox, this took me to a Google Search page. In Chromium, the XSS was specifically detected and blocked:

So, going from theory to practice, I am now wondering: is Reflected XSS still a relevant security concern today?

This obviously does not apply to Persistent XSS where the malicious content is served directly by the website itself.

Reflected XSS is not only by GET. It can be by POST too. And they are not prevented always by the browsers. And of course, is still relevant.

A couple of definitions:

https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
https://www.acunetix.com/websitesecurity/xss/

And from Checkmarx knowledge base, it says: "The most commonly found XSS". Extracted from here. So if is the most commonly found I guess is still relevant.


SSL Finished message contents I'm a little bit confused about the contents of Finished Message used during Handshake Protocol. In particular, this message (clientside) contains the connection-id originally sent from the server and it also contains a hash value derived from all previous handshake message and master secret.

So this message is encrypted with a key derived from master secret or only connection-id is encrypted, and Finish Message is still transmitted in plain?

Another question is about detecting replay attack serverside. The server receives Finished Message from client; how can server correctly detect a replay attack from Finished Message and why we use connection-id and hash only one isn't enough?

There is no "connection-id" in the Finished messages. For that matter, there appears to be no "connection-id" concept at all in the whole SSL/TLS standard. The closest concept is that of a session ID, which is exchanged through the ClientHello and ServerHello messages, not the Finished messages. By definition, the session ID is not specific to a single connection.

The contents of the Finished message are a hash computed over all the previously exchanged handshake messages, in both directions. The Finished message being sent after the ChangeCipherSpec, it is protected with the newly negotiated cryptographic algorithms and keys, i.e. encrypted and MACed.

The protection against replay attack relies on the way the Finished message contents are computed: since the hash is done over all handshake messages, it includes, in particular, the client_random and server_random elements sent by both client and server. An attacker trying to do a replay cannot reuse both randoms, because, by definition, the attacker is replaying the client while talking to the genuine server, or replaying the server while talking to the genuine client.

As a SSL walkthrough, I recommend this answer.


Why would a website that resets your password to one of their choice be considered a plain text offender? What's wrong with generating a password for you without storing it?

Like why is MasterCard on the plain text offenders list?

Because most users do not change their password after such a reset and mindlessly instruct their browser to save the new password and/or the site does not force users to change it after their first login.

Thus they effectivly send the new password in plain text, thus they are offenders.

A better way may be a One-Time-Token for a password reset, preferably sent via snail mail or SMS.


Program or method to create an encrypted bulk file container I have several hundred gigs of data that I store on a NAS for my own usage. The NAS storage solution manages local encryption, however I am looking into cloud backup solutions for disaster recovery. To that end, I am looking for a way to create a bulk file container (like a zip or tarball) and a piece of software that will let me encrypt said container using a keypair.

I am looking for a solution that meets the following requirements:

Cryptographically secure (obviously)
Able to handle large input files; the data in question is many hundreds of gigabytes with individual files as large as 50GB
Can output a single, portable, file container for easy upload
Has the option to use a key file for encryption

Note: something like Vera/Trucrypt's encrypted volume containers already occurred to me. The problems are twofold:

A portable volume file cannot grow/shrink to fit my data
I am looking to encrypt existing data so I don't want my backup utility to have to first decrypt a portable volume, copy data to it, then re-encrypt it for upload

Note 2: This question and this question, while similar, do not provide an option for using a key file rather than a passphrase.

EDIT: As an alternative, maybe I am off-base and using a key file doesn't get me any more security than a good implementation and strong passphrase. If that's the case, I'd love to learn why.

If a zip/tarball is an option for you, you can try using PGP to encrypt/decrypt your backup.

PGP uses key pairs for encryption/decryption.

gpg -er <email> -o <encrypted_archive> <raw_archive>

The above solution does require re-encrpyting the whole archive...

If you want file system behavior to allow adding/modifying files, without re-encrypting the whole output - You may want to try eCryptFS with tar for incremental backups (and then you can just use tar to update modified files).

tar -uf myarchive.tar ~/.ecrpytfs/


Do my router and OS "know" which URLs I visit, if SSL is used? Is it possible for a router or an operating system to get access to URLs I visit in my browser, if SSL-encryption is used between a browser and a webserver?

The full URL is protected by the end to end encryption of HTTPS, but the target IP and hostname (the full name of the host, i.e. FQDN, i.e. something like
www.example.org) are not. Thus the router could get the name of the host you visit but not the full URL (i.e. not the path after the hostname):

 https://www.example.org/some/secret/page.html
         |-- visible --||---- protected -----|

An application on the same OS as the browser might be able to get the full URL if it has the same or even more access rights than the browser and could thus inject code into the browser process or read internal data from the browsers memory. By injecting into the browser it could even not only read the full URL but has access to all the other transferred data and can modify these. This is for example done by malware targeting online banking.


SSL's (security) benefit to the website owner I know the many benefits of SSL for the users of a website. It creates a contract whereby the user can be certain that the entity they're transacting with is who it claims to be and that the information passed is encrypted. I also have some idea about other benefits (e.g. speed benefits from HTTP/2).

But something I was wondering recently was whether the website benefits in a similar way from this transaction. That is, does my website become more secure from attacks if I enable SSL? I suppose because I would also know that the client I'm transacting with is certified and information I send them is encrypted. But can't any client act unethically and access my website with self-signed certs, etc., claiming to be whoever they like?

By the way, I've come into what knowledge I have in a self-directed way, so if this is a basic question or an XY problem don't hesitate to point me to elementary resources or set me straight.

Edit: For everyone continuing to answer or comment with general reasons to use SSL: these are appreciated and no doubt of use to new users. That said, I do make it a part of each website I set up, and was curious specifically about the security benefits. In SE tradition I just want to remind people to keep to the question if possible. (Sorry about the title originally missing the key qualifier!)

It prevents the ISP from injecting their own ads in place of your own. If you rely on advertising for revenue, https helps protect your revenue stream.


What are the alternatives to door passcodes? Passwords have been a problem since the dawn of computing. They tend
  to be either so complex that no one can remember them, or so obvious
  that anyone could guess them.

  ...

  Some users choose to write their passwords down on paper and keep them
  in their desk drawers or (even worse) stick the paper to their
  computer screens.  - ComputerWeekly

Assuming that I'm a doors manufacturer trying to avoid passcode-based door locking systems.

What other authentication techniques are there that are quicker / easier than passcodes, but don't reduce security?

What are pros and cons of each one?

As a general rule to remember: Don't make it to hard to use! If it's to hard to use and you keep forgetting, all you've done is shown that you need a different security method to make your door usable.

Things mentioned in this post:

Private/Public authentication (keys)
UUID pre-authentication (fobs)
MFA(specifically 2, fob and code gen)

Things mentioned in the do not use section:

Biometry
Security Guards alone
Cameras(security theater)
Security Through Obscurity (Handshakes/patterns)
Roll Your Own Security

Well, with a door there's always physical security like keys to look at.

A lock is a private/public system where a physical public key is used to access the internal private mechanism (tumbler). When a user inserts a copy of the public key, they can gain access to the door and can modify its internal states (including unlocking, and locking it themporarily). This can be enhanced further by a timeout that causes the lock to lock itself, preventing follower.

Pros

Faster (put in place, turn)
Easier (one action)
Almost as secure as passwords (replication based on sight)
User Pre-Approval (only a copy of the public key gains access, so you control in advance who gets it)
Strong to interception (someone would have to run a pretty strong grab attack to gain access)
Widely accepted and used (most people are already used to the system)

Cons

Bad users replicating keys and leaving them around (only an issue if someone can find the lock it goes too, but worth mentioning)
Bad users giving copies of the key to other people who aren't supposed to have access
Bad locksmiths who keep copies of the keys for nefarious reasons
Loss prevention (he who has the key, has the power)

As you can see above, unless you run into some bad user/system adminlock smith situations you should be fairly safe as long as you make sure your ciphertumbler is safe against the usual brute forcebump key/tamper (lock pick) tactics that exist out there and is installed with long screws and a strong door frame.

Okay, let's say you want to completely do away with passwords. Now you can do something called a universally unique identifier (UUID) with pre-registration to the lock.

For this you generate a long, hard-to-guess string that gets stored on a device that gets registered with the system in advance. If that generated thing was always registered in advance you can easily change it and try to restore it before you put it on the device to give to the user. Now if the user wants access, they just put the device up against a reader, which confirms the string with your security system, and they gain access!

Pros

Faster(put against square, wait for light)
Easier(one action)
More secure than passwords
Ease of use(just put it on a small square, and you're in)
Pre-registration means easy tracking
UUID is so unique it can register every atom in the universe(good luck running out)
Impossible to replicate without already knowing the string

Cons

Bad system users (users with access to the codes internally could cause issues, scripts are you friend)
Loss prevention (whoever has the fob, has the power)
LOSS PREVENTION

Really this system is as secure as a key, but gives the extra advantage of unique "fingerprints" for the device they use to enter the building, meaning you can easily track who comes and who goes with what key.

That loss-prevention con is a big one though, as then the person needs to come back, prove they are who they say they are, and you need to invalidate the old key, flag it to watch for someone who stole/found it and tries to gain bad access, and give them a new one with the hopes it won't happen too often.

If a key is something that is easily captured or replicated in the part of town your door is going to be installed in, or your users are REALLY bad about loss prevention, you could instead look at pinned unique identifiers like magnetic key fobs and a time-based password delivered over text message or through a special device, which is called 2-Factor Authentication

Using this technique, a user is given/makes a password to the security/lock system which is stored in a key fob. Then they register their phone with a service that will generate the other password they need to enter for them upon their request. Now when a user wants to gain access, they present their key fob and enter their password from their phone into the keypad. This provides extra security from bump keys and locksmiths because you can tie a security system into it and analyze who tried to gain illicit access in an incorrect manner so you can lock out their credentials and they have to come and get new ones at security.

Pros

MUCH stronger security than passwords
VERY strong(the password can be good for as little as a minute if you decide to set it up that way
Extra security techniques (you can instantiate rate limiting, lockouts, and credential rollover)
Pre approval baked in (they have to register with you to even make their fob active)
You can know the exact time frame someone logs inunlocks the door based off of the password that got confirmed (once confirmed, write and entry in your security logs)
Uniqueness (each fob stores something from the user, and each text is based purely on the pre-authenticated phone number which allows for limitless unique entries in your security system)

Cons

Loss prevention (if someone loses their phone/fob you have to reissue a whole new credential for that part of entry)
Ease of Use (you always have to have these present. If you forget one you have to go get it)

Wow, that's a short list of cons with a long list of pros! Heck it even gives you remote security abilities!

It's a little hard to implement though since there are a lot of systems that would have to be put in place, but that's not really a con and more of a setup cost.

The "do not use" section

Biometry is a cool idea, but horrible in practice. This is like fobs, but accuracy can't be guaranteed here, and it can be thwarted with something as simple as silly putty. People also change over time. It's just a bad in practice.

Security Guards when used alone is also a don't-use this protocol. They can be overpowered, bribed, subverted, and have biological needs that may cause holes in your security during unknown times.

Cameras provide NO SECURITY on their own. They're really more of an addition to security, and can't actually stop something. It's akin to a Security Theater. Sure you could watch it all you want, but really all you're doing is fooling yourself into thinking it's secure. Someone can still break in if a camera is there, and it's really easy to hide from.

HandshakesSecurity through Obscurity is another bad case of security theater. If I have to knock twice, say a phrase, knock again, and then turn turn the key why would I ever use this system? I'd look like an idiot, and someone can just replicate the steps. You gain no more security here than you do with a key, and it's harder to use.

Making Your Own Security Protocol/System should be avoided at ALL costs unless you're doing it for research and testing purposes and let EVERYONE bang on it to confirm just how smart you are (or bring you crashing to reality on how bad your idea was). Until it's proven as safe, it's nothing more than a really bad play in the Security Theater showing.


Is a secure cookie without the HttpOnly flag a problem? I understand that cookies with the secure flag should be transmitted over a HTTPS connection. It also means that these cookies should be protected from adversaries (private cookie). Thus, it is important to set the HttpOnly flag on this kind of private cookie to prevent XSS.

Is a private cookie with the secure flag but no HttpOnly flag a problem?

Essentially, I think the HttpOnly flag should be added to a cookie with the secure flag.

The secure flag ensures that the setting and transmitting of a cookie is only done in a secure manner (i.e. https). If there is an option for http, secure flag should prevent transmission of that cookie. Therefore, a missing secure flag becomes an issue if there is an option to use or fall back to http.

httpOnly ensures that scripting languages (ie. javascript) won't be able to get the cookie value (such as through document.cookie). The only way to get it is through http request and response headers. Therefore, a missing httpOnly coupled with XSS vulnerability is a recipe for stolen session token.

It's best to put httpOnly and secure flag for your session token. Other cookies, it would depend on how sensitive it is and what is it used for.


Is using a network sniffer for host discovery a viable option? Would a packet sniffer like tcpdump be effective for network host discovery and if so how effective is it compared to more active methods such as the infamous network mapper nmap?

Passive sniffing requires that the sniffing device is able to see traffic from the hosts that you want to discover. This is made difficult in a switched environment that segments traffic.

Active scanning, like nmap, reaches out to hosts to see if they are alive and overcomes the problems with passive sniffing.


How can a cracker get past through this regexp? I recently had a chat with a cracker and he told me that he can get past uri regexp checking.

I'm checking if the path_info matches my regexp and after that I match that to my routing table. If there is no routing for that path i redirect to a 404 page.

I have some little code here and I was wondering whehter someone can crack this by providing wrong data or my web app is protected? Is it possible to bypass this? (Please note that this is just some sample code):

<?php
// alphabetic characters, numbers, "-" and "/" are allowed
$pathRegex = '/[a-zA-Z0-9\/-]+/';
$pathInfo = $_SERVER["PATH_INFO"];
$routes = array(
    "homepage" => "/",
    "some_page" => "/param1/param2-something"
);

$res = preg_match($pathRegex, $pathInfo, $matches);
if ($res && $matches[0] == $pathInfo) {
    if (checkRouting($pathInfo, $routes)) {
        // keep on running
    } else {
        // 404, sorry
    }
} else {
    // wrong path
}

function checkRouting($path, $routes) {
    $res = false;
    foreach($routes as $key => $val) {
        if ($val == $path) {
            $res = true;
            break;
        }
    }
    return $res;
}
?>

Using a regular expression creates uncertainty,  makes it difficult to debug and can be resource intensive.   That being said I use Regex buddy to debug regular expressions.  In fact this is a tool I used to hack PHPIDS, which contains many regular expressions.  The best security systems I have encountered are very simple and easy to understand, complexity is the worst enemy of security.

However what you are doing is just a simple white list to insure that $_SERVER["PATH_INFO"] is an approved path.   This can be done in O(1) time complexity with a dictionary.   Create a dictionary where each path is the key called $route_paths;

if(isset($route_paths[$_SERVER["PATH_INFO"]])){
    // keep on running
} else {
    // 404, sorry
}


Reasonable computationally lightweight security? I've read a bunch about how one should use bcrypt or PBKDF2 as a good middle ground between tunable workload and acceptable time to make brute force and collision attacks unfeasible.

What if the system is not a stock, off the shelf, general purpose computing system?

I work with an embedded system, that runs on a 200MHZ ARM CPU and over 90% of the CPU time is dedicated to performing the actual job the system is doing, continuously. Everything else is secondary, slow and conservative in terms of memory, CPU time and such.

Currently, access to remote control is protected by a crude challenge-response based on md5; device generates a random string and sends it to the client, client submits md5(password+string). This is to stop script kiddies and overly curious amateurs, but I'm  aware this security is rather pathetic.

Now I'd gladly add something better, except I can't really spare much RAM, CPU time, or even disk space to fancy solutions and I'd prefer a valid client to be able to get in within reasonable time. Moreover, the same protocol is to be used to authenticate these devices communicating with each other, so the constraints must apply to all authenticating systems.

How to reasonably solve this? Any algorithms and methods that would allow reasonable security, assuming the constraint that it must not impose a performance penalty of more than 1%?

Protecting passwords in storage and transit are two separate issues. The primary reason for using PBKDF2 or bcrypt is that their resistance to hash cracking is high, in cases where the hashes are captured from the server (e.g. via a database dump through SQLi).

Since you're looking at protecting passwords in transit, I think you may have already fallen into an unexpected trap. If a legitimate user sends a request with a correct response to the challenge, what stops the attacker performing a man-in-the-middle attack and modifying the request contents, whilst keeping the valid response token?

So, first you need to define what you need:

Confidentiality of the password.
Integrity of the message.
Authentication of the client (w.r.t. the password and the message).

A challenge-response system alone can't do this, unless you integrate a MAC (message authentication code) into it. In fact, what you technically need is a MAIC (message authentication and integrity code), since you need to make sure that the exact message you received is the one sent by the user, that it wasn't tampered with, and that the user is who they say they are.

Now you're running into areas where there are mistakes to be made and where implementation flaws run wild. Writing a protocol that effectively provides authentication, confidentiality and integrity is hard, especially on an embedded system using low level languages. However, TLS (SSL) does exactly this. Contrary to what some people say, TLS is amazingly efficient in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers with very few problems.

So, in conclusion, I highly recommend finding an SSL library (libssl maybe?) that will compile on ARM, and then use that.


Security risks of Read-only MySQL Database access behind firewall Are there any obvious security risks to providing a none IT Staff member read-only Database access (through MySQL Workbench) to a Wordpress Database, if this is behind a firewall/VPN?

As per your Question, No one can give Yes, No Answer. Because Risk is not a hacking. Security is not a providing technical security with firewall or any security devices.

  Risk is a situation involving exposure to danger.

You have to understand what is a requirement of users. And according to that you need to provide only appropriate access to users. Because if you have classified data, which has permission level.

If you give access to users, you need to make sure that they can access only data which related to their permission level. Otherwise users will gain all secret information from your database without having any technical attack.

That will be a big risk ever you face.


question about clean reinstallation of infected windows 7 (nuke from orbit approach) I am attempting to reinstall windows 7 on my infected PC (with the shortcut virus) using a fresh USB drive.
The USB drive is NOT infected and contains the ISO.

will the USB stick I'm using get infected if I use it for reinstalling ?

I plan on inserting the USB drive in its port immediately  after I restart the device so I can boot into it right away.

I also plan on booting my PC from the USB drive to start the process without ever opening it from My Computer.

As long as the USB has never been inserted into an infected machine, the original infected operating system is not booted while the USB is present and the virus has not modified lower level systems (like BIOS / firmware) - which the shortcut virus appears not to - you should be fine.

I would suggest if you do not have files you wish to recover on the infected system to fully wipe the drive before/during the install process. Letting Windows move the old files to a Windows.Old folder may risk re-infection.

If you want to be particularly paranoid boot from a linux live USB or Windows PE disk and wipe the HDD before reinstalling Windows.


CSRF with special characters in parameter name I am pentesting a web application which does not use an anti-CSRF token, but uses parameters whose names contain colons. One of the parameters is, for example, _pt1:p1:1:pc1:pageToolbar:t_id_.

When I make the HTML auto-submit page with input element like this:

<input type="hidden" name="pt1:p1:1:pc1:pageToolbar:t_id" value="1"/>

it will be sent URL encoded, so it won't be correct for the application.
Does this mean that CSRF is impossible?

There are three different content types you can let a form send (unless you have special CORS permission):

application/x-www-form-urlencoded
multipart/form-data
text/plain

You have tried the first one, and it doesn't work. It's unlikely that the second would help you (it's just a way to stitch multiple content types together when you are uploading files). So your best bet would be the third. Try a form looking like this:

<form enctype="text/plain">
    <input type="hidden" name="use:a:colon" value="This is an attack!">
    <input type="submit">
</form>

You will be able to send requests  without having the colons encoded.  Wheater it actually works or not, well, thats another story. The server might not accept this content type or there may be other hurdles.


More secure to use e.g. Whatsapp Web in Franz than in browser? Yesterday I found out this application called Franz. Their policy says they don't collect any information about your chats and can't read them (because it's just an application who bundles them all and doesn't serve as sender).

But I was wondering, is it actually more secure to use for example Whatsapp Web in Franz instead of the browser? When you use a browser you'd be more vulnerable to browser-exploits, no? So, by using Franz you separate your browsing activity from your chats, so your chats are more secure?

TL;DR:
Is it more secure to use web-based chatservices like e.g Whatsapp-Web in Franz than in your normal browser.

But I was wondering, is it actually more secure to use for example Whatsapp Web in Franz instead of the browser?

No,  Franz is not inherently more secure than a regular browser.

Under the hood, Franz actually uses a web engine itself as you can tell from grepping through the binary. It is built with electron (which is based on Chrome which uses Blink, a WebKit fork). Further, since Franz combines multiple services, a vulnerability in the app could potentially compromise all your messaging profiles at once.
In general I'd be careful about using third-party apps instead of the native clients or their respective web services. Franz in particular is rather new, it's not quite clear who the individual developers are, there is no evidence that the code has ever had a thorough security auditing and it is closed-source which doesn't necessarily build up trust.

Edit: Doesn't look good.

In an ordinary web application the impact of this XSS flaw would have been restricted to that particular domain, but in a desktop application it endangers the host itself.


If you've been compromised once, are you more likely to be compromised again? I apologize in advanced if I am misusing vocabulary, as I'm no security expert.

If you've been compromised (mostly regarding web accounts like e-mail, FB, etc.) once, are you more likely to be compromised again?

I can imagine that a hacker might have constant access to some piece of a table in the database where your account info is stored. Then, even if you change your password, he will know the new one and be able to compromise your account again.

Is this possible?

No. At least not for the reason you state.

You're confusing a single compromised user account, e.g. because someone figured out your password, with a compromised application platform. If I get access to your facebook account, that doesn't mean that I get access to the underlying machinery. And if I did get access to facebook's innards, it wouldn't just be a problem for you, but likely for every facebook customer. So while its true that with such access, I could keep compromising your privacy etc, that would also apply to lots of others, so you wouldn't technically be more likely than anyone else to be compromised, and being compromised yourself wouldn't have anything to do with an individual breach of your account.

Of course, if you used the same password on every online service and I found out what it was, then I could compromise every one of your accounts. But I assume that's not what you meant.

Also, if I compromised your mail account without you noticing, I could get continuous access to most your online accounts, even if you changed your passwords on them, because I could use their password reset functionality thanks to the access I had to your mails. But you'd notice sooner or later, because I'd need to change the passwords in order to gain access, so you'd keep wondering why your passwords didn't work.


Sanitize computer after Homeland Security seizure I flew from overseas back to the USA and all my electronic equipment was seized by Homeland Security, including my laptop computer, external hard drives, flash drives, etc.

After more than a month I have finally gotten my stuff back. I have 2 questions:

Is it known whether Homeland Security has ever planted spyware, viruses, tracking devices, etc. on seized computers?
What should I look for, what steps should I take to sanitize my stuff, what would you do?

EDIT: I can't reformat, burn hard drive, etc. as some have suggested because very important work is on the laptop, i.e. software I've been working on for over a year.

Yes, I had backups of all my data.  Unfortunately, the backups were all with me, and they seized all of those too (2 external hard drives, 3 usb flash drives). So merely utilizing backups isn't an option.

Also, someone said people can't help me without breaking laws. I am unaware of any laws which state it is illegal to remove spyware/malware/viruses, or that it is illegal to remove anything the government put on your computer.

EDIT: I guess I could rephrase the question as "how would you go about getting source code you had written (text files) off the computer safely, 'safely' meaning scanning text files to detect anything unusual, and then transmitting or somehow putting them on another computer?"

Given that your laptop was in possession of a government entity with unknown intentions towards you for an extended duration, there's really no way you can restore it to a fully trustworthy state.

If you assume the U.S. DHS to be hostile, then the only secure process to move forward with includes:

Assume all data on the laptop, and all other confiscated hardware, to be compromised.

Change all passwords for accounts which may have been stored/cached on the devices.
Change all passwords for other accounts which use the same password as the accounts which may have been stored/cached on the devices.
Void all payment mechanisms which may have been stored/cached on the devices.
Communicate appropriate privacy warnings to potentially-affected third parties.

Assume the laptop, and all other confiscated hardware, was modified to allow future collection of data, or control of the system, by U.S. DHS or related agencies.

Destroy the devices. Do not capture any backup images or copy any files. Just burn/shred/pulverize/crush them as-is.
Purchase replacement hardware/software from a trusted source, through a trustworthy supply chain, and re-build from scratch.
If trustworthy backups exist (backups which were not also confiscated, and would not be remotely accessible with credentials that may have been stored/cached on confiscated devices), restore data from those sources as needed.

Anything short of this leaves open several extremely undesirable possibilities:

U.S. DHS may continue to have access to your online accounts and/or financial resources.
One or more of your devices may have persistent malware which allows U.S. DHS, or related agencies, to spy on you or control your systems. And you're back to #1.
Files stored on one of your devices may have malware which will install itself upon opening. Then see #2.
Hardware or firmware on one of your devices may have been modified to include malware, which may install itself upon connection to another device. See #2 again.
Any software projects you were working on, and/or the tools you use to compile them, may have been modified to include malware. Back to #2 again, and also add further impact to your customers if it's not discovered and dealt with before distribution.

You should check out the 10 Immutable Laws of Security. Law #3 certainly applies. Assuming they've exploited that law, you can probably bet Laws #1 & #2 also apply.

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
  Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Also check out the 10 Immutable Laws of Security Administration. Here, Law #4 is most apropos.

  Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with


How safe is an email BCC field? If I want to send an email to multiple recipients without them knowing each other, can I consider the BCC field safe enough to do this?

Obviously the server will still know and have a log of who the recipients are, but if we assume that server will not be hacked would the BCC field be enough?

The idea of the BCC field is indeed to keep recipients undisclosed from each other. But it should not be understood as a reliable security feature and I wouldn't trust it in a life-and-death situation.

Servers often add additional headers to emails during processing. These headers might, as a side effect, inadvertently reveal BCC recipients to everyone else. For example, this has been a problem with various email encryption implementations. Some research on that can be found in the paper Correcting Privacy Violations in Blind-Carbon-Copy (BCC) Encrypted Email. From the abstract:

  We show that many widely deployed email encryption systems reveal the
  identities of Blind- Carbon-Copy (BCC) recipients. For example,
  encrypted email sent using Microsoft Outlook completely exposes the
  identity of every BCC recipient. Additionally, several
  implementations of PGP expose the full name and email address of BCC
  recipients.

I could imagine that similar problems exist with anti-spam filters or other forms of email processing that your mail server might employ.

Also, there have been flawed implementations in the past. For example, Microsoft Outlook Express Information Disclosure Vulnerability
(CVE-2004-2137):

  Microsoft Outlook Express 6.0 SP1 and prior contain a vulnerability that could cause private information to be disclosed to e-mail recipients.  The application may arbitrarily allow a recipient to view the addresses listed in the BCC: field.

As an alternative I'd suggest you to send the mail to each BCC recipient individually. If there are many of them, you can use a bulk email plugin for your mail client that will send the mails one by one.

You can find a related answer here.


How does the ruby vulnerability affect me? Visiting this site: http://ruby-doc.org/

I get this message:

  There were 3 Ruby vulnerability reports in the last 14 days. 2 high, 1 medium. Most recent: CVE-2013-4562. See details.

I only installed ruby for fun and to play with it. Does this vulnerability affect me? I'm really afraid what should I do?

CVE-2013-4562 is a CSRF vulnerability in the "omniauth-facebook". Since whatever app you're developing is only available on your local machine, there's no way for an attacker to exploit this.

CVE-2013-5671 is a vulnerability in the image processing library which allows attackers to execute malicious code as the user Ruby runs as with a specially crafted image file. As always, your app is only available on the local machine and the only way to exploit this is to convince you (the user) to download that image and pass it through this library.

CVE-2014-0130 is a vulnerability that allows an attacker to read any file from the filesystem using a specially crafted request, assuming that the user Ruby runs as has the permissions to read this file. This is probably the scariest one of all three, but as always since your app is only available from your machine and isn't open to the internet, you are safe.

You are safe as long as your app isn't open to the entire internet (your router/firewall takes care of that).


Can Chrome sync be infected? Can Chrome sync be infected by malware? I cannot imagine how, but a particular unproven example that comes in mind is to change the "preferences", so that a malicious proxy server is added.

Another one might be to add some malicious web page bookmarks that load as closed tabs or in the "new tab", "speed dial" section. In both the above unproven examples, malicious information is stored at the Google's servers and it is synced with your browser.

Are those examples applicable? Is there any other ways to infect Chrome sync?

P.S.: I hope those examples I wrote already exist (if they are applicable) and not give ideas to hackers on how to proliferate their malware.

Generally, yes, it can. You can even find instructions about how to fix this problem.

More specifically, Chrome sync synchronizes (per the advanced sync settings of  Chrome v.47):

Apps and extensions
Autofill information
Bookmarks
History
Passwords
Settings
Open tabs
Themes

If any of those can be maliciously manipulated, it will likely be spread by Chrome sync. Here's malicious activities that I can think of; I'm sure there are more:

Apps and extensions - Many, many ways to do bad stuff here. These can open windows, alter page contents, redirect pages, etc...
Autofill information - An attacker could try to have online orders shipped to the their address or fill in other information.
Bookmarks - Alter your bookmarks to go to attacker's site.
History - As this is used for completion, you can misdirect the user when typing an URL to go to the attacker's URL.
Passwords - Assuming you can only set passwords and not get them, all that I can think of is that an attacker could trick a user into logging into a site as the attacker. Presumably the user would enter confidential information or do something else that would be of value to the attacker.
Settings - You mention proxies. Therer's also the settings for the new tab and home pages. I'm sure there's more.
Open tabs - Open pages with malicious content or downloads on remote devices.
Themes - Can't think of much. Perhaps change the user's theme to lots of cats?

Destroying data in Chrome sync may also be a way to spread malicious activity. For example, just deleting all of a user's bookmarks could cause great pain for bookmark-heavy users.

While every piece of browser malware may not be applicable to being synced across instances, certainly there are many ways to do it.


What do the Disabled and NotBefore properties do for root certificates on Windows 10? On this Microsoft page, they mention that a new feature in Windows 10 is that it can stop trusting root certificates using the Disabled and NotBefore properties. What is the exact meaning of these properties, and how does disabling a root differ from removing it?

I could not find a Microsoft page explaining (or even mentioning) these new features in any detail.

For instance: what exactly does Windows 10 do if a root gets automatically "disabled" via an update? Does it move the certificate to "Untrusted Certificates" container?

These properties are well documemted on this MSDN website.

Not Before

Certificate not valid before this date.

Disabled

Certificate can be re-enabled, rather than reinstalled.

I assume you are a developer who wants to implement current updates, so here comes example for Visual Studio.


Does SSH rekeying take place in the encrypted tunnel or outside of it When an SSH session is rekeyed, does the new key exchange take place within the existing encrypted channel, or does it take place outside of the existing encrypted channel?

Key re-exchange is performed using whatever encryption was in effect    when the exchange was started

rfc4253

  Key Re-Exchange

  Key re-exchange is started by sending an SSH_MSG_KEXINIT packet
  when    not already doing a key exchange (as described in Section
  7.1).  When    this message is received, a party MUST respond with its own    SSH_MSG_KEXINIT message, except when the received
  SSH_MSG_KEXINIT    already was a reply.  Either party MAY initiate the
  re-exchange, but    roles MUST NOT be changed (i.e., the server
  remains the server, and    the client remains the client).

  Key re-exchange is performed using whatever encryption was in
  effect    when the exchange was started. Encryption, compression, and
  MAC    methods are not changed before a new SSH_MSG_NEWKEYS is sent
  after    the key exchange (as in the initial key exchange).
  Re-exchange is    processed identically to the initial key exchange,
  except for the    session identifier that will remain unchanged.  It
  is permissible to    change some or all of the algorithms during the
  re-exchange.  Host    keys can also change.  All keys and
  initialization vectors are    recomputed after the exchange.
  Compression and encryption contexts    are reset.

  It is RECOMMENDED that the keys be changed after each gigabyte of
  transmitted data or after each hour of connection time, whichever
  comes sooner.  However, since the re-exchange is a public key
  operation, it requires a fair amount of processing power and should
  not be performed too often.

  More application data may be sent after the SSH_MSG_NEWKEYS packet
  has been sent; key exchange does not affect the protocols that lie
  above the SSH transport layer.