Firewall Showing 1,000's Of Strange GET Parameters Being Sent To Login Page? So I woke up today, and checked my Firewall Events on CloudFlare for my website like I do normally. Most of the time I'll just see thousands of failed SQL injection attempts, but this morning I was confused when I saw nearly 20,000 requests all coming from different IPs sending random GET requests with random values to my login page, here's an example of what it looked like.

Ever single request from the 20,000 had different GET parameters with different values set.

My best bet would be this was a failed DDoS attack, what do you think?

Here's a list of the most common ASN's used from these requests if anyone is interested in adding them to their firewall

45899, 7713, 9299, 17974, 42298, 7552, 24086, 12849, 23969, 132199, 9770, 8708, 55699, 133481, 27699, 45758, 3215, 9121, 4788, 17552

And some of the useragents (separated by ||)

Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.02 || Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 || Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 || Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 || Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 || Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8 || Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 || Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1 || Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

And some of the most commonly used IPs from the requests

14.234.151.201, 113.172.242.246, 89.211.211.191, 113.161.61.186, 36.84.231.11, 213.57.127.146, 110.138.92.187, 116.97.53.203, 27.76.100.72, 36.38.55.91

This is almost certainly not a DDoS attack. The 1.10.188.0/24 block is a residential IP block in Thailand. A large number of the IP addresses in that range are known for forum spam. You can read a report for one of the IPs in your logs here.

The weird parameters look like cache busters. By putting random words on the end it makes the request unique and prevents an old (cached) result from being returned. A lot of sites and tools use cache-busting for various things. My guess is that they're hitting sites all over the internet to look for forums and other chat features that they can then send spam messages to.


Sniff Android and IOS app traffic for privacy audit I am trying to figure out a way to sniff Http and Https traffic from app, to see who the app is sharing data with, and what data the app is sharing. The information should be used to audit whether the privacy policy informs correct or not. The solution must be viable both on windows and OS X.

So far I have tried charlesproxy(on OS X and Iphone), but whenever I set up a proxy I cannot get any internet connect through the app I am testing. Does anyone know what might cause this? Or is there a better setup I should try?

Have you installed the certificate from Charlesproxy on your Android/IOS device?
If no, the TLS handshake will fail, and you have no connection.
If yes, it is possible that the app uses Certificate/Private-Key Pinning. In case it's very difficult to intercept the connection.

For Android you can setup an Android-Emulator with root (https://www.genymotion.com/) and install the xposed framework. There is a Module too hook the validation-funktion. But this don't work for all ways of implementin certificat-pinning.

You can also disassemble the APK-file and patch the code. After that you can reassemble the code and install the app.


ISO 9564 Approved Encryption Algorithms for PIN, why symmetric block ciphers? I am currently researching best practices in designing a potential PIN management solution for a financial services application and began looking into ISO 9564 as a source of requirements.

One of the things that popped into my mind while reading this was that under the section for approved encryption algorithms they list:

Triple DES (weak symmetric block cipher)
AES (symmetric block cipher)
RSA (asymmetric cryptosystem)

I wondered immediately if there would be a legitimate use case for needing to ever directly decrypt cipher text of a PIN.  Other requirements of the ISO standard here claim that if the PIN is forgotten or potentially compromised that a new PIN should be issued.

The question that burns in my mind (that likely has a very obvious answer that currently escapes me) is why would the standard not recommend a cryptographic hash instead?  Why can't validation of a PIN entry attempt be done in much the same way that is commonly understood as best practice for password management?  The salt in this case would be the customer account number which is XOR'ed into the PIN itself anyway.  What am I missing here?

The reason ISO PIN blocks are used instead of a hash is related to the structure of the payments industry.

The diagram above shows the simplified data flows for a PIN transaction.  The ISO PIN block is sent to the Merchant Acquirer bank.  The Merchant acquirer bank decrypts the PIN block and forwards it to the card association, which in turn forwards it to card issuing bank.

In order to use hash based authentication, the merchant acquirer bank would need to know the plaintext PIN.  The merchant acquirer bank would then hash the PIN (and any associated salt and metadata) and compare the results with the value received from the merchant.

The problem with the above approach is the the merchant acquirer bank would need to know the PIN codes associated with every card it could possibly  process.  The card issuing banks are willing to confirm if a given PIN is valid, but do not want to share their entire PIN database with every merchant acquirer bank.

It would also be possible to send the hashed PIN to all the way to the  card issuer bank.  However, there would need to be some way to authenticate that the PIN block was generated by a particular PIN entry terminal at a particular merchant.  Without authentication, an attacker could replace a merchant pin pad with a counterfeit device that emitted the raw PIN.  The attacker could then hash the PIN and send it on for processing.

Any authentication solution would require a mechanism to authenticate the keys used for authentication.  Secret MAC keys are not used since it is impractical to share every PIN terminal key with every acquiring bank.  Asymmetric signing keys could be used as part of a PKI, but PKI technology was not widely used in the 1980s when encrypted digital payments first become common.  Adding a PKI to the existing data flows would require substantial changes in the end-to-end data flows.  Since the benefits of changing are marginal at best, the industry is unlikely to transition to any hash based authentication scheme.


Data exposed through campus proxy I want to connect with Firefox to my university campus proxy, in order to access subscribed research journals, but first I need to know, which of the transmitted data through the network are visible to campus admins.

Will any of the following show up in their logs?

Other browser's internet activity
P2P
Anything else that doesn't go through Firefox

EDIT: HTTP SOCKS v5 proxy connection (set up through "Choose how Firefox connects to Internet")

If you define the local university proxy in Firefox, every byte of traffic generated by Firefox will be available to them. And that includes:

Time and date of every packet
Source IP (that's you) and destination of every connection
If not encrypted (SSL/TLS/VPN), every single byte in clear
Amount of data transmitted

If the proxy wants to log everything, it can even log all your session for later examination.

Having the capability to log everything does not mean they do log. That would cost a lot in terms of processing power and storage media, so generally they log the origin and destination addresses, protocol, and timestamps. But that is enough to see if you are accessing a research journal or a recreational magazine.

Generally, only the traffic generated by Firefox would be routed through the proxy. But there are some programs that will try to access the Internet directly, and will search for proxy configuration in case the direct connection fails. If you have programs of this kind, they can reach the proxy by themselves.


Does embedding images in PDF retain metadata? I have a PDF file which I can select images to embed in. The customers are not technical so I do not want them to remove metadata themselves (e.g. GPS location of photos, etc). Will the PDF automatically remove them when they are embeded in the PDF.

For example, I have used PDFStreamer to find my embedded image and it is in base64: contentType="image/png" href="" [CONTENT in BASE64].

Maybe my question is if base64 image encoding contains metadata?

Yes, EXIF data may be saved, depending on how your PDF tools work.

As an example, you can take a JPEG with EXIF data, put it into LibreOffice Writer, then save that document as a PDF with "Lossless Compression" enabled and "Reduce Image DPI" disabled. If you then extract images from that PDF (there are many tools for this, I used an online one for speed) the JPEG EXIF data will still be there.

If you enable lossy JPEG compression, at least in LibreOffice's PDF export dialogue, it appears that the JPEG is recompressed to a new file with EXIF data stripped.

It is not difficult to remove EXIF data from images in Windows, and you should be able to talk them through the process. For each image, right click it, go to properties, go to the details tab, click the "Remove Properties and Personal Information" link at the bottom, select "Remove the following properties from this file", click the Select All button, then click OK.


Is this type of encryption one-way? I am writing a Powershell script that requires a privileged account to do something. Of course, I'm not going to include the password of this account in the .ps1 file in clear text so I am following this guide to create a more secure way of doing this: https://www.pdq.com/blog/secure-password-with-powershell-encrypting-credentials-part-2/

Here is the code that generates the key and encrypts the password:

$KeyFile = "\\Machine1\SharedPath\AES.key"
$Key = New-Object Byte[] 16   # You can use 16, 24, or 32 for AES
[Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($Key)
$Key | out-file $KeyFile

$PasswordFile = "\\Machine1\SharedPath\Password.txt"
$KeyFile = "\\Machine1\SharedPath\AES.key"
$Key = Get-Content $KeyFile
$Password = "P@ssword1" | ConvertTo-SecureString -AsPlainText -Force
$Password | ConvertFrom-SecureString -key $Key | Out-File $PasswordFile

$User = "MyUserName"
$PasswordFile = "\\Machine1\SharedPath\Password.txt"
$KeyFile = "\\Machine1\SharedPath\AES.key"
$key = Get-Content $KeyFile
$MyCredential = New-Object -TypeName System.Management.Automation.PSCredential `
 -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key)

However, the bottom of the article mentions the following:

  Be sure to protect that AES key as if it were your password. Anybody
  who can read the AES key can decrypt anything that was encrypted with
  it.

Of course, anyone with access to both the .ps1 file, which is clear text by default, and the AES key file can simply read the code and use the account name and files to create a PSCredential object to do stuff with. But can they use the key file to decrypt the contents of the Password.txt file and get the account password in cleartext? I tried doing this myself with ConvertFrom-SecureString but to no avail which, I guess, makes sense?

Additional remark: The code needs to work on multiple computers, so no "local machine only" encryption mechanisms as often seen with Powershell can be used here.

First of all, the AES symmetric encryption algorithm (which ConverTo-SecureString seems to be using) is definitely not "one-way". You can always recover the plain password if you have the key, otherwise even the suggested sample wouldn't work.

The source of your problem seems to be that this sample code looks like a serious misuse of the PS/.NET API. The purpose of SecureString objects is to make in-memory attacks more difficult by hiding/deleting sensitive information if it's not in use. To achieve this SecureStrings may use encryption, but this is an implementation detail, not a service meant for this kind of "public" use. The sample may work nonetheless, you should note that (counterintuitively) encryption is done via the ConvertFrom- cmdlet, while decryption is done with ConvertTo-.

If you want a proper API for encrpytion start here.


very secure router and advice to prevent intrusion I suspect that my home router was been hacked (with firmware upgrade), so that I would like to build and buy a new router enough secure. Something that can prevent not authorized firmware upgrade. I don't think that a username and a sophisticated password are enough because these data can be sniffed or captured with a simple code inject on the browser by a 0-day.

Maybe I need of a device that can be upgraded only by serial or that have a jumper that disallow firmware flashing. Then my questions are:

Is there such kind of home router?
Can u give me some advice to prevent such kind of intrusion?

Many routers can be flashed with custom firmware, e.g. DD-WRT, OpenWRT, or Tomato. These alternative systems have additional security features, for example:

Enforcing SSL-only administration.
Allowing HTTP(S) logins only internally, or only on wired connections.
SSH login with client certificates.
Stateful firewalls with more features than your average home router.
Advanced logging (e.g. log servers, SNMP traps, etc.)
Native IPsec support.
More advanced settings for wireless security (e.g. RADIUS)

On some of these systems you can also disable firmware uploads on the web panel entirely, to make it a little more difficult for attackers to do drive-by attacks.


Why FATCA IDES "protocol" does not use RSA encryption directly on Zip archive? Here is the context: to transmit FATCA data to US IRS service the IDES protocol defines the following steps

sign the XML Payload.xml file with enveloping signature, SHA-256 with RSA private key, as Payload-signed.xml.
pack the signed XML Payload-signed.xml file into a zip file Payload.zip
generate a single-usage 32 bytes key for AES-256
encrypt the Zip archive Payload.zip with AES-256 as Payload
encrypt the AES with RSA public key for exchange as Key
bundle encrypted AES key Key and encrypted zip file Payload in a Zip archive

Questions:

Is there any security reason not to encrypt directly Payload.zip with RSA public key designed for exchange ?
How to compare security of RSA encryption between a (really small) 32 bytes (the AES key) file and a larger Zip file ?

Due to how the algorithm works, RSA cannot "encrypt" data larger than the key size. When padding is used, this size drops even further - e.g. for PKCS#1 padding you can only encrypt (k/8) - 11 bytes of message, where k is your key size in bits.

Scaling this up to work with arbitrarily sized messages is infeasible due to the additional cost of long RSA keys. As mentioned elsewhere, RSA's performance scaling is quadratic for encryption (i.e. doubling the key length causes it to take four times as long), and cubic for decryption (i.e. doubling the key length causes it to take eight times as long). So if you want to use keys long enough to encrypt, say, 16kB of data, you'd need an 131072-bit key, which would take 262144 times as long on decryption than the same operation on a 2048-bit key. This simply doesn't scale.

What they're referring to in the specification is a hybrid cryptosystem which encrypts the data using a symmetric cipher (e.g. AES), whose key is then encrypted with RSA. This provides the sharing properties of asymmetric cryptography (e.g. anyone being able to create a message, but only the private key owner being able to decrypt it) without using ludicrously huge asymmetric keys, which would ruin performance.


Does services provided by different companies for DDoS protection work well? Is it necessary to use any DDoS service provided by different web hosting provider and other people?
We know, they are running their business to provide security to thousands of web property. They are earning plenty of money from this B2B service.

Some are good at what they say and what they provide, like CloudC.me, Cloudfare etc.
While other may get you more frustrated than DDoS attacker. Am I right?

Can't we, as a web owner, resolve issue by ourselves?

Distributed Denial of Service attacks work because they use multiple (sometimes thousands) of hosts sending traffic to your site to overwhelm your resources. This is not something you, as the target, can remedy. Cloud services, like the ones you mentioned, modify and limit the traffic to your site, and to do that, they need access along the path between your visitors and you.

Yes, there are ways to deal with DDoS on your own, but you can't stop or redirect the traffic. You can spin up a new site, on a new IP and URL, on a different hosting service, but your valid visitors won't be able to find you. It is also easy for the attackers to redirect their attack to the new site. You could change ports, shut down the service, or play with DNS tricks, but these are temporary solutions and have limited effectiveness.

"Is it necessary"? That's going to be up to you and the risks you have determined for your own site. If you can deal with a site that is overwhelmed for a while, then you do not need to pay for a service and wait out the attack. That decision is entirely in your hands.


Can a rogue wifi network install a CA certificate? Could an attacker create a false wifi network, then force (either via the user exploitation or other means) CA certificate install to the browser, allowing them to use something such as Burp Suite to MITM their browsing?

No, it's not possible to install a certificate through simply connecting to a Wi-Fi network. Now, it's possible to make a browser download a certificate through autodownload to somewhere in the Downloads folder, but that's just downloading the cert file and still requires you to manually install this certificate and enter an admin password.

That's about as far as it goes. Of course, sneakier ways exist, like getting you to download an executable that poses as a legitimate program but installs the cert, however that is going way out of the scope of the original question and just requires common sense to thwart.


Is there a way to enforce policies in x509 certificates? I have noticed there are some policy features in x509 certificates.  Are there some ways to enforce these policies in the certificates?

For example, let's take a certificate with imaginary oid 1.2.3 which means "public key length is 2048  bits".  Is there an automatic procedure which able to process this policy and deny certificates with other key lengths?

The enforcement of policies is done in the systems using these certificates for authentication or similar, i.e. web browser, mobile apps,  mail clients (S/MIME), IPSec peers, ... .  There are a few policies which are clearly defined in the standards and which are usually implemented in all of the systems dealing with X509 certificates (i.e. things like expiration, key usage...).

Any uncommon and/or vendor specific policies will likely not be supported universally. They might be supported for a specific use case (i.e. authentication in HTTPS) or in some vendor specific environments but not everywhere.

X509 has a way to mark extensions as required though and a client which does not understand a specific extension still knows if the understanding of a extension is required or not. This means that a standard-conforming client which does not understand a specific required extension will treat the certificate as invalid. If the extension instead is not marked as required then the client can simply ignore such an unknown extension.


Using a virtual machine for increased layer of privacy (w/ tor)? One of my friends told me that running tor in a virtual machine Linux and then passing it through a proxy on the underlying Windows would provide in his words great security. Is this true?

If you create a more anonymous environment for your VM, then yes.  You can keep its software and browser plugins, etc, ... to a minimum and hence provide a more "vanilla" machine.

On top of that, if you'd prevent it from accessing the host machine, and sign in with a generic login (i.e: user and root).  Even when someone would compromise the machine, they'd have less information about the user using it.

If they compromise the machine completely,it's unlikely that they were to access the hosts' saved passwords, etc.  But it all depends on how well you keep both (or more) environments separate.


Is this codes usage of document.location.toString() a DOM based XSS vulnerability? I have come across the following JS code in multiple web applications. I think the reason for the popularity of this code snippet is this accepted answer on SO. Developers seem to be using this code a lot of switching menu tabs:

var url = document.location.toString();
if (url.match('#')) {
    $('.nav-tabs a[href="#' + url.split('#')[1] + '"]').tab('show');
}

It basically reads from document.location and passes anything after a # to $() without any sanitation.

Even Burp Suite's Active Scanner reports it as a True Positive.

I've tried to exploit it, but it seems like a false positive to me. My hypothesis is that since JS is converting the URL as a String, any payload (including special chars) will be treated as a string.

Posting this here just to make sure if you guys can think of any other way to exploit it to cause a DOM based XSS?

This code snippet is vulnerable to XSS in jQuery prior to 1.9 (and in conjunction with the jQuery Migrate plugin). Even now, it remains at least a bad practice.

The string argument to $() (shortcut for jQuery()) can be parsed either as a CSS selector or HTML code. Parsing the string as HTML implies an XSS vulnerability, just as document.write() would. On the other hand, injecting into a CSS selector is not directly exploitable in current browsers.

The changelog for v1.9 explains how they changed the parsing behavior:

  Prior to 1.9, a string would be considered to be an HTML string if it
  had HTML tags anywhere within the string. This has the potential to
  cause inadvertent execution of code and reject valid selector strings.
  As of 1.9, a string is only considered to be HTML if it starts with a
  less-than ("<") character. The Migrate plugin can be used to restore
  the pre-1.9 behavior.

Since the string from your snippet ('.nav-tabs a[href="#' + <payload> + '"]') does not start with a <, you will not be able to inject your own code, when the page is running a current version of jQuery.

However, you should still sanitize the output. Sometimes, different modules (e.g. Wordpress plugins) come with their own jQuery library that might inadvertently override the newer version and reintroduce the legacy behavior. A simple fix would be to reject the string if location.hash is not alphanumeric or not contained in a list of predefined links.


Multiple Versions of SSL Signing Certificate I was checking out the SSL chain on onlineaccess.ncsecu.org because a network glitch made me paranoid.  Both Firefox and IE on my computer have this chain:

onlineaccess.ncsecu.org
Serial number 6C:16:7D:5A:D0:A3:0B:06:D2:C1:DE:A4:7C:C4:A9:23
 ^
Symantec Class 3 Secure Server CA - G4
Serial number 51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF
 ^
VeriSign Class 3 Public Primary Certification Authority - G5
Serial number 18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A

However, multiple SSL chain checker sites around the internet, e.g. https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp, say that the VeriSign G5 certificate at the end of that chain has a different serial number: 25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd.  They all agree on the other two certificates in the chain.

So are there actually two different legitimate versions of the VeriSign certificate which can be used to sign the same child certificate?

So are there actually two different legitimate versions of the VeriSign certificate which can be used to sign the same child certificate?

Signing is done by the public key in the certificate. Both certificates have the same  public key, so both can be used to verify the signature. The difference is that  18:da:d1:9e:26:7d:... is issued by itself while 25:0c:e8:e0:30:61:2e:... is signed by C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority.

Such setup is common if one wants to introduce a new root CA, like when switching the quality of the public key, i.e. 1024 bit to 2048 bit. Since it takes some time to get this new CA trusted everywhere one first signs the new root CA by an existing trusted root CA so that browsers can verify the trust path. Once this new CA is established one can abandon the old root CA.


How to prevent spam message sending to my Android web services I have an Android app that allow user to post comment. However this mean spammer are able to reverse engineer the services API and create a bot to post spam message automatically.

My research results:

Using recaptcha seems nice idea but it ruins the user experience.
Limiting accounts per IP is not a good idea cause in Universities and companies lots of people are using the same IP.
Limiting action per account is not also a good idea, As the user can spam using bunch of accounts.
The best idea I have is to randomly call recaptcha, this is a little better than the fix recaptcha but needs a lot of working on my side.
I think this is something that Hidden reCaptcha should solve in Android !

Please let me know if there is a solution for spam prevention in Android apps. Also please tell me if I'm wrong in something.

As answers to this question explains, your two main options are rate limiting and captchas. You say you dont want to use these, because rate limiting can be circumvented by creating multiple accounts and captchas are bad for the user experience.

To get around these problems, how about this:

Rate limit posts per account
Require successfull captcha to register a new account
Develop routines to easily block accounts that are found to spam (e.g. by letting users flag spam posts)

The captcha on account creation shouldn't be to intrusive since a user only has to complete it once, and it makes it harder to circument the rate limiting by creating new accounts. If you need stricter measures, require a captcha on each post until a user has provided some non spammy (unflagged) posts.


Implementing an invitation process for user setup In a new ASP.NET MVC application I'm working on we'd like an administrator user to be able to set up other user accounts by creating invitations which will be emailed to the new user. That email will have a link that will take the user to a one-time page where they can either create a site login or elect to login with an OAuth provider (LinkedIn in our case).

I'm concerned with the potential security implications of such a process. The danger is that a user's email could be compromised and an account established by an attacker, thereby gaining access to the application.

These invitations may not be immediately acted upon, so an expiration window would have to be too long to be helpful. Because one user will be creating invitations for another, I also can't restrict based on the IP address.

Am I being paranoid here? Is there a more secure process to handle user creation by invitation?

(Cross-post of my Stackoverflow question.)

It is up to the user to keep their email account secure. If it is compromised, it is their problem. There's no way to really solve the problem, other than ensuring that your site's authentication is good (see here for a guide) and that you have appropriate monitoring and moderation controls in place to deal with unscrupulous users.


Would disabling resumption/renegotiation mitigate the triple handshake issue? The Triple Handshake Issue was disclosed lately. As far as I understand it, it highly depends on renegotiation and resumption.

So the simple question is: Would disabling resumption and/or renegotiation mitigate this problem?

In more details:

Renegotiation seems to be quite secure, and there is only one problem about new certificates being presented. The authors highly recommend checking the newly presented certificate carefully. So fixing this would allow to keep renegotiation.

Resumption seems to be quite insecure. So until a long term fix is deployed, it seems to be better to disable it completely. Is this correct?

I am aware that disabling resumption will have a performance impact. For my current scenarios this is not relevant (long living TLS sessions). If someone still wants to elaborate on details, don't hesitate.

From my understanding the main point of the attack is, that the part of the browser responsible for checking the Same Origin Policy thinks it is connected to host A, while the part responsible for sending the appropriate client certificate thinks it is connected to host B because it got the certificate for this host in the renegotiation. This way the browser will let script etc from host A access authorized data from host B, because it thinks they are from A.

If you disable renegotiation this attack should not work any longer, even if session resumption is still enabled. But, if you really need renegotiation you should disable session resumption so that the attack does not work.


Is there really any safe way to store an encryption key? I'm aware of multiple ways to store an encryption key, some very bad, such as in your codebase or elsewhere on the same server, and others much better such as where the encryption/decryption is done away from your application or is bound to specific hardware (e.g. with a H.S.M.).

It strikes me that whatever method is used, if an attacker gains access to your codebase, they can simple write a script that would decrypt and export the database.

Obviously, keeping them out of your server is very important, but am I missing something obvious in the scope of what's mentioned above?

It strikes me that whatever method is used, if an attacker gains
  access to your codebase, they can simple write a script that would
  decrypt and export the database.

Preventive controls - like securing the encryption key with an HSM - attempt to prevent that from happening.  But as you say, if someone is deep enough into your application, they can leverage the existing decryption methods to access the data.  Preventive controls are often imperfect.

Which is where Detective controls come into play.  Your application should log decryptions, and those logs should go to a SIEM that can report upon anomalous usage.  If someone starts dumping all your records out, you should catch them.

No single control is perfect.  Layering different controls leads to greater security.


All users can write only one can read system The system I want to implement has the following requirement: All users can insert some sensitive data, but only one, master user, can see it.

There is any known, already implemented solution to this issue? I have to encrypt data so without the master password is impossible to read it.

The only solution I thought about was using asymmetric encryption. The users that can write will use the public key and the master user can use its private key to read the data. The problem here is that it's impossible for the user to remember a long password (public/private key)

Thank you!

You can create it in two ways: with access control or with encryption.

Access Control

You create a system where the settlers can access only a insert data page, and don't create a page to read data accessible to them. This way you have the write only system. To actually read the data, you create another page accessible only to the admin, where s/he can read all the posted data.

Pros:

Easy to create
Easy to maintain
Simple

Cons:

If the information is sensitive, a database leak can be devastating
No way to garantee the integrity of the data

Encryption

You create a system with one page to settlers, and other page for the admin. As soon as the data is posted by the settler, you encript it with a public key owned by the admin, then store the encrypted data on the database.

To read the data, the admin logs in using the special page, and gets the encrypted data in a json file, XML or csv. Then it runs the file through GPG or any other encryption software and decrypts the file.

The requirement of an external program can be solved by decrypting data locally using javascript. It's crucial to not store the private key in the server in any way.

Pros:

Very secure
Even a database leak will not compromise data

Cons:

Adds complexity
May require external programs


Proper method of block ads/tracking on VPN Server for Clients I´m running a VPN service on Debian(for a few friends) as kind of like a self learning project to gather more experience running a secure and highly available service.

At the moment OpenVPN pushes opendns servers to the clients and clients route all traffic through my server. I would like to implement some kind of Tracking-Block, like a list of know domains/IPs that are used by ad or tracking services (yes I know the list apporach is far from good) that automatically gets blocked for the user when running the VPN. So if user A would for example visit a website shadycompany.com/wedotrackingforaliving that loads various js which connects to one of the domains in my list, the traffic will not be forwared or just dropped.

Thinking about this left me with 2 valid options:

Use dnsmasq aliases on all domains to reroute all dns querys that
contain a domain from the list to localhost
Simply reroute to localhost via the hosts file

So my question is, are there any limitations to either method? Like max. number of rules, performance (https://serverfault.com/a/759896 - considering stated delay for hosts file lookups as (O(log2(n)), considering the list contains around 50000 entries atm) or security wise (bypassing dns etc.?).
Is there any best practice for such blocking that is better than the dnsmasq and host file approach?

Looking at the dnsmasq man page, it looks like that'll definitely work.

As stated in the man page,

  It is possible to use dnsmasq to block Web advertising by using a list
  of known banner-ad servers, all resolving to 127.0.0.1 or 0.0.0.0, in
  /etc/hosts or an additional hosts file. The list can be very long,
  dnsmasq has been tested successfully with one million names. That size
  file needs a 1GHz processor and about 60Mb of RAM.

Which looks like exactly what you're trying to do.


Cryptography behind RedHat subscription system (DRM)? I have to do a project like a subscription manager. Ideally this should work like RedHat subscriptions. I'm having a hard time figuring out how it was implemented. How do they manage to avoid a customer modifying the subscription components in a operating system and getting free patches to more instances that they have in the subscription? (ie they have X instances in the subscription but customer runs Y number of instances and Y > X.)

Does anyone know how it works, the cryptography of the system, etc.? Any open research articles, documents?

RHSM is the new x509 based PKI solution to their older RHN subscription manager.

Unlike RHN which provided authorization only for registered systems, RHSM provides authentication, authorization and repudiation based on certificates.

Those certificates rely on your typical asymmetric encryption making use of private and public keys to generate and sign the x509 certificates used for authenticating and authorizing subscription based updates.

If you are looking for the specific algorithms used to generate the keys you can always use the OpenSSL command line tool to examine the ASN.1 structure to determine that.

openssl x509 -text -noout -in


Why isn't PGP used to authenticate with keyservers? OpenPGP can be used to sign messages / authenticate.  Why is this not required by keyservers to ensure that only the owner of the private key can upload / modify / remove the public key on the server?

I understand that keys are synced between servers, but it seems that having even one server that required this auth (and did not accept keys from other servers) would be a much more reliable source and cut down on impersonations / dead, unused keys, etc.  Seems this could allow for per-key privacy settings and all kinds of improvements, but maybe I am missing something?

There are a few things to take into account here.

  Why is this not required by keyservers to ensure that only the owner of the private key can upload … ?

The main problem with a malicious key is someone posing as an identity he is not allowed to use. The uploader of the key would hold the private key, so we didn't gain anything here.

On the other hand, it is sometimes useful that a third party can upload a key.

  … only the owner of the private key can modify the public key on the server?

This already happens. You can't eg. add an identity or a subkey to a key unless you have the private part of the main key. Not only the keyservers, openpgp clients would detect that such key is wrong, too.

However, it is possible for anyone to add a signature to your key. This translates to a vouch that the key belongs to whom it claims (eg. they checked your passport and it states the same name as your OpenPGP key). This is a crucial part of the PGP web of trust model (even though, if not indicated otherwise, it is educated to send the signed key to the user instead, rather than publishing the signed key directly).

  …remove the public key?

To a point, it already does so. Note that the keyservers form a distributed system, with the many servers syncing their different keys. Thus, if a keyserver completely forgot about a deleted key, it would be readded a few hours later when syncing with another server. Thus, what we need is a deleted flag that only the key owner can set.

This already exists, with the name of revocation certificate.

-

Note also that the goal of the keyservers is to hold many keys (so you can find the one you need), not having trusted keys or providing any kind of insurance over its contents. You are expected to use the Web of Trust for that.

A closed keyserver that functions more similarly to what you propose is the debian one: https://keyring.debian.org/ It does so by adding a human into the process (the Debian Account Managers) in order to perform some steps (most importantly, the upload of new keys).


Why is GPG file encryption so much slower than other AES implementations? Correct me if I'm wrong: When encrypting a file, GPG creates a one-off AES encryption key and encrypts that key using RSA. This is supposedly to take advantage of AES's superior performance when handling larger amounts of data.

If that's true, then why is gpg --encrypt so much slower than, for example, p7zip's AES-256 encryption?

Let's try...

First, I create a 500 MBytes file full of random bytes:

dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500

then I encrypt it using GnuPG, measuring the time taken by that process ("keyID" is the UID of the public key I am using):

time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo

Total time on my machine (Intel i7 at 2.7 GHz, 64-bit mode, GnuPG 2.0.22):

3.77s user 0.55s system 99% cpu 4.328 total

so an encryption bandwidth of 115 MBytes per second: that's not so bad ! Now let's try again, but this time without deactivating the compression (i.e. let's remove the "--compress-algo none" options):

20.99s user 0.79s system 98% cpu 22.038 total

which is 5 times slower. So there you have it: it is not the encryption which is "slow", it is the compression (although more than 20 MB/s can still be decently fast for many usages).

115 MB/s is consistent with a "portable" implementation of AES. Code which uses the specialized AES opcodes (which are available on my i7) would be faster, up to, say, 300 to 400 MB/s (though AES-NI opcodes have a very high throughput, they also have a non-negligible latency, which means that the best performance requires parallel processing, i.e. CTR mode; but the OpenPGP standard mandates CFB, which is sequential).

Anyway, since a good mechanical hard disk tops at about 120 MB/s, while a very good Internet access (optic fiber) will be below 10 MB/s, one can say that 115 MB/s of raw encryption speed is sufficient.


Random SYN_SENT connections to Amazon EC2? I have looked around but couldn't find anyone else with this issue. On my console (standard asus i7 laptop) running Ubuntu 14.04 LTS - I noticed in tcptrack that there are a lot of connections being made to an ip address belonging to Amazon EC2 services. I don't have any connection to amazon at all, and these connections are all status SYN_SENT. IP examples: 50.17.195.149 and 54.243.128.120.

Is this a security offense of any kind, or is there a rational explanation?

Thanks in advance.

Check out the output from tcptrack immediately after opening chrome.

Netstat Output:

I noticed this same phenomenon with my Ubuntu 14.04 machine today (all kinds of connections to EC2 instances such as ec2-52-22-249-100.compute-1.amazonaws.com from Chrome), and on my machine at least, Ghostery and the DuckDuckGo search engine integrated with the omnibar both seemed to call out to EC2. You mention you don't have any extensions installed, what about other search engines?

By disabling Ghostery and closing Chrome completely, waiting a few minutes for the TCP connections all to close, then starting up Chrome, the connections eventually stopped. The instant I checked the box to enable Ghostery, they started back up. For DDG, I noticed it made EC2 connections after performing a search through the omnibar.


nodev option for /tmp directory The CIS standard for Ubuntu 14.04 LTS (01-07-2015) states that the /tmp directory should be mounted with a nodev flag - this is under the FileSystem Configuration (Section 2). This prevents the creation of block and character special devices.

Is someone able to confirm how could an attacker exploit not mounting the /tmp directory with nodev flag?

To my understanding, the device files (which to my understanding allow low-level connection to connected hardware devices) generally appear in /dev directory for connecting devices and are typically not accessible unless you have a root or tty user. The /dev directory is also not writable by a user other than root.

With the mknod command it is possible to create device files other than those that already exist in /dev.

$ sudo mknod /tmp/sda b 8 0
$ fdisk -l /tmp/sda
Disk sda: 80 GiB, 85899345920 bytes, 167772160 sectors
...

When a filesystem is mounted nodev, you can still create such device-files, but they are no longer usable.

An attack on /tmp files works like this. A program with elevated privileges opens some temprary file in /tmp and writes something to it. An attacker will beforehand do something to this file so that the program actually writes to another file.

The attacker symlinks /tmp/tmp1234 to /etc/passwd.
Root runs some program which writes to /tmp/tmp1234 as a temporary file.
/etc/passwd gets overwritten.

You can see that if /tmp/tmp1234 is not a symbolic link but a device file instead, the program would write to /dev/sda, or some other device, which could have bad results.


What is the difference between "unknown" and "undefined" trust? When you trust a GnuPG key, you can choose one of these five options (and I'm assuming the same options exist in other OpenPGP tools):

  1 = I don't know or won't say (undefined)
   2 = I do NOT trust (never)
   3 = I trust marginally
   4 = I trust fully
   5 = I trust ultimately

However, there is a "sixth" option that doesn't show up in the list: if you haven't yet set trust for a key, it shows up as unknown.

Is there a reason GnuPG makes a distinction between the two? Is undefined trust treated differently than unknown, or is the distinction just for personal reference?

The options 2 to 5 (never, marginally, fully and ultimately trusted) correspond to a definite decision made by you on the trust level which influences validity calculation.

Unknown says, you haven't made any decision at all and thus is special, indicating no value at all (you might consider it some kind of NULL value).
Option 1, undefined is similar and has similar outcome regarding validity caluclation, but is a statement you can issue on not wanting to decide on the key's trust level. You might want to use it as future reference instead of not setting any trust value.


Terminology: authentication vs verification The two words have a similar meaning and I'm having difficulty adequately explaining the difference to someone. You verify a person's identity by having them show a form of identification, such as a passport of driver's license. You also check for signs that the document is not a forgery. If it all checks out, you'd let them into a bar, let them open a bank account or something like that.

Authentication is very similar. You ask for knowledge, possession and/or inherence factors to check if someone for example is allowed to log in to his e-mail or internet banking. Is there a difference between the two, and if so, what's an easy to understand explanation for it?

Edit to clarify what's confusing for me: isn't the verification of a person's identity in my example a form of authentication with a possession factor?

Let's pretend we ordered some movie tickets online, and the process of later acquiring them involves identification in person at the box office before the event. You will be asked to produce your identification document (ID). That's identification. The box office attendee will then verify your identity by visually inspecting your ID - that's identification verification. This attendee will then check against their database to verify you've purchased those tickets online, and give them to you - that's verification and you end up with an authentication token (in our case - a ticket). You will then produce those tickets before entering the theatre - that's authentication.

So in short, identification is a sub-process (integral part) of identity verification, which is a sub-process (integral part) of verification, which is a sub-process (integral part) of authorisation.

In each of these steps, you verify one set of data of the client, against another set of data of the service provider. In multi-factor authentication, this data can have different forms and/or roles, such as something the user is, something the user has, something the user knows, e.t.c., or the previous sub-process produces new set of data (or a ticket, token, nonce,...) that the next process uses to determine the outcome of its function. The level of verification, or number of times the producer's data is verified against, (or scrutiny, as @TerryChia put it), denotes how we in turn call this verification process.

TL;DR - If it involves verifying access permission, we call this verification process as authentication.


Is online security training effective? I'm looking at an organization that requires that all employees undergo an annual one-hour online cybersecurity training (watch a video and take a quiz, apparently built using SANS's end-user security awareness training).

Is there any evidence on whether this is effective and how effective it is?  For instance, is there any measure or estimate of how much this kind of online cybersecurity awareness training reduces security incidents, or improves outcomes in some other measurable way?  Should one expect to see a 5% reduction in security compromises?  50% reduction?  0% reduction?

I did check on SANS's Securing the Human site, figuring that if there was any evidence or quantitative data they would show it prominently, but they don't seem to say anything about it.

The efficacy of a 1-hour annual online series of videos to affect user behaviour is very low (industry stats are 0-5% change in behaviour - perhaps statistically insignificant). Compliance is higher within the days after training, but then trails off very quickly. This type of training needs to be coupled with other supports in order to see results, but it is possible to see positive results up to 70% (consistent adoption of targeted behaviours) with certain supplements to this kind of training. Repetition of training and support and follow-up are perhaps more important than the knowledge transfer itself.

As for supplements, the most effective methods include regular prompting of behaviours and providing immediate feedback to the user as to the correctness of the presented behaviour. The most common form of this is simulated phishing, but it can include any behaviour the organization wishes to see.

In some phishing simulation programmes, studies have shown a decrease in users clicking links in emails of up to 70%. This usually requires regular testing and users slowly learn what to do over time. The key is regularity and immediate feedback.

This same approach can be done for password policies, tailgating, locking computers, incident reporting, USB device handling, etc.

Awareness is awareness. Knowledge transfer is knowledge transfer. But behavioural change is a different ballgame. It starts with knowledge (sometimes), but then it needs to transition to action. And that can't be done with a 5 minute video.

(I am writing a book on this very topic)


Retrieving client certificate using Tcpdump results in zero length certificate I am trying to proxy a mobile app (with Fiddler), which sends a client certificate to the server it connects to. I would think that capturing traffic with Tcpdump, retrieving the client certificate and using it with fiddler would be enough to bypass this.

However, when I capture packets using Tcpdump without a proxy, I notice that the server sends some certificates, asks for a client certificate, and the client sends an empty certificate (certificate's length was 0). After the whole SSL process, application data is sent normally, and the app works fine after that. The fact that a certificates length 0 is accepted made me think that any certificate would be accepted, but this does not seem to be the case.

I do indeed pass a fake certificate to Fiddler, and I see a similar entry again (certificates length 0), such that makes me think that I am missing something on how the client sends the certificate.

After the SSL process, I get a server Encrypted Alert and the app won't work at all. So, I am wondering, why do I get a 0 certificate's length even though I send a certificate? Even if fake, shouldn't I be seeing it in Tcpdump?

In TLS, after presenting its own certificate, the server may ask for a client certificate (CertificateRequest message). The request contains the list of the CA names that the server will use to validate the certificate. The client must then respond with a Certificate message containing a matching certificate: the client will scan the certificate it owns for one which has been issued, directly or indirectly, by a CA whose name is one of the names specified by the server.

If the client does not have a matching certificate, then it must send a Certificate message with an empty list (which is what you observe)(in SSL 3.0, in that situation, the client omitted the Certificate message altogether, but since TLS 1.0 an empty Certificate is mandated).

When the client does not present a certificate, it is up to the server to decide what to do next. The server may accept the connection nonetheless. In IIS configuration, that's the difference between "request certificate" and "require certificate". Among possible behaviours, the server may accept the connection at the SSL level, and then fall back to an application-level authentication protocol within the tunnel (that, from the outside, would appear as "encrypted application data").

Therefore, either you do not have a matching certificate on the client side, or the client does not notice that his certificates are matching, e.g. for lack of an intermediate CA (in the case root -> intermediateCA -> end-entity, and the server sends the name of the root, but the client knows only "end-entity").


My DNS Name Server does not support DNSSec client queries, what alternatives do I have? I am using a web browser to access DNSSec enabled sites.  My current name server doesn't (won't) support DNSSec for at least a year.  What are my alternatives?

Do any ISPs currently offer DNSSec?  Any other viable secure companies?

You may have to clarify what it is you mean when you say that your current nameserver doesn't support DNSSEC when you're speaking from the resolver perspective. You see, any nameserver (that will do recursive queries for you) will cache and forward any record set your request. That includes RRSIG records which are the foundation of DNSSEC.

Examples:

http://www.digwebinterface.com/?hostnames=www.isoc.org&type=ANY&ns=all

http://www.digwebinterface.com/?hostnames=www.isoc.org&type=RRSIG&ns=all

You can run a DNS resolver on your own machine that rejects invalid DNSSEC records. It is the local resolver's job by default, however. No special configuration is needed for nameservers to support this.


Is the IP address of the client present in the email headers for webmail services and for desktop clients? When I receive an email sent by someone using a webmail service (e.g. Gmail, etc.), I can find the IP address of the sender's email server in the email headers.
But do the email headers also contain the IP address of the desktop (client) computer used by the person who sent the email?
Would it be the case if they use something like Thunderbird instead of webmail?
Notes:

I have read Email headers from messages sent via Gmail online client contain private IP addresses. What are these addresses? and its answers, but I am not 100% sure if there are cases for which the client computer's IP address (where Gmail in the browser, or Thunderbird desktop client, is open) are disclosed.

More precisely, this comment "A desktop mail application is itself the SMTP client" + "The Received: header contains the address of the SMTP client" seems to imply that the IP address of the computer where Thunderbird is running could be in the headers. Is that true?

The Received headers in an email track every SMTP conversation an email has.
If you're using Thunderbird or another MUA (mail user agent), you're almost certainly speaking SMTP and therefore your IP address will be logged in a Received header as per RFC 5321 §3.7.2 (though a rare few outbound SMTP relays violate the spec and actually omit your IP address).
If you're using web mail, the SMTP connection is controlled by the web mail server. Many web mail servers will add the client IP either in a Received header (typically saying with HTTP) or another header such as X-Originating-IP. A number of web mail providers removed this data in the mid 2010s in anticipation of privacy laws like GDPR and the speculation that IP addresses are personally identifiable information (which is a debated topic), so this is not as available as it once was.
IIRC, Google never had client IP information in its web mail headers.
Arguably, with a responsible web mail provider using authentication for outbound mail, tracking the client IP is unnecessary since abuse reports can pin content on the sending account, which is more telling. This unfortunately limits what third party analysts can do since an attacker may be cycling through multiple accounts from multiple providers using the same pool of IPs.


Using public/private key without signed certificate I am working on a java program and I am now working on its network security. I want to use a secure connection since it transfers a lot of sensitive information.
On all security guides it is mentioned to always go with a standard way and dont use your own encryption/way.

Are there any security issues if I use my own public/private key pair without it being a trusted certificate? I understand that an attacker can send its own key during the exchange but what if the key is standard and I hardcode it into the code?

With SSL, the client must use the server's public key, and it must have a way to make sure that it is using the right server key, not a fake one sent by some attacker on the network path. That's what certificates are about. If you cannot trust the information in the server's certificate, then... you cannot trust it, and you lose.

If you know the server's public key in advance, and can hardcode it in the client code, then you actually trust it, and that's fine (although not very flexible). A hardcoded server certificate value is, in fact, a very reduced PKI.


Proxychains dosen't work, DNS leak test shows location I've been trying to use Proxy Chains with Tor but when I launch Firefox with them a DNS Leak test will show exactly where I live. I'm on Linux Mint and I'm using the stranded Firefox, not the Tor browser or something like that. I configured the proxychains.conf file by enabling dynamic_chain and commenting out strict_chain, I've also added socks5 127.0.0.1 9050 to my proxy list. I've been using Linux and the Terminal for about a year now while learning Web Development and I'm trying to learn some security now to better protect my web sites.. I'm completely confused here, thanks so much for any responses :D Here is the full conf file:

proxychains.conf  VER 3.1
#
#        HTTP, SOCKS4, SOCKS5 tunneling proxifier with DNS.
#

# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
#strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see  chain_len) from the list.
# this option is good to test your IDS :)

# Make sense only if random_chain
#chain_len = 2

# Quiet mode (no output from library)
#quiet_mode

# Proxy DNS requests - no leak for DNS data
proxy_dns

# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000

# ProxyList format
#       type  host  port [user pass]
#       (values separated by 'tab' or 'blank')
#
#
#        Examples:
#
#               socks5  192.168.67.78   1080    lamer   secret
#               http    192.168.89.3    8080    justu   hidden
#               socks4  192.168.1.49    1080
#               http    192.168.39.93   8080
#
#
#       proxy types: http, socks4, socks5
#        ( auth types supported: "basic"-http  "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4  127.0.0.1 9050
socks5  127.0.0.1 9050

By default Firefox does not do DNS lookups over the SOCKS proxy. You have to check the appropriate checkbox when configuring the proxy in Firefox. As example see https://i.stack.imgur.com/vB93s.png but in the current version of Firefox the dialog looks slightly different.


What are some of malware-based MITM attacks that can compromise the organization when working remotely? With the Coronavirus happening, employees use remote access to work remotely from not organizational laptop access to their VDI or remote access machine via company's web portal (e.g. SSL Portal VPN). I was wondering if the laptop is infected with malware, what are some of the malware-based MITM attacks that compromise the organization when working remotely?

I understand your security concerns with the use of non-work (hence non-controlled and not secured by your habitual standards).

I don't believe that there are any sort of malware that could possibly, via a MiTM attack, compromise the organizations security as long as they are using SSL.
Albeit if we look outside of the MiTM type attacks, there are, as you surely know, multiple attacks that could compromise your work VDEs given that they could emulate your user's access. A simple keylogger could permit an attacker to access a certain user's VDE giving them multiple attack opportunities if the VDIs permissions are not configured correctly.

Just to summarize, I don't believe MiTM is in the threat model for this type of operation albeit other sorts of attacks could allow a perpetrator to access your VDEs so they should be properly configured permission-wise and you should always be cautious of what sort of data you store/allow access to on the VDE.


How to monitor my home network traffic? I have an ATT U-Verse Wireless router supplying 5 computers throughout my home. It is hardwired to my main computer.
I have three children of all ages, one of which has had a tendency to make poor decisions on websites, email, and internet chatting.
We have discussed the issue, but I am of the 'trust but verify' mindset at this point

it will be a very good idea if you use a proxy server in your home network that will help you controlling web traffic and view the log file which contains the trace of connections I personally use Squid as a web Proxy and Sarg as a log analyzer .


Why http microsoft connection in netstat check? I checked established connections with "netstat" command in command prompt, and I found that there are some connections with ip's of microsoft (I checked ip online) that have http (and not https) connection established, they bring to some svchost.exe in a Win32 folder of the system. I know that http connections are not safe, but I guess they are safe since they have microsoft ip, but why these connections are not encrypted (http)? Is it normal?

I don't know know what connections in particular you observed, but here are some candidates that a Windows service (the background tasks or "daemons" that run in svchost.exe processes) might be using:

Reporting basic diagnostics and telemetry. Lots of software does some of this but Win10 in particular has a lot of telemetry that lets Microsoft know things about how the OS is used, and most people don't disable it (it's actually quite hard to disable on most Win10 editions). The data is not supposed to be personally identifying or tied to a specific user, so there's no particular need for it to be secure.
Checking for or retrieving Windows updates. I would certainly expect this to be done over a secure connection, although in theory with enough signatures and timestamping on the traffic TLS isn't required for security (it's not like the patches themselves are secret, they just absolutely must not be tampered with).
As part of Windows Defender, checking whether unrecognized files have been categorized as safe or not (it generally doesn't need to transmit the files themselves for this, just a non-reversible cryptographic hash, though it might upload the full files sometimes). Like the update checks, this is something I would expect to be done over TLS but in theory doesn't have to be.
Retrieving certificates or related metadata from Microsoft (which issues its own certificates and also provides updates to the Windows ones sometimes). Since certificates are inherently signed - their entire security hinges upon it - this can and often is done over insecure connections (a TLS server sends its certificate to the client over plain text as part of, but before actually establishing the secure connection).
Querying Microsoft servers for the time, to help keep your PC synchronized. This is often done over an insecure protocol but it's usually NTP (Network Time Protocal) which uses UDP on port 123, rather than HTTP which uses TCP on port 80.
Checking for updates to, or downloading packages for, "Windows Store" apps. As with the Windows Update possibility, I'd be surprised if this wasn't using a secure connection.

There are probably many more that I missed, but those seem like some of the most likely to be running unexpectedly in the background, as a Windows service, and communicating with Microsoft.
Doing a reverse DNS lookup on the IP address (where you try to see what domain names are associated with the IP address), or examining the network traffic (using a tool such as Wireshark or Microsoft Message Analyzer), might help you determine what that connection is being used for.
Incidentally, Windows ships with a graphical utility called Resource Monitor that can, among other things, provide a real-time view of network connections and traffic similar to netstat, and may make it easier to trace the connection back to the service owning it.


Does different clear text size mean different encrypted size in TLS? Is an attacker able to intercept tls communication and get cleartext size information from the encrypted size of intercepted payloads? Or is there some kind of padding which would prevent messages such as yes (3 letters) and no (2 letters) from producing different size (larger for yes)?

It depends on many parameters, such as the encryption algorithm used, the specific mode being used, and the exact difference of data.

For example AES uses block sizes of 16 bytes, and will always pad up to 16 bytes. Any message that is not a multiple of 16 bytes will therefore be padded up to 16 bytes. In your example with yes and no, this means that both will end up being 16 bytes long.

It furthermore depends on the length of those messages. If one message is 2 bytes long, and the other is two terabytes long, then no amount of "automatic" (meaning, as being part of the algorithm) will save you. You can of course manually pad a 2 byte message up to 2 terabytes, but it will be very wasteful.

So if your confidentiality depends on the fact that two ciphertexts are indistinguishable, then you need to manually pad the plaintexts.


Sending HTTP 403 as. 200 - "Silent Identification of Admin" A researcher recently reported an issue in a site about using script on a 3rd party site to discover if a user is an admin.

Here's the scenario:

Main site is target.example
Attacker site is evil.example
target.example has SSL and HSTS and redirects all http traffic to https using a 301 redirect
the session cookie on target.example is httponly and "secure"
evil.example has javascript that loads javascript src from target.example/admin/utility and using success/error of loading that html page can execute attack javascript

Example javascript that would be on evil.example:

<script type="text/javascript"
src="https://www.target.example/admin/utility"
onload="alert('Hello, Admin')"
onerror="alert('Ok, you are not the admin')"
async="async"
></script>

This technique leverages the fact that the site returns a 403 instead of a 200 on admin pages. The suggestion was to return a 200 error on admin pages for logged out users instead of returning the 403 error.

The risk presented by returning a 403 or 404 is that the attacker will only send attacks for users they know are admins. This would let the attacker fingerprint the site or attempt to exploit it and the only "noise" in the logs would be higher than normal number of 403 errors in the error log which might not raise suspicion as much as other kinds of activity might.

The question:
Does it actually add practical security benefit to return a 200? Is this a thing that many sites do?

Generally…

I would not return a 200 OK unless you want to tell web-clients that there is a resource available at the requested URI and that it is accessible (eg: to be indexed by search engines). Especially, I would never return a 200 OK for protected areas as long as the requesting client has not authorized.

Details…

Let me try to provide you with a bit of insight on the HTTP status codes you mentioned:

200 OK

Tells bots (and geeks) that the URI request is valid and the target resource (html page, css file, ZIP download, whatever) exists and is being returned together with that header.

What happens: requesting client gets told that resource exists and is available. It can and will get indexed by bots like search engines.

403 Forbidden

Tells bots (and geeks) that the URI request is invalid as the client requesting the data does not have appropriate authorization to request that resource.

What happens: requesting client gets told that resource exists but that he's not authorized to fetch it. It's like slamming the door on someone's nose while saying "you aren't allowed to do that" because authentication is required. Benign bots and search engines will respect that and treat this 403 Forbidden almost the same as if it were a 404 Not Found. They will not retry to visit the URI unless they have good reason to revisit the URI. Example: when checking new links pointing to that URI.

404 Not Found

Tells bots (and geeks) that the URI request is invalid as the URI that is used does not point to existing data on the server.

What happens: requesting client gets told that resource does not exist. It's like saying "nothing here, don't try again". Benign bots and search engines will not retry to visit the URI unless they have good reason to revisit the URI. Example: when checking new links pointing to that URI.

From a security standpoint…

You should always return the correct header matching the situation. Besides the obvious protocol reasons, let me give you a simple example why correct headers are needed: Imagine someone malicious trying to hack your site. If you always return a 200 OK you will have a hard time filtering the good from the bad requests. But if you - for example - notice a series of 403 Forbidden in your server logs, it's easy to nail down the timestamp, IP, and User Agent... which helps you filter and/or block such client requests.


How to test for OCSP? I have to test OCSP feature on a SSL server. Since it is a pretty standard feature now, I was looking around for tips on test plans/setting up OCSP responder etc?

An OCSP responder is not part of a SSL server; it is maintained by the Certification Authority which issued the certificate for the SSL server. Indeed, the OCSP responder publishes information on the revocation status for certificates, and it is the CA who chooses which certificate is revoked and which is not.

Thus, OCSP responders usually come with the software for managing the CA. See for instance EJBCA, an Open Source PKI, which comes with its own OCSP responder. There are also stand-alone responders, which feed on CRL produced by the CA; see for instance this one.

Either way, an OCSP responder is only good as far as validators talk to it. Software trying to validate a certificate, in particular a Web browser which acts as client to your server, will use a given OCSP responder only if they know that it exists and where to find it. In practice, this means that the URL to the OCSP responder has to be included in the certificate itself, as part of an Authority Information Access extension. Of course, it is up to the CA to include, or not, such an extension in the certificate, when it issues it.


Security on Login whats the best practices Everywhere i have looked at login's and how to deal with them, or tutorials is just showing me compare to plain text.

I know never to store a plain text password in the database.
I am just asking if there is any material i can read or look at that has a general standardized way of storing password at a semi-commercial level.

I'm asking due to creating a application myself, and wish to have good security practices from the start, so as to improve on them further in my IT life.

Things i am assuming

Encrypt the password and store it
Upon logging in Encypt the password and compare the two.

I just want to further my knowledge for a more commercial level login system, instead of learning about plain text logins.. Any sources would be much appreciated.

This is a very good read: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

In general you are going to usually want to store your passwords as a "salted hash". Then you accept their password, run it through your hash function (I use bcrypt) and compare the two.

Also another little detail to note that some people do not think about is the messages you are returning to your users. For example: If someone submits the credentials {user1, mypassword} and either of those credentials are incorrect, you should return "user/password combination invalid" instead of giving a specific message as "password incorrect" which would reveal that they are attempting against an existing account. Never give more information than needed.

This question will be useful as well: How to securely hash passwords?


Connect through two VPN clients What exactly happens if I connect through two VPN clients on my laptop? For example, I connect using Cisco Any Connect, and then use another VPN client (such as HotSpot Shield or proXPN) to connect through another tunnel.

Will the actual data be decrypted at the first server/site and be in plaintext/visible? I mean, will this happen: data is encrypted at my laptop, sent to server 1, decrypted, then encrypted, sent to server 2 where it's finally decrypted. I doubt it, because the second tunnel is through my client to server 2, not server 1 to server 2.

Or will it be a tunnel in a tunnel? So: data is encrypted and encapsulated twice at my laptop, decrypted at server 1, but is not yet in plaintext, and would be routed to server 2 where it'll be finally decrypted.

Or will the laptop simply pick one tunnel (the latter?) for a normal client-to-site VPN? Or will the second connected not even establish in the first place?

A typical VPN client works like this: it connects to the server, and then it instructs the operating system to give him all packets which are to be sent to any address in a given set. For instance, let's assume that the VPN client advertises that it should handle all packets meant for 10.0.0.0/8 (i.e. all IP addresses which start with "10"). When the OS sees a packet which should go to address "u.v.w.x", it checks whether "u" is "10"; if yes, then it gives the packet to the VPN, which does its magic with it and forwards it, under heavy encryption/MAC/whatever to the server; otherwise, the packet is emitted "to the Internet" as the OS would have done without the VPN client.

Details on how this system is implemented depend on the VPN implementation (e.g. it may declare specific "routes"; or it could intercept all outgoing packets with firewalling rules and redirect the packets it is interested in;...).

If you have two VPN clients and their "advertised sets of addresses" do not overlap, then chances are that they will live together nicely at the IP level: each will grab the packets for its own virtual network, leaving the other packets untouched. However, they might also fight for the "interception resources" which may result in the first VPN client to be wholly deactivated.

On the other hand, if both VPN advertise overlapping sets of addresses, then trouble is pretty much guaranteed. If you are lucky, the second VPN will refuse to run with an explicit message. Otherwise, one of the clients may take precedence, possibly intermittently, and things will be weird and confusing. Possibly, one VPN server will receive the packets which were due for the other VPN, thus incurring a severe data leak.

There will be trouble with DNS. Applications and humans do not want to deal with IP addresses but with host names. The DNS converts host names to IP addresses. A VPN being a "virtual private network", it uses names which are not visible to the worldwide, Internet DNS. Therefore, a VPN client will not only intercept IP packets, but also the name resolution system, and redirect some (if not all) of name resolution requests to a dedicated DNS server on the VPN.

Your two VPN clients will compete for that redirection. Things might just work well if the clients manage to redirect requests for just some domains. But chances are that hijinks will ensue. Some names for one VPN will probably cease to be convertible to IP addresses, resulting in reduced functionality. Possibly, one VPN will receive name resolutions for the other VPN, so not only is the functionality broken (because the DNS in one VPN will not know what to do with names from the other VPN) but some private data leaks from one VPN to another (host names are rarely very sensitive, but that's still a leakage).

In this last situation, the VPN which receives name resolution requests for private names of the other VPN is in ideal position to respond with forged DNS answers and redirect all traffic from the other VPN to itself.

So don't do that. Running several VPN clients concurrently is a source of trouble, hard-to-diagnose failures and potential data leaks.

To avoid issues with multiple VPN, you should endeavour to use more "controlled" forms of VPN. For instance, a SOCKS proxy with ssh. This would allow you to run one Web browser which redirect all its traffic to another host (the "VPN server") while leaving the rest of the machine (and, crucially, other browser instances) unaltered. See this answer for instance. Some purists say that such proxying is not a VPN, but for many practical purposes (anything which is Web-based, really), this is functionally equivalent. See also the alternative with port-based tunnels.

I used to do that a lot at one time (a dozen or so port-based tunnels, and also SOCKS proxying, and it was all working well). The SOCKS solution works well for name resolution too: the name resolutions requests from the Web browser will go through the tunnel, to be resolved on the other side (i.e. in the VPN), without touching the local DNS configuration. Port-based tunnels require a static local name declaration.


Can virtual machines be used to isolate vulnerable software? I have had a look at most of the previous questions about virtual machines (VMs) and they all appear to be focused on hosting malware in the VM and preventing it breaking out of the VM.

What I can’t find is anything the other way round…for example using a VM to run an out of date OS and preventing malware compromising the VM via the host.

Obviously to minimise the risk of compromise the vulnerable OS needs to be isolated from external threats as much as possible, so let’s assume the following:

No network connectivity;
Other interfaces disabled (USB, Bluetooth etc.);
File transfer via a dedicated drive/partition on the host only (i.e. no access to the host’s system drive).

And the following for the host system:

Current OS;
Regular patching;
Up to date AV:
File import restrictions (i.e. block dangerous file types via email, Internet and removable media).

Is running the vulnerable OS (or any other software for that matter) in this way an effective way of isolating it and preventing external exploits?

It's possible to break out of a VM and execute onto the host machine which is usually version and software specific so the scope of this actual attack but as I'm sure you'll of guessed it's very low possibility but not to be overlooked.

If you're very paranoid and want the most secure then no software can offer you full isolation. Use a physical computer which doesn't have access to any device which is capable of outputting any signals to any remote devices.

If using a physical machine isn't possible then yeah, VM is the best solution. Just ensure you restrict the user you execute the actual VM under doesn't have more permissions (DACLs etc) that it actually requires to minimise the security risk of malware executing outside of the VM.

Edit:
Sorry, I misread what the OP was asking for. Nether the less I'll leave above answer if any is doing the reverse.

With that been said, of course it's possible to break into a VM. I use Visual Studio which is a programming IDE and there is a VMWare plugin which you can debug your software into running VMs which is created by VMWare. So, if VMWare Plugin can see all running VMs then they must be some export that uses an IPC to the VMWare itself.

Even if the VM vendor didn't have inbuilt functionality if the malicious software can execute OpenProcess (or lower APIs such as NtOpenProcess), ReadProcessMemory (NtReadVirtualMemory), WriteProcessMemory (NtWriteVirtualMemory):

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680553%28v=vs.85%29.aspx

Well, this list could go on about other forms of code injection. Breaking from host into a guest would be must easier as you'll have direct access to the memory.

To secure your software you'll want to execute it under another user and deny all other users using DACL to the following:

PROCESS_VM_OPERATION
PROCESS_VM_READ
PROCESS_VM_WRITE
WRITE_DAC
WRITE_OWNER
PROCESS_DUP_HANDLE

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx

Finally ensure to use an AV which monitors IPCs and virtual and physical memory.

@Comment
Yeah, the risk is quite minimal really unless your targeted as an individual.
If the attacker can compromise the host machine then your VMs are easily at risk unless you've preformed the above tasks to reduce the scale of the attack.
Though, if the malware manages to get into kernel then it's game over regardless of the security you put in place. Malware on the host machine gaining access to the guest machine is a whole different field.

To explain this little better I'll make the scenario:

Your VM software is Oracle VirtualBox
Your host machine is Windows operating system which is infected with x malware.
Your guest machine is isolated from any remote connections etc which is currently virus-free (This is why it's differs from scale of attack on host)

Exploiting the inbuilt components of the software (Easy method):

Simplest way to explain this without knowing Windows internals would be there is an executable called VBoxManage.exe which is capable of managing hardware of your VM and the whole VM itself.
So, the malware just invokes passes the malicious commands to VBoxManage.exe to copy and executes the malware onto guest machine. Though, do note that administrator permissions is required by the malware.
If you let me know the VM are your using then I can give you more accurate scope of attack. VMWare has pretty much same functionality as Oracle VirtualBox without getting all hardcore into details.
I've not used VirtualBox in a while so things maybe slightly different but you could used to use a command called VBoxManage.exe guestcontrol.

Memory hacking

Let's for argument sake say there is no command-line executables to manage the VM and/or SDK on how to communicate with VM.
If the malware process can use OpenProcess API with PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE the malware can perform many varies ways to inject code or read data from your VM process.
This can be a very challenging or easy task but it's hard to say without trying it myself though I'm sure administrator permissions would be required to begin with.

I don't know if you want me to go into the details of process security and reverse engineering the software? Or you just stick to the above on how to reduce the attack scope regarding process permissions and user permissions.


Java Object encryption I am developing a Java application and I need to do a symmetric encryption to secure some of my sensitive information. There are many algorithms like AES,DES 3DES in java cryptography. What is the best algorithm should I use to encrypt my sensitive information ?

Mostly I do have string values and there are couple of instances that I need to secure java object.

AES-128 (or higher) is the recommended algorithm.

You should also choose a good Chaining Method with a random Initialization Vector. Padding variable length source data is helpful since AES is a block algorithm. AES/CBC/PKCS5Padding is a good option.

The encryption Key should be generated from a Cryptographically Secure (Pseudo-)Random Number Generator. (i.e. Java's SecureRandom)

Alternatively, the encryption key could be Derived from a reasonably strong Password using a suitable Key Derivation Function. (comparison here)

I'm assuming you need to encrypt data at rest. Key Management will have to be considered.

If you need to encrypt data in transit you'd also need MITM and Integrity verification, which is best accomplished with TLS. (HTTPS)


Password storage/retrieval for local network server I have an application server, written in C++ and also uses REST API to serve requests. There is no database, just a simple service which returns if the content of request is valid.

Situation

The server is in a local network and only reachable there, has no internet connections, and only meant to serve request from the same local network.

Our solution

Now I want to secure the REST API with Basic Authentication, with one user only, and have no idea if this following method to store password is secure enough :

The password will be passed as parameter on deployment
The deployment will encrypt (with DES) the password with a key, store it in an environment variable, say PASSWORDENV, whereas the key will be hard-coded in the application code.
When request comes, the application should read the HTTP headers for id and password, encrypts the password, and compares with PASSWORDENV

Concerns

The encryption key is hardcoded, but I dont know any other way else to verify the password
Is there any security problem with our solution ?

Basic Authentication, will give you marginally more security than you already have:

Consider the vectors you are defending against: bad actor who gains access to the network or disgruntled employee with access to the network.

Bad Actor: If you are not using TLS, anyone on the network will see the entire request/responses (including the password), so TLS is required to prevent the first vector.

Disgruntled Employee: If you are using TLS, anyone on the network with the private keys, will be able to see the entire request/response (including the password), something more may be required to prevent all instances of the second vector.

Now you need to assess the risk associated with these vulnerabilities, which requires you to consider the probability of the vulnerability being exploited and the loss you would take if the vulnerability was exploited (financial, repetitional, etc.)

Side Note:

There are widely accepted forms of token based authentication that may help increase the security of authentication: OAuth or OpenID may work depending on your use case.


Web Applications (http): Don't get how token based authentication is secure See something like this:

https://stackoverflow.com/questions/10826293/restful-authentication-via-spring/10864088#comment21706215_10864088

Or more specific:

Token-based authentication - Securing the token

My question now is:

Man in the middle can just read the token and use it in is own request. I mean he doesn't need to know what the token actually means or anything, he can just use it. What am I missing?
I don't see how this is any better than having a session cookie in terms of security?

So as far as I can tell, the only thing you can actually do is to always use ssl and then you can just drop the whole token thing and use basic auth for every request?

The only advantage of the token I see is that you don't need to use basic auth and get more control, like an actual log out and nicer login form and such (at the cost of higher complexity).

What am I missing?

Token-based authentication is not about securing the communication against third party attackers. It is to secure the server against the client himself.

For proper security you need SSL anyway. Without SSL, imagine an active attacker, e.g. that funny-looking bearded geek sitting two tables from you in the same restaurant -- you don't know it, but he has a fake WiFi access point in his backpack, and he is currently intercepting your Internet traffic, which you believe to go through the restaurant "free WiFi". That guy can hijack your communications at any point. He sees what you send to Web sites and what you receive from these sites, and he can alter both kinds of data at will. When he chuckles and almost gags on his milk-shake, that's because he is reading your emails.

To defeat active attackers, you need something which protects the data confidentiality and integrity, and makes sure that you talk to the right server, not to the Bearded-Geek-in-the-Middle. And that "something" is SSL.

With SSL, you can indeed just use HTTP Basic Authentication. This will work... provided that you want to use HTTP Basic Authentication, because that authentication is handled by the Web browser, with its own popup, which can be ugly. For instance, it may look like this:

Most Web designers are appalled at the sheer practicality and minimalism of this popup, which is reminiscent of the glorious architectural experiments from the Stalin era. Therefore, almost nobody does that. Instead, Web sites implement their own "login page", in pure HTML, and therefore cannot benefit from the inherent support of Basic Authentication by the browser. They must use a cookie, i.e. the "authentication token" which we are talking about.

Moreover, user authentication is not necessarily based on a login and a password. Some sites do funkier things, including delegating authentication to another server, using the OAuth protocol. This very site, security.stackexchange.com, does that. This again calls for some storage of data on the client browser, data which is not a login and password.

Once you begin to store data on the client browser, you may envision to store data that should remain opaque for the user himself (should he be inquisitive enough to have a look at his cookies), and which resists modifications from the user (depending on the data and what it's used for). This calls for, respectively, encryption and checked integrity. That kind of "securing" is all about storing things in the client system but without trusting the client system.


What are the pros and cons of using DNS to block unwanted domains? There are many methods to block unwanted outgoing requests. Examples include browser settings and extensions, and .hosts files. While DNS blocking won't affect direct accesses to a numeric IP address, it can be easily implemented to block entire domains and their subdomains, for an entire network as opposed to app-by-app or device-by-device.

Philosophically, DNS may not be the place do do such blocking, but it can be very effective, especially as part of a defense-in-depth strategy. What additional advantages and disadvantages are there to blocking with DNS?

Pros
 - Easy to implement network wide (DHCP server and a local DNS server are enough)
 - Easy to block (just add it to a list in the DNS server and route it to a bogus address or local address)
 - Easy to Bypass (if needed its easy to bypass)

Cons
 - Easy to bypass, just use a different DNS or add an entry to the hosts file is enough.
 - Is considered "Bad Network Practise" as you are redefining a Domain that is not yours.

In my opinion its better to either use a Proxy to redirect the users inside to a "Do not use" page. Possibly with the addition of IP blacklisting in your firewall.


The Walmart clerk takes pictures of my IMEI # and Phone numbers I went to WalMart looking for a cover for my new LG-Stylo Smartphone. I asked a one of the workers where to find them and he said they don't have any. Come to find out he has the same phone so I start asking questions.Then it gets weird.I tell him I'm not happy with the camera. Next thing you know the phones in his hand, he goes to my Settings/About phone/Status then takes a picture of my phone number, IMEI# and IMEI SV#. He tried to take pictures other setting info when I asked "Should I really be letting you do that"? When he gave me some line about, he just wants to get info on the camera etc...I've been uneasy about the whole event ever since. For Crying out loud I just surrendered my Antique Flip Phone for the Smartphone. This this phone has far more personal and vital info then my flip phone did. It just happened so quick. What should I do?

Get a new phone, seriously. If someone has your IMEI they can authenticate with your IMEI to whatever cellular provider (this is not easy, but provenly possible with the required skills). If your IMEI is used for any kind of illegal operation and police start investigating, this can get you into deep trouble. E.g. someone threatens to blow a bomb using your IMEI. It is very likely that police discover the fraud in such a case but i'd not want to get into something like this.


How does Tor protect against fake entry nodes / total redirection? There is much material on how to protect yourself from malicious exit nodes, especially by using SSL and minimizing the leakage of identifying information (user-agent, screen size, etc.).

However, I was wondering why an attacker could not just setup a bunch of fake Tor entry nodes, and redirect your outgoing connections to them (assuming you must route all data through their network). They could even virtualize or fake the whole Tor network with ease.

What measures does Tor have against such attacks, and what can a user do against it?

Are there e.g. a list of hardcoded entry servers with known public keys? If so, how do I know that those priviliged servers are not operated by the NSA or the Chinese or whoever? They could be a) compromized from day one, or b) someone could have manipulated torproject.org when I downloaded the software, and replaced the server list and checksums.

(I hope this doesn't sound too paranoid. I got this idea when I was working a large (US-)government-run facility, and noticed how pervasive their computer security measures were (probably with good reason). If I were a dissident or had something to hide, they could have easily 'rabbit-holed' my entire network. I guess this is a much more pressing problem in other countries.)

[Is there] a list of hardcoded entry servers with known public keys

Every server is capable of acting as an entry as every packet is either a packet to be forwarded or an exiting packet. This is achieved by encrypting each packet to a specific node. Each node has a public key listed which is used to negotiate a session key with that node.

The principle behind this is called onion routing. The fine details are expansive, so reading the article is best. The summary is that the packet is encrypted for the last node, then that is encrypted for the 2nd to last node, and so on.

Without controlling every node in the chain, linking the original sender to the raw packet would require traffic analysis.

Since the public key of a Tor node is published, no node in the chain can redirect your traffic in a meaningful way. It must pass to a node that is capable of decrypting it. A symmetric key is derived using a signed Diffie-Hellman exchange, and thus will not be accepted from a node that doesn't possess the matching private key for the published public key. That key exchange and layered encryption is what protects you from malicious nodes removing downstream nodes from the chain.