In Internet Explorer a P3P header allows 3rd party cookies within iframes. It works out of the box in all other common browsers as far as I know.  However, be warned that simply copying this P3P header onto your site without understanding the legal ramifications may expose you to liability.

You cannot share one cookie between websites on different domains. But you can include url parameter in iframe to forward user information from the parent to the child sites. Of course those informations need to be signed, to prevent the user from tampering with it.

If you are asking because of Single Sign On, you may want to look at CAS or openid. CAS is useful when the accounts are managed at one central place, openid easily allows for federally distributed account management. Unlike CAS, openid does not support a signle sign out.


proxy services for torrents vs encrypting data

The growing popularity for Torrent proxies is for anonymity. You can encrypt traffic all you want, but it can always be traced back to the public facing node. The contents of your communication will remain private, however it can be identified that your IP address was in communication with a remote IP address. Without a proxy that will trace back to either your home or wherever you are physically connected to the internet.

With a torrent proxy (or any proxy for that matter) the traffic is negotiated by your proxy, and as such the proxy IP is the one exposed in transport and the traffic is sent back to you over an encrypted tunnel. Your computer acts as though it's on a LAN where your proxy server is, and as such the traffic is not traced back to you (assuming the proxy isn't keeping logs of connections)


Is being able to access /proc/ in Linux a security breach?

/proc is used to interact with the kernel and is required by a lot of tooling.

