Telegram messages in group are seen immediately We have a small friends group using Telegram Messenger without any bot attached to group. When we send message in this group it is always seen (double checked) immediately even at midnight and hours that seems no one is online. Is there any security problem or any third party software attached to our group?

I think your group is in fact a so-called Super Group. Super Groups work a little differently than normal groups and the one-check/two-check system doesn't apply here. All messages get double checks instantly when received by the server. (That's a feature.)

The creator of your original group has clicked the 'upgrade to supergroup' button at some point, causing your group to upgrade. You cannot undo this upgrade, so if you want to go back to a normal group, you'll have to create a new one.

I'm guessing it has something to do with the original intend of Super Groups being aimed at large communities. These Super Groups were originally introduced for groups larger than 200 people, but since then the group and Super Group limits have been increased to 5000 members and upgrading to Super Groups is unlocked for Groups of any size.

Here is the original release blog post: https://telegram.org/blog/supergroups


Can a TPM storage key used to generate encrypt leaf key (child key) if it is stored outside TPM? In a TPM, if I create a storage key by Storage Root Key (SRK) and store it outside TPM (migratable), the SRK can be its parent key to encrypt it.

If the storage key is generated by SRK and then stored outside TPM, can this storage key used to generate and encrypt a leaf key? Or only non-migratable storage key can be used to encrypt its leaf key?

What are the common case?

Migratable doesn't mean it is stored outside the TPM. All keys except the SRK and EK are stored outside the TPM.

The TPM protection comes from the fact that the blob stored outside the TPM are encrypted by the SRK and can only be used when we feed back in the TPM.

The 'migratable' distinction defines that a key is not tie to a specific TPM and can be used (with proper authorization) elsewhere. I suggest reading this document to understand the different migration process options even if it seems a little outdated.

IIRC, only the EK, SRK and Certification Keys cannot be migratable. You define whether a key is migratable or not at creation time.

Updated: Here's two other documents covering the process to different extent.

TPM Key Management and Key Replication Mechanisms
Introduction to the TPM 1.2 - see section 7


When paying by card on a website, will fake payment information make the order fail? When ordering online websites often redirect to a payment service like 2Checkout (see image below). On their page I must specify my personal information (like name, address, city, sometimes birth date), as well as my banking card information (like card number, CCV, expiration, owner name).

What do they do with my personal information which are not my banking card information?
Why is it required?
Is it their own policy or an international banking policy?
What happens if I just put James Bond born in 1980 living in 9000 South Pole Street, South Pole instead of my personal information (as long as my banking card information is correct)?

Verified by Visa (VBV)

  Verified by Visa helps prevent people using your details without your
  permission. And it’s good for retailers who want to make sure their
  customers are protected.

  When you complete your payment with Verified by Visa, your bank is
  able to make additional security checks to ensure your card details
  have not been compromised. Your bank wants to make sure that it’s
  really you making the purchase before they authorise the payment.
  After all, nobody would expect to take cash out of an ATM without
  using their PIN. Your bank wants to give you the same high standards
  of protection on the internet as well. VISA

As I understand the legacy payment system using CVV, exclusive, only requires three things: Card Number, Expiry Date and CVV. Anything else should not matter. However, this is why Verified by MasterCard and Verified by Visa came about, to mitigate this attack vector.

  What do they do with my personal information which are not my banking card information?

This can relate to the individual countries money laundering laws. Equally, this could be for their records, to detour fraudsters from committing fraud. As I understand, credit card (MagStripe and CVV) is not particularly difficult. Although, this is not a huge issue for the customers as authorisation hold is performed. Could the legacy system have been better, yes!

  Is it their own policy or an international banking policy?

If approached by the police, then they have records:

Card details
'Owner name'
Transaction time and date

  What happens if I just put James Bond born in 1980 living in 9000 South Pole Street, South Pole instead of my personal information (as long as my banking card information is correct)?

If a legacy payment system is used, then this should work. This is difficult to make a statement about because individual companies do not publish the source code for their antifraud systems. Hence, some conjecture with reverse engineering needs to be done here. But, this is why VBV and VBMC exist. To make this type of fraud more difficult.

So, the company's anti-fraud system should check:

Does our personal information match the card details?
Should additional verification be performed?
Is the email address domain from a 'blacklisted' domain?

In England, Anti Money Laundering Acts, require companies to validate each user with: government issue ID, utility bill, and sometimes a webcam chat. Before their account is marked as 'verified'. This is behaviour is seen with exchanges, LocalBitcoins encourages this model.


In the age of BadUSB, are micro SD cards a secure alternative media immune to those style of attacks? Why or why not? As a corollary, I saw a presentation description in a recent CCC demonstrating the (non-hostile) use of micro SD cards as a cheap source of processing power. Does this render micro SD card fundamentally vulnerable, or potentially vulnerable, to the same type of attacks? Why or why not? Does it make them open to other forms of attacks? Why or why not? Are there other alternatives that are immune? Micro SD cards are nice because there are now SD card bays in most mobiles and workstations alike.

SD cards of any flavour do not provide processing capabilities except internally to support standardised data access. They are not a source of processing power, cheap or otherwise.

The main advantage over a USB key is that it is harder to squeeze the required hardware in them that could be used to attack a PC via the USB port. That does mean they are less vulnerable. Also, the standard interface for SD cannot be used for power which removes some of the other potential issues with a USB interface.

There are cards that do have processing capability and that have the same connector layout as SD cards, Smartcards and SIM cards for example. And there are smartcards that have significant security processing capability (most have fairly minimal capabilities) but this is not the same as the SD memory card format.

So bottom line is that SD card slots are safer than full USB ports but they are not immune to some attacks such as autoplay.

If you need more, look for a PC with a smartcard interface.


Is it safe to hash passwords on the users device? I don't know much about hashing, but I noticed a (relatively reputable) site logging me into my account by sending the url parameter "hash=longStringIAssumeisTheHashOfMyPassword".

The point of hashing passwords is so that if an attacker gained a list of all of the hashed passwords, they still wouldn't be able to get into accounts. If they are hashing my password on device, couldn't a hacker bypass the hash?

If I get a list of hash passwords, couldn't I just go to site.com/login?hash=stolenHash and login?

It's also sending my ip as a parameter, I'm not as worried about that, but it looks like anyone could type in any IP they want there.

Am I completely wrong, or is this something I should report?

edit: The hash apears to change every time I login, but I can login with old hashes multiple times.

This completely depends on what the server does with the provided hash. If the server simply puts that hash into its database, and then compares the hash you send to the value in the database, then yes, that would have the problems you describe.

Instead, the way this should be done is to first stretch the password locally, and then hash again on the server. "Stretching" means to apply a time-intensive key derivation function (KDF), most commonly PBKDF2. This mixes additional "salt" data into the password, and applies a hash function in a specific way to convert a human-provided password into something that is "effectively random." How that salt data is generated depends on the system. It may be random, or it may be based on some static but unique piece of information such as the user's id. There are several approaches here that provide reasonable trade-offs.

The resulting stretched value should then be sent to the server. Doing it this way ensures that the server never sees the user's actual password.

Once the server has this value, it should then apply some fast cryptographic hash function (SHA-2 most commonly) to that value and use that hash to compare to the database value. Doing it this way ensures that even if an attacker has access to the database, they cannot use that to directly login.

Based on your edit, I suspect that what they're actually sending is an encrypted password or encrypted hash. They are probably encoding something like a timestamp in the encryption. Whether this is implemented in a secure way depends highly on the details, but there is nothing inherently insecure about this approach. (The fact that old hashes are reusable is not ideal, but whether it is a significant concern depends on the rest of the system.)

As a first guess, I would assume it's insecure and badly designed, but only because this is always the working assumption when assessing a security system until proven otherwise. Without exploring the details, it's not possible to evaluate this system, but nothing you've described is incompatible with a good system.


Should I report the IP address that an attack is coming from? Is so, who to? My web site was under an SQL injection attack for a while. After it was noticed, I closed the problem places and the attacks have failed.

Examining the logs I find about 46 unique IPs have been trying to run SQL injection attacks consisting of more than 500 GET/POST requests over a couple of weeks (highest one was 147816 requests).

After the loopholes were closed the number of requests dropped right down (to a handful a day - probably just probing).

My question is, is there any point trying to report these guys? They are probably from some compromised machine somewhere, so maybe not.

Related: Is there a way to report IP addresses scanning for Exploits?

However this isn't a scan - the volume implies they knew it was a success.

I can imagine a couple of scenarios:

These addresses are actually the attacker, in which case they may be able to "assist the police with their enquiries".
These addresses are from some innocent victim, in which case they would probably be pleased to be told their machine is infected.

Assuming the answer is "yes, report it", the next question is "to whom?". If I have to spend an hour filling in a lengthy form, per address, it won't really be worth it.

Countries involved

(edited to add)

I am in Australia.

The most prolific attacker is in Montreal, Canada.

Others are:

Bromley, UK (near London)
Glattfelden, Switzerland
Amsterdam, The Netherlands

It's hard to see one police jurisdiction getting interested in this, unless they have a special department to handle world-wide attacks.

If you are suspecting they are using a compromised machine, you can notify the administrator of the network. You can find contact information by doing a whois lookup:

$ whois 151.301.193.69

...
OrgAbuseHandle: ABUSE4771-ARIN
OrgAbuseName:   Abuse Account
OrgAbusePhone:  +1-555-496-9353
OrgAbuseEmail:  abuse@example.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE4771-ARIN


What to do when asked for a weak password The guys who made the security for my country's state bank are completely nuts in all senses. Their internet banking password must be between 8 and 10 characters, and contain only letters and digits.
I don't think I need to stress how insanely backwards such restrictions are.
In another news, my card's password must be exactly 4 numbers. I'm pretty sure most passwords are an year, and quite possibly an year between the first half of the past century and the current.
Meanwhile, my e-mail password has... 35 characters.
The only non-public thing needed to set up the online banking account is to have that 4-number password. It's also used in their ATMs along with a 3-syllable case-insensitive password that the bank gives you. I guess they realised their passwords were weak, so they thought, "hey, let's top that up with another insecure password".
Speaking of ATMs, they run some Windows version that I believe to be between 9x and 2k, whose desktop I saw in a ATM whose software seemed to have suffered a buffer overflow (there was a command prompt window open). This doesn't reassure me that they take security seriously.
So the question is:
When asked for a weak password, in the sense that the character set and count is limited, what do you do?
I considered hashing my current password, but it would be a nuisance to generate the hash all the time. My current solution involves applying a rememberable algorithm to the aforementioned 35-character password that I use in my e-mail.

Edit: even though an answer has been accepted, you're welcome to share your thoughts.

As discussed in the comments section, password based security is very minimal for banking, as it is worth the effort for a thief to try to steal your password. They basically only have to infiltrate your browser and log your entries. Furthermore, if this is achieved, they have full access.

Approaches such as hashing or other algorithms do not really matter, as you still will be typing in a password that has to commit to the set limits. Thus, you are really only making it harder to remember for yourself, but someone trying to bruteforce -- although it still is a lot of characters for bruteforcing -- still has to do the same effort.

We also discussed other approaches, such as security tokens -- which I personally prefer -- and SMS-based one time passwords. The idea of the former being that you must have your card at hand, and use this to set a signature. However, most non-connected implementations work by signing a number (hash) that most users cannot relate to the action that is about to take place, so a smart attacker may try to fool you by changing the numbers on the screen and the actual numbers. This is where the connected token comes in, which uses its display to show you the complete action you are about to allow, which is probably the most usable secure method out there at the moment. However, I have no idea on banks supporting these techniques in your region.

Finally, with banking security, auditing is most important. Check your statements for crazy transactions and report those as soon as possible. This still is the best approach to banking security. Recall, for example, that credit card fraud is not so hard, but recalling transaction is not hard either.


How is mailbox.org 2FA method referred to as, correctly? Their 2FA to log in to their web interface requires two things:

something you know (PIN);
something you have (OTP, generated by app for example).

After that, you need to log in by:

input email address;
input PIN, in password field;
input generated OTP right after PIN, in password field.

I have never seen such a 2FA method and from an ignorant-point-of-view, it seems ineffective or less secure (at least).
Hence, I want to learn about it and before doing so: I need to know how to refer to it, so I can make my searches.
What is it called?

I've only heard of this method being called OTP "append mode".
From what I can tell, it's a legacy / backwards-compatibility method of 2FA, for cases where an interface doesn't support adding an additional authentication step or field.
Examples include some modes of Symantec's VIP offering (used on a few major financial sites like E*TRADE; and because it's one of the earliest solutions, it uses append mode to make it easy to integrate without modifying login pages); and Duo's append mode.
From a UX perspective, it's pretty confusing for users. Unless the authentication site/context makes it very explicit how to do it, and because appending the OTP isn't intuitive (very different from the other authentication workflows most people carry out every day) ... it's very easy to forget to mess it up - to forget to append, or enter only the OTP or only the password, etc. So the support burden (user lockouts, support tickets/calls, etc.) is probably pretty high.
So it's probably better to avoid OTP appending unless there's a backwards-compatibility need. (But it's no less secure than other options, as long as the OTP is truly randomly generated and expires in a small time window.)


Why are SSL handshakes secure and why can't a hacker look at that and decrypt the data? If I understand right, there is a "handshake" where both the server and the browser verify who they are and agree on an encryption key. Why cannot a hacker just watch the network for the keys going through?

Why can't a hacker just watch for the handshake, collect the data, and run it through a easy-to-write piece of software?

See the Handshakes section of Thomas Porrin's answer to How does SSL work? for full details, but for the very short answer:

Because the first handshake of a sessions ends up using asymmetric cryptography to encrypt a symmetric key to the other side's public key (which is indeed available via packet sniffing), and then the other side uses their private key to decrypt it.  This private key is not transmitted between the two, and without it, it is prohibitively difficult to decrypt the message containing the symmetric key (barring implementation or design flaws).

After the symmetric key is transferred, then a symmetric cipher can be used since there is a "shared secret" key.


What information could be identified about a Virtual Machine which routed traffic via a VPN? Background:

I have a Virtual Machine which is running all it's traffic through a VPN (from within the Virtual Machine) so to obfuscate all web traffic. This Virtual Machine is running from within an account with limited privileges on a Windows PC.

This Virtual Machine would be used to access the internet and whilst the Virtual machine is running, all it's data will be held in volatile form.

To be clear:

I'm not asking how to secure this Virtual Machine.

What I would like to know is:

What information or data concerning the activity of the Virtual Machine could be logged either by the Windows Machine (which the VM is running on), or by the network surrounding this Windows Machine?

Thanks

What information or data concerning the activity of the Virtual Machine could be logged either by the Windows Machine (which the VM is running on)

Everything. The host has complete, unrestricted access to the guest. It may be possible in the near future to make VMs a bit more secure from their hosts by utilizing SGX (Software Guard eXtensions) on Intel Skylake processors. These use the CPU's Management Engine to encrypt data in memory so even the host's ring 0, the supervisor mode, cannot view it.

If you are asking what is unintentionally left over on the host, as opposed to maliciously snatched by the host, then it's mostly limited to swap (called virtual memory on windows) which is written to the disk when memory pressure is high, coredumps, which are performed when certain applications crash, and screenshots, which many virtual machine managers automatically take.

  or by the network surrounding this Windows Machine?

Other than side channel metadata such as packet sizes and timings, an external network may be able to tell the guest's operating system version and uptime. See http://lcamtuf.coredump.cx/p0f3/ for an example of this, called TCP fingerprinting.

Note that a VPN does not obfuscate web traffic, it encrypts the contents of web traffic. This is fine if you are trying to hide the literal contents of your communications from your ISP, but it is not particularly effective at keeping you anonymous.


Serving javascript from an API and having that execute on the client I have been proposed a solution where our API serves up some JavaScript which will be executed on the client. The code will render some HTML on the client and provide some functionality such as calling other APIs and verifying info entered into the dynamically rendered elements.

In essence it would do everything a programmer would do if they wanted to call this API, we are just providing a pre-packaged version of all that. So the rendered HTML and JavaScript wouldn't be doing anything that we wouldn't be doing on the client anyway.

From an initial walkthrough I can't see anything insecure with this approach so long as the API we are executing the JavaScript from is trusted. are there any major security flaws with this approach?

EDIT

I am not an expert in security, but here is a hopefully better explanation of my concerns.

If a hacker gets into our system, the API is the last thing we are worried about because we have a bunch of other more valuable things he will want. However, if this API which serves dynamic JavaScript makes it any easier for a hacker to get in then that becomes a concern.

Additionally, I have always been skeptical of dynamically executing code, I have been taught under the notion that it is inherently insecure, which is why I am asking this question in the first place. Admittedly I don't see why it is insecure unless the dynamic code is being generated from user input, so my other concern is, are there any inherent security holes in running this dynamic JavaScript so long as it is coming from a trusted source.

By trusted source I simply mean, we are hosting our API at www.myapi.com/some/stuff. So if the client calls the endpoint at that URL we are going to assume that it is a trusted api. Maybe that's bad to do? I don't know I am not a security expert.

Also, we are going to be serving everything over SSL.

It's not clear what your threat models are or how you designate any of the nodes in the system as "trusted." Here's a short list of things you should have already considered:

What happens if the primary API is compromised (e.g. hacker serves malicious javascript code from the API)?
What happens if the connection between the primary API and the client is compromised (e.g. MITM (are you using SSL?) injects malicious javascript code)?
What happens when the client's computer is compromised (e.g. client starts hacking around to see what happens) and sends other "locally-verified" commands to the other APIs?
What happens when the connection between the client and the other APIs is compromised (probably no different effect than if the client's computer is compromised)? Or the other APIs themselves are compromised?


Security of different Filesystems Are there any preferred filesystems that have some boni regarding security and confidentiality? Or does it really not matter if I, for example, encrypt a HDD with LUKS?

As an example, I read that the ZFS file system has some good implementations against data corruption which I would consider a bonus for security.

LUKS is just the encryption to the disk itself. LUKS can exist on any partition and the filesystem is whatever it has been formatted to. If you're running ZFS and you create a /dev/loop point for it and encrypt it with LUKS, you'll be running whatever file system you use to format the /dev/mapper/device, in an encrypted container, on top of zfs. Ex: EXT3|LUKS|loop|zfs

Learn about using lvm. You'll thank me.


What is the most secure way to store cross subdomain cookies I am working for a company we will call "Company x". This company has a domain companyx.com. They have a cloud platform that manages things like SSL, but in order to do this you are required to use that domain. There are 3 apps app1, app2 and app 3 that have the following urls...

app1.companyx.com
app2.companyx.com
app3.companyx.com

These are need to use stateless auth since they are highly scalable. All of these "share" the same session (JWT) using a cookie that is http-only and secure but because there is no way to create a subdomain are all using the companyx.com domain for their cookie.

The security team has pushed back saying that we are "providing the cookie" to the whole domain. This seems a little weird to me since the company also controls the core domain but I also know there is a lot of focus today on internal as well as external threats.

So is there a way to structure the cookie so that app1, app2, and app3 have access but app4 does not? Is there a more secure way than just using the core domain? How big of a threat is this really?

From RFC 6265:

5.1.3.  Domain Matching

 A string domain-matches a given domain string if at least one of the
   following conditions hold:

   o  The domain string and the string are identical.  (Note that both
      the domain string and the string will have been canonicalized to
      lower case at this point.)

   o  All of the following conditions hold:

      *  The domain string is a suffix of the string.

      *  The last character of the string that is not included in the
         domain string is a %x2E (".") character.

      *  The string is a host name (i.e., not an IP address).

That is, if the domain name in your cookie's domain parameter doesn't start with a period, then it will not let subdomains read that cookie.  If it does start with the period, then all subdomains will have full access to that cookie's value.

For example:

Set-Cookie: lang=en-US; Path=/; Domain=example.com

Can only be read by example.com.

Set-Cookie: lang=en-US; Path=/; Domain=.example.com

Can be read by example.com and any subdomain, including foo.example.com, baz.bar.foo.example.com, and baz.example.com.

Set-Cookie: lang=en-US; Path=/; Domain=foo.example.com

Can only be read by foo.example.com.

Set-Cookie: lang=en-US; Path=/; Domain=.foo.example.com

Can be read by foo.example.com and any subdomain, including baz.bar.foo.example.com, but not example.com or baz.example.com.

If you want to share cookies across subdomains, but leave out other subdomains, you should explicitly state which subdomains you want to read them, setting a new cookie for each, rather than using wildcards.


Truecrypt - One keyfile multiple passwords Is it possible to create one keyfile that opens a Truecrypt volume and this keyfile is protected (aes encryption fe) with a password?

The use case is a True crypt volume accessed by multiple individuals. I would like to distribute one master key in the form of a keyfile with high entropy to prevent brute forcing if the volume gets in the hands of a malicious person. This keyfile is distributed on a usb token where it should be encrypted with their personal password.

What you have described will work perfectly fine, and I would suggest using TrueCrypt again for encrypting the keyfile, given that all participants already know how to use it. Simply create a TrueCrypt partition on the USB device, and put the unencrypted keyfile into that partition.

Doing it that way also has the advantage that it is impossible for a user to accidentally leave the keyfile unencrypted. If you were to use file encryption such as openssl to encrypt and decrypt the keyfile, it would be possible for someone to forget to re-encrypt the keyfile once they have finished using it. Using an encrypted partition via TrueCrypt means this is not possible, which is good.

The drawback here is that you have multiple copies of your keyfile spread around the place. Some users might think that plugging in the USB, entering their personal password, and accessing the keyfile every time they want to access the shared TrueCrypt partition is a hassle, and there is nothing to stop them from copying the unencrypted keyfile onto their local disk for the sake of convenience, which breaks the encryption for everyone.

You are also relying on the strength of the weakest personal password, which with a large number of users is likely to be very weak.

You also have the problem of revoking access: it is difficult to remove a person from the 'circle of trust' because everyone knows the same key. You would have to redistribute/replace the TrueCrypt partition under a new master key, and update everyone's keyfiles to match.

LUKS solves a lot of these issues by allowing multiple passwords to unlock the same disk. Provided the permissions are set up correctly, it is impossible for a user to get the master key for a disk, even if that user knows a valid password for that disk. This makes access revocation very easy.


Classical Cryptography Tools I'm wondering if there are any tools out there that can assist in solving classical cipher text.  I'm looking into developing some tools such as frequency analysis, transposition tools and so on but want to know what is already out there.  I suppose it wouldn't be just a technique specific tool such as for caeser ciphers only but something that might help in solving something that may or may not be a caeser sipher.  I know it sounds a bit shady but its all for educational purposes.

http://www.cryptool.org/ - free, and have all that you need for educational purposes. I use it in different cryptography trainings.
From their site:

" Numerous classic and modern cryptographic algorithms (encryption and decryption, key generation, secure passwords, authentication, secure protocols, etc.)
 Visualization of several algorithms (Caesar, Enigma, RSA, Diffie-Hellman, digital signatures, AES, etc.)
 Cryptanalysis of several algorithms (Vigenère, RSA, AES, etc.)
 Cryptanalytical measurement methods (entropy, n-grams, autocorrelation, etc.)
 Related auxiliary methods (primality tests, factorization, base64 encoding, etc.)
 Number theory tutorial
 Comprehensive online help
 Accompanying script with additional information about cryptology"


Is it possible to stop webcam surveillance by having an always running camera application? Blocking the camera isn't something new, using a piece of tape.

When I try to create or launch or run multiple programs which take a feed from camera, only the first one gets access, others don't get access.

Instead of physically blocking a camera with a piece of paper or scotch-tape, what if I logically block the camera, by running a script like this.

import cv2

def show_webcam(mirror=False):
cam = cv2.VideoCapture(0)
while True:
    ret_val, img = cam.read()
    if mirror:
        img = cv2.flip(img, 1)
    cv2.imshow('my webcam', img)
    if cv2.waitKey(1) == 27:
        break  # esc to quit
cv2.destroyAllWindows()

def main():
    show_webcam(mirror=True)

if __name__ == '__main__':
    main()

Wouldn't it be more smarter to secure privacy.

Is there something I am missing?

I take it as a dilemma whether a physical protection of a camera is significantly better than a software protection (given an example of the latter). With that in mind, this is ultimately a risk assessment question. For an ordinary user, there might really be no difference, but they could probably as well get away without any camera covers.

Physical security is so much different from a software security. If a recording device is disabled physically, there's virtually no way to get around it, if a camera cover isn't supplied by the NSA. Contrary, for a software solution, there would always be a plenty of theoretically possible ways to get over a simple script.

E.g. your Python script allocates some memory, thus might be forced externally to be killed by the OOM killer, and after that a malicious process might immediately take over the recording device. Or, the mutual locking within your OS around the camera might not be as strong as you think. Or, your script could be broken by a software dependency update. Or, anything else.

Those are issues that are there even if there's no possibility that a rogue process might have a system-level access to your computer (whereafter you have no chances to win against a skilled attacker, whilst a camera cover would cover you — taking in account though that your microphone device would still be exposed).

Physical solutions are tough and always hard to maintain, but they are reliable as well.


Access Control for REST APIs - OWASP recommendation OWASP states:

Non-public REST services must perform access control at each API
endpoint. Web services in monolithic applications implement this by
means of user authentication, authorisation logic and session
management. This has several drawbacks for modern architectures which
compose multiple microservices following the RESTful style.

in order to minimize latency and reduce coupling between services, the access control decision should be taken locally by REST endpoints
user authentication should be centralised in a Identity Provider (IdP), which issues access tokens

Does this mean that we should have an IdP integration in every microservice we build?
It seems really confusing and not feasible at all in a microservice architecture. I imagine things get easier with something like a service mesh, but we're still not at that level of maturity.

Background
Lets start from the top here. Your server receives a request:

Hi server,
Can you do X for me?
- Jane

Access Control is when the server checks to see that Jane is actually allowed to do X before processing the request. Generally speaking, all apps will have some endpoints that need an access control check -- maybe Jane is not allowed to delete records from the DB, or maybe Jane is not allowed to change settings of Bob's account, etc.
OWASP's point is that in an old-school app, when the user logs in, you might build a session info object telling you who the user is and what permissions they have, and keep that in server memory until the user logs out. Obviously that does not scale with modern cloud architectures.
JWT To The Rescue!
The key part of that OWASP quote is (emphasis mine)

user authentication should be centralised in a Identity Provider (IdP), which issues access tokens

Take anything that your microservices need to know about the user (ie anything that you would traditionally have put in the sessionInfo object) and stuff it in a JWT, hand it to the user, and have them hand it back with each REST call. Omitting the crypto parts of a JWT, the claims you care about might be:
{
  "sub": "48",
  "name": "Jane",
  "admin": true,
  "exp": 1621004706
}

Now, by unpacking the JWT from the request, microservices have everything they need to make an access control decision; no network calls needed! Trying to delete data? Do they have Admin: true? Trying to change Bob's settings? Are they Bob?
To make this all secure, we rely on the fact that JWTs are cryptographically signed (and sometimes encrypted, but that is optional) by the IdP. So to make this whole thing work, the only piece of info the microservice needs is the cryptographic key to verify the signature on the JWT. This is generally static, so you can stick it in config data or whatever. If the IdP is external (say you've integrated with Google or GithHub's SSO service) then the JWT verification key will be an RSA public key. If your IdP is an internal component of your app, then you can simplify a bit and use a symmetric HMAC key where the IdP and the microservices all have the same "JWT secret" in their config.
Service-to-service
Question from comments: is this model applicable for a service-to-service API?
Sure, why not?
Your client, even an automated one, will typically have some sort of long-term credential, typically an API key or a TLS client cert. You still want to make the client authenticate against a central IdP for a number of reasons:

The long-term credential usually does not carry all the meta-data. So something in your backend needs to look up the associated meta-data.
What if that access changes? Say you're auditing your config and realize you gave that component wider DB access than it really needs, or heaven-forbid someone accidentally posts that client secret key in a public git repo and you need to revoke it.

Doing the full access control check against the DB on every HTTP request is really expensive, but issuing a JWT with an expiry timestamp and forcing the client to re-do the /auth/login every 15 mins / 1 hr / 24 hrs is usually a reasonable security-performance tradeoff.
In some simple cases you may not have any meta-data and you just want to check that a request is coming from another authorized component; basically a "Are you me?" check. In these cases I've seen each component get a copy of the same symmetric JWT and just create themself a token before each request.


Is it safe to keep passwords in an Evernote note? I would like to keep a password matrix in an Evernote note.  I would like to ask for feedback on the security of that storage.

No.  Evernote's own description of their encryption indicates that they use 64-bit RC4.  64-bits is way too short, and RC4 is generally considered broken.

Encryption aside, I've never gotten the impression that Evernote was design around high security, so I'd avoid using it for highly sensitive data like passwords.  Consider tools designed for storing passwords like Keepass or LastPass.  They may still have weaknesses, but at least their engineers are designing with password storage in mind.


Invalid beef hook id: the hooked browser cannot be found in the database? So I've just installed beEF on my centOS server, but so far it hasn't been working on any page that's not in the same browser that I'm logged into. The beEF admin panel only works on the demo pages that are on the same IP address as the server.
Can anyone help me figure it out? Whenever I try to use it on a different site, it either doesn't show up on my hooked browsers, or this error shows up:

  "[EVENTS] Invalid beef hook id: the hooked browser cannot be found in the database".

Any help would be greatly appreciated.

Maybe your database (sqlite by default) is damaged... or incorrect after an update. You can try to remove the sqlite file. I'm not sure of the location in CentOS... In my Kali Linux is on /usr/share/beef-xss/db and there you can delete de beef.db file (or rename it to beef.db.old as backup). And then you can start the framework using -x parameter which seems to re-create the database file.

You can also modify the config.yaml file to set debug mode to true and http to true too in order to show more info on console. Maybe you can see the problem with this. Usually are problems related to ruby gems.


How does a person request gmail.com from my server? I run a number of websites / web services on NGINX with Ubuntu.

Today I noticed the following line in my rogue.access.log (I have a separate vhost/log file to catch all requests for websites other than ones I'm expecting):

Server: "gmail.com" - Virtual Host: "_" - Remote Address: "195.62.53.168" - Request: "GET /engine/log.txt HTTP/1.1" - Status: "501" - Referer: "-" - User Agent: "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:30.N) Gecko/20110302 Firefox/30.0".

I regularly receive strange requests including \x01 (scanning bots) and people setting their domain's A records to my IP, these I know are normal, though probably with malicious purposes; they just reach my catch-all vhost (a current example would be top10datingsitesuk.co.uk. However, I'm confused as to how a person can request gmail.com from my server? Obviously Google didn't accidentally change their A records to my IP, so how is this done, and how might I better stop it? The URL above points to my server and demonstrates how I deal with this situation, but am I handling it correctly?

Its by spoofing the Host: header inside the HTTP request. I however don't know WHY an attacker would want to think your server is gmail's. Propably they want to target servers that does have some sort of catch-all vhost and they just use gmail.com because they know no real server will reply on that, instead of randoming up a hostname like dlgjdlgdlgdjlgj.com , because they are trying to get the engine log, which is only available on the vhost bound to the physical machine, not any virtual hosts.

You can try it yourself:

telnet [your server ip] 80

GET / HTTP/1.1
Host: gmail.com
[include 2 newlines]

and then watch your logs.


Is it secure to distribute Certificate Revocation Lists over HTTP? I'm still trying to understand the functionality of a Certificate Authority, so if this obvious, I apologize.

I understand CRLs play a role when the CA wants to invalidate a certain SSL certificate. In every SSL certificate I checked, both OCSP and CRL URLs are served in plain HTTP. Is there any particular reason to distribute them over HTTP?

The chances of someone stealing a server private key and spoofing the clients connection to the CA's servers are quite slim, but I'm wondering if there is nay accessibility or technical reason behind that.

As always, thank you for your attention and time

HTTPS (or any TLS clients really) need to know the certificate revokation status before being able to trust that TLS connection. If the HTTPS connection used to fetch the CRL itself can't be trusted, then what is the point? Not to mention, your original HTTPS connection triggers a CRL lookup, which in turn triggers another HTTPS connection for the CRL server, which in turn... you get the point, we end up with an infinite loop of resource-expensive, untrustable and thus pointless connections.

Fortunately CRLs are signed themselves so the transmission medium doesn't matter, it must on the contrary be as lightweight as possible, so that excludes HTTPS (or any other crypto protocol really).


Is bit.ly a malware distributor? I clicked this link

http://girlsguidetosurvival.wordpress.com/

Chrome gave me this warning -

  Attackers currently on bit.ly might attempt to install dangerous
  programs on your computer that steal or delete your information (for
  example, photos, passwords, messages, and credit cards).

  Google Safe Browsing recently detected malware on
  girlsguidetosurvival.wordpress.com. Websites that are normally safe
  are sometimes infected with malware. The malicious content comes from
  bit.ly, a known malware distributor.

I thought bit.ly was a good company. And can they really steal my password/messages just if I visit a website and read some posts (if I'm not giving them any information)?

Is there a safe way to browse this website?

bit.ly itself does not distribute malware, bit.ly is just an URL shortener service which allows you to mask/shorten your original URL.
bit.ly however is not only used for good reasons (shortener) and for marketing reasons (click tracking).

You have to think about scam and phishing websites as well, which often use bit.ly to hide their domain which otherwise would be blacklisted automatically by filter programs (or to override blacklists). This simple act of piggybacking hurts bit.ly because it offers a simple redirection, and Google interprets this (probably it has been triggered automatically from their systems) as bit.ly being part of a malware network.

This can be easily confirmed if you visit the Google Safe browsing diagnostic page for bit.ly

  Of the 91854 pages we tested on the site over the past 90 days, 669
  page(s) resulted in malicious software being downloaded and installed
  without user consent. The last time Google visited this site was on
  2014-10-24, and the last time suspicious content was found on this
  site was on 2014-10-24. Malicious software includes 200 trojan(s), 185
  exploit(s), 152 scripting exploit(s). Successful infection resulted in
  an average of 3 new process(es) on the target machine.

  Malicious software is hosted on 365 domain(s), including
  xxxx.mobi/, xxxx.net/, xxxx.com/.

As you can see, Google associates bit.ly with each of these single domains.

To answer your question, you shouldn't worry about the bit.ly website itself and you can browse it safely, however when clicking to a shortened URL there's generally no way (for bit.ly specifically there's a way, check Sumurai8's comment below) to prevent you being warped into a scamming/phishing site.

You can take precautionary measures by using various extensions on your browser, especially ones which allows you to prevent to run javascript on unknown pages, adblock might be a good thing also to prevent scammers to generate any income from banners/ads placed on the malicious site. You can also block and analyze the bit.ly redirection before it triggers on your browser, so you can know which URL you are going to be redirected to.

On a rule of thumb I'll generally recommend the following:

Triple check the address bar, specifically the domain of the website
Check again on google if not sure
If it's a suspicious and dodgy page, leave and never come back, it might be good if you can blacklist and block it from being accessed again.
Don't download warez and free programs promising you hot girls, money or whatsoever.
For whatever service you use on the internet, if it involves serious personal stuff always use if possible a 2-way factor authenticator by attaching it to your mobile, this might dampen the probabilities from being scammed.


Deauth all users on AP except yourself I am looking to create a small first project to further my self education into infosec. I will be putting this on my Github.

My idea is to create a script that automates the process of deauthing all users on my wireless network except myself ( the machine running the script ).

GAMEPLAN

Host discovery with nmap
Find mac addresses of associated clients
airodump to get mac address of AP (or I could just plug the mac in because I know it)
Deauth all users except the machine running the script
Back into managed mode and surfing the web

I understand that:

all deauthed users would most likely immediately reconnect if the password is saved in their system
during the process of the deauth my wireless card would be in monitor mode

My overall question: Is deauthentication plausible to where I could hog my own network?

Here are some links to other question I have asked on this site related to this project:

Wireless card simultaneously in monitor mode and managed mode?

In replies, specific aircrack / nmap commands are not needed I just want to see if the idea concept is plausible?

Here is some documentation for users who are not yet aware of:

Host Discovery with NMAP
Simple Deauthentication with the aircrack-ng suite

A rather quick Google search for "python wifi deauth" reveals several results for your question.

WiFi Jammer seems to do the job:

  Continuously jam all wifi clients and access points within range. The
  effectiveness of this script is constrained by your wireless card.
  Alfa cards seem to effectively jam within about a block radius with
  heavy access point saturation. Granularity is given in the options for
  more effective targeting.

More infomration can be found at: https://github.com/DanMcInerney/wifijammer


Does Anti-Forgery token make sense if cross-origin requests aren't supported? If my site only responds to requests from it's own domain, does it make sense to implement CSRF tokens on my requests?

I believe it is the Cross-Site in CSRF that's leading me to ask this question.
If cross-site requests are just ignored, does the CSRF Anti-Frogery token add any value?

Cross Site Request Forgery is by definition a cross-site request. If cross-site requests are not accepted by your application (i.e. everything same-site) then of course CSRF is not a problem. But, make sure that you properly check if this request is really a same-site request. This means especially that you should not allow empty Referer headers because these can be created by cross-site requests and that you should not check the Referer header with an overly permissive regular expression.


Post Data tamper detection I have been studying a bit on security on how to make my mobile rest server secure. I am looking at one mobile application that uses plain HTTP.

I have Charles proxy breakpoint enabled and edit the post data before submitting to their server.
For example when I edit the "request" from

[{"func":"HeartBeat","time":1475481665} ]

to

[{"func":"HeartBeat","time":1475481777} ]

I got a "wrong signature" response. How did their server know that the "request" data was tampered in the first place?

All I know is the session is the current user, signature and request might be connected somehow. I think I need to generate a new signature when editing the request data.

One way to ensure security is to have the client create a Message Authentication Code for the request and then send the MAC along with the data. The server will recreate the MAC and then validate it against that what was sent.

This is probably what is happening in your example with the "signature".


IP forgery (theories are fine) Is there any (practical/theoretical) way to forge "IP address"?

By forging I mean feed to the website the IP you want.

Let take PHP as example:

You need to change your IP address to this IP 225.225.225.225.

In the final result $_SERVER['REMOTE_ADDR'] on my server will contain IP 225.225.225.225. (global variable $_SERVER['REMOTE_ADDR'] will be equal to 225.225.225.225).

And just in case: question is about IP forgery NOT 'what is proxy and how to use it'.

UPDATE: I used PHP only as an example. If will continue with PHP then, of course, HTTP_X_FORWARDED_FOR  should also contain 225.225.225.225 or be equal no nothing :)

Full IP spoofing is hard for the commoners.

Everything in IP is made of packets. Each packet has a source address and a destination address. IP spoofing is about sending packets with a wrong source address. Sending such a packet is simple enough with a few lines of code (it tends to require local Administrator / root rights; on Linux, this is a matter of a socket() system call with the SOCK_RAW parameter).

Making the packet reach its destination might be a bit problematic. Normally, packets hop from router to router, and routers only look at the destination address (they are interested in where the packet should go, not from where it comes). However, some routers enforce anti-spoofing mechanisms: the routers "know" what IP addresses are behind it, and will see that the spoofed packet is not "possible" (its source address is not one of the source addresses which are normally behind the router). Such routers react by dropping the offending packet. Some ISP employ such routers, because they do not want to be seen as lax ISP who let their customers engage in network practices of questionable morality and legality.

Assuming that your ISP is lax and lets the spoofed packets transit, you reach the other problem known as "TCP sequence numbers". A Web server does not expect lone packets, but a TCP connection. The TCP connection begins with the "three-way handshake":

Client sends a first packet containing the SYN flag.
Server responds to that packet with a packet containing the SYN and ACK flag.
Client responds to that packet with a packet containing the ACK flag.

Each packet with SYN contains the initial sequence number (a 32-bit value) for the data stream originating from the same machine. Indeed, each data byte will be "numbered" and the counter starts at a value that the sender chooses. These values are used in the TCP control flow; client and server use them to tell to the other machine which bytes have been received (the "acknowledge"). In particular, the third packet for the three-way handshake (the ACK from the client) MUST contain the sequence number that the server sent in its SYN+ACK packet.

But a spoofing client never gets that SYN+ACK packet. Indeed, the server sends its SYN+ACK to the alleged client address, which is the source address in the SYN packet. By definition, the spoofing client used a fake source address. So the SYN+ACK went to that fake address, not to the client. Not having received the SYN+ACK, the client has no way of guessing the sequence number which the server put in its SYN+ACK. Therefore, the client cannot send a valid ACK. The server will thus never consider the three-way-handshake as completed. No handshake, no data. No data, no HTTP request or response. The attempt at connecting with a fake source address will simply not work.

Guessing the server's sequence number is hard if the server uses a decent random number generator. The TCP sequence prediction attack is about first opening some connections to the target server, to get a few fresh "random" sequence numbers. Then, the attacker tries to work out the internal state of the Random Number Generator used by the server's operating system to produce the sequence numbers. If the RNG is of cryptographic quality (as it should be in any decent operating system), such prediction is not feasible, and the attacker has to rely on luck. Since sequence numbers are over 32 bits, the attacker has one chance in about four billions to get it right. That's not good odds for the attacker...

To be able to finish the three-way-handshake, the attacker must thus, practically, "see" the SYN+ACK packet, even though it is sent to the fake address. This requires the attacker to be "close" to the target server, on the same LAN or maybe one or two routers away, at most. This explains why I said that full IP spoofing is hard for the commoners: as a basic ISP customer, you do not have the physical access to the wires required to make a full TCP spoofing on a generic Web server. Of course, employees at the facilities where the server is hosted can do a lot more things...

And the answer ? Even if you succeed in making the three-way-handshake and sending the HTTP request, the server will send the HTTP response to the fake address, not to you. There again, you need extensive wire-level accesses to get the response. Otherwise, you could, at best, send "blind" request but not witness their result. This might be enough for an attack, or not, depending on what the server does and why you try to contact it under a fake address.


How to enforce software updates on workstations? There are many workstations on the company network with various kind of software installed: web browsers, OpenVPN clients, remote management agents, encryption utilities and other tools.
Some of the applications update automatically, like Google Chrome or antivirus, but the others don't.

How do you verify if that software is up to date, and how to enforce update if it is not?
Are you updating it manualy, use a dedicated software or enforce users to do so?

There are multiple vendor products that exist to fulfill this purpose, and unfortunately we have to use more than one of them.

They are not foolproof; Microsoft SCCM may think we don't have any versions of Adobe Flash installed older than X.Y, but then (another product) finds a slew of them, while also missing versions of Internet Explorer below Y.Z.

(I think the divide comes, like all Microsoft solutions, where Microsoft products work best with Microsoft products but not third-party products, and third-party products work best with third-party products but miss the mark on interfacing with Microsoft products. Also inconsistent version string parsing across solutions)

What it comes down to is having some sort of agent on every local workstation that reads from the respective registry and reports software versioning information to a central server. From the central server you get an overview of what percentage of your infrastructure is up-to-date, and what remains vulnerable.

In a separate workflow, another server (something like WSUS, but again, the Microsoft divide rears its head) then forces update agents on the non-compliant workstations to update within compliance during the next update window. Automation tools like Puppet and Chef can be deployed to achieve something like this cross-platform; it's a simple problem with well-documented solutions.

Do NOT leave it up to users to diligently update. They won't, even under threat of firing.


Using DNS to track browser activity on a LAN I am trying to create a small network auditing script that tracks HTTP and HTTPS domain names visited by certain hosts using the libpcap wrapper for Nodejs. At its best the script would be able to give a printout of the names of the websites that a host visited as well as a timestamp of when the visit occurred.

My initial thought is to do a standard capture on the LAN with a packet filter to monitor only for "udp port 53" traffic, inspect only DNS questions, and then save them to a hashmap by ip or MAC address. However this method will give somewhat cloudy results as any asset loaded on a page will make another DNS request. Going to say, https://amazon.com, actually triggers ~20 hostname lookups. Is there any sensical method of separating hostnames visited by a browser from ones that are requested simply for assets? One method I can think of would be to employ some sort of "debounce" timer where my script listens only to the first DNS question request made every 1000 milliseconds (give or take), that way I could at least ignore the first wave of assets loaded by any web page. Any thoughts on if this is a solid method for tracking webpages visited (both http and https) or suggestions for ways to improve it?

This cannot work as you envision.

For one thing, web browsers are not the only thing that cause DNS lookups: anything (such as a network time client) that needs to convert domain names into IP addresses or vice-versa will do so.

For another, you cannot count on the browser doing a DNS lookup every time it loads a page.  The DNS resolver should cache the results so that, for example, Amazon won't be looked up more than once per minute, while visiting my home website shouldn't produce more than one lookup per hour.  Additionally, it's possible to browse websites by IP address, which doesn't generate any DNS traffic at all.

A third problem, and one that will trouble any tracking system, is that a page load doesn't equal a page view.  Some browsers perform "predictive loading" to pre-load the page they think the user is most likely to visit next, and some anti-virus programs do the same thing to pre-scan links for damaging content (one antivirus famously DDoS'd a number of sites with a poorly thought-out implementation of this).

Your best bet is to set up a transparent proxy that logs all traffic going through it.  This will let you track page-load activity for HTTP, and the IP addresses for HTTPS traffic.


Is it true that frontend validation is generally redundant for minimalist contact forms on minimalist environments? Say I have a continuously upgraded and well maintained LAMP environment with a website which its CMS is all-core and continuously upgraded as well and I have created a simple backend HTML contact form which is CMS-agnostic (not a module of the site's CMS) so the overall environment is minimalist and very secured and the contact form is minimalist in these regards:

It doesn't store any data in any database existing on the environment

It doesn't include fields for any sensitive data (passwords, financial data, etc.)

It only has and should always only have the following fields:

Name (input type="text")
Email (input type="email")
Phone (input type="tel")
Topic (<select><OPTIONS></select>)
Preferred day for appointment (input type="date") [exact hour would be set in private because as of 11/03/2021 W3 doesn't offer a combined date && hour-minute field]
Notes (input type="text")

Question
Is it true that frontend validation is generally redundant for minimalist contact forms on minimalist environments?
Notes

By "frontend validation" I mean solely to CSS/HTML trickiness and not for any HTML-derived special tag behaviors
I still don't have a mechanism to send a copy of the message to a potential customer but I hope to add one in the future
I still don't have AJAX/AJAX for a message which indicates that sending was successful but I hope to add one in the future

I would say that frontend and backend validation are not redundant because they serve different purposes:

Backend validation: enforcing the data format as it enters the application.
Frontend validation: reducing user frustration when filling out the form.

If your app needs input validation for some important reason (security, data correctness, etc) than you need to do that on the server and reject input that does not conform (400 Bad Request). Doing validation on the client side should only be about user experience -- for example you can give them a "This is not a valid email address" message in the UI as they are typing -- but should never be relied on because client-side logic won't be respected by tools like curl, or by malicious users who do Edit&Resend in their browser.
So if you can build a reasonable user experience with only server-side validation, then yeah, no need for client-side validation.


Does unsubscribing from an email actually remove my details? I get quite a few emails from valid companies and organisations in my inbox. Unfortunately most of these emails are marketing-type emails which don't have any value for me. As a result I tend to unsubscribe these emails often. My question is this - When I click unsubscribe, are my details removed from the sender's database/address book? If a database is being used, are my records put into a "soft-delete" status? Is there a general consensus for what action is normally taken when I choose to unsubscribe?

Assuming you are in the EU, then simply unsubscribing from communication will likely not remove any personal information. By law they are still allowed to store any personal information you gave including your email address and it is likely that they are.
If you want your personal information to be forgotten you would have to make a specific request for that to take place under your "right to be forgotten". This is typically done by simply sending a request along those lines to their privacy contact.


SQL injection without the use of union and select I was wondering if there is a way to use SELECT and UNION keywords without being caught by a algorithm (see below) that filters these keywords out.
 $filter = array('UNION', 'SELECT');

    // Remove all banned characters
    foreach ($filter as $banned) {
        if (strpos($_GET['q'], $banned) !== false) die("Hacker detected");
        if (strpos($_GET['q'], strtolower($banned)) !== false) die("Hacker detected");
    }

This filter searches for UNION, SELECT, union, and select. So UnIoN or SeLeCt will pass the filter.


Real life scenario for remote file execution This is a commonly demonstrated attack because it is easy to explain and understand.

The premise is that the victim does something like (oversimplified PHP example):

include( $_GET['file']);

And the attacker can pass a path to a php script on it's server.

My question is have you ever seen some thing like this or similar in real life code? I can't imagine what kind of requirement can cause a programmer to include a file based on user input.

Just a few days ago I wrote this code:

$pathinfo = explode('/', $_SERVER["PATH_INFO"]);
$action = $pathinfo[1];

if (ctype_lower($action) && file_exists(__DIR__ . "/$action.php")) {
    require_once __DIR__ . "/$action.php";
} else {
    header("HTTP/1.0 404 Not found");
    error_out("No such entrypoint");
}

Here I am taking the name of the action provided in the url, and load a module with that name.

You could have the same functionality with this slightly simpler condition:

if (file_exists("$action.php")) {
    require_once "$action.php";
}

which would exhibit the mentioned remote execution vulnerability (if allow_url_fopen is enabled), or even allow reading unexpected files (think on $action = "/etc/mysecret\0" scenarios).

(By splitting on '/' above that, it is possible that it would not work, as you would need a protocol which doesn't use a /. The file reading would clearly still be problematic on windows, though.)


Are browsers still vulnerable to IDN homograph attacks? Is it not possible for Chrome and Firefox to protect against this > https://www.аррӏе.com/

Navigating to that above (fake) apple website using Firefox 59.0.2 doesn't actually take me to the apple website, but it still says apple[dot]com in my web browser...

References:

  https://www.xudongz.com/blog/2017/idn-phishing/

  https://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

  https://en.wikipedia.org/wiki/IDN_homograph_attack

No, Humans are vulnerable to the homograph attack, browsers are unaffected.

Chrome has a partial work-around that offers a false sense of security to those who buy the hype.

In the general case of the attack both domain names are IDN and the user can't be expected to differentiate between two different random-looking strings of ASCII characters.


Why sometimes intermediate certificates don't include a "CA Issuers" part? I'm learning about certificates, and would like to understand:
How is it possible for intermediate certificates to not include a CA Issuers part?
Is it not a must so that clients can figure it the Chain of Trust?
I'd like to give here 2 examples:
One whose intermediate certificate includes a CA Issuers (*.stackexchange.com), and one who doesn't (udemy.com).
Let's start with security.stackexchange.com:
openssl s_client -connect security.stackexchange.com:443

Outputs:
[...]
-----BEGIN CERTIFICATE-----
MIIHJTCCBg2gAwIBAgISA72+1m+qM4K1gtDMN1jR2FJbMA0GCSqGSIb3DQEBCwUA[...]
-----END CERTIFICATE-----
[...]

Let's save this conent into a file named stackexchange.pem and parse it:
openssl x509 -in stackexchange.pem -text -noout

Outputs:
Certificate:
    Data:
        [...]
        X509v3 extensions:
            [...]
            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

Now, let's go to that issuer:
http://cert.int-x3.letsencrypt.org/

Once browsed, a file named download.cer (der encoded) is downloaded, which I'm not sure how to use openssl to directly parse it, so let's first convert it to pem and save it, and then parse it:
openssl x509 -inform der -in download.cer -out download.pem
openssl x509 -in download.pem -text -noout

Outputs:
 [...]
 Authority Information Access:
   OCSP - URI:http://isrg.trustid.ocsp.identrust.com
   CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

(The next certificate up the path is the root, so we'll leave it).
Great, so both certificates have a CA Issuers part.
Now let's do the same for udemy.com.
Its leaf certificate has:
[...]
X509v3 extensions:
   X509v3 Key Usage: critical
      Digital Signature, Key Encipherment
   Authority Information Access:
      CA Issuers - URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
      OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018

But parsing the certificate at http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt has no CA Issuers:
[...]
Authority Information Access:
   OCSP - URI:http://ocsp2.globalsign.com/rootr3

How then, should clients go up the Chain of Trust path?
Now, I know that browsers have a predefined certificates list, and also that Windows have a predefined certificates list, so technically that udemy path may be resolved, but what if a client (let's say it's not a browser nor a Windows app) doesn't have that predefined data? How can the intermediate CA certificates be followed?

How then, should clients go up the Chain of Trust path?

The clients use the Issuer information (and X509v3 Authority Key Identifier) and not the AIA CA Issuer information to build the certificate chain. The intermediate certificates are supposed to be send by the server during the TLS handshake and are not downloaded by the client separately using the AIA information. And this is also the case for the domain you mention as for example openssl s_client -connect udemy.com:443 -showcerts shows.
In other words: AIA CA Issuers is not needed for certificate validation at all and that's why it does not matter if it is included in the certificate or not. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more information.


When paying online with a credit card, what is "3D authentication" and is it reliable? I tried making a purchase from http://www.laptop-batteries.ca/ but on the very last step the page reloaded with an error. A representative contacted me asking why I didn't complete the order and I said the webpage had an error and he said

  use Credit card must pass 3d certification

and provided me with a link to do so (see addendum). Is this legit or am I being scammed? What is 3D authentication, is it like PCI compliance? I would really like to purchase a laptop power adapter because  I live in Canada and other retailers (e.g. Amazon.com) charge a ton when shipping here.

Addendum: why is the following link not allowed?

hxxp://make%203D%20authentication,you%20can%20Look%20https://acs.onlinesbi.com/sbi/enrollment/enroll_welcome.jsp

Addendum 2: I'm not sure how I got the link above but here it is again https://acs.onlinesbi.com/sbi/enrollment/enroll_welcome.jsp

From Wikipedia:

  3-D Secure is an XML-based protocol designed to be an additional
  security layer for online credit and debit card transactions. It was
  developed by Visa with the intention of improving the security of
  Internet payments and is offered to customers under the name Verified
  by Visa.

NOTE that your link is garbled, it might be that he is trying to redirect you to a fraudulent site adding a link into an html form  to make  you think you are going to your bank's website, but instead you are being redirected to a phishing website.

In your case they want you to go to: https://acs.onlinesbi.com/sbi/enrollment/enroll_welcome.jsp

But they seem to add something to the front which might redirect you to another website.

If you are indeed redirected to this website, check the URL and verify the certificate:

If you are not a customer of the SBI or you are not being redirected to this website with a valid certificate for the SBI as shown above then I would not continue anymore.


How can trusting ONE certificate jeopardize everything I do online? I am not sure I understand how TLS works correctly. To my understanding trusting a certain website's certificate is all about trusting that website or not, but the questions below suggest that trusting ONE certificate would put everything you do online at risk.

My college is forcing me to install their SSL certificate. How to protect my privacy?

I can't access websites that use HTTPS, instead getting the message “your connection is not private”!

I have trusted self-signed certificates more than once from many websites because they simply can't afford to pay for a certificate. Does this mean everything I do is vulnerable to MitM?

Trusting one site's untrusted (self-signed or blatantly invalid) certificate could potentially compromise the connection to that particular domain, however you're still safe for other sites, except in the rare case when the other sites embed content from that site with the untrusted cert. For self-signed certs the only danger is the initial trust you put in the certificate, since you have no way to verify if you're talking to a legitimate server vs. an MITM. Once you trust the certificate the first time your browser still checks whether the cert is the same on subsequent connections (if an MITM were to appear next time you won't get owned unless you also trust their own certificate). As far as cryptography is concerned the type of certificate has no incidence on which cipher suites will be in use, and HTTPS with a self-signed cert is no easier to break than HTTPS with a trusted cert.

The nightmare begins when you start trusting someone's CA certificate (by manually downloading the cert and importing it), in that case you're telling the computer "let that entity vouch for any website you encounter", and from there you're giving that CA the power to tell your computer whether any site you visit is trusted, since any site that has a cert signed by that CA (let it be for legitimate reasons or because of the CA owner MITM'ing you) is now automatically trusted by your browser.


Is the argument really over on SSO? I got shot down on ServerFault recently for suggesting that SSO can be less secure than having different credentials for each service. What are the arguments against SSO?

Two views:

Corporate:

Whether you have control over all the machines, or at least the central auth server, you're better off with SSO. One place to hire employees, one place to terminate them, one set of credentials they have to worry about. Individual server compromises shouldn't leak credentials. Users are less likely to get annoyed, forget passwords, and use horrid patterns of passwords especially when the 7 different computers they have to access start hitting their password change periods at staggered points.

In a company environment, you want one point of authentication.

The Wild Internet

Spoofing / phishing is a bigger concern. Privacy becomes a concern. A third party knows everywhere you log in. Compromise of that 3rd party compromises all your accounts. The benefits of one identity, one login have to be weighed against all those. When you get duped into a fake login page from your web forum and it links to your email, and hence your bank, things may get ugly.

For the ServerFault guys, there's no question that they want that on their network. For the world at large, there's a big bit of trade-off to be had.

Edit to address commments

Submitting one's login credentials to a 3rd party service is the antithesis of single sign on.
In some cases, it does make sense to provide users with multiple accounts. Many wise system administrators have their normal operations accounts and their elevated privilege accounts. At the same time, this is still an SSO system. It is often the case that a central authentication server handles the multiple accounts.
In regards to password sharing, I consider that a poor argument against SSO. In any case where access to something should be shared, it should be done with different credentials. While we have to accept that there are some systems out there that need sharing and do not implement the ability to assign rights, this should be addressed by altering the system whenever possible.


Logging True/False Negatives on Snort I'm using Snort in a lab environmnet with artificially generated traffic.

I'm looking to build a confusion matrix from known generated attacks.

True Positives and False Positives are easy to parse out of the alerts file, but I'm looking for a way to quantify True/False Negatives.

These would be instances in which Snort could have alerted, but didn't.

I'm not sure how closely related this is to number of packets, because I'm not sure if Snort could potentially alert multiple times per packet.

Any help is appreciated.

The key thing you need is ground truth.  You need an a priori way to know which parts of the traffic are in fact attacks, and which are not.

Once you have ground truth, then building the confusion matrix is straightforward.  For each attack in the traffic, you check whether Snort detected the attack or not (this gives you a count of True Positives and False Negatives).  For each non-attack in the traffic, you check whether Snort alerted about an attack or not (this gives you a count of False Positives and True Negatives).  Now you put those four numbers into your 2x2 confusion matrix.

If you don't have ground truth, you cannot build the confusion matrix.

There is no way to use Snort to look at negatives in terms of alerts.


Can ModSecurity defend from Brute Force Attacks on PHPmyadmin and WordPress as well? Can the software ModSecurity defend from Brute Force Attacks on PHPmyadmin and WordPress as well?

A particular hosting company providing shared hosting told me that ModSecurity should cover PHPmyadmin and WordPress as well as their Admin area and Cpanel area.

Does it sound plausible to you?

mod_security sits in the Apache webserver to offer some level of security for applications hosted on that webserver.  Assuming you're talking about shared hosting (as opposed to dedicated or VPS providers), there's no reason their mod_security installation wouldn't be able to protect against attacks against any application installed on their webserver.

That being said, mod_security is highly configurable, so you'd need to check that there's brute force protection for the login pages you care about, and you'll also want to check if mod_security is even enabled for those paths.

Also note that some mod_security rulesets (those looking for SQL injection) are likely to have a very high false positive rate on PHPmyadmin, as they'll look for strings similar to the SQL queries legitimate users might enter into PHPmyadmin.


Did the October 21, 2016 DDoS attack on Dyn's DNS service cause Bandwidth Exhausion? A recent attack on Dyn's DNS services affected several major websites last Friday, Oct 21, 2016. I would be interested to know if this was Bandwidth Exhaustion, or if it was mainly load on the server and/or router equipment?

The official statement states that 10s of millions of IP addresses were involved in the DDoS attack. I presume that Bandwidth Exhaustion would occur under such circumstances. Bandwidth Exhaustion attacks of course can only be solved in cooperation with the ISP.

However, based in this description, it seems like that is not the substance of the attack. (emphasis mine)

  [Dale Drew, CSO of Level 3] says the attack consisted mainly of TCP SYN floods aimed directly at against port 53 of Dyn’s DNS servers, but also a prepend attack, which is also called a subdomain attack. That’s when attackers send DNS requests to a server for a domain for which they know the target is authoritative. But they tack onto the front of the domain name random prepends or subnet designations. The server won’t have these in its cache so will have to look them up, sapping computational resources and effectively preventing the server from handling legitimate traffic, he says.

On the other hand, both of those strike me as fairly simple to mitigate quickly. For example, temporarily disabling/throttling TCP requests and recursive lookups
(or is my interpretation wrong? Perhaps it's not a recursive lookup, just a database lookup?)
to make room for more important requests; such as authoritative lookups of i.e. twitter.com, that are almost exclusively served over UDP.

Besides better understanding why those vectors could not have been temporarily sacrificed to mitigate the attack; my main question is whether or not Bandwidth Exhaustion occurred? (Is this public knowledge?) That would certainly explain the impact more so than the above reported vectors.

TL;DR: The attacks effectively capped out allocated memory buffers and ran CPU usage up to capacity, leaving the servers unable to respond to legitimate requests. Bandwidth Exhaustion rarely occurs with SYN attacks, because very little bandwidth is required for SYN attacks and/or bogus DNS lookups.

A TCP SYN flood simply fills up available memory buffers while the server waits for non-existent ACK packets to return. Very little bandwidth is consumed in this attack, and can take down a server with small TCP pools even if they had literally unlimited bandwidth, because the bandwidth isn't the source of the bottleneck, the memory held by the pending connections are.

You can visualize this like a telephone operator's switchboard, where many of the calls are just people breathing into the other end of line without actually saying anything useful; legitimate callers have to wait for the operator to decide to hang up on all the prank calls. Eventually, there's no more spare phone lines so legitimate callers effectively get a busy tone and have to try again later.

A prepend attack also uses very little bandwidth, as the scripts simply ask for random sub-domain names of the target domain, forcing the DNS server to spend time performing recursive look ups and repeatedly querying DNS records for entries not in its cache. In this case, instead of memory being the bottleneck, the CPU fills that role by performing a lot more work than it has to for legitimate requests.

You can visualize this sort of attack as many people calling the operator at the switchboard, each asking to speak to non-existent people. The operator has to take time initially to look up each request before telling the caller that there's nobody there by that name, while callers that want to talk to known people have to wait for all the lookups the operator has to go through. This works best if you visualize the operator having a huge phone book and they have to spend a lot of time flipping pages to determine if the name actually exists.

Bandwidth Exhaustion, by way of comparison, is when the network becomes saturated with data trying to reach the server. In this case, neither the server's memory nor processing power are the bottleneck, but instead depends on the network exceeding 100% capacity for some length of time. The best way to accomplish this type of attack is to send really large packets really fast, from as many locations as possible.

This is harder to visualize, but imagine many prank calls coming in at once, and the operator at the switchboard has to wait for each person to finish saying what they have to say before going on to the next call. Each prank call is actually some person prattling on about their entire life story and family history for the last 50 years, tying up the lines for that caller that simply wants to be transferred. It's not a such a perfect analogy as it is for the others, though, because this is actually effectively occurring upstream from the operator. It's out of their control.


What is the recommended file extension for GnuPG-encrypted files? I used .asc for ASCII armored (using --armor) encrypted messages.
But what extension should I use when encrypting file.tar.gz for example?

.asc is appropriate for all ASCII-armored output, even if the input file was in a binary format.  Traditionally the original filename will be maintained so that the recipient knows what to expect once they've decrypted the file, e.g., file.tar.gz.asc.


tshark - dump the data section As the name suggests, im trying to dump the data section of the packet,

man would suggest that its something like tshark -r file.pcap -t fields but im not having any luck

options are case sensitive, -t means format of timestamp and I guess you want to use -T that set the format of output. Depends on what kind of data you would like to dump, e.g., http host, tshark -r file.pcap -T fields -e http.host should be what you are looking for.


Removing Google Analytics cookie string from URL - security hole? On our site, we use google analytics and we have to put the GA cookie in the URL since we have a two letter domain and IE imposes some cookie limitations on those. This means that when going between subdomains we get these long URLs with the cookie string appended after a hash:

http://test.ab.la#_utma=what_have_you&_utmc=something_else&so=on&so=on

So, I added this code:

(* Remove fragment (the part after #) from URL if it contains a Google Analytics cookie.
   We do this to hide the extremely long URLs that otherwise will be visible to the users.
   Will not work in IE and other browsers that do not support history.replaceState().
   Use GA's push functionality to do this to make sure the page has been tracked before
   removing cookie information.*)
_gaq.push(function() {
    if (window.history &&
        window.history.replaceState &&
        location.href.indexOf("__utma") > 0) {
        window.history.replaceState({}, "", document.location.href.split("#")[0]);
    }
});

After watching a talk at Jfokus by John Wilander where he mentioned a specific Twitter security issue, I got a little nervous.

My question is: Would my little hack above introduce any security holes, XSS or others? I don't think so, but I guess you've heard that before.

Update:

Maybe I should clarify my maybe somewhat unclear question: I did suspect that I wasn't having the exact same security problem as the Twitter one, but I since I am doing similar things I am wondering if there are any other vulnerabilities in my code?

The Twitter hole was that they didn't check that the URI supplied in the fragment identifier was what they expected it to be (a root-relative path). It could be any other URI, including an external site, or (what caused the XSS), a non-locating-URI (ah, javascript: URIs—how we all wish you had never been invented).

You don't have this hole here because (a) you are re-using the scheme and hostname from the existing document URI, which must necessarily be a locating-URI, and (b) you are using replaceState: this only updates the apparent path showing in the address bar, and does not actually navigate to the target address.

You could use location.path+location.search as an alternative way of getting the rooted-path part without bothering with splitting out the other parts manually.

How you are handling re-injecting the cookies, and whether you care about the analytics cookies being easily falsified/leaked, might have other implications.


Why must VMX instructions trap? What would happen if each of these instructions didn't trap into VMX root when executed in VMX non-root?

INVEPT, INVVPID, VMCALL,VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, and VMXON.

Would it allow the guest operating system to compromise the host's security?

I suggest that you familiarize yourself with Popek and Goldberg's virtualization requirements.

In particular, the VMX instructions are sensitive instructions: they can provide privileged access to devices and system resources.  Therefore, access to the VMX instructions must be controlled.  If those instructions did not trap, and there were no other special provisions made, there would be no way to control access to those instructions.  In particular, in a trap-and-emulate architecture for virtualization, we need to ensure that those instructions trigger a trap, so that the VMM can emulate them properly when the guest executes one of them.

If they did not trap, and if no other special provisions were made, it could open up a security hole.  It could also cause a loss of fidelity for virtualized guests.

You might also be interested in learning about nested virtualized (aka recursive virtualization).


What is a good way to generate a one time pad, and is this a good way? Is there a good/better/best way to generate a one time pad?  I would like to only utilize about 40 characters (a-z, 0-9, .,!-).

What I have come up with is perhaps not the BEST way, but seems to fill my needs.  It essentially works this way:

Initialize:

1) Generate a random seed using the MS RNGCryptoServiceProvider service

2) Populate an array with a base of all of the characters I use

3) Perform a "switch" based on the random number of the 1st character and the random number (base 40) character in the array after this character

4) Pause a random amount of time determined by yet another random seed call (1-5ms)

5) Get a new seed

6) Perform a "switch" based on the random number of the 2nd character and the random number (base 40) character in the array after this character

7) Continue until all characters are swapped, generating a new random seed at every iteration, switch, etc.

8) Repeat the process 5,000 (adjustable) times

Generate lines:

9) Repeat steps 3-8 10,000 (adjustable) times

10) Write the line to a secure location (either on-screen, encrypted thumb drive, etc.)

11) Using the previous array-based line, repeat steps 3-8 for however many times/lines I want.

This has the residency of reusing old/new seeding (i.e. seeding upon itself) for the switches.  I know there are holes in this, but for the actual generation aspect, I figure I can define how many loops per cycle can be run (if a user want to go crazy, they can do 100-millions of switches per line, and can adjust the starting point to between 100-millions).  More seems better, but to what end is up to the user.

I will put this out there - my machine runs extremely fast with the Intel CPRNG on the chip.  I KNOW this is/can be a security hazard, but I am wondering, just for the generation algorithm, does this seem to be a good way to generate OTP pads?  As there is a whole host of other security problems that can be either added to the list or removed judiciously, I am just asking - how much do you need to make an OTP pad, and would the above work?

Thanks in advance, and I will correct anything anyone has questions about.

A one-time pad is an encryption mechanism consisting of combining a stream of key material with the data to encrypt, using a reversible operation; this combination can be very simple, and even doable by hand (without a computer), and still retain security as long as the key material (the "pad") is as long as the data to encrypt, and is never reused (that's the "one-time" part).

Security is relative to how much the key material is unpredictable to attackers. The mathematical beauty of the OTP is that there is no upper bound for that: you can reach information-theoretic security, i.e. achieve perfect protection against computationally unbounded adversaries. Well, you might. Things can become a bit unclear once we begin using infinities.

"True" randomness can be defined as that which cannot be predicted by any attacker. It is unclear whether true randomness can exist at all:

Right now, physicists work under some assumptions, one of which being that there is an unavoidable level of incertitude in where things are and how fast they go. This is Heisenberg's uncertainty principle. While this interpretation of the real world has been very successful for the last century, and allowed many stupendous technological advances (including the computer you are using to read these lines), it still is a theory in the strong sense of the term: it is "true" as long as it works well at predicting behaviour of physical systems. Whether Heisenberg's principle is fundamental, or a mere illusion due to our imperfect analysis of some underlying mechanism, remains to be seen.

In a sense, Heisenberg's principle guarantees us existence of randomness only through the usual Argument by Authority: many very smart people with blindingly white lab coats say so. But not all were convinced. Famously, Albert Einstein, one of the smartest physicists to date, was unconvinced, and expressed so in his famous quote: "God does not play dice with the universe". Of course, we can retort that for all his smartness, Albert has been dead for more than 60 years, but that's a rather feeble argument.
Maybe more importantly, in the case of OTP, the supposed randomness has been measured, since it became the very macroscopic object that is the OTP. What matters for security is how much that pad is not known to the attacker, but since the pad has been used, it has existed in the tangible, human-sized world, e.g. as a piece of paper with printed ink. This is bound to leave some traces. For instance, if you printed it with a common printer, then remains of the data may linger in the printer memory. If you wrote it down with a ball pen, the pressure of the pen may have let a readable depression in the paper sheet below the one you were writing on. If you burned the paper down in the chimney, the carbonated remains might still leak some information (I saw that one in a MacGyver episode, but it turns out to be a real thing as well).

Thus, in a quest to True Randomness, we must not only defeat Albert Einstein, but also Sherlock Holmes. Physics may come at our rescue, this time the second law of thermodynamics, which can be interpreted as the assertion that information really gets lost over time. Thus, physicist are ready to agree that if we got an unpredictable piece of data at some point, then we may hope to completely suppress it, so that it won't be uncovered by an inquisitive adversary. Possibly.
Even if we obtain really random events, in the sense explained above, these events may still be biased. In any practical setup for OTP, the key stream must be uniformly random, so there is a need for some unbiasing. Unfortunately, generic unbiasing mechanisms (namely, hash functions) are "normal" cryptographic objects, which live in the computationally bounded world of security. We do not know how to make a hash function that would still fulfil its unbiasing role even against a computationally unbounded attacker.

(We can make perfect unbiasing if we know the exact distribution of the source random data from which we want to remove any bias. But since we do not even know whether random sources really exist, pinpointing that distribution could be hard.)

Fortunately, there is no practical need to reach absolute unpredictability. This is because computationally unbounded attackers are mythological (in the true sense of the term: we make stories about them, but we have never undeniably met one). The points above may seem excessive in their nitpicking, but that's nothing with regards to how utterly unrealistic an unbounded attacker is. Infinity is kind of big; remember that.

So, for practical purposes, you just need randomness which is unpredictable by actual attackers, not mythical ones. This means that a cryptographically strong PRNG will be sufficient. It won't deter God, if He wants to spy on you. But He already can (because omniscience), so what would be the point anyway ? You create an RNGCryptoServiceProvider instance -- so, just use it. Once it is created, it will happily spew megabytes of data at a high rate. There is no need to add random delays or any other ritual dancing step.

Programming is the art of not goofing up, and yet there is plenty of room for that. For instance, a CSPRNG like RNGCryptoServiceProvider, or /dev/urandom on Linux systems, produces bytes, which are values in the 0..255 range. Extracting random characters out of these bytes can be done correctly, or poorly. If you have an alphabet of 40 signs, then you could imagine that you just need an Euclidian division of each byte value by 40 and keep the remainder (the '%' operator in C#, 'mod' in VB.NET). While this would produce only values between 0 and 39, these would be biased, even if the source random bytes are not. This is because 256 is not a multiple of 40; thus, remainders 0 to 35 would be somewhat more probable than remainders 36 to 39.

The correct way to generate random values in the 0..39 range from source bytes in the 0..255 range is to use a rejection method. When you want to get a new random integer in the 0..39 range:

Obtain the next random byte x.
If x < 240, then return x mod 40.
Otherwise, loop to 1.

In other words, you must discard some possible input values, and get additional bytes when such a value occurs.

As a final note, one-time pads are grossly impractical and cumbersome. They were used in the pre-computer era because there was nothing better at that time. But now they are mostly an historical curiosity, and a mathematical concept for reasoning about infinities.


Blocking Internet Monitoring Software So if a provider has software that blocks you from using their internet to connect to, say, Spotify or Skype. Is there a way to block your computer from communicating that this program is running? Or to disguise it as another program?

This can't be done simply on your computer. You will need an SSH server which you will use to establish an encrypted tunnel:

Because your traffic is encrypted, the provider will not be able to view and thus not block your traffic. Note that the provider might still try to block you on DNS level. To bypass such a protection you should use public DNS servers, preferably these DNS requests also should be sent through your SSH tunnel.