It is considered safe to access, the more sensitive data (eg: /proc/[pid]/* showing per-process information) having stricter permissions.

It is possible to further restrict permissions on /prod/[pid] directories using the hidepid=n mount-time option. (see man page for details).

You can ask the provider to tweak this option to the strictest setting, but I would not call it a security breach.


How can websites know that I accessed them before if I use a VM and different IP?

Tricky question! It will be hard for us to give certain answers, we may only guess that they might employ fingerprinting techniques that match in both VMs. For example, the VMs might both have have the same operating system, user agent string, set of fonts, give the same canvas fingerprint, have similar CPU performance, etc. It might also be that they found the local IP address to be in the same range, if that was obtainable via WebRTC.

If you did the IP routing correctly (such that the IPs that you used are not the same), and the VMs are indeed clean (so there are no cookies or localStorage), and it's not a very esoteric setup (so your user agent by itself is already unique), then as far as I know, they can only rely on fingerprinting techniques.

You say you 'registered': maybe the email address domain matched as well? When all these factors are combined, it may give a pretty accurate result.

Note that the VMs can very easily become unclean. If you checked that the IP addresses differ by going to tell_me_my_ip_please.com, that website might have tracking scripts. A Like button from Facebook, Google Analytics, an embedded YouTube video, advertisements, etc. are very widely used and can all track you. If you did this to check that it works and then clone the VM, you now have two linked VMs. If you did not, then they'll not be able to link the VMs directly, but they may also do the fingerprinting and combine the information of "no cookies, using this operating system and browser, from this country, etc." into a profile like "probably a white male from Belgium". This information is often reported to website owners, and could also loosely link your visits. It's a little more far fetched, but could be an additional datapoint on which they based their decision.

You might get a better answer if you are able to share the software/website you were trying to use, but from your question it sounds like it's a small, commercial party that might see this post and identify you, so I assume you can't share that.


How can I determine the encryption strength of an SSL connection

The SSL symetric encryption is the result of a negotiation between client and server. It is possible to restrict it from the server side by using the configuration files. For example, apache SSL configuration include a

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

That can be tune to accept only the strongest encryptions, for example you may want to require only :

SSLProtocol all -SSLv3 -SSLv2
SSLCipherSuite HIGH:MEDIUM

Other variables can be used to do more things like client authentication or require per-directory ciphers.

You can also manipulate the negotiation from the client side. As for an example, please refer to this link that is talking a bit about Firefox SSL settings tuning. I assume other browsers have ways to do this as well.

It seems as this page says that :

  The server decides upon the list of cryptography and compression algorithms sent by the client whether to continue or cancel the session. There must be at least one match in both lists, otherwise the session will fail. The cipher combination which took the highest place in the client's list will be used for future communication.

I'm looking for the official protocol.


Can I see the MAC address of a router on an encrypted Wi-Fi network?

Yes!
Using airodump you can look for WiFi networks around you. You can the look for devices on a specific WiFi network (this includes the router) by specifying the bssid. Your WiFi adapter should start finding devices connected to the AP.

Note: You need a WiFi adapter that supports monitor mode.
Here are the commands:

First we have to start our WiFi adapter card, go ahead and do

1.)
airmon-ng check kill
airmon-ng start [interface]

(The first commands kills all processes the might cause problems)
This will put your WiFi adapter card into monitor mode, letting you scan for WiFi networks. Your WiFi card should be renamed to something like mon0 or wlan0mon. Use this name in commands from now on.

2.)
airodump-ng [interface]

This command will start finding WiFi networks around you. Remember the BSSID of the WiFi network you want to look for devices on.

3.)
airodump-ng —bssid [bssid] -c [channel number, can be found when scanning for the network] [interface]

This command will scan on the WiFi network, it will look for devices connected to the AP. It should give you the MAC addresses of the devices connected, including the router.

That should do it! Forgive me for formatting mistakes as I am on my phone.


oauth and passing received toking to other application

A user can login once and use OAuth, and this token can be used to access a 3rd party resource.  This design is common, especially for webapps that want to tap into the Facebook API.

As a pentester I find nearly every OAuth implantation is in violation of at least one of OAuth's RFC security  requirements.  It is as if developers aren't even reading RFCs anymore * gasp *.

RFC-5839 section 4.5 states it acceptable to store the shared secret and OAuth token,  as long as they not stored in plain-text.  Hashing the credentials is preferred, however this token can be encrypted and retrieved without introducing a significant security threat or violating an RFC security requirement.


Risks of letting user know if the username is invalid?

If you start with the assumption that usernames are or can all be public, then there are no security risks in revealing invalid usernames. However, this assumption is not typically the case, and as such revealing the validity of usernames will make brute force attacks easier.

As a ridiculous example, some movies will show someone using a device to crack a password of a digital safe or door code. Perhaps the lock has an 8 digit password and you can see the digits getting solved one at a time on the special device. If that mechanism worked, you would only have to do 10 attempts per digit, for a total of 80 attempts to brute force the password in the worst case. Compare this to 10^8 = 100 million attempts in the worst case for the normal way digital locks actually work. (Which is you attempt a password, and the lock unlocks or it doesn't.) Along those same lines, separating guessing a username until you hit one, then guessing the password for that username would be easier for the same reason.

That being said, it doesn't necessarily mean this is a bad practice. It usually is the case that usernames can be easily guessed anyway, particularly on a popular site, so the amount of entropy lost by revealing username validity may not be enough to warrant worrying about it.


Password write protect an external hard drive (DOK) without encryption

Hardware

It is not possible to write-protect a USB device via the standard USB mass storage protocol. You would need to find a flash drive vendor that provides that as an extra feature. Make sure it is implemented in hardware, and not as some silly program that one has to run in order for the protections to be enforced. There are surely some out there, but they are likely expensive, and many of them can be easy to bypass.

Note that, even with hardware, it will not necessarily be hard for a skillful or even just clever attacker to bypass. Many flash drives can have their firmware overwritten, which will necessarily disable any write protection. I would recommend against a hardware solution for this reason.

Hash lists, stored on your computer

If your budget is low, and your threat model does not involve particularly advanced adversaries who may be able to exploit flash drive firmware or filesystem drivers, then the solution may be as simple as generating a hash list, and checking the list when the drives are returned. If any of the hashes do not match, you know that a file has been modified. A simple way to generate a hash list using Linux, using relative paths to avoid issues if the mountpoint location is different:

To generate a hash list and save it to your home:

cd /media/usb
find . -type f -exec sha1sum {} + > ~/SHA1SUMS

To verify the hash list:

cd /media/usb
sha1sum -c ~/SHA1SUMS

Signed hash lists, stored on the USB

If you do not want to store a separate file with a hash list for every USB device, you can also put a signed hash list on the drive itself. This works basically the same way, but rather than keeping the hash list on your own computer, you keep it on the USB, using a signing key so you can know if it has been modified. This is a common technique used for distributing software securely as well. You will need to create a key for signing with GPG.

To generate and sign a hash list:

cd /media/usb
find . -type f -exec sha1sum {} + > SHA1SUMS
gpg --clearsign SHA1SUMS -o SHA1SUMS.asc -b

To verify the hash list:

cd /media/usb
gpg --verify SHA1SUMS.asc
sha1sum -c SHA1SUMS

You can likely automate this all with a script.

dm-verity

Another Linux solution, far more powerful than hash trees, involves using a feature called dm-verity, originally designed for protecting the Android boot process. When a drive is used with dm-verity, a master signing key is used to sign the root hash. The root hash will change if anything on the partition with dm-verity changes, and the signing key will no longer validate it. By default, any change will result in that file not being readable. This is far more secure because it cannot be bypassed without knowing the secret signing key, and it can be used on any storage device.

This solution is more efficient than using a hash list, as files are only verified as they are accessed, negating the need to verify it all at once. The partition will however be made read-only, so adding a new file will require reformatting the drive. This is great if you have a write once, read many situation, but is not so great if you have to add new files to the flash drive and redistribute it all the time.


What is the benefit of OAuth "one-time code flow (hybrid authentication)"?

So as you have described, a "Hybrid Authentication" is a middle solution between pure server-side and pure client-side authentication. That means that all the tasks that are involved to get an authentication complete will need both the server and the client.

This is how a server-side authentication occurs:

you click signin button
you get the consent dialogue asking for your permission
you have to specify a (redirect URI)
you get 2 things:

1- get redirected to the redirect URI

2- get a code appended to the redirect URI (User ID Token)
you exchange the (User ID Token <-> Access Token, Refresh Token) from the google authorization server #NOT SECURE

This is how a one-time code flow occurs:

you click Sign In button (a state variable gets created in the background)
you get the consent dialogue asking for your permission
you have to specify a (redirect URI)
you get 2 things:

1- get redirected to the redirect URI (#State Variable gets redirected back with you)

2- get a code appended to the redirect URI (User ID Token)
you exchange that code with your server #VERY SECURE
(You hand in the code + state variable, and the server compares that state variable with the one that it has already) #NO CSRF
server exchanges the (User ID Token <-> Access Token, Refresh Token) from the google authorization server

So this exchange here is immune to both replay attacks and doesn't provide a MITM with any useful information, because even if the attacker intercepted any packets, he will still have to get that state variable and process the appended code through the server. In contrary to the pure server-side implementation where all the attacker has to do is to send the code to google in exchange with the access token and the refresh token.

Here is also a picture to put things into perspective, hope that the difference is more clear now.


How to make sure an API request is coming from a specific domain?

I'm assuming what you mean is that visitors to another site will make client side requests to your API, and you want to attribute these requests to that site.
There are several ways to go about this depending on how strong you need the authentication to be.
If you're just using the data for statistical purposes and maybe to stop unauthorized use from very unsophisticated attackers then you can use the HTTP referrer. This can of course be forged, so this won't be suitable if you require very strong authentication.
Another option is to use an API key / site ID that is passed along with all requests. An attacker could easily take the API key from one customer and abuse it, or use it on another site - but at least you can reissue the key/ID if it's abused unlike the referrer.
If you need very strong authentication then you'll have to have your customers generate a time limited signed token on the server side which the user then passes in their request to you. Basically, each customer would have a secret key on the server side and they'd use that to encrypt a message including a time limit - you can check that by decrypting it when the user passes it to you. You might be able to leverage something like http://jwt.io/ to do this. The disadvantage of this is that you can't do this completely on the server side, so your customers might have to make some changes to their application.


In which ways could a javascript making a cross domain HEAD request be a threat?

There's two issues with cross-domain requests: whether a request makes it to the server and whether a response is visible to the client script that issued the request. So-called "simple" requests (which use a "simple" method and include only "simple" headers) are guaranteed to make it to the server, but their visibility to the client script still depends on appropriate CORS headers. Non-simple requests are not immediately sent to the server; first, the browser sends a "preflight" request (using OPTIONS) and uses the headers in that preflight response to decide whether to send the actual request. This is because non-simple requests might alter server state, and thus could cause damage even if the client was forbidden from seeing the response.

Let's be clear that the result of a preflight OPTIONS request is never made available to the client script. It is only used privately by the browser to decide whether to perform the actual request initiated by the script:

If you wrote a script that tried to make an actual (i.e., client-visible) OPTIONS request, it would be subject to normal CORS rules:

var xhr = new XMLHttpRequest();
xhr.open("OPTIONS", "http://cors-enabled-server.example.com/");
xhr.onload = function(e) { console.log(e); }
xhr.send();

This request will generate a preflight (because OPTIONS is a non-simple method) and the request will fail, unless the server sends a Access-Control-Allow-Methods: OPTIONS response. Note that this generates a preflight OPTIONS request, but that preflight OPTIONS request is never made visible to the script. The script can only see the "actual" OPTIONS request/response, which comes after a successful preflight.

Second, you ask:

  But a HEAD request won't receive anything other than headers and a status... yet it would effectively be blocked.

This is not true: the visibility of the result might be blocked, but the request is not. This is because the HEAD method is a simple method according to CORS and thus does not necessitate a preflight, just like GET and POST:

  A method is said to be a simple method if it is a case-sensitive match
  for one of the following:

  GET
  HEAD
  POST

A simple cross-domain HEAD request still requires an acceptable Access-Control-Allow-Origin response, but it does not require a preflight. Therefore, a simple HEAD request (i.e., one that has no special headers necessitating a preflight) will always be sent directly to the server.

OPTIONS, on the other hand, is a non-simple method and must be approved by Access-Control-Allow-Methods in a preflight response. Do not confuse a preflight OPTIONS request (which is never subject to CORS, but is visible only to the browser, not the script) with a JavaScript OPTIONS request (which is visible to the client, but only if it passes CORS requirements).

To answer the title question in your title, "How could a JavaScript making a cross-domain HEAD request be a threat?": it's a threat roughly on the order of allowing a cross-domain GET request, since HEAD should be --according to the HTTP spec -- the same as making a GET request, but without the response body. There's still the potential for lots of sensitive data to leak through headers and status codes.


Storing credit cards to use for purchases on customer's behalf

From what you've said, he clearly does not understand the enormous size of the risk he's taken with this.  I assume that if he is doing shopping for other people, those other people are wealthy, and have high dollar limit (possibly unlimited) credit cards.  He needs to be aware that if this data is stolen, he will be personally held liable for all the fraud committed.

If he has the cards of 10 million-dollar clients, he needs to treat these card numbers as if they were $10 million worth of diamonds.  He should keep them on a piece of paper, locked in a safe.  If it were me asking one of my employees to use a card, I would have them come into my office and ask me to type in the card number for them, instead of giving the card numbers away.

Some other piece of bad news is that if one of his clients' cards is stolen somewhere else (at a restaurant or gas pump skimmer), and if Visa learns he has stored these card numbers, they may hold him liable anyway -- even if he had nothing to do with the actual theft or fraud.

Making it easy to get at should be the opposite of what he wants.  He should instead be paranoid about who can get to this list.

Since he is lacking the security basics (demonstrated by failing to understand the value of what he's been entrusted with) I further doubt his ability to maintain a secure computing environment.  He needs to understand that he can't afford to trust this information to a computer that could be hacked in exchange for a little convenience.


I'd suggest to hide your REST API behind a so-called API Gateway. Such components should handle that.

I know that APIGee provides different features (http://docs.apigee.com/api-services/content/comparing-quota-spike-arrest-and-concurrent-rate-limit-policies) that can help to mitigate DDoS attacks.


Basically, you can try by starting a PTY shell:

echo "import pty; pty.spawn('/bin/bash')" > /tmp/abcd.py
python /tmp/abcd.py

After that, you could install sudo (but I think that it's not necessary because after su -, you are a root user) with:

su -
apt-get install sudo


I tried your match-and-replace rule out myself and identified two issues:

Based on RFC6265, the Cookie Header starts with Cookie:, followed by cookieName=cookieValue. This means your rule Match: cookieName:.*; Replace: cookieName:myValue; should instead read Match: cookieName=.*; Replace: cookieName=myValue;
The type should be Regex instead of Literal

This modified rule worked for me:

Item:    Request header
Match:   cookieName=.*;
Replace: cookieName=myValue;
Type:    Regex


I dug out my copy of Applied Cryptography to answer this concerning symmetric crypto, 256 is plenty and probably will be for a long long time. Schneier explains;

Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even imagine a world where 256-bit brute force searches are possible. It requires some fundamental breakthroughs in physics and our understanding of the universe.
One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38 × 10−16 erg/K, and that the ambient temperature of the universe is 3.2 Kelvin, an ideal computer running at 3.2 K would consume 4.4 × 10−16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21 × 1041 ergs. This is enough to power about 2.7 × 1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
But that's just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

The boldness is my own addition.
Remark: Note that this example assumes that there is a 'perfect' encryption algorithm. If you can exploit weaknesses in the algorithm, the key space might shrink and you'd end up with effectively less bits of your key.
It also assumes that the key generation is perfect - yielding 1 bit of entropy per bit of key. This is often difficult to achieve in a computational setting. An imperfect generation mechanism might yield 170 bits of entropy for a 256 bit key. In this case, if the key generation mechanism is known, the size of the brute-force space is reduced to 170 bits.
Assuming quantum computers are feasible, however, any RSA key will be broken using Shor's algorithm. (See https://security.stackexchange.com/a/37638/18064)


Internet IPv6 address shows up instead of normal IP in Gmail activity information page, may have been hacked, how to solve the issue?

Maybe this was your real ipv6 address. If the ip came with * at the end, it could be 99.99% your ipv6.

Also don't get the information about the IP by google 100% correct, NO! As I get a vary location since my ip is valid every week.

You simply change your password with a strong string, plus enable two-authentication and in the activity window ask google to log out all other sessions just your current one.


What threats are associated with using Teamviewer?

"Obviously a person can copy over a virus and run it, but you would see this happening so I don't count this as a method."

Actually this is the method used most often with a malicious intent.

There is a scam, where you get a call from a "Microsoft"-technician. He tells you, that your computer is behaving strangely. In order to show the user, that he really is from Microsoft and can see your pc, he will tell the user the CLSID (which is the same on every windows pc) via assoc in the command line.

When the user installs Teamviewer for the "technician", he continues to show some other tricks like using "tree" or even "color c" to make you think, that your machine has a virus.
Usually he offers to install antivirus-software, clean the pc, etc.

Sometimes he doesnt even bother to help you clean the pc - instead he installs an encryption-trojan and locks you out of your pc, until you pay ransom.

Scammers try to scam a lot of people and often enough the less-techsavy / older people fall for this scam.

The older users see what the technician does, but are not able to understand it!

Therefore teamviewer is used for exactly this reason when a malicious person tries to install it.


Why self-signed https is less trustworthy than unencrypted http?

Since most traffic is intercepted merely passively, meaning that encryption without authentication will let you get away from surveillance ....

It is usually easy to intercept traffic actively if you are inside the same (W)LAN, e.g. by doing ARP spoofing or similar techniques. And, for the parties who are able to intercept the traffic passively on the wider internet it is usually also possible to change or redirect it in some way (like with DNS spoofing) and there are even ISP which modify traffic to inject ads etc.

It is already hard for people to understand the difference between plain HTTP (no encryption),  "simple" HTTPS and "better" HTTPS (e.g. extended validation certificates). What you propose here is another level of security, which is slightly better than no encryption and far worse than simple HTTPS, because blindly trusting whatever peer certificate you get makes you just open to easy man-in-the-middle attacks.

Of course, if only few people use a given service you can use self-signed certificates or similar techniques. But in this case you must verify the certificate or public key off-band, like with getting the fingerprint of the certificate or public key some other way and checking it against the fingerprint presented by the connection. This works if you have your own mail server or if you do ssh with hosts you control. But, because you usually don't have an established and secure infrastructure for off-band verification, this will not work for a larger audience.


How to make / dump contents of memory for forensics analysis?

If you google for forensic memory dump tools, one of the first ones to come up is the free Microsoft SysInternals tool, LiveKd. Helix is also free, and has greater functionality. Download the Helix ISO and have a good look at the tools available.

As far as complexity, all these tools provide a wide range of functionality. This shouldn't be confused with being too complex, as you will just use the functions you need. This goes for Volatility as well.


Security of emails from ProtonMail to Gmail

I understand that Gmail to Gmail is not very secure.

Depends on the threat. Do you care that a handful of people who work for google and the government can read your messages? If not, then gmail's great.

On the other hand, ProtonMail is a very good option with great features. But there is one thing I don't quite understand:
Why should I use ProtonMail if the recipient uses Gmail? How is this more secure? I mean, if Gmail is not secure enough, then what's the point of sending an email to Gmail from ProtonMail instead of just keep using Gmail (given that it has extra features)?

Yeah, once you send the message outside of the protonmail ecosystem it's only as secure as the least secure link. It's likley that protonmail uses TLS to communicate with gmail, and again, gmail's pretty darn safe.
However, if you had sent the messages to yahoo in the past, then the NSA had a tap on yahoo's network, and that would not have been very safe, unless you don’t care if the NSA reads your mail.
If you sent the message to Hillary Clinton's basement email server, then the cleaning lady could have taken the hard drive. That's not very safe.
Then again, if you sync your email to your personal device, or your computer is compromised, then your proton mail is also compromised.
Maybe use signal on your phone for really really sensitive messages, and gmail with two factor for the rest.


Server is sending large amounts of encrypted UDP traffic

This answer are being given taking in account the comments:

It seems that the attacker either using it as vpn hop server (more likely) or as data exfiltration (less likely, since I assume the target are not important)

The reason why I assume that this is most likely VPN over DNS hop server, is that at some point of time I've had to experience with one of my clients pretty close to the described scenario.


Firefox:Secure connection failed(Error code:ssl_error_weak_server_ephemeral_dh_key)

Is this a problem with my browser?

Firefox 39 and the Firefox 31 and 38 ESR releases upgrade the TLS implementation NSS to version 3.19.1. To harden the browser against Logjam attack the minimum key length for DH parameter within the TLS handshake is now 1023 bits. But the server at acs.onlinesbi.com only uses a DH key of 768 bits. This key length is considered insecure because it might already be broken by academic research and more so by a state sponsored attacker with more computing power.

  How can I solve this?

The site needs to upgrade their security. It is expected that other browsers increase the minimal required DH key length in the near future too so that the site will not be reachable by lots of users unless they improve their security.

To use the site with the current Firefox version follow the instructions below (from this MozillaZine.org forum post) to disable use of DH ciphers in Firefox:

In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
In the search box above the list, type or paste ssl3 and pause while the list is filtered
Double-click the security.ssl3.dhe_rsa_aes_128_sha preference to switch it from true to false (this usually would be the first item on the list)
Double-click the security.ssl3.dhe_rsa_aes_256_sha preference to switch it from true to false (this usually would be the second item on the list)

Note: A browser restart is not required. The change takes effect immediately.

This will cause FireFox to fall back to non-DH ciphers so that the weak DH key is not in use. Note that this effectively disables Forward Secrecy with sites which don't support ECDH but only DH.


Is it normal?

Yes

can I actually hack my website by this?

No.
Telnet simply connects to your web server in the same way that a browser would connect to your web server.  The difference is that with telnet, you type the request manually, and then telnet displays the underlying text of the response -  whereas with a web browser, this happens behind the scenes (although you can view and/or modify the requests and responses using the developer tools in most web browsers).
Therefore, using telnet alone does not enable you 'hack a website' - unless the site already has some vulnerability, in which case you may be able to exploit the vulnerability using telnet or another tool.
Last but not least, telnet can only be used to connect to a web server via (unencrypted) HTTP (usually on port 80), not (encrypted) HTTPS (usually on port 443).  To connect to a web server via HTTPS using a similar text/command based tool, you can use openssl s_client.  See https://www.openssl.org/docs/man1.0.2/man1/openssl-s_client.html for more info.


Governement like classified information system

Using PKI for access control is a bad idea. It is a very common mistake, everybody who works in the field of PKI makes that mistake, then learns from his errors.

In your situation, suppose that someone who has been cleared for access level 3 has been awarded a "level 3 certificate". This means that this individual has a private key Ks (e.g. on a smart card) and the corresponding public key Kp is in a certificate issued by the CA; the certificate is duly tagged as "level 3". The individual uses his private key and certificate for two purposes:

To authenticate with some systems which verify that the client's certificate is a valid "level 3" certificate.
To decrypt documents which have been encrypted with his public key.

Now it turns out that the individual was bribed by an evil competitor / government. His level 3 clearance must then be cancelled, of course. Unfortunately, this will not fare well with the two usages above:

The individual still has his token in his hands, and the token still works. In order to make the authentication fail, the certificate must be revoked. But revocation is asynchronous; it works with CRL and OCSP responses which have a finite but non negligible lifetime. Revocation will be effective only after a few hours or possibly days. I would not like to be the Security Officer who reports to the management that "the scoundrel has been identified and his certificate was revoked; he will no longer be able to connect and plunder files and spread chaos in our systems, starting... tomorrow. For today, he still can do all of that, and is currently doing it, and we cannot do anything about it because the CRL we issued earlier this morning is still acceptable for all servers".
For encryption, this is worse: revocation or not, you cannot enforce forgetfulness. The bad guy still has his token, thus he can still decrypt. To really prevent him from decrypting data, you must recover (and destroy) his token.

The above means that certificates are a poor location to encode authorization information.

A more robust way of doing things is the following:

A certificate is for authentication only. A valid certificate, containing Bob's name and Bob's public key, is an assertion that Bob is in exclusive control of the corresponding private key. It does not state that Bob is a nice guy or has been cleared for any access level. When Bob turns out to be a spy, he is still Bob and still has his own private key. The certificate should be revoked when that "key ownership" property may be broken (e.g. Bob lost his token, and it may have fallen into other hands), but not in other situations. Loss of key ownership is almost always asynchronously discovered (Bob looks for his token and does not find it, so he assumes that he lost it previously), which is why the asynchronism of revocation is tolerable (i.e. we cannot do better anyway).
All authorization data, including clearance levels, must be maintained "elsewhere", in a system that relevant systems (e.g. servers) can interrogate dynamically, to obtain fresh information at any time. In a Microsoft world, you would put Active Directory accounts in security groups, and removing access would become suppressing the group membership; the effect is immediate (for a more complex and flexible authorization management, see AzMan).
Data shall not be encrypted with a recipient's public key until the last moment. E.g. you encrypt an email when you send it; you don't encrypt thousands of documents with a given user's public key "in advance". You must do such late encryption for two main reasons: because you cannot enforce forgetfulness (as seen above), and also because encrypted data is utterly lost when the corresponding private key becomes unavailable (e.g. Bob loses his token).
Data, when stored, should probably still be encrypted, but with a locally known key, and that encryption is meant to avoid leaks when old disks or backups are discarded. The system which handles the data uses the "master key" to decrypt it and encrypt a copy of the data element with the public key of a given user, but just for that element, and only after having duly verified that right now, in the central authorization manager, the said user is allowed to see the document. Alternatively, the data element, once decrypted with the master key, is sent as is to the user through a protected tunnel (think SSL here) after having verified that the user is indeed at the other end (here goes the user certificate and its validation) and that the user is authorized to access that data element.

In fact, classification levels are only a very crude authorization system, and are not even the main source for authorization. When a document is "secret", it does not mean that every secret-cleared user may read it; it rather means that a given specific set of security features must be activated for that document (keep it in a safe, don't make copies, don't move it outside of a given building...). The relation between classification levels and authorization is one-way: to read "secret" documents, a user MUST have the "secret" level clearance (or higher), but that is not sufficient; the user must also be authorized (because of his role) to read that document. In a business context, this means that though both the Vice-President for Human Resources and the VP for Sales both have "top-secret" clearance, there is no automatic reason why the HR VP should be able to read top-secret Sales documents, and vice versa.

(In actual government / military contexts, it turns out that when papers are tagged "secret", with a very visible red banner or stamp, this mostly is meant so that the janitor does not discard the paper as garbage when he finds it on a desk in the evening.)


Is a smartcard single or multi-factor authentication

Factors refer to the three different modes of authentication (although there are more - geographic, time of day, etc, but they're less typically referenced)

The 3 main factors are

1) Something you have

2) Something you are

3) Something you know

You are correct that a smart card is single factor on its own - anyone with it can authenticate to the system.

It becomes multi-factor when it's paired with an element from 2 or 3. If I have a password and a smartcard, I have two factor. If I have a password and a smartcard and a fingerprint scan I have three factor.

As an aside - If I have two smart cards and a password I still have two factor. You can't use two passwords, smart cards, or two fingerprints to make two factor.


Is a Password secure if I change one letter?

Unless the attacker managed to get access to one password (which would obviously make it much easier to guess the other one), the answer is no.

Veracrypt will hash your password with the hash function you selected when creating the volume, and that function will make sure that a slight deviation in the input (your 64 character password), will have an unpredictable output. The result of that hash is what is used to encrypt the master key.


To answer the question given in the title:

  How can someone spoof texts with my phone number?

First, it is important to understand that one of the central systems phone providers use to communicate and to send information from one carrier to another (SS7) is based on trust. The system was developed in a time when all operators would trust the information received from others.

This gives way to sending information into a network with false content, something that is very easy, given that you have access to a SS7 gateway into the network. A carrier can simply tell another that the message is from a specific number, and this will be accepted.

More practically for the average Joe is to use internet services that give you the option to enter the desired sender's number, such as this. You are then able to send SMS messages pretending to be someone else.


Confusion: Why isn't a passhrase encrypted SSH key two factor auth?

A passphrase-encrypted key provides two-factor authentication, but only if used correctly. It is easy for the user to misuse the key, providing only a single factor, and the server cannot detect incorrect usage. Hence a passphrase-encrypted key cannot be considered two-factor without additional assumptions. From the point of view of the system as a whole, the passphrase-encrypted key provides two factors, but from the point of view of the server, there is only one factor, which is the private key.

The password is what-you-know. However, the password is not visible to the server. The server does not know if you used a weak password or no password at all. In any case, typing a password on a machine which may be running a keylogger is not valid use of a password for authentication.

The key file is what-you-have, but only if you do not copy it willy-nilly. Strictly speaking, it's the USB stick where the key file is stored that is a something-you-have authentication factor. The key file itself stops being an authentication factor once you allow for it to be copied off the stick.

In the scenario that you describe, where you copy the key on a machine that you do not control, is not valid usage. It transforms what you have into what the attacker also has. If the attacker can install a keylogger on that machine, he can also install a program that makes an copy of the content of every removable media that's inserted into it. What you have must be tied to an actual physical object that is not accessible to the attacker. A key stored on your own laptop or smartphone is fine. A smartcard inserted into a smartcard slot is fine (for normal smartcard usage, where the secrets do not leave the card). A USB stick inserted into a public machine does not provide an authentication factor.

And yes, there is off-the-shelf malware that grabs the content of removable media. Depending on where you plug in, it may be more or less common than keyloggers (though I'd expect the two to often go together). The attacker who installs a removable disk imager may be after authentication data, or possibly after other confidential documents. There is a resale market for corporate secrets (confidential documents, contact lists, etc.) which fosters this kind of malware, and grabbing authentication data is an easy side benefit.

With a user who may insert his USB stick into a public machine and type his password there, the passphrase-encrypted key provides zero authentication factor.


Wireless MAC Address Filtering - Authentication/Association

It is really that simple, if the AP has a MAC filter, any device which attempts to authenticate that doesn't have a MAC address on the list will just be denied.
However the problem from a security perspective (which is why this should not be used as a security function) is that it is trivial to spoof a valid MAC address (by sniffing them wirelessly and waiting until the valid user has gone - this is a common technique for avoiding usage costs in airports)
Update to show where MAC address denial happens:

Client --------------Probe-------------> AP
AP -------Probe Response----------> Client
Client ---802.11 Auth Request-----> AP

MAC authentication happens in here. If the client MAC is not on the list the following responses will not get sent:

AP ------802.11 Auth Response---> Client
Client --802.11 Assoc Request----> AP
AP -----802.11 Assoc Respons----> Client

Which is then followed by EAP etc.


You already mentioned some of the problems:

misconfiguration is easy,
privilege escalation bugs could put you at risk,
offering raw, more or less uncontrolled access to the data can lead to DOS situations.

But there are some additional problems with your idea:

This means that your university will be bound to offer the service as long as the product is in use by anyone. Continuity is a problem; if one of your users decides to clone the whole database over that connection, it might become unresponsive for others. Additionally, there might be people that want that software to run without an internet connection.

While an http-API is the way to go to let people use your database relatively safely in general, in this particular case, the best way - from my point of view - would be to use good compression on a database dump and host that file for download on your university server if it’s too big for github.

This way, you do not needlessly introduce a single point of failure for the application to work and put yourself to less risk, let alone spare yourself some tedious, possibly vulnerability-introducing work.


Cookies not cleared after logout in website, is this a security bug?

Short answer: maybe.

Depending on the actual implementation, this is a small risk as @multithr3at3d mentioned. Believe it or not, this is common behavior. Many companies have internal battles over security vs. usability, and at a certain point, the company will make a decision to accept a certain level of risk.

Some things to consider

Exactly how long is the cookie expiration set for?
Does the session persist even after the user has closed their browser? (this is a bigger issue)
What is the application actually doing? Banking apps require a higher level of security than cooking websites, clearly.

I am not advocating weak security practices. Rather, I'm just trying to illustrate how application owners may make decisions like this.


Prevent Cross Site Scripting but still support HTML file upload

Security-wise, the first solution is better. Forcing a download via content-disposition is simple and clean.
HTML parsing and sanitizing on the other hand is a complex task with lots of room for error, possibly allowing an attacker to still perform XSS attacks. Additionally, you'd also need to worry about other attacks related to the SOP (eg CSRF if your CSRF defense is a referer check, Clickjacking, etc).
Usability-wise, it seems that you would prefer the second approach though (the user can view the file directly instead of having to download it). Going with a well-established library is a good idea in that case.
Alternative approaches might be isolated subdomains (probably one per user) serving the files, or sandboxed iframes displaying the content (configured as restricted as possible for your use-case, and taking other SOP issues under consideration).


As far as the modem functionality itself, it doesn't really matter that much.  Unless someone is taping your phone line (which is normally done at the ISP's end now anyway) then it won't matter a bit.  It's a wired connection that isn't going across a public network.

If the ADSL modem also provides router functionality, then the same advice as a router would apply.  You'd want a strong firewall and good wireless encryption.  For more info on router functionality to look for, you can look at this question which already answers it.


Android exploit demos to scare my parents?

Exploiting vulnerabilities in someone's personal device in order to educate is often a recipe for disaster.
If you show a video of someone else exploiting someone else's device, that's still going to be abstract and difficult to personalise.
It's better to create a parallel to something that they do understand and care about

changing the oil filter on the car
emptying the lint trap
vaccinations
dental cleaning
replacing weather stripping
etc.

Something that they know that they have to do on a schedule to maintain something they care about, and if they do not do it, damage occurs.
Digital technology is invisible, intangible, complex, and difficult to understand. Tie it to something that is visible, tangible, simple, and understandable.


A person knows my IP address: how to save my data and address?

Don't worry about it, those are things that any website you visit can obtain.  The OS and browser info might help them develop a more targeted attack, but as long as your home firewall is secured these are likely empty threats.

They could target a botnet at you to DDoS your connection, but many ISPs will notice this traffic and might block as much as possible (flood detection) or might assign you a different IP address anyway.

If you're paranoid, try powering your modem off for about half an hour.  You will usually get a new IP address assigned to you from your ISP.


JSON is merely a data interchange format, and has no inherent "vulnerabilities" of its own.
Also fortunately for you, the text takes the input and renders it as plain text in the given element.  As a result there is no concern for XSS.  Note though that it is only the use of the text method that protects you.  If later on you decide that you want to also inject your own formatting so do something like this:
var body = $('<p>').innerHTML = '<strong>' + obj.message + '</strong>';

Then you will absolutely end up with a stored XSS payload.  This is one of the good reasons to use front end frameworks like Angular and React.  They automatically handle output sanitization for you, so you don't have to worry about these things.
Finally, for completeness, sanitization/encoding are more or less the same thing, and are quite possible.  You would just need to replace " ' < > & with their HTML equivalents, and that will work in 99.9% of cases.  Still, it's even safer to use a framework that will handle those details for you.


Does the CA have to be same for mutual authentication?

Client and server authentication don't have to use the same CAs, but you should tell the server which CAs it should trust to authenticate clients, which seems to be the issue here.

Why? Many people make their own CA and issue certificates directly to their own clients. This saves customers the trouble of going through a sometimes-messy certification on their end. This information is also passed to clients during the TLS handshake.

Another option is to tell clients to get certificates from public CAs: it seems your company did this, and did not specifically tell clients which CA to buy from. If I interpret your description correctly, this client picked QuoVadis to get certified on their end. If you trust QuoVadis to authenticate servers "well enough" for your purposes, then configure the server to trust QuoVadis for client authentication. For Apache:

SSLCACertificateFile /etc/ssl/certs/name-of-quovadis-certificate.crt

Possibly, concatenate all CAs you know and trust (RapidSSL and Digicert, I gather).
You can also take a shortcut, and just trust all known CAs. In Debian/Ubuntu:

SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Careful though: many CAs will just automatically validate ownership of the domain (Let's Encrypt does this for free, for instance). To cut things short, let's say this: if free domain auto-validation is not good enough for you, look into Cloudflare or just forget commercial CAs and manually issue certificates to your own clients.

If you're the client instead, flip the question around: ask the other side which CAs they trust, possibly add RapidSSL or DigiCert to their list, and make sure the list is sent.


Logging SSH commands on Linux - is custom kernel the only way?

We use a Privileged Access Management (PAM) program to handle access control.  Not only will it control who can run ssh remote commands, but it will also log it immediately... who ran what command on what host an when.


putting my password in a php file (phpmailer)

Passwords do not ever belong in source code, triply so for source code that is ever committed to a VCS. Anyone who has or has ever had access to the file has the password, including contractors, former employees, any VCS hosting service you use, etc.

The simple answer is, retrieve the value from a configuration file (that is not stored in your repository) or, better, from an environment variable.


How long will it take to break a salted password?

OK, let's slowly walk through this.

We have 32 possible characters at each of the 8 positions within the passwords. This yields 32^8=2^40 possible passwords overall. From this set of passwords there's a subset of size 2^30 from which the password will be with probability of 1/4 and not with probability 3/4. This means you'll first try the small subset and get a hit with expected probability of 1/4 and thereby have expected workload for this of 1/4 * 2^29. Now you test the remaining passwords which are of size 2^39-2^29 which is roughly 2^39. You now test those with a probability of 3/4 and thereby your overall workload becomes 2^27+3*2^37. If all 256 passwords in your password file have the same salt, your workload doesn't increase and if they do have different salts, you need to multiply (2^27+3*2^37) with the number of distinct salts s. Now you can test 64 passwords per second and thereby you divide your amount by that number and get (2^22+3*2^32)*s seconds or roughly 150k years per distinct salt.


How do I access a firewall log (Windows 10 w. Windows Defender)

Applies to

Windows 10
Windows Server 2016

To configure Windows Firewall to log dropped packets or successful connections, use the Windows Firewall with Advanced Security node in the Group Policy Management MMC snap-in.

Administrative credentials

To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs.

To configure the Windows Firewall log

Open the Group Policy Management Console to Windows Firewall with Advanced Security (found in Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security).
In the details pane, in the Overview section, click Windows Firewall Properties.

For each network location type (Domain, Private, Public), perform the following steps:

Click the tab that corresponds to the network location type.
Under Logging, click Customize.
The default path for the log is %windir%\system32\logfiles\firewall\pfirewall.log. If you want to change this, clear the "Not configured" check box and type the path to the new location, or click "Browse" to select a file location.

Important: The location you specify must have permissions assigned that permit the Windows Firewall service to write to the log file.
The default maximum file size for the log is 4,096 kilobytes (KB). If you want to change this, clear the Not configured check box, and type in the new size in KB, or use the up and down arrows to select a size. The file will not grow beyond this size; when the limit is reached, old log entries are deleted to make room for the newly created ones.
No logging occurs until you set one of following two options:

To create a log entry when Windows Firewall drops an incoming network packet, change "Log dropped packets" to "Yes."

To create a log entry when Windows Firewall allows an inbound connection, change "Log successful connections" to "Yes."

Click OK twice.

Resources

If you have any more questions you can see this whole guide and read more into it here:

https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/configure-the-windows-firewall-log

Hopefully this helps you solve your problem!


Alternatives to blocking suspicious IP addresses?

There are other alternatives, collective honeypots that generate lists of commons attackers is an alternative. I maintain a list built from the result of some honeypots (both public and private), and some production servers that I own.

There is a way to analyse everything on internet like a global ids system ? Yes, there is, but if you ever used an IDS/IPS system before, you would imagine how much false-positives would be generated and the amount of processing power needed to run it on a global scale.

You can focus on protecting your company, a good firewall, web application firewall, an IDS/IPS solution, good internal procedures, security policies, regular pentests, antivirus solutions, training the users so they don't open on everything that they receive via e-mail, and the list goes on, there are several things that you can do to help.

You can always do some proactive job, but imagine the scenario where the attacker, never attacked any other host before, so he won't be on any list, and his first attack is against your company. It's the concept of pre-crime, how did you know that he will attempt to do something and block it before ?

Don't ever expect that one solution will make you 100% secure, if you apply my list to your firewall, you will still vulnerable to the above scenario and several others. But usually hosts that are compromised, and became part of a botnet, will launch several kinds of attacks and scans. Keep that in mind when you try to block something.


This link https://unix.stackexchange.com/a/63758 explains it very well.

Basically, compile a new version on the system.


Does Cloudflare masking my IP make my server more secure?

Yes.  The idea is that you block all HTTP and HTTPS connections to your server, except those originating from Cloudflare's network.  Therefore, your server cannot be attacked directly - all HTTP and HTTPS requests must go through Cloudflare's web application firewall (WAF) first, before reaching your server; and Cloudflare's WAF will block any suspicious requests.  So, it's not 'security through obscurity'.


What would be a good way to create a security testing schedule?

"Testing" only won't do it.

Risk Assessment

Frequency: Bi-annually

Document information assets (systems, networks, infrastructure components, etc.)
Identify threats to those assets (vulnerabilities, attack vectors, etc.)
Examine and review how security controls and measures that are in place mitigate or eliminate the risk of those attacks (access controls, processes, policies, security standards, etc.)
Identify security needs, remedies or areas for improvement

When categorizing assets, don't simply look at the importance of the service it provides to the organization (e.g. mission critical), but look at the risks that are associated with potential compromise, the value of the information, the impact of potential compromise. A system could be totally unimportant to the organization's daily business, but it might be of great importance in terms of the information it can provide to an attacker, if compromised. We had a running joke at the office - one of our pentest engagements wasn't going anywhere, the web servers and public infrastructure of the client were all rock solid, but we managed to compromise the CFO secretary's laptop. Interestingly, it had a copy of the company's financial statement - days before it was going to be officially released. Since the client was a publicly listed company... you know where this goes.

Security Audit

Frequency: Quarterly

Unfortunately, many forget that most issues can be identified by looking at things from the inside, rather than testing from the outside. A properly done audit may reveal issues that you might not be easily revealed during a pentest (let's have a look at the accounts defined for that Tomcat manager). Here are some basic points:

Review configurations (servers, routers, switches, firewalls)
Verify policies are enforced (e.g. make sure accounts of ex-employees have been removed, look at passwords and when were they last changed)
Look at how backups are configured and done, encryption of sensitive data, how access control is implemented (including physical - badges and other seemingly unimportant items)

_

Systems Lifecycle

Frequency: On-going

Every time IT bring up a new system, add a network, or provide a new service, or decommission an old one, the infosec team must be involved to review, analyze and implement security measures. Make it a part of the process.

Vulnerability and Patch Review

Frequency: Weekly

When you receive those security bulletins, if they contain items that are directly related to products/systems you've got installed, pay attention.
Also, don't "assume" all is patched on Tuesday - WSUS may work fine, but you've got to run some basic checks and look at the logs.

There are more items, but this is already too long, and I'm not writing a book. Additional things to look at:

Security events, incident reports and incident response
Security awareness days
Security round-table (involving the CEO)
...


How to protect myself against paid DDoS services?

Have a dedicated router or firewall to do the filtering.

The reason your CPU is being stressed is that the software firewall on your system is attempting to handle way more packets that your system can tolerate.

Having a hardware router or firewall drop packets before they hit your computer should do the trick. Of course, there IS a limit even to dedicated routers or firewalls. So it really comes down to how much resources the attacker is willing to use to DDoS you.

Besides that, there is really nothing else you can do to stop an attacker, besides coordinating with your ISP to block the incoming packets or reporting the matter to law enforcement.


IOCs are breadcrumbs attackers leave and organizations gather up to share with each other. There are atomic indicators in an IOC like IP, port #, username, filename, etc that you can configure your IPS to reject.

There are host-based or network-based indicators. Because of all the types of IoCs, your IPS won't be the only tool you use to guard against attacks, though a good one of course.

This article from FireEye on OpenIOC will help anyone who wants to better wrap their mind around the types and parts of an IOC, using this framework as a specific example.


Paypal IPN, SSL and man-in-the-middle attacks

This should be secure against man-in-the-middle attacks if your machine checks that it has received a valid certificate for Paypal from its correspondent.
Be warned that some SSL libraries leave it up to you to implement/request this check, so you will need to carefully confirm that your code is performing that check.  (Since your machine is initiating the HTTP request to Paypal, for purposes of the SSL protocol, your machine is the client and Paypal is the server.)

No.  Buying your own certificate doesn't help with this communication with Paypal, when your machine is initiating a HTTP request to Paypal.  (However, there might be other reasons why it is good for your users to connect to your site via HTTPS rather than HTTP, which does require a cert.)


What are the security concerns for base64 encoded JSON files?

First of all, there's all the standard web service security risks (connection security, authentication, authorization, session management, denial of service, logging, patching, etc.). I'm not going to talk more about those for now, but do bear in mind that you need a secure environment for something like this.

As for the risks specific to your system and ones like it... The most obvious risk comes if the users have any control over the filename the service creates. If so, you have risks such as file system traversal, overwriting of others' files, and so on. It doesn't look like you plan to do this, but it's something to bear in mind.

There's also the risk of uploading content that could be used to attack either the server or the other users. These attacks are easiest if the attacker can control the filename, but are possible if all they can control is the extension (and they learn the file name), and if there's a web API to download the file. To attack the server, upload a malicious file that the server will treat as executable (for example, a PHP page if the server supports those) and then navigate to it; this may not be possible if you're using a well-configured Node server. To attack other users, upload a malicious HTML file and try to trick other users into viewing it in their browser (resulting in stored XSS); this can be mitigated by making the files retrievable only from a different domain than the one for which the user has cookies / authentication, and/or forcing the browser to download the file rather than display it.

There's denial of service via simply uploading too much data. Consider how much data you'll allow users to store, and how you enforce that limit.

There's the risk of illegal content. The standard example here is child pornography; if users upload such content to your server and you are then found to be "in possession" of it, things could go badly for you. I'd recommend checking local laws, and ideally asking a lawyer, what your rights and responsibilities are when it comes to hosting user-uploaded content.

There's some risks to your JSON or base64 parsers, though these formats are simple and widely-implemented, so I wouldn't expect problems there. I don't understand why you want to use these formats, though; MIME content types are the standard way to upload files to a web server (and therefore feature built-in parsing in most web servers) and are less wasteful of bandwidth (base64 expands all encoded content to 4/3 the size, but there's no reason an HTTP request body needs to be composed only of printable characters).

Since you're storing a lot of user data, you need to consider at-rest data security. Encrypting the files individually, encrypting the whole volume, or using a transparently-encrypted external store are all potential ways to achieve this, but they also present the issue of key storage (as nearly all cryptosystems do). Don't forget to ensure your backups are also protected; tons of sensitive data has been leaked or stolen after somebody got ahold of the backup tapes or similar.

You may also want to consider the issue of user privacy. While not exactly a security feature, privacy (preventing unauthorized users - potentially including you, the service operator - from seeing what was uploaded) involves a similar mindset and is often provided using security tools (such as encryption). You tagged this question as "file-encryption", but you don't actually talk about encryption at all (base64 is an encoding, but there is no key involved; anybody who wants to can decode it, so it isn't an encryption scheme).


How does a country block its citizens from accessing a site?

You have covered the main ones. In short: it's very hard, if not impossible, to effectively block a site you want. You can make it hard by using the techniques you've mentioned: blocking IPs, redirecting DNS, blocking HTTP requests to certain sites / containing certain keywords.

These methods are thwartable by proxies (in the case of deep packet inspection, encrypted proxies would be required) so you end up with a chase situation: as you block a site, proxies will spring up, and as you block those proxies even more will start. The closest anyone has come is North Korea, and they manage this by controlling all sites in their country's intranet.

So the most effective methods:

Whitelist (North Korea's method) - Only allowing the sites you control.
Blocking all encrypted traffic + deep packet inspect (China's method) - this solution allows the communication that pass your criteria for what is acceptable and blocks communications that you are unable to determine the content of.

Both of these methods require complete control / authority over all the internet infrastructure in the area you want to censor.

As you've said, blocking all encrypted traffic doesn't really work - China has found this too: although they tried to, people are getting round this by using Steganography which is the practice of concealing messages, for example:

I am illustrating a hidden message because I
hate to see unanswered questions. I will help
you to understand.

Reading the first word from each line reveals the hidden message "I hate you" (there are, of course, more intelligent ways to to Steganography but that's just an illustration)


Difference between Kali Linux and Santoku Linux

They both are similar in nature, just a Linux distribution with a bunch of tools pre-installed, you could take a vanilla Mint and install the software you need, so if you're debating which one to use you need to know what you will use it for, it comes down to the programs that you need and are comfortable using.

In my opinion, Kali is more complete, it comes with a much wider array of software, this also means its bloated, and at the end of the day I only use maybe 5 or 6 programs at most so having it installed is -for me- just the convenience of isolation inside a virtual machine with anything I could need.

Having said that, I do not think Kali linux comes with development tools.


The sample code you link to does not do any kind of verification.

It fails to verify the certificate chain because it does not use SSL_CTX_set_verify to enable verification (and the default is off). This way it accepts any certificate.

It also fails to verify the hostname against the certificate. Even if chain validation would be done this would mean that the attacker could use any certificate with a valid chain (which are easy to get) to man in the middle SSL connections to any host.


Use any Hex Editor, to split open the contents of the PDF file(aka image, text, javascript code etc). You can validate your file's contents henceforth and filter the javascript or suspicious code.


Strange SMS received on Android phone. Is this an exploit? Should I be concerned?

Judging from the contents in this SMS Message, looking at lines as:

///Hackmaster&67;-&67"
//Fregbugg190&@"67"@/ ;

You'll notice these are all random characters, especially this Hackmaster line, which of course paired with these random characters could arouse suspicion around non-tech savvy people.

As mentioned in a comment before by others, it indeed looks like someone trying to troll/prank you, your suspicion isn't a bad thing however, referring back to the case of the Apple iMessage Glitch.

Long story short, I shouldn't worry too much about this specific text ;)


Does a PC with many NIC's can create vulnerabilities for each network wihich it is connected?

yes,, that is not secure for your networks, your PC will be an entrance for other network if it got exploited, attacker can use PC as a zombie or even launch attacks to the three networks from it directly,,


where can find sample coding for use of Bouncy Castle(java)?

BouncyCastle is a standard JCE provider, so most Java crypto code will work just fine. You just need to add the provider to java.security...  security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
I'd recommend using something like OWASP ESAPI instead of using the crypto API directly.


Is possible to know if increased marketshare means more viruses?

Although there has been reported malware on both platforms (Anroid and iOS) I believe most of the Android malware can be attributed to the freedom given to the user regarding apk (app) installation and the vetting of apps prior to publishing.

On iOS Apple must approve all apps before they are published on the App Store. This process can take several weeks with much back and forth between the developer and Apple. For non jail broken phones this is the only source of apps. Although a few reported cases of malware has slipped through, this process increases the difficulty of publishing iOS malware. Put this on top of the fact that to register as an iOS developer Apple takes good care to get your business registration details. The level of effort is not insignificant for iOS malware.

However on Android it is easy to install apps from third parties. Apps on Google Play itself are only partially vetted (via Google Bouncer and a new client side malware check on 4.2 Jelly Bean for malicious behavior). It's easy to register on Google Play without official business documentation (for example Articles of Organization)

The vast majority of Android trojans are posted on third party app stores as free versions of some paid app. Even on Google Play a number of malware apks have been published and downloaded by hundreds before Google has taken them down. It's relatively easy to convince users that a pirated version of an app is just that, without injected malware.

I personally have seen push notifications telling the user they must download the "Official Android Update" after which the user is brought to a 3rd party site.

The bottom line is the freedom that Google gives its users to download whatever apps they want from wherever they want in addition to a less rigorous pre-publishing process for the Play Store makes the level of effort for publishing Android malware significantly less than iOS malware. So while numbers do play an important role "How can I get the most installed with the least amount of cost/effort" leads to Android being more popular for malware.


why MAC address can not be used as session identifier instead of session ID?

The MAC address is an identification of the specific network card at layer 2 (data-link layer). It stays only constant within the local network where no routers are involved. Once the traffic crosses a router the original MAC address is lost, i.e. the packets now have the source MAC address of the router. And if the packet is transferred by another router the MAC address is replaced again.

Given that in typical setups server and client are not within the same local network, the server has thus no knowledge of the clients MAC address at all and thus cannot use it as an identifier for the client.


No, even though it seems different, processors only process one at a time, so even generating a GUID on different tenants at the same time would still create a unique key since:

If on the same processor, their timing is different, even if by nano seconds, which would produce a unique key.
If two processors at the same time, the processor's signature is different, so unique keys.

Add on to this, all the other factors used by these systems, and it would be extremely unlikely to get the same GUIDs.


How can I report a new vulnerability to cve.mitre.org such that they assign a CVE ID to it?

[Note: see the answer by @tim, which is a more thorough anwser than my quick google.]

MITRE has official documentation that answers your question right on cve.mitre.org, specifically have a look at https://cve.mitre.org/cve/identifiers/index.html which gives a thorough description of CVE Identifiers, how they are created, and how to request one.

The home page https://cve.mitre.org also has the following right in the main column:

  CVE Numbering Authorities (CNAs)

  CNAs are the main method for requesting a CVE-ID number.

  CNAs are major OS vendors, security researchers, and research organizations that assign CVE-IDs to newly discovered issues without directly involving MITRE in the details of the specific vulnerabilities, and include the CVE-ID numbers in the first public disclosure of the vulnerabilities.

  The following 22 organizations currently participate as CNAs: Adobe; Apple; Attachmate; BlackBerry; CERT/CC; Cisco; Debian GNU/Linux; EMC; FreeBSD; Google; HP; IBM; ICS-CERT; JPCERT/CC; Microsoft; MITRE (primary CNA); Mozilla; Oracle; Red Hat; Silicon Graphics; Symantec; and Ubuntu Linux.

  A message about turnaround times for requesting CVE-ID numbers from MITRE is posted above. For more information about requesting CVE-ID numbers from CNAs, visit the CVE Numbering Authorities page.

If you're not satisfied with the official answer, then please specify what you know, and what you're missing in your question.


How to check if a server is not vulnerable to Logjam?

Do the smoke test: (stolen from OpenSSL blog. (Archived here.))

openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key"

  The key should be at least 2048 bits to offer a comfortable security margin comparable to RSA-2048. Connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL 1.0.2. Earlier versions of the client do not display this information.)

(If the connections fails straight away, then the server does not support ephemeral Diffie-Hellman ("EDH" in OpenSSL-speak, "DHE" elsewhere) at all and you're safe from Logjam.)

[...]

  Finally, verify that export ciphers are disabled:

$ openssl s_client -connect www.example.com:443 -cipher "EXP"

  The connection should fail.

In other words:

get OpenSSL 1.0.2.
add the -cipher "EDH" option to your connect string.
assume vulnerability if export ciphers are enabled on the server
assume vulnerability if 512 bit (or anything less than 2048 bit) turns up.


If you see the information about somebody else, then it is not your account which is being hacked; rather, you are (involuntarily) hacking the accounts of other people.

If the server accepts to send you pages with private information about other users, then the server has a problem (most probably a mere, mundane bug; no need to invoke actual malice here) and there is nothing you can do client-side (i.e. on your machines) to really solve that. If you are positive that you are obtaining information that you should not be able to get, your best bet is to report the problem to Apple.


Are RADIUS and TACACS+ Ever Allowed in FIPS 140-2 Compliant Scenarios?
RADIUS:
Microsoft has FIPS-certified crypto modules for their recent operating systems (search for "Microsoft").
Enabling FIPS mode via Group Policy will force use of that crypto module.  However, as one answer pointed out, most RADIUS protocols are not allowable under FIPS.  PAP, CHAP, MS-CHAP, MS-CHAPv2 all use no/limited encryption or some form of MD hash (not allowed under FIPS).  There are some protocols that use FIPS-level encryption: EAP methods (PEAP, EAP-TLS).
TACACS+:
Cisco has taken their AAA servers through FIPS.  However, from the doc linked in one of the answers, it is only for 802.11i (wireless security using RADIUS), not for the TACACS+ piece.
One issue with TACACS+ (which is hard to find) is that it apparently uses MD5 to protect TACACS+ traffic.  Search "TACACS+ MD5" and you should come up with a SANS Institute document that makes this statement.  Cisco does not say on its website what TACACS+ uses for encryption.
Bottom line: TACACS+ in FIPS mode?  No, unless someone can show that the TACACS+ traffic is using 3DES or higher encryption.  RADIUS in FIPS mode? Yes, as long as you are using an EAP-method.


Considerations for information exchange agreement between governmental agencies

In my experience in high level agreements of any type it's very difficult to insert specific requirements relating to security due to the challenge of matching controls that different organisations have in place (i.e. trying to get the other party to state compliance against your specific standards)

That's why most times, you'll see language around things like ISO2700x ISMS' .  These form a common base where someone can say that the other party has a "reasonable" level of security in place (with the usual caveats that apply like the scope of the ISMS matching the use of the data etc)

Apart from that I'd say that the main security requirements you could consider would depend on how much you know about the specific data being shared under the agreement.

If you know for example that one class of data that's being shared should only be used by a specific department or individual in the other government that's something that would be worth adding to the agreement.

Also having a mapping of terms relating to things like protective marking could be useful to ensure that there are no mis-understandings relating to the information shared.


As I assume you want a monitoring tool beside the WAF, there are two well-known tools for this purpose:

ManageEngine event log analyzer
Nagios IIS log monitoring


With OpenID, should I ever refresh/reauthenticate?

Typically with Token Based Authentication you have two types of tokens:

Access Tokens

These are the tokens passed to actually request access to resources. They are short lived.

Refresh Tokens

These are tokens used to get a new access token once it expires. These have long expiration times and are stored securely on a system.

The idea behind this,is that Access Tokens will be used to grant you access to resources. They expire in a short time, so if compromised, access to the system is limited. Refresh Tokens only need to be used when you need a new Access Token, so don't travel over the wire constantly. The emphasis on storing Refresh Tokens securely.

Session Management

There is two method that can be used to store Tokens, Web Storage and Cookies. Of the two, my current preference is with Cookies with the flags HttpOnly and Secure set.


GnuPG does not verify signature while decrypting

gpg will verify the signature if the signature is over the encrypted content. In other words, say you generate fileA.gpg as follows:

gpg -r [Some ID] -o tmp.gpg -e fileA
gpg -s -o fileA.gpg tmp.gpg

Then gpg -d fileA.gpg will validate the signature of the encrypted content and then proceed to decrypt the data if the signature is good. Now if we do this in the opposite order of operations i.e.:

gpg -s -o tmp.gpg fileB
gpg -r [Some ID] -o fileB.gpg -e tmp.gpg

Then gpg -d fileB.gpg will simply decrypt the file and the result is a signature, but gpg does not proceed to do anything with the signature. In other words gpg will only verify the signature when performing decryption if the signature is for the data it is decrypting.


That means you need some way to access the Javascript code after it got downloaded but before it got executed.

Depending on the web browser, there might be a browser-specific way to create an extension or plugin which is able to access the website content before the rendering engine does. Refer to the relevant documentations about your web browser for details.

A much more browser-independent solution would be to create a local proxy server and configure all your web browsers to use that proxy server to access the internet. That proxy could easily examine all html and javascript files for malicious code before relaying them to the client. There already are solutions which work that way, free or commercial.

One problem with this solution is that it is impossible for a proxy to scan any content transferred via HTTPS. With TLS, the content is encrypted between browser and server, and the proxy has no way to decrypt it. But there is also a workaround for that: SSLStrip is an example for a proxy server which handles the TLS en- and decryption itself. It then re-encrypts the connection between itself and the browser using a new certificate signed by itself. This, of course, requires that the proxy servers root certificate is added manually to the list of trusted certificate authorities of the browsers.

While TLS certificate spoofing can be used maliciously, this method isn't uncommon in corporate environments to be able to filter the web from content which might be malware or distract employees from their work in other ways (games, porn, etc.).


Which PCI DSS SAQ applies when you don't store store but transmit CHD?

If your systems touch the cardholder data during transmission but you don't store any data, you will be an SAQ C.

For more guidance on determining you SAQ type, see the PCI DSS SAQ Instruction Guide v2.0 page 12, Selecting the SAQ and Attestation that Best Apply to Your Organization.


Ldap differences between {crypt} and {CRYPT}

I suppose that you are talking about an OpenLDAP server. It seems that OpenLDAP follows the format specified in RFC 2307, where we see:

    passwordvalue          = schemeprefix encryptedpassword
    schemeprefix           = "{" scheme "}"
    scheme                 = "crypt" / "md5" / "sha" / altscheme
    altscheme              = "x-" keystring
    encryptedpassword      = encrypted password

which would indicate that the "correct" scheme names are in lowercase, not uppercase. Since existing, deployed servers use uppercase names, it is probable that the name is not case-sensitive. In that sense, "{crypt}" and "{CRYPT}" would be equivalent and designate the same algorithm.

Since RFC 2307 is both old and marked "experimental", there is no guarantee here. I suggest that you try it out by taking one "{crypt}" entry and changing it to "{CRYPT}", and see if the user can still log in.


CORS works by determining if the request target responds with an Access-Control-Allow-Origin (ACAO) header. In this case, the request target is the performance probe. It does not matter whether the page is served with an ACAO header.

From Wikipedia:

  Note that in the CORS architecture, the ACAO header is being set by the external web service (bar.com), not the original web application server (foo.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application. For the latter, Content Security Policy should be used (connect-src directive).

Assuming that the same-origin policy is implemented correctly, a user agent (browser) that does not support CORS will simply produce an error when making a cross-origin request.

A user agent that supports CORS will make a cross-origin request with the Origin header containing a value of the site where the request is sent from and one of the following situations will happen:

Response does not contain an Access-Control-Allow-Origin header. In this case, the browser will simply produce an error as the server does not allow for cross-origin requests.
Response contains an Access-Control-Allow-Origin header with a value of *. In this case, the code will continue executing as any site is allowed to make a cross-origin request to the server.
Response contains an Access-Control-Allow-Origin header with a list of origins. In this case, if the current site is in the list of origins then the code will continue executing as it is allowed to make a cross-origin request to the server. Otherwise, an error will be produced.

The above points are a slight oversimplification of the actual process. There can be more Access-Control-* headers involved.

For complex methods (i.e. non-simple methods) there is an extra step involved known as preflight in which a preflight request is made before the actual request.

Here is a flowchart that shows the process. The OPTIONS call represents the preflight process.

(Image used with permission, licensed under CC-BY-SA 4.0 by Bluesmoon [source])

You can read more about using CORS on HTML5 Rocks. The CORS specification is pretty helpful as well, though the wording is technical because after all, it is the specification.


Does changing /etc/ssh/moduli impact previously generated keys?

You'll be fine. /etc/ssh/moduli is only used by sshd:

  The /etc/ssh/moduli file contains the system-wide Diffie-Hellman prime moduli for sshd(8).

sshd has nothing to do with client keys that you are using to connect to other machines.


Lua loadstring, whitelisting against injection

I would recommend spending a little effort writing a parser for the arithmetic expressions in the input rather than dynamically executing it as Lua code. Even if you haven't got a third party parsing library available, it's not too difficult to write a lexer that splits up a string in relevant symbols, and then traversing those with a state-machine or recursive function.

Remote-code injection vulnerabilities are very serious, and there are so many possibile avenues for attacks here: what happens if an attacker tries to divide by zero? Or tries exploiting a bug in your Lua interpreter? Or does something weird with character encodings? Or uses some obscure language feature you did not think about? Considering all these matters is probably a lot more work than writing a parser for simple arithmetic expressions.

Even if you were able to choose a whitelist that would render this completely secure, it might still be possible that some future version of Lua introduces some new syntax or feature that would allow a new attack on this.

Another potential issue: if you would want to introduce some new feature in the future (e.g. also allowing users to compute square roots) you would either need to drop this approach and start building a parser anyway; or expand your whitelist, making it more complicated and therefore more likely to be insecure.


How do I make sure it is actually authenticated user performing an action?

In my app (and website) a user logs in with their email to perform actions like making a comment on the website under their name. Obviously it is important that malicious people cannot pretend to be this user and send comments on their behalf.

  I read that any state changing actions should never be performed by a GET request. What is to stop someone from creating a POST request using the authenticated user's email address? Is it possible for someone to tell my website to perform a POST request and spoof the inputs?

Yes, an attacker can certainly craft any request they want.

You are on the right track, but what you've done is reinvent sessions. The user provides authentication information (generally a username and password), you create a session and send it back to them as a cookie value, and then every subsequent request comes with the session id and you verify it against your session database to know who the request came from.

  Is transfer of authentication_token safe over https?

This is a session stealing attack, popularized by Firesheep. Using https is the generally accepted mitigation. Attacks tend to try to avoid https, eg via sslstrip, so you should abide by https best practices, like HSTS.


Reliability of Certificate Authorities and Certificates in 2015

Are there any truth to these claims? Is there any data to support it?

What data you need to support the claims apart from the ones already in the article? Netcraft is usually not a company which makes unfounded claims.

  Has the Quality of PKI for the web gone down lately?

I don't think so. But since more and more users link SSL with security and phishing sites want to look secure the existing system of lousy checks by the CA gets more abused. Most users don't understand that SSL only protects the transport and does make any statements about the security of the site itself.

But actually, from the perspective of a potential victim a site like https://phypal.com (example from the Netcraft article) is probably not more trustworthy than https://paypal.secure-payments.toplevel or https://support.toplevel/paypal/ which you could probably easy create even when stricter checks are done by the CA. There are usually lots of ways to make your site look trustworthy. In my opinion it is much more important to educate users what kind of security they can really get from SSL, and what it does not protect against.


From the DB try to get a shell or at command execution. From there you can poke around the whole file system and OS to try to find a way to elevate to root, assuming the DBMS is not running as root.

Since your friend rents the VPS it might be better to just review the configurations and setup and provide input based on that. But trying to get root is fun, so maybe do both. If you get root you can then look at all the configuration and setup to review it.


The XML standard will implicitly decode all attribute values. When rendering an HTML page, these attributes are interpreted as their decoded character literal values before interpreted as a possible JavaScript event.

In the context of XSS, a DOM event can lead to XSS by undermining the escape routine used to build the XML document.  For example, the following escaped sequence is an XSS vector:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);sendHaxor(document.cookie);//');" />

This is one of the many reasons why the Content-Security Policy (CSP) is valuable at preventing the slippery problem of XSS.


What credentials does this hardware device steal?

The article mentions that Responder is used, which is a tool for grabbing NTLM hashes from a variety of Windows protocols using LLMNR/NBT-NS/mDNS poisoning.

Basically, it takes advantage of the fact that many background connections are made by Windows, most of which rely on an identification/resolution protocol that has no guarantee you are talking to a legitimate server.

The same can also be done with a $10 Raspberry Pi Zero (or similar). Take a look at PoisonTap as well.


Reverse TCP connection from exploited SearchIndexer.exe failing

Allright, answering my own question. SearchIndexer and other services are protected by Windows Service Hardening. A part of WSH functionality is firewall rules for the service based on the way the service is supposed to communicate. So if the service is not supposed to communicate over the network, the developers may restrict it's ability to connect/receive data on the network.

The WSH firewall rules are checked before and independently of the Windows firewall, so even if you turn that off, they will be in effect.

The effect of this is that SearchIndexer.exe is not allowed to make outbound connections.

Fortunately, the WSH firewall rules are set in a registry key, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable. Deleting the SearchIndexer subkey makes the exploit work flawlessly:


Can servers store the mac address of the computer on the server side to prevent session hijacking?

Using the MAC address as a condition for session termination in general

Generally a changed MAC address might be used as a weak condition to terminate sessions, but be aware

they can be arbitrarily faked for most network cards (so you just need to find one which makes this possible)
they will also change when a user is on the same device, but switches network interfaces (for example between mobile broadband, WiFi and Ethernet connection).

Servers do not know MAC addresses of clients

Anyway, learning the MAC address is not possible for a server, as the server does not receive the client's MAC address at all and cannot query for it (as long as he's not on the same network segment, which will pretty much never happen in any internet scenario).

MAC addresses are only used for data transmission on OSI layer 2 (Data link), and MAC address information of the previous sender is discarded by each router on the path as he replaces the frame headers for the next hop.

The Address Resolution Protocol ARP will not help at learning the client's MAC address either, as it's limited to the local network segment.


What is the Purpose of placeholders (e.g. %k, %f) in some GnuPG options?

Using those placeholders is especially helpful if you define such notations in your GnuPG configuration (~/.gnupg/gpg.conf). These placeholders get replaced by GnuPG just before the notation is applied (or the photo viewer called, ...) to be able to insert some information on the current operation. From man gpg:

  There are special codes that may be used in notation names. "%k" will be expanded into the key ID of the key being signed, "%K" into the long  key  ID  of  the  key  being
                signed, "%f" into the fingerprint of the key being signed, "%s" into the key ID of the key making the signature, "%S" into the long key ID of the key making the signature,
                "%g" into the fingerprint of the key making the signature (which might be a subkey), "%p" into the fingerprint of the primary key of the key  making  the  signature,  "%c"
                into  the signature count from the OpenPGP smartcard, and "%%" results in a single "%". %k, %K, and %f are only meaningful when making a key signature (certification), and
                %c is only meaningful when using the OpenPGP smartcard.

For example, consider you're running some certification service and host a website with further details on the certification of each key. If you want to append a notation containing a URL to further information on the signed key (without any discussion on how to achieve that), you could add following to your gpg.conf:

cert-notation details@cert.example.com=https://cert.example.com/lookup/%K

If you now sign a key 4E1F799AA4FF2279, following notation will be appended:

details@cert.example.com=https://cert.example.com/lookup/4E1F799AA4FF2279


By default, a user’s SSH keys are stored in that user’s ~/.ssh directory. You can check if your private key is in that directory by listing the contents:

$ cd ~/.ssh
$ ls
authorized_keys2  id_dsa       known_hosts
config            id_dsa.pub

The private key is usually something like id_dsa or id_rsa. To regenerate the public key part with just a private key, use the -y switch to the ssh-keygen application and write the output to a corresponding .pub file:

ssh-keygen -f ~/.ssh/id_rsa -y > ~/.ssh/id_rsa.pub

From the 'man ssh-keygen' description:

 -y      This option will read a private OpenSSH format file and print an
         OpenSSH public key to stdout.

If you don't know whether your private key is Digital Signature Algorithm (DSA) or Rivest Shamir Adleman (RSA), you will have to use the ssh-keygen application with the -f switch. Make sure the name of your new public key matches the name of your private key.