Should I be concerned that Google no longer trusts specific Symantec root CA cert that is also on my Windows system?

Does Google's decision mean that it would be prudent for me to also delete or disable the root CA from my machine?

Dunno. Symantec ain't being too helpful. Theoretically it should not hurt but something seems to be broken in clients.
Also: Vendors don't seem to agree on this.
I've whipped up a quick script and parsed four trust stores (Apple, Java, Microsoft, Mozilla) that the ssylze SSL test tool ships with:
$ grep -rl 'Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority$' | xargs -- grep -A2 -- 'Serial Number'
apple.truststore/108.cer.txt:        Serial Number:
apple.truststore/108.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
apple.truststore/108.cer.txt-    Signature Algorithm: md2WithRSAEncryption
--
apple.truststore/164.cer.txt:        Serial Number:
apple.truststore/164.cer.txt-            3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
apple.truststore/164.cer.txt-    Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/143.cer.txt:        Serial Number:
java.truststore/143.cer.txt-            3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
java.truststore/143.cer.txt-    Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/61.cer.txt:        Serial Number:
java.truststore/61.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
java.truststore/61.cer.txt-    Signature Algorithm: md2WithRSAEncryption
--
microsoft.truststore/15.cer.txt:        Serial Number:
microsoft.truststore/15.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
microsoft.truststore/15.cer.txt-    Signature Algorithm: md2WithRSAEncryption

So: (if the sslyze stores are up to date) Apple has both, Java has both, Microsoft has one. Mozilla has none.
Sidenote: sslyze also ships with a "Google" trust store, I've skipped that, because I don't know what that even is. (For Android phones maybe?) For one thing, Chrome does not use its own trust store. It relies on the OS trust store. And this may be the root of the problem here. They can't just remove a CA, they must explicitly revoke it. -- Mozilla Firefox has it easier in that respect, since they run their own trust store.

Or might Microsoft Windows have some automated process that would also stop trusting the same certificate (in for example IE)?

Yes. They have an automated CA update mechanism. And they regularly make changes. For example they announced the intention to remove some 20 CAs just today.

Also, instead of deleting the root CA, I could go to it's properties and maybe update it with "Disable all purposes for this certificate". Would there be any benefits from choosing this option instead?

Absolutely. Either that or moving the certificate to the Untrusted Certificates store. Otherwise it will just be re-added by the automated process.
Update 2015-12-30Wed. Oh dear, oh dear, oh dear.
Ryan Sleevi made another blog post. This time privately and not as a Google spokesperson and has these (discouraging) words to say about it:

Ryan Sleevi, blogged via Medium.com, A History of Hard Choices:

December 2015: With only one week’s notice, Symantec requests that a root certificate trusted on billions of devices be revoked, so that Symantec will no longer be obligated to abide by the Baseline Requirements for that root. Without this notice, Symantec’s use of their root in this manner would have been in violation of their agreements with root programs, putting at risk every other root certificate they operate and every single customer of theirs. Yet, even with this notice, it will likely take years to reduce the number of users and devices at risk from certificates issued by Symantec from this root to a something quantified in the tens of millions.

Steps to explode apple.pem bundle
I ran these commands to split the PEM bundle into individual PEM files:
[~] $ wc apple.pem
  4903   5279 303714 apple.pem
[~] $ mkdir apple.truststore
[~] $ cd apple.truststore/
[~/apple.truststore] $ awk 'split_after==1{++n;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".cer"}' < ../apple.pem
[~/apple.truststore] $ for RAWCERTFILE in *.cer; do openssl x509 -in $RAWCERTFILE -text 2>&1 > $RAWCERTFILE.txt; done


Data Leakage Prevention tips for regular home users

As mentioned, you can keep sensitive data and your internet connection on separate machines. It is quite a hassle, but it is quite secure. It really depends how valuable you think your data is.

One method a bit easier than separate physical machines, is separate virtual machines. Qubes OS has the basic idea here. Because it's a software layer, any of your internet exploits will be blocked, provided they don't manage to bypass the hypervisor. Although this is quite good security from software, for some people, that's too big an if.


What is the state of Security in Comp Sci Programs

From the universities I have looked at, the basics are there (to a greater or lesser degree) but as it isn't a focus, there is very little effort put into updating the course material, for example some course material we have seen has code examples containing well known security vulnerabilities. This just isn't going to get rectified onthe low budgets universities have. And as far as advanced topics, you'll need to be on an Infosec related course.

Initiatives such as the Scotland & Northern Ireland Centre of Excellence in Security & Cybercrime are hoping to make a difference by using volunteers from industry to improve the training in order to lead to graduates who actually understand security.

(disclaimer - I am one of the volunteer supporters of the CoE in Scotland)

Edit - to be fair there are a couple of universities in the UK that have excellent security modules but these are normally part of infosec degrees (eg Royal Holloway, Westminster, Napier)


My advice to you is, rip off the band-aid and go modern.

It's hard to judge without knowing more about your situation (who's collecting the CHD?  What environment?  In an office?  On the phone?  On the street?).  But the easiest way to make it all go away is to go for mobile-device based swipies that will encrypt before the info hits your device and send it on in.  If you never have unencrypted card data, you don't have to worry as much, and you have less PCI scope.

I'm aware of Roam and Square that do this off the top of my head, and there are other companies out there doing the same.  Enabling the mobile device is the new black.

Could you add compensating controls to ease your existing solution?  Sure.  Google quickly shows me that Ricoh has a device whose scanner can

  Protect sensitive or confidential scanned documents with security
  features, including encrypted PDF transmission.

Some doco for that here.

But it sounds like you've got some jury-rigged methods in place, and that's what's drawn the auditors (well, that and the lack of encryption).  If you jury rig controls on top of a jury rigged solution you're not doing yourself any favors.


How safe are the password prompts of the SafeNet eToken 5110 or similar cryptographic hardware tokens?

If a key logger is infecting your machine, any text you type, including the private key you enter to the SafeNet prompt will be stolen as you type it in. You better use an automated entrance of the private key like in this article I wrote. The idea is to use an API call to connect to the hardware token and to sign an .exe with it but instead of using the user interface provided by SafeNet.


I have used AIDE in past and it does only file integrity monitoring. It creates a database when you first install the same, probably mapping hashes along with the respective file names. This comes handy when you want to see any Malware/Program changes which files.

Said that, OSSEC is more superset. Read "AIDE only does file integrity checks. It does not check for rootkits or parse logfiles for suspicious activity, like some other HIDS (such as OSSEC) do." from this site

I don't see any issue with both of them running on same system, but I don't see value in having both unless you find anything which proves OSSEC prone to hash-collision.

To answer the second part of your question, decision of deploying the OSSEC in Manager/Agent mode or standalone mode depends on the requirement. If there are hundreds of hosts, you want centralized management where all the database is stored on server side.


What are some important concepts to teach developers about cross-site scripting (XSS)?

From a developer's perspective, the first two points you have are not very relevant. Stored and Reflected XSS have the same mitigation: properly escape things you output according to their context. Layers of defense will likely only be viewed as an excuse for poorly implementing this mitigation: "The WAF will catch it for me."

Instead, focus on these code hygiene practices:

Validate, not escape, at input. Input validation should be only for ensuring the input makes sense, not that it is "safe". It's impossible to know at this point whether it is safe, since you don't know all the places it will be used.
Assume all data is unsafe. Never make the assumption that some data has been escaped, or does not include tags or quotes or entities or whatever. Understand that unsafe input can come from anywhere: HTTP headers, cookies, URL parameters, bulk import data, etc.
Escape at point of use. Escape the data for the context in which it is used, when it is used. Only want to escape once to improve performance? Name the destination variable according to where it is safe to use: jsstringsafeEmail, htmlattrsafeColor, htmltextsafeFullName, etc.


Difference between brute-force and dictionary-based in the mitigation process of the IPSs

The terminology is not fully universal so I will detail my definitions:

A brute-force attack occurs in a situation where there is some secret value X that the attacker wishes to obtain, and the attacker can "test" whether a given potential value for X is the right one or not. So the attacker tries potential values until he hits the right one.

Such an attack can be online or offline. In an offline attack, the "test" for a potential value is a computation that occurs solely on the attacker's computer. For instance, X is the key for an encryption system, and the attacker has at his disposition a message encrypted with key X, and the attacker knows enough on what the decrypted message should look like to unambiguously detect whether his current guess for X is the right one or not.

When the attacker cannot run an offline attack, he must resort to an online attack: each test involves talking with the defender's systems (e.g. trying to log on the server). The attacker really prefers offline attacks because they are a lot more discreet (everything happens on the attacker's machine, without leaving any trace) and also because he can speed them up by throwing more hardware at the problem.
A dictionary attack is a special-case of a brute-force attack where the secret X is something "human-compatible": this is a value that a human user accepts to memorize and possibly chooses himself; typically, a password. The brute-force attack is then about trying out potential values, i.e. values which are simple enough for the human user to handle in his brain. The set of such values is called the dictionary because what humans choose and keep in their minds is usually words.

There again, dictionary attacks can be offline or online.

An important point to consider here is that when X is chosen by a human in his brain, then not all possible values for X are equiprobable: some words are a lot more likely to have been chosen by the user than others (i.e. a human password is much more often "dragonfly" than "kelxdparf", even though both are sequences of 9 lowercase letters). The dictionary is thus a list of guesses for a brute-force attack, ordered from most to least probable.

There are basically three ways to defeat brute-force attacks:

Make it so that the space of potential values for X is large enough that the attack is doomed from start. E.g. specify that X is a sequence of 128 bits, and generated with a strong PRNG: since a strong PRNG is used, no sequence of 128 bits is more probable than any other, so there is no way for the attacker to optimize his search (there is no order of guesses that is better than others); and the space of possible 128-bit sequence is huge (it has 2128 = 340282366920938463463374607431768211456 elements) so the attacker's probability of hitting the right one within the next century is abysmally low.
Make it so that no offline attack can be performed. This is not necessarily possible; e.g. in the case of a password-encrypted file, the attack context assumes that the attacker got a copy of the encrypted file and tries to crack it, in which case an offline attack is always possible. But if you can arrange for all attacks to be online, then you can apply countermeasures, e.g. refusing to talk to a given requester after 10 wrong guesses. An extreme case is a smart card, that requires a PIN code and locks itself after a few wrong guesses.
If offline attacks cannot be avoided, then make it so that each guess is unavoidably expensive. This is the whole idea of password hashing. The processing of a given input is done through a function with many iterations, such that all usages are slowed. The concept is that taking 10 milliseconds to verify a password instead of 10 microseconds is normally no hardship for a server (because it does not have to do it many times per second anyway), but making each try 1000x more expensive will also make the brute-force attack 1000x more expensive. This is a trade-off: making password processing more expensive tends to imply increased fragility against denial-of-service attacks.

The main difference between "brute-force" and "dictionary" attacks is that when the secret is human-compatible (the dictionary attack context), then this also means that the space of possible values for the secret is awfully small. Human minds are simply not good at all at remembering complex values; there are even worse at making random choices. Thus, when a dictionary attack applies, the first defence method I explained above (extending the space size) is not possible. So you have to resort to one of the two others.

Avoiding offline dictionary attacks means using communication protocols and architectures that never expose anything that could be used as offline test for a potential value for the secret X. This is outside of the scope of IPS. What an IPS can do is to enforce rejection rules for the second method (mitigation of online attacks): a good IPS should be able to detect when many requests come from the same source, and efficiently block them upon entry.

In that sense, there is no real difference, for the IPS, between a dictionary attack and a non-dictionary brute-force attack. At best, we can say that brute-force attacks that are not dictionary attacks should be defeated through using large spaces for secret values (i.e. in cryptographic terms, for symmetric encryption, use 128-bit keys, not 40-bit keys), making IPS irrelevant.


If I backup my files to "The Cloud", will they be kept there forever?

"The cloud" is marketing-speak for "other people's servers", so I will use that term instead.

When you move your data to other people's servers, you need to be aware that they have direct access to your data. When they are not trustworthy, they are able to steal your data. Read the privacy policy of the people you give your data to. Many people do not give you any guarantee that they won't look at your files and might even share it with third parties for fun and profit. This is usually worse with people who offer you to store your files for free. Remember: When you are not paying for a service, you are not the customer. You are the product!

A sensible precaution is to encrypt your files before you upload them to other people's servers, so that they can't see the content. But then you are responsible for remembering the decryption key. Lose your password and you lose your files. You might also miss out on some convenience features other people's servers provide, like viewing your files online, sharing them with others or automatic versioning.

Also, read the terms of service in regard to availability. They might not guarantee that their service will be available forever. The people might reserve the right to delete your files from their servers with a very short notice or even no warning at all. This is, again, usually worse with people who don't want any money from you. But even if they give you a written guarantee, that guarantee is worthless when they go bankrupt and have to sell the servers you have your data on. Taking legal actions against a bankrupt company is usually pointless.

However, when you believe you can trust these people, having your data on their servers can even have a security benefit. People who provide such services as their primary business model usually(!) have lots of know-how about how to properly secure a datacenter against logical and physical attacks. When you lack the know-how and resources for proper IT security precautions, letting someone else handle your files might not be a bad decision. But you should do your research about the security track record of the people whose servers you are storing your files on.


Is OpenBSD's low number of exploits really that relevant?

Yes, it's relevant, but you have to understand the context.

There are several ways a platform can achieve a low rate of exploitation such as code quality, a hardened configuration, a limited feature set, and obscurity. There's no doubt that OpenBSD benefits from obscurity to some degree - if it were as popular as Linux or Windows, many more people would be scrutinizing it. However, it's had so few exploitable flaws over time that you can't simply write off it's track record as obscurity alone. Other platforms of a similar size usually contain many more exploitable bugs.

OpenBSD has consistently emphasized code quality over features, and has always minimized the number of services listening by default, so there just isn't much attack surface. It's a minimalist OS compared to Linux and Windows, so it's really a different animal.


There's a really good explanation of the crypto/auth for FxA.  Looking at it, it shows that both the authentication key and the private data wrapping key are independently derived from the password in a manner in which it's not possible to derive the wrapping key from the authentication key.  So nothing stored on their servers would ever allow them to retrieve kB, which is the key used to store the "Class B" sensitive data, including all sync data.


For this CVE, you should see T3 traffic which would contain embedded serialized objects. See the poc for more.


Yes. You can see at https://hstspreload.org/ that it is a requirement to include subdomains:

  The includeSubDomains directive must be specified.


How to mitigate the risk of X forwarding?

There is a rather extreme measure, which should work: run a virtual machine on your side. That machine will power some minimal Linux system with X11. You do the ssh from that machine. That way, if the worst happens, the evil people on the remote machine may compromise your virtual machine, but just the virtual machine.

(Beware of "guest additions" from the VM: this is the kind of extension included in the guest system so that things like copy-paste work between host and guest; such a system may help a compromised guest X11 obtaining information from the host X11. Don't install such extensions. For extra safety, deactivate support for guest additions in the VM engine.)

A lighter version involves Xnest: it is a X11 server that uses for its display a window within an outer X11 server. This will be enough to protect your other applications from X11-based attacks (e.g. sending synthetic events), but not if the attacker succeeds at compromising the connected X11 server through some buffer overflow or a similar hole.


It sounds like you want to provide an app that will pay your subscribers to send SMS messages on your behalf.  But since sending messages might cost the clients, you think your clients might cheat you by claiming to have sent the message without actually having sent it.

Unless there's a cryptographically trustworthy component baked inside the GSM modems that can provide a signed report of status back to you, there is likely no way to enforce it through cryptographic means.  The clients are always able to provide their own implementations.

So instead, I would approach this with a random testing methodology.  For each client, your server could randomly decide when to have them send a message to a trusted receiver.  Maybe the test message is sent one time out of ten ordinary messages, or one message out of 50, something like that.  Maybe you build the testing on a sliding scale.  To start, one out of the first three or four is a test message, then as they continue to pass tests, you reduce the testing requirements.  If someone is cheating, you won't receive the SMS, and you can investigate.

You have to be thoughtful in the design, of course. You can write it into the EULA agreement telling the clients that the system will periodically send test messages, and that they can be unsubscribed at your discretion.  But you mustn't give them details of the testing methodology.  If your clients can learn exactly which messages are test messages, they may still cheat and only respond to the tests.  So your test messages must look like ordinary messages, and they must go to ordinary looking destinations.  And if a message fails to arrive, you shouldn't immediately decide they've cheated you, as there are many other components that could have broken.  You would have to investigate.

A different option would be to require that the clients provide proof of sending in the form of a copy of their billing statement.  GSM systems record every SMS message destination.  Perhaps you could arrange with the GSM providers to audit their records?  Related, perhaps you could lease them the GSM modems and provide the accounts yourself, having the clients pay you for GSM service.


Any risk of email configured for pop/imap access?

Oh, it's high risk, but not necessarily for the reasons you think.

If an attacker gains access to your emails, the easiest attack vector is to find every email address possible, then email them pretending to be you, and attach some malware to the email.

Malware-attached-to-emails is the oldest trick in the book, and still one of the most effective. It's how Cryptolocker is spreading, and many high profile hacks used this method.


Does HSTS inlcudeSubDomains directive include subdomains on all levels?

Yes, this should apply to all subdomains (see Steffen Ullrich's comment for caveat).

In foo.bar.foobar, foo is a subdomain of bar.foobar, and bar is a subdomain of foobar, so therefore foo.bar.foobar is an indirect subdomain of foobar.


Infected usb flash drive detection and cleaning

Typically you would use an anti-virus program to detect and prevent infections from external storage devices. This is only as good as the AV protection installed. A good, up to date AV can protect systems against the majority of infections, but there is plenty of malware that use unknown vulnerabilities which will not be stopped by any AV program. So there's no way to prevent all malware infections from portable storage.

The approach many companies take is to prevent external storage from being used in the first place, which is inconvenient to users, but prevents that threat vector.


You're describing a basic content/document management system that implements a watermarking library (and online document viewer). This could be created and deployed in a few hours by someone with any coding knowledge. (I get the impression you're more of a sysadmin?)

Basically you deploy something like Drupal to serve as a frontend and handle user authentication and access control. You serve up a list of directories as pages, the user navigates to the file they want, you have a library that can modify files that appends a watermark to the metadata and serves it to the user.

Uses entirely open-source tools but requires a little elbow grease on your part, unless you want to hire a college student to write it for beer money.


In order to be accepted as an issuer for other certificates, a CA certificate must be marked as such: they must contain a Basic Constraints extension with the cA flag set to TRUE. If a client (e.g. a Web browser) sees a purported server certificate chain, with the "X.com" certificate, not marked as a CA, used as an intermediate CA, then the client will reject the chain, in application of the standard certificate validation algorithm, in section 6.1.4, step (k):

  (k)  If certificate i is a version 3 certificate, verify that the
       basicConstraints extension is present and that cA is set to
       TRUE.  (If certificate i is a version 1 or version 2
       certificate, then the application MUST either verify that
       certificate i is a CA certificate through out-of-band means
       or reject the certificate.  Conforming implementations may
       choose to reject all version 1 and version 2 intermediate
       certificates.)

Note the comments about "version 1" and "version 2" certificates. Modern X.509 certificates are "version 3" (their version field contains 2, not 0 or 1). Previous versions for the X.509 format did not have room for extensions, so no Basic Constraints. The glaring vulnerability that you feared, with any certificate owner being able to act as a CA, was, well, glaring indeed. But it took several years for people to catch up.

Fortunately, all current implementations of SSL consider v1 and v2 certificates as "definitely non-CA", just like v3 certificate which lack a Basic Constraints extension.

On a similar vein, Internet Explorer, up to circa 2003 (if I remember correctly), did not check the cA flag... and it was indeed a serious problem, which was promptly fixed when discovered. It says quite a lot about X.509 that nobody had actually tested that for quite some time, because IE already had SSL support back in 1996 and v3 certificates were standardized in early 1999 (so, as is typical for Web thing, they were already deployed at that time, and the standard was more of a documentation of existing practice than anything else).

As for your specific question: how long does this chain extend ? There is no intrinsic limit, in the X.509 standard, about chain length, as long as all certificates in the chain are duly marked as CA (except possibly the last one) and have proper signatures and all the fields in certificates match up as they should. However, certification is trust delegation and trust dilutes very fast when delegated too much. Thus, overly long chains are a strong indication that the whole PKI process has gone bad.

Also, long chains may hit internal limits in some implementations. Chain building (the operation which prepares potential chains to be validated) can become expensive (with specially crafted certificates, it can have factorial cost for a given chain length), so implementations must include some guarding mechanism, which often is an internal maximum chain length. Practically encountered chains have length 2 to 4 certificates (i.e. one root, three intermediate CA at most, and then the end-entity certificate). My own code tends to reject chains beyond 8 certificates, and that arbitrary limit has never been, in my experience, an issue.


OpenSSH declares ssh-rsa deprecated. What do I do next?

You don't need to do anything to your keys. From the same page that you quoted:

  The better alternatives include:

  The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
  algorithms have the advantage of using the same key type as
  "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
  supported since OpenSSH 7.2 and are already used by default if the
  client and server support them.

(Emphasis mine)


OpenSSL: Enable cipher suites per protocol version

From a cursory look in OpenSSL's source code, no, the library is not up to what you want. The cipher suite selection appears to be done in ssl3_choose_cipher() (in ssl/s3_lib.c) and that function works with a list of "supported cipher suites". The list is pruned depending on the negotiated version (OpenSSL won't select a cipher suite which is not supported for the version which will be used), but the list does not contain version-specific preferences.

Programmatically, it would be possible to make an input filter on incoming data, which recognizes a ClientHello message, and dynamically adjusts OpenSSL settings based on the maximum version announced in that message. This would be a rather terrifying hack, which would "just work". However, you won't have that with configuration only.

At least the protocol supports what you wish to obtain. This would not be true in the opposite direction: since the client announces in one message the maximum version it accepts and the list of cipher suites it supports, there is no way for the client to say "AES-CBC, but only for TLS 1.1+".


Edit
Here is a more formal answer:

Designing a security system often mostly always finding the right balance between cost, usability and security.

In the far end of the spectrum, you have your initial solution: printed QRcode that needs to be scanned. It has the lowest cost (1 piece of paper per deployment location), highest usability (a simple scan with an app) and lowest security (can be gamed by anyone with next to no equipment and knowledge).

You traded some cost and usability for a bit more security by adding an iBeacon. That was a good move but it turns out you can't seem to be able to afford neither the additional cost (the beacon) nor the lost usability (the necessity to change the battery).

So, what you should be looking for is for a solution that will be less expensive and more usable without compromizing security too much.

So, I would suggest something that is:

Still mostly paper-based (at least as far as the deployment points are concerned)
Allow you to adjust your cost/usability/security based one the specific situation.

So, my idea is to extend your QR code to include two additional elements:

A type of "rule selector" that lets you define what security profile is requred to use that code
A signature to prevent forgery.

I would then create several different rules:

The most basic type of rule would be to require your application to be geo-located close to the deployment point before validating the visit. That should be your normal deployment option.
A time limit to the validity of the code so you can generate (and print or simply display in an app) code that can be carried around.
An IP limitation that you can tie to the deployment location (so that visitors will only be able to validate their visit from the local wifi, for instance).

Such a scheme will allow you to tailor the validation you make to the situation you face and adjust the usability/security ratio accordingly.

Of course, that's not the only possible option: you can (as suggested by @TripeHound) generate fast changing codes and display them on a local terminal (for instance on a TV screen, maybe as a superimposition over the regular program) but that's a completely different cost calculation.

Initial answer:
Obviously, your issue is cost: any solution to your problem is going to require some form of active device at the location that is hard to fake yet not too expensive to deploy.

I would suggest the following:

Change your application to use the GPS location of the device.
For delivery men, generate special codes (signed) that disable GPS checks for the given date that they can print before going out.

It's far from perfect and there are several ways to cheat (for instance, take a picture of a delivery man's code)


Normally, you'd build a solution with an edge gateway, whereby the dangerous zone (WAN) hits your gateway, and that gateway forwards traffic through to the DMZ. This is best achieved with a physical hardware solution.

There are multiple ways of doing this, but my preferred method is to have a dedicated edge gateway that sits outside the DMZ, which then VPNs into the DMZ. The VPN endpoint inside the DMZ can be configured to limit the traffic coming through. The edge gateway essentially acts as a transparent proxy, passing requests through to the target server inside the DMZ. You can achieve this with most load balancing products, either as dedicated appliances or virtualised solutions.

This has the following benefits:

The WAN-facing device is outside the DMZ.
Everything going in and out of the DMZ is encrypted, authenticated, and integrity checked.
The edge gateway can provide inline NIDS / NIPS and stateful firewall, thus allowing you to block bad traffic before it even enters the DMZ.
You have multiple layers of network security control: the edge gateway's firewall and forwarding rules, the VPN endpoint's security settings, and the firewall on the web service box.
You can detect and block outbound connections (e.g. for mitigating reverse shell) on multiple layers of the network.
Compromising the gateway doesn't immediately put the attacker in a privileged position within the DMZ, since they're limited to what the VPN allows.


Can I check the content of a suspicious file directly on the server using an editor, e.g. vim?

In order for the opening of the file to pose a risk, the file would need to include an exploit for the specific text editor you use. Then when you open the file, the exploit would trigger.
While possible that's not very likely. It certainly isn't common.
The far more likely threat is that there is malicious PHP code in the file that triggers when the file is executed by a PHP server.
But all that aside, I'm not sure why you are questioning whether you have been infected when you are looking at files being served that you did not create and there are links to malware. You've been infected. Start with that assumption...


Strict secure cookies vs. cookie prefixes

The strict secure cookies draft describes a limitation of strict secure cookies where cookie prefixes can help:

  The mitigations in this document do not, however, give complete
     confidence that a given cookie was set securely.  If an attacker is
     able to impersonate a response from "http://example.com/" before a
     user visits "https://example.com/", the user agent will accept any
     cookie that the insecure origin sets, as the "secure" cookie won't
     yet be present in the user agent's cookie store.  An active network
     attacker may still be able to use this ability to mount an attack
     against "example.com", even if that site uses HTTPS exclusively.

If there is no cookie yet, an insecure origin can set a secure cookie, but not a prefixed cookie. So cookie prefixes are still a good idea when using browsers that implement strict secure cookies.


Where does the GSM A5 key come from? Why isn't DH used?

GSM was designed at a time when consumer products, in particular the first GSM phones and the smart cards, were a lot less powerful than they are today (at that time, a desktop computer was using, at best, a 16 MHz 68020 CPU or something similar). Asymmetric crypto could not be achieved within a reasonable time frame on these cards.

The shared key model is a problem, but not really the one you may think about. The goals of the protocol are:

To protect the confidentiality of the conversation against over-the-air listeners.
To establish some "proof" that the call really occurred, for billing purposes.

The confidentiality was never meant for anything else than the radio transmission between the phone and the nearest base station. It is not, never has been, and never meant to be, an end-to-end (ie. phone-to-phone) encryption system. Providers want to access the raw data, if only to be able to (re)compress the voice feed more aggressively than what the phone themselves do(*). In that model, the provider is, by definition, trusted. A "shared secret" model, with a key known to both the phone and the provider, is fine in that respect.

Of course, there is ample room for making mistakes, for instance by using a poor key derivation function or an even worse encryption algorithm. The shared secret model, though, is not at cause here.

It is for the second point that using a shared secret is suboptimal. If the secret is known to both the user's device and the provider, then anything that is computed relatively to this secret could have been computed by either the user or the provider. As such, it should not be usable as proof in a dispute between the user and the provider. The billing mechanism is thus at risk (though experience shows that, in practice, providers don't find it hard to obtain money from consumers). An "academically" better model would involve asymmetric signatures (so not DH, but rather DSA) where a phone would sign its request for opening or maintaining a communication channel.

(*) Of course, accessing the raw data also helps interception by legal authorities, but to my knowledge that is not the primary reason. In fact, end-to-end encryption is hard because both ends must agree on the protocol to use. Point-to-point encryption is way easier.


Should traffic between two hosts in the same data center be encrypted?

If the machines were on your own network (home, your company's datacenter, etc), simple IP-based restriction and/or putting the Redis-related machines on a separate VLAN should be enough.

However, in case of a hosting provider, I recommend considering their networks as hostile and equivalent to the open Internet, in which case you should create your own internal network using IPSec between your machines, and passing whatever unencrypted traffic you want over that.

It won't protect against the hosting company going rogue against you, but at the very least whatever attacker would have to do much more (memory analysis which requires hypervisor or physical access) to get the IPSec keys and make sense of your data than passive packet capturing which is really easy.


How to run a meterpreter script multiple times

It is not possible to create loops with Meterpreter commands in the .rc script alone, but luckily Meterpreter scripting supports Ruby with all of its looping methods. An example with the while loop, 10 iterations:
use auxiliary/dos/rpc/rpcbomb
set RHOSTS 192.0.2.1
set RPORT 111

<ruby>

$i = 0

while i < 10
    run_single("exploit -j -z")
    $i += 1
end

</ruby>

Or an infinite loop which also waits two seconds before running the exploit again:
use auxiliary/dos/rpc/rpcbomb
set RHOSTS 192.0.2.1
set RPORT 111

<ruby>

while true
    run_single("exploit -j -z")
    run_single("sleep 2s")
end

</ruby>


Yes. There are two options: set this in the request and make sure it's preserved when signing (something a commercial CA will be disinclined to); or explicitly set during the signing.

The DN (distinguished name) is a single field in a request or certificate. It's an X.500 name, so it has one or more typed attribute/value pair components. This meaning of "attribute" isn't exactly the same as an "attribute" used in a request, this part of the documentation explains some of the distinction.

(There is also a distinction between X.509 attributes, and extensions, here's my answer that shows how to go about adding arbitrary extensions to a certificate when signing, which might be what you need if you want to add something that's not in the DN.)

If you want extra components in the subject name (DN) then it's easiest to use the -subj option when generating the request, or when signing it. If the types are not already known to OpenSSL you can use OIDs directly, or add them via an oid_file, or oid_section in openssl.cnf .

Note however that the attributes that are widely supported in a DN are limited, see RFC 5280 §4.1.2.4 (these are the constraints for the Issuer field, but §4.1.2.6 for the Subject field refers to this for its requirements).

If you want to be prompted for these during the normal openssl req process you can add them to either [ req_distinguished_name ] (where they will become part of the DN) or to [ req_attributes ] (where then will become an extra attribute in the request, which is probably less useful to you). There are some examples in the req documentation and in the extensions documentation.


I spoke to the CTO of Symantec at a conference once who said something that I'll never forget:

  If every user does everything they are supposed to do all the time,
  then you do not need anti-virus.

The question becomes, can you ensure all those conditions? Do you live with others? Are you 100% diligent with your protections?

I'm a security expert and extremely paranoid (my techniques are far beyond yours in terms of what of I do to protect myself) and I'd never run a computer without anti-virus.


This sounds like you are looking for the scope property of oAuth 2.
with scope you can ask for different level of access and to different type of access.

You could even use scoping to limit access to specific Datacenters, just use a named scope per Datacenter.

The oAuth 2 provider can even inform the client about the given scopes, going beyond the scopes requested by the client (this is not true for all clients but is valid in the specs for oAuth)

Remember. oAuth is an Authorization protocol, all it does is inform you that you have access to a specific endpoint with a specific scope.

It will be important to actually limit the REST api calls with the proper scoping (instead of just gatekeeping based on having a valid JWT). The client used should not matter in this choice at all. Since the protocol will inform you about what you can and can not use. You can react to this difference  with a different UI based on the scopes you received.


Can a KVM switch be vulnerable through a VGA port?

There are I2C lines in the VGA port, that are used to identify which display is connected (maximum resolutions, etc) and to control it if it supports DDC. Thus, bidirectional digital communication is possible.

On the computer side, there could be vulnerabilities in how it parses the EDID sent by the device connected to the VGA port. That could be used to execute malicious code.

On the display device/KVM side, it depends whether a smart device like the main CPU is connected to the I2C bus or if it's just a dumb one like an EEPROM (you can get away with connecting an off the shelf I2C EEPROM with the EDID data in it). In the former case, there is software that interprets the data sent by the computer over I2C - this software could have vulnerabilities and once you can achieve code execution on the KVM you are free to rewrite its firmware to persist. In the latter case, there is no smart device to compromise and you can write a malicious EDID that exploits bugs in connected computers and hope a vulnerable computer is connected.


SPF, DKIM and DMARC - How do receiving/recipient mail servers know how and when to validate the mail?

SPF, DKIM and DMARC require both that these are setup by the legitimate sender and that these are verified by the recipient. In theory the combination of SPF+DMARC or DKIM+DMARC is sufficient at the sender side, where DKIM is the more robust regarding message forwarding. But if neither SPF nor DKIM is used by the sender and if no DMARC is setup by the sender and verified by the recipient (which implies verifying SPF/DKIM) then sender spoofing is possible.


What is the risk of running a IOT device exposed to the internet using non https port?

The risk is the same as with any other exposed service. Misconfigurations or vulnerabilities may end up providing an entry point to your LAN.

However, why expose it at all? Why don't you setup a VPN, connect your mobile to the VPN and then access the device internally in the LAN? That would be a better approach than just expose this service, as usually these kind of devices use software that tend to be somewhat weak in terms of security.


Where can I find information on existing viruses?

VX heaven (which is now unfortunately down) used to be a great source for research materials.  You can probably still find some places where they have some of the documentation and malware examples they provided (Google is you friend here).

Malware Sample Sources for Researchers has some malware's sources which can be studied to understand how they infect computers and spread.

The information you will find should be only used for educational purposes though.


Are there any dangers in sharing ifconfig information publicly?

There are at least 3 dangers:

Sharing your public IP addresses - it will surely result in several kinds of unauthorized security scanning (this applies, if your servers have public IP addresses).
Sharing your public IP addresses combined with possible OS version (ifconfig results on different OS-es look differently, you can compare ifconfig from modern Linux with ifconfig from BSD, or with typical Linux from eg. 2004). This is dangerous, if you are forced to use old software for some reason.
Sharing valid MAC addresses - a few years ago I read an investigation report about some fraud, which - apart of the most important facts - used changed MAC addresses on computers, where these MACs were changed to imitate valid MAC addresses gathered from competitive company's computers, just to mislead the investigation. I have completely no idea, how popular might be this kind of misleading activity, but I wouldn't publish my MAC addresses, just for sure.


Do the Windows shared source files compile into the same binaries as the retail version?

There are varying levels of access, which depend on the particular NDA and whichever agreement is signed. These are my observations made from public discussions.

As far as I know there is no level that allows direct checkout of code for compilation. It's all in a prettified format, similar to how Github et al show code. Someone with access could copy files out no problem, but they can't do a bulk export or checkout.

The majority of Windows is written in C and some newer stuff in C++, with very little written in assembly. Someone could compile the code with standard MS compilers (assuming they got the versions right), but to make the necessary DLLs and EXEs they would need to know how it builds, they would need various MAKE and related files, and those files probably aren't present in the any of the agreements. At the very least they aren't present in the less-privileged agreements (erm. supposedly. NDAs make it impossible to explain in detail what is actually present as those that know can't share or acknowledge they have access. ;) ). In the event someone could build, the results could differ because there may be some post-compilation/pre-packaging processes when shipping.

Where things get interesting though is getting access to compiler symbols for certain Windows components. This allows devs to more easily follow code paths while debugging. Between the symbols and browser access to the source, someone could look for bugs/backdoors/whatever.

However, looking for problems in code like this is more complicated than some may think. There are millions and millions of lines of code in Windows, and the structure of the files may seem precarious if you aren't familiar with it.

EDIT: In theory the code is the same, otherwise it kind of defeats the purpose of sharing the code. It isn't clear how often the code is updated for things like patches though. Whether it's really the same code, well... who knows.


Is Tweetdeck authentication really safe?

And how can Tweetdeck access my Twitter account without my permission?

You just gave Tweetdeck your "permission" by entering the username and password to your Twitter account...

I'm not very familiar with Twitter's API but it's definitely not as optimal as generating a PIN/token/whatever that limits access to one particular application in that it isn't as easy to revoke. However, I don't see any particular problems with it as long as you trust the application (and this doesn't change regardless of the authentication method.)


What is happening to second response in HTTP Splitting?

HTTP plitting is not the simplier attack.
The target is not your browser, sometimes you could use CRLR injection to target the browser (like injection of Location: header) but really the whole domain of HTTP smuggling is not about targeting the attacker browser.
When a single HTTP request generates 2 or more HTTP responses and the communication occurs just between you (your browser) and the server nothing happens. The extra responses are just discarded.
Things are different when there are other actors between the attacker and the server. Think Load balancers, SSL/TLS terminators, Reverse Proxy caches. they became the target of the attack.
They saw 1 request incoming and they received several responses. Several things could happen:

they store the responses for next requests (socket poisoning), request that could come from different users
you did not just send 1 request, but a pipeline of 2 request (see HTTP Pipelining), then the splitting will mix the results of your 1st bad request with the second one (cache poisoning)
also with a pipeline of 2 requests, the 2nd response is incomplete (the one you injected), the intermediary waits from more content from the backend before delivering it to you, if resuing the same tcp/ip connexion for intermediary->server another user legitimate response could be appended tou your incomplete response and you could receive it.

That's examples, but as you can see this is something quite complex and should maybe not have been added to webgoat examples (they are a lot of athoer attacks easier to understand and exploit) :-).


What steps should I take now that my online gaming account was compromised?

Not every case of fraud is the result of some crazy nation-state sponsored rootkit worming its way through your network.

First, consider the target. It's an online gaming account, existing independently of your own computer(s).

Have you clicked on any phishing emails lately? Let's assume not.
Have you installed any third-party mods for your EA games?
Have you participated in any third-party exchanges unaffiliated with EA, that requires sharing your EA credentials (i.e. anything like tf2outpost)
Did you have 2FA enabled in the first place? I'm guessing not.
Do you share passwords across third-party accounts? Is there some other account you've ever used, ever, that used the same email + password combination?
Could he have exploited the password reset mechanism? EA sends a password reset email to the email address on file in the case of a lost password. He would have had to have access to your email account to intercept it. Gmail in particular will give you an access history (look at the very bottom of your inbox) to see what IPs have logged in, but you might want to follow remediation procedure on this one (and it sounds like you already did).
Could it have been malware? Possibly, but...

Unless he did compromise your email too, it seems to me like he already knew your password. If you had a keylogger or malware on your machine, you likely would have seen other IoCs by now. AV (though not bulletproof against APTs, who have bigger concerns than your online games) also found nothing. So...

Typically anybody after gaming accounts is looking to bust out by stealing digital content (any tradeable loot or currency), playing your games for free for as long as they can (South America is really bad about this due to high tariffs on gaming) or testing/using hacking tools with other peoples' accounts to avoid bans.

Ask yourself truthfully how easy to guess your original password was and/or what steps you might have taken to accidentally provide it to a third party. Not saying it's the case here, but sometimes the simplest solution is the most likely one.

If you answered no to all of my questions and you're still uncomfortable with it, do go ahead and wipe the computer. It's inconvenient, but it's what you'd end up doing anyway if you did have concrete proof of infection.


You should have been given a temporary root password right after you setup the server.  See page 28 of AlienVaultUSM Setup Guide for further details.


How can I prevent my FTP from being hacked?

I wonder how you know that FTP was the method by which the unwanted file was uploaded. FTP is definitely problematic in that it defines no countermeasures against eavesdropping. You can find out about using a different protocol. You could consider the discussion of alternatives at SFTP, FTPS and SecureFTP differences and security implications. You will also want to ensure that you use a strong password (or passphrase). Roughly, a strong password is not in the first billion guesses. That way, if an attacker can find a way to try 100 guesses per second, your password can still resist attack for a month.


Windows Server Update Services (WSUS) - can I pivot to a client machine?

Okay, I've done some investigation on this one. I still can't find any word from MS about it - presumably they feel it's such an obvious thing to do that it needs no such assertion.

Examining the WindowsUpdate.log file suggests that signature checking is taking place, and examining the wuaueng.dll file with a debugger verifies this. Windows update will reject images signed by someone other than MS.

I've done a blog post containing the gory details - http://strange.systems/a-quick-check-that-windows-update-validates-updates-against-mss-certificate.


How to hide victim pop-up in clickjacking?

Using window.confirm() is a valid method of mitigating Clickjacking when it is not possible to use x-frame-options.  This popup window cannot be framed.  In every browser except for Internet Explorer the origin of the confirmation window is displayed if the domain differs from the parent iframe in the popup because of Clickjacking.  The use of window.confirm() as method of defending against clickjacking has been used by Google.

Using the x-frame-options is still a better method preventing clickjacking,  however there are some cases where it cannot be used.  For example not every browser supports the whitelist feature,  and sometimes sites need a very large whitelist.


XSS using SVG: Is AllowScriptAccess attribute ignored?

I believe, the attribute AllowScriptAccess only works in context of Flash-Objects, as referenced here. It does not appear to be part of the embed-tag definition, as these links suggest.

Therefore my answer would be:

No. Not in an embed-tag.
Yes. I would disallow the embed-tag to secure your application.

As suggested in this answer you could also consider to use a different domain for the user content and let the same origin policy aid you.


Are SSL encrypted requests vulnerable to Replay Attacks?

The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2:

  To prevent message replay or modification attacks, the MAC is computed
  from the MAC secret, the sequence number, the message length, the
  message contents, and two fixed character strings.

EDIT: As @CodesInChaos points out, the handshake must also be taken into account, otherwise the whole TLS connection could be replayed (not just some records, which is what the MAC and sequence number would protect against). If an attacker replayed the same Client Hello message, the server would return a Server Hello with a different server random value thereby altering the rest of the key exchange. In addition, in RSA key exchange mode, only the initial legitimate client would know the pre master secret it has encrypted; in DHE key exchange mode, the client and server randoms are signed together in the server key exchange message (hence the importance of good random numbers there too). (There's a bit more on these two modes in this question.)

It's not clear from your question what you're trying to protect against replay attacks. Typically, this would be a message sent above the SSL/TLS layer, used by your application.

The encryption provided by SSL/TLS certainly prevents an eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.

However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms at the application level to address this problem (which is rather independent of SSL/TLS, although preventing eavesdropping helps).


Fail2ban is a nice option, but it will create some problems if a sizable part of your userbase is behind a proxy, and someone on that proxy abuses your service and locks out every single user of the proxy.

You probably have a traditional database (MySQL, Postgres, Oracle, DB2) hosting your data, but the overhead of the tokens are too high for them.

You could use a small NoSQL database just for the tokens, and let the main database take care of the data. Redis is a good option, and CouchBase is another good one. Couchbase is known to be very fast, so I would try it first. On the other hand, Redis looks easier to integrate.


Internet and Email privacy in an "internet-enemy" country

Here where I live, it is believed that all the internet traffic goes through the hands of government agencies, and the telecommunication office is actually owned by the government.

so i assume you're either in EU-europe or US of A? (scnr)

to your questions:

yes, tampering is possible, either as man in the middle as well as later decoding of recorded traffic. your login-data is doomed
no

3.

have no trust in privacy on the internet (no tor, no i2p, no nothing)
keep as much traffic out of the internet as you can
be aware of the meta-data-problem (they are stored, anyway)
learn about how you're tracked
learn to stay invisible (e.g. avoid to be tracked by the big players)
learn end-to-end-encryption
keep informed
tbc

sorry to be that pessimistic, but the internet is broken and wont be fixed soon :(


Can't brute force password cracking somehow be throttled?

You are talking about online attacks, somebody is entering passwords via website. This you can slow down by the methods you described, though it is not as easy as you may think.

When you read about cracking passwords, normally you are speaking of offline attacks, that's why you calculate hashes after all. Think about the situation that somebody could read all your password hashes (e.g. SQL-injection, or from a thrown away backup...). Then the attacker can brute force as fast as his hardware can do, he can e.g. use the GPU to calculate hashes. Even then you can slow down the attack, this is why nowadays you use slow key-derivation functions like BCrypt or PBKDF2. This algorithms allow to define a cost factor, which defines how many iterations are done, so you can control how much time is used to calculate a single hash.

An example: If you can calculate 8 Giga MD5 hashes per second all password combinations up to 6 digits can be calculated in 2 seconds. If you even need 1 millisecond per hash, you already need 8 month.


What can we do with non persistent XSS vulnerabilities?

An attacker can try to phish me with a malicious url, steal my cookies or my history etc... but does he also need my intervention or a human interaction for his attack?

The source could be anywhere there is a link for you to follow: an email, a forum, a Facebook post, Twitter, or it could be that you are already browsing an evil or compromised website.

The "human interaction" part is you following the link, no more interaction is required. For example. if there was a non persistent XSS bug on www.example.com and you were already logged in as the site "remembers you", the link exploiting this bug could grab your session cookies from www.example.com and send them to the attacker automatically - there is no requirement for you to do anything as the victim apart from following the original link.

Some phishing attacks wait for your browser to become idle and then transform the page in the already compromised site - there is nothing stopping them adapting the attack from phishing to XSS by redirecting you to an XSS compromised page in order to hijack your session cookies in the hope you don't notice as you haven't activated the tab in a while. The full page redirection may be necessary when the XSSed site is protecting against framed loading via X-Frame-Options so the site needs to be loaded full page in order to be compromised.

  What else he can do with non persistent XSS?

Lots of things. Drop in a JavaScript keylogger for example. Basically the attacker will be controlling the client-side of your sessions and will have access to view and change any of your data for this domain that is on the client-side.


Unless there is a regulatory or compliance framework around your offering, expiring PINs or passwords is up to your organization.  Usually, a company or organization will define this practice in their security policy.  If your organization has one, that's where you should be looking for your answer.

That said, if you don't already have a security policy, take a look at NIST's security policy framework.  They provide a rich example that you could apply to your organization.

In the specific case of asking a user to provide a "recovery PIN", there probably isn't much point to trying to expire it unless you're going to demand they change it periodically (this would be unusual.)


.NET extraction and storage of compression files concerns

It has nothing much to do with .NET or IIS and make your mind clear about just you are in risk because of using MS products. When you get input from public, of any kind, you should act pessimistic. Check the input and be sure it is of the kind you are expecting. There are two possible situations:

1) You had no mistake in your part but a vulnerability in some library (like zip for example) is exploited by hacker. You can do little about it like using a separate VM which has nothing sensitive on it and in charge for management of received files, extracting and making them available to other parts of system (pulling by other parts is preferred). If VM is not possible keep the process in charge low privilege. So in case of any exploit your concern is just minimizing the damage. Microsoft autoupdates lowers leveraging zero day exploits risk. Your real concern goes to number two.

2) Most important advise for security programming: don't trust user input. Consider SQL injection, XSS, BoF... All happens because of trusting the type , size, format... of user input, so check it and make sure it is what you expect from all aspects. Use an updated antivirus on VM responsible for file management and check archives.

You can recap it as plan A when you do your best to prevent disaster, plan B, damage already happened and you try to minimize its consequences.


How to make a file detected by anti virus

There is a standard file treated by all AV software I have used - the EICAR test file but this is used for testing the deployment and integration of a malware scanner, not its database. The only practical way to test the latter is with a very large number of live viruses.


Ensuring security for SharePoint hosted app (Office 365)

I would recommend code review by peer developers. Introduce a policy where no code can be added unless it has been reviewed by someone else. The reviewer can be another developer, it doesn't have to be a senior or a dedicated reviewer.

This reduces the chance of errors. It makes it harder to put some hidden functionality in the code. And it works great for sharing knowledge within the developer team.


Is it okay to reveal database's table names?

Think about it this way

On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If it's a news website, it's very likely you'll have a table called articles, or if you have some subscription service you'll have tables subscribers or users, and so on. Also, if your server is compromised, an attacker will figure out the table names almost immediately.

On the other hand, if there's a way around it, there's no need to disclose it. If your security is taken care of, a layer of obscurity wouldn't hurt in that case. In fact, a layer of obscurity on top of good security measures is often a good thing.

However, I'm afraid you're trying to do something like this
SELECT * FROM $UNTRUSTED_INPUT WHERE blah = 1
In that case, absolutely not. Don't do it.


Depends. In general, no. If the attacker launches a man-in-the-middle attack after HTTPS communication has already started, he can do nothing.

If he launches the attack beforehand, he can do various things. For convenience, let's assume that the server in question is GMail.

Pretend to be mail.google.com: This is a pretty transparent attack. The attacker cannot obtain a trusted signature for his SSL cert, and thus cannot pretend to be Google without throwing an error similar to this one. If the client clicks through this; well, that's the client's fault.
Catch you when you try HTTP: Some people enter http://www.gmail.com, which means that their browser will first try HTTP. Most HTTPS-only sites issue a 301 Moved Permanently redirect, but an attacker can stop this from happening and pretend to be HTTP-GMail (and pretend to be you in communications with the real HTTPS GMail -- individuals don't have/need SSL certs so this impersonation is easily done once your password is with the attacker). Note that the browser icon will no longer have a green padlock in such a case. However, not all mobile browsers visually distinguish between HTTP and HTTPS. Generally it is better to use bookmarks and save history on the client side, and use HSTS on the server side to protect against this.

There used to be many other HTTPS implementation vulnerabilities (they're pretty much all fixed now). There probably still are a few. But most rely on the user not noticing (or blindly clicking through) a warning.


Man in the middle attack to a website which uses public key pinning

I wonder if it works if a website uses public key pinning?

Yes it does. A certificate which is signed by a CA which was explicitly added to the trust store will not be affected by the pinning checks. This is deliberately done to allow useful and legal SSL interception. Such interception can be found in most enterprise firewalls but also lots of desktop AV and is needed to scan HTTPS traffic for malware etc. If this would not be done malware delivery would simply move to HTTPS (which is cheap enough).


Code is not going to become more secure per se by splitting it differently across files. The important thing is what code is going to be executed when anyone requests a certain URL. Whether this changes because your web server is executing a different file or because you have an if..else statement in one file is entirely irrelevant. Separate files may help code organisation and thereby prevent possible bugs, but it's not more secure per se.

If it's possible to access "include files" which should not generally be executed by themselves, and this allows an attacker to circumvent some protection or another, that's entirely your fault for exposing this executable code publicly in the first place. You must only place "public" code in the public webroot directory. If a visitor is not supposed to go to http://example.com/include/never/execute/this/directly.php, then this URL must prompt a 404 response by the web server instead of making it execute some code. The sane way to do this is to not put the file there in the first place, but outside the webroot:

myapp/
  includes/
    sensitive.php
    ...
webroot/
  contact.php
  index.php
  ...

This can go so far as to only have one index.php in the webroot, using mod_rewrite to direct all requests into it and using a request router to handle requests in PHP.

Your web server is responding to URL requests. This has nothing to do with physical files at all. Always keep that in mind. Which URL request involves which files is completely up to you. The point is which URL will trigger what response; how the files are laid out on the backend is completely irrelevant.


SSL what's the client write key used in application layer?

I found out the answer myself : the function RC4 I've used didn't save the cipher state, while SSL stream cipher required that. I've used a RC4 class and problem resolved!


Snapchat keeps a log of all messages sent and their corresponding IPs, so they can easily tell who sent which message and from where.

If someone compromised the Snapchat account and sent some content from another machine, the IP address would be the one of the machine/phone from where the content was sent, or possibly the address of a proxy/compromised server/anonymization service such as Tor.

If attacker really wanted it to appear as if your child sent the content, he could compromise a machine on your home network and use it as a proxy to send the content (it will appear as coming from your home network connection and would be potential evidence unless you have proof someone else was at home or your child wasn't there when it happened).

In theory he could also compromise the phone itself to send the content directly via the mobile network, but in practice I'm not aware of any iOS exploits for the recent iOS 8.X versons allowing this kind of attack, so the only option would be to make your child install some specifically crafted malware designed to give the attackers remote access to the phone and root privileges (to break into the Snapchat app's sandbox and steal its session token, to be able to impersonate this app). Installing such malware is no easy task and is definitely an unusual procedure, and most importantly requires a jailbroken phone.


How can I mitigate the threat that DPAPick poses to my DPAPI protected data?

@nealmcb asked me (Thanks!) about this and this is indeed a great question that is not covered in our paper. I agree that we are not giving enough advice about how to deal with DPAPI security. I will fix this by writing a blog post but in the meantime here is an overview of what you can do:

Overall DPAPI is a blackbox API that allows you to tie any secret data, such as the firefox passwords database, to a windows account password. To decrypt any DPAPI secret you need a hash of the user password (in SHA1 (16_LE) not NTLM though).

So in an offline attack setting an attacker first needs to brute force (or guess) the user password to get this hash, so a "strong" password is definitely the first good line of defense. But remember that we have rainbow tables for NTLM so DPAPI security is also affected by this.

Disk encryption such as bitlocker and truecrypt are a good first line of defense against this because  the attacker obviously needs to decrypt the hard drive before attempting to recover the DPAPI data.

What is not a good idea is believing that EFS will solve the problem, because the certificates needed to decrypt the file are encrypted with a "DPAPI" like system. So once the user password is known, all the attacker has to do is first decrypt the EFS files by recovering the certificate and then decrypt the DPAPI data.

I hope this clarifies the situation. For the CREDHIST problem, I am thinking of writing a tool that clears it (at least the first N old passwords).

Let me know if you have other questions


How to Conceal/Detect PGP Symmetric Algorithm Used

Note, there is no legitimate reason to hide the algorithm used if you use a suitably strong passphrase/key.

If you are really concerned, you could open the encrypted file in a hex editor and change the fourth byte of the symmetrically encrypted ASCII armored file.

E.g., the first four bytes of an symmetric encrypted file are:

8C 0D 04 09

with the fourth byte being 09 indicating AES256.  See common/openpgpdefs.h to see other values:

typedef enum
  {
    CIPHER_ALGO_NONE        =  0,
    CIPHER_ALGO_IDEA        =  1,
    CIPHER_ALGO_3DES        =  2,
    CIPHER_ALGO_CAST5       =  3,
    CIPHER_ALGO_BLOWFISH    =  4, /* 128 bit */
    /* 5 & 6 are reserved */
    CIPHER_ALGO_AES         =  7,
    CIPHER_ALGO_AES192      =  8,
    CIPHER_ALGO_AES256      =  9,
    CIPHER_ALGO_TWOFISH     = 10, /* 256 bit */
    CIPHER_ALGO_CAMELLIA128 = 11,
    CIPHER_ALGO_CAMELLIA192 = 12,
    CIPHER_ALGO_CAMELLIA256 = 13
  }
cipher_algo_t;

So if you change the byte to 0a (decimal 10), it will think I used twofish rather than aes256.  It will not be possible to decrypt with gpg until I change the byte back to 09.

Before altering I see:

$ gpg -d some_file.gpg
gpg: AES256 encrypted data
Enter passphrase:

and after altering that byte I see:

$ gpg -d some_file.gpg
gpg: TWOFISH encrypted data
Enter passphrase:

Granted this only adds obscurity and forces you to remember to change the byte back and greatly lowers readability.  I do not suggest you do this.


No. Not at all. They are sent in plaintext. Without SSL, a POST request is just as secure as a GET request. Sure, it may not show up in the URL, but it is not secure in any way.

  Will this password be encrypted if there is no SSL?

No, the password will not be encrypted. The only reason it doesn't show up when you are typing it in is just the browser obscuring it so that people nearby cannot see your password in plaintext on your screen. It can be easily revealed by inspecting the DOM or using some javascript like this: javascript:alert($('input[type="password"]').value) .

  Is it possible for the post message to get intercepted somehow, say using a packet sniffer, and for the intruder to view the post request's text?

This is absolutely possible, and very easy to do. A packet sniffer does exactly this, and can view POSTed usernames and passwords in plaintext. To someone sniffing HTTP requests, a POST request looks pretty much identical to a GET request, except a POST request has "POST" at the top instead of "GET."

You didn't ask, but yes, post requests can be forged as well.


Return address encryption prevents ROP gadgets from being used because the attacker won't be able to predict the value of the key, so the attacker won't know what to write on the stack to cause the return instruction at the end of one gadget to transfer control to the next gadget.

Remember how ROP attacks work.  The attack involves executing a sequence of ROP gadgets.  The attacker has to arrange memory so that these gadgets will be executed in the desired sequence.  In a ROP attack, the attacker does this by overwriting the stack to contain a bunch of fake stack frames, where each stack frame contains whatever stack data will be needed/expected by a single gadget.  Each ROP gadget ends in a RET (return) instruction, so the corresponding fake stack frame contains a saved return address that will be used by the RET instruction: when you execute the gadget, when it gets to the RET instruction, the RET instruction will pop off the "return address" on the stack and jump to it.  So, the attacker arranges the contents of the stack so it has one fake "return address" for each gadget, and the fake "return address" has a value that is the address of the first instruction of the next gadget to execute.

In a standard ROP attack, this works, because the attacker knows the address of each gadget and can write those addresses onto the stack.

With G-Free's return address encryption, this attack no longer works.  The attacker can't store the address of the gadget onto the stack; instead, the attacker needs to store an encrypted return address (namely, the encryption of the address of the next gadget).  Without knowing the encryption key, the attacker won't know what to write.

So, without knowing the encryption key, ROP attacks don't work, because the attacker can't chain the gadgets together.

P.S. I agree with you.  G-Free is indeed awesome.  I wish I had a compiler flag that let me compile a program with G-Free; it is a very cool defense, with modest performance impact.


Sqlmap fails at enabling xp_cmdshell procedure

You could try passing --priv-esc to sqlmap,  and this may raise your privileges,  but this has never worked for me.  sqlmap's file system access functions could lead to a greater compromise.

SQLNinja is better at privilege escalation.  One attack that it supports is simply brute forcing the SA password using SQL injection and I have found this to be quite effective.  SQLNinja also contains other known privilege escalation exploits such as CVE-2010-0232.


Scan for infection of malicious files manually?

Basically what you ask is how can you become your computer's Anti-Virus. Simple answer - you can't.

You can make or find scripts which will give you some indicators of compromise for your system and start looking at them suspiciously, you can explore through processes and their insights, you can analyze your network traffic and see what's not good here. You can learn how to monitor your system with Windows Management Interface and PowerShell (i assume you work on windows for this one). You can also take snapshots of your system and compare them. You may also use or write tools to check the signatures of your files with Yara rules and see if you get any malicious hits. You will learn tons of stuff, but still, you may be missing something. It's not worth compromising your system for something like this.

So basically, you will be doing by hand what a good AV does. Scan files based on their signatures database and/or process behavior. Check for changes in the filesystem and registry keys, suspicious network traffic and strange strings. The difference is you will be doing it slower, less efficiently and not in real time.

If you want to learn stuff about analyzing and thus tackling malware set a nice virtual environment, get to learn static and dynamic analysis, some tools that will help you and start learning your OS's insights. Find a nice malware sample list and off you go. But you can't replace an AV and you shouldn't either. That's what it's made for, speed and efficiency in detecting and blocking tons of known attacks and trying to detect unknown ones, based on behavior.

P.S. Feel free to ask anything below :)


Why are one time password reset links safer than one time passwords?

This could be fine - after all a password reset email contains a "one time password", albeit one that is really a secret key and based upon a long, pseudo random sequence that is unfeasible to brute force.

Also, this could also mean there is a Denial of Service attack against a legitimate user:

Attacker goes to website, knows that Bob@example.com is a user (e.g. through a username enumeration vulnerability).
Attacker presses to reset Bob's password.
New temporary, secure password sent to Bob@exmaple.com
Bob, without current access to his email now cannot log into the system.

Password reset links do not have this flaw, however minor it may be to the system in question.

If temporary passwords are issued, it would be wise to generate one with at least 80 bits of entropy (the current NIST recommendation), and force the user to change it immediately on login, even if they "force browse" to any other URL in the authenticated section of your website. i.e. it should redirect them back to the change password screen until they do, and it should also make sure that they select a different password.

The other problem you've now got it that if the user does not use the temporary password immediately. You've got a password sitting in cleartext in the user's mailbox, which isn't the best location for password storage. You may have to expire this password somehow, leading to additional complexity in your application. Having separate password reset links simplifies things, as its only the instance of a link itself that expires, not their primary password.

In short, it is much easier and more secure to have a separate password reset mechanism that doesn't touch the user's password until they've confirmed that they can in fact access the mailbox associated to the account.


Password recovery flow - Send Password recovery to any email?

Possibly.  It's not immediately clear if you are relying on the email address as the sole identifier (i.e. you're using it as the username) or if a separate username is in play.  If the latter case, then the obvious flaw is that an attacker can supply the username of someone else, but provide their own email address as the destination for the recovery password.

Assuming the email address is the only identifier for a user, obviously it will need to be supplied by them in order to reset their password.  I would suggest that regardless of whether an account associated with that email address actually exists, the system should respond similarly.  (E.g. saying "Your password recovery information has been sent.")  However, you would obviously only want to send the recovery email if there is a corresponding account; if no such account exists there is nothing to recover.  This prevents an attacker from trying multiple addresses to see which succeed and which fail, and thus building a list of valid accounts on the system.  (If your application is faster to respond if it doesn't need to send the email, you may wish to intentionally add a random bit of time delay to hide that.)


Would using both SHA1 and MD5 hashes of files help reduce the risk of deleting non duplicates

First off, yes both MD5 and SHA1 have been retired from cryptographic use because because it's possible to construct pairs of messages which produce the same hash value (aka "collisions"). That said, the chance of hitting a collision at random is absurdly low.

MD5 has a 128-bit output, SHA1 is 160 bits. Let's assume that a file being hashed will hash to one of the 2128 / 2160 possible outputs with equal probability, then on average, you expect to find a collision after hashing 2127 / 2159 different files.

Say you filled a hard drive with 512-bit (64 byte) files. You would need 2133 bits = 1.3 x 1027 TB for MD5, or 2165 bits = 5.8 x 1036 TB to store these files. For comparison, it's estimated that by 2020 the human species will be producing 44 zetabytes (4.4×1010 TB) of data per year.

So even if you hashed every file on the planet with MD5, you only have a 1 in 1026 chance of getting a collision by random chance.

To answer your original question:

  To remedy this I thought I would switch to SHA1, but then had the thought that if I compared both, there would be even less chance of collision.
  Does anyone here know both algorithms well enough to confirm or deny this?

Yes, it's true that since they are different hash functions, the chances of there existing two messages which are collisions for both of them is minuscule. Whether it's less minuscule than the chance of collision in SHA-2/256 or SHA-2/512, I don't know. At this point we're debating astronomic probabilities (ie the chance of getting a collision is smaller than the number of atoms in the universe type thing) so /shrug ?

Now, if you are talking about malicious attacks (ie files specifically crafted to fool MD5 or SHA1), then maybe you have a point. ... In that case use SHA2 (which is 256 bits) and you're fine :)


OSSEC is a great FOSS HIDS that works well to reduce the number of log events you need to check out to something potentially manageable.

It supports all of the log sources you mentioned:  http://www.ossec.net/main/supported-systems

We built an in-house app that allows us to do a quick “daily check” of all the alerts OSSEC fires in a day; it typically takes us less than 20 minutes of time to call out an all clear or to kick-off an incident investigation.  For one environment we receive ~70,000 OSSEC alerts per day, but most of the alerts/events are clusters of auth events or app errors spamming the logging system, for example:

Since you have Splunk going you could do the Splunk + OSSEC integration:
http://www.ossec.net/main/splunk-ossec-integration

The other day I saw a couple enterprise SIEMs in action – I was stunned to learn they apparently have no canned reports detailing unusual or rare log events.  Unusual and rare events are frequently the best indicators of something bad and can serve as your short list of events to chase down until the leads turn cold.

We also use Logwatch as a secondary log analyzer.


Will creating a shortcut/favorite for my network drive instead of using a mapped drive help prevent encryption by ransomware?

No and Yes

No:

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore

10 Immutable Laws of Security

Ultimately, if it's running on your system, malware has (at least) the same level of access to your file system, and those of networked resources, as you do. So, strictly speaking, it won't matter whether a file share is "mapped" or linked through a shortcut - if you have access to it, the malware can get to it too.

Yes:

The key word in the above paragraph: can.

Just because malware can do something, doesn't mean it will. Unless you're dealing with an attacker that's specifically targeting you or your organization, the majority of malware you'll encounter is going to be from generic toolkits engineered to optimize effectiveness across the largest possible number of targets. In short, most malware is generic.

It is relatively easy, and generally more valuable on the majority of targets, for malware to just look for mounted drives to infect. If a resource is already mounted in the OS, it's a fair bet that it's within close reach (i.e.: low latency) and that you've got at least some level of access to it. Searching all devices on the local network for drives that will allow the malware to have read/write access is a much more complex and time-consuming matter, and generally much less likely to bear fruit. It's also a lot "noisier", and therefore more likely to be caught by corporate monitoring systems.

This is very commonly seen with ransomware. Most ransomware will (on a Windows system) simply run through all the lettered drives (e.g.: local hard drives, local removable media, mapped network drives) and encrypt whatever it finds in those areas that matches the file types it's made to target. Resources that aren't linked to a drive letter usually won't get touched. So, for ransomware and other malware that behaves similarly, there certainly is a benefit to avoiding mapped network drives.

It is certainly still possible for malware to discover network shares you're connected to even when they're not mapped to a drive letter. To see this in action (for Windows systems), manually browse to a non-mapped network share in File Explorer and then run net use at a command prompt. You'll see the resource you're connected to in that list, with no letter associated.

That said, avoiding networked drive mappings still offers a certain amount of defense against this sort of discovery. To be most useful, mapped drives have to be persistent - that is, the connection is re-established on system startup and it is maintained until you explicitly destroy it. The connection that is made when you follow a desktop shortcut is more transient, though - at most, it will usually only last until the next reboot. So, while it is not impossible for malware to discover this connection it will generally reduce the likelihood of it happening.

TL;DR:

Strictly speaking, once you have malware running on your system it can do whatever it wants to do with resources you have access to - regardless of whether or not they're "mapped".

However, in practice, most malware that you will see is simply going after "low-hanging fruit". So, it will not usually be made to go very far beyond whatever resources your system has mounted at the time of infection. If you avoid using network drive mappings, you substantially reduce the likelihood that there will be a connection for malware to discover when it runs. If you happen to get hit with something that only looks for "drive letters", the impact is completely isolated to the local system.

So, while it may be far from foolproof, there is still some security value in staying away from mapping network drives. In many ways, it's like using a non-default port for common network services. It's a low-effort, additional layer, that you can add to your security posture to obtain potentially high value. (Emphasis on additional because, again, this is not foolproof. You also should have other, more reliable security measures in place to prevent malware infections and isolate their impact.)


Hotspot with same SSID, how does authorization work?

Your phone or laptop will not necessarily automatically connect to that alternate AP, because even though it has a known SSID, it also has a MAC address which does not necessarily match the one at your home. Whether a given system will be ready to disregard the MAC address change depends on that system (from an explicit experiment at home, I can say that Windows 7 will not automatically connect to a known SSID if the access point MAC address does not match). Of course, an evil attacker may have followed you home, stopping just outside of your door, and recorded the MAC address of your own WiFi AP, so that he could mimic it with his own fake AP.

Assuming that your phone/laptop does indeed connect, PEAP includes SSL/TLS, and this should protect you (subject to some caveats; see below). Basically, when using PEAP, the client (your device) opens a SSL connection with the access point, and will proceed to sending your username and password only after duly validated the access point's certificate. This mimics the situation with HTTPS Web site: the client first makes sure that it talks to the right server, and sends sensitive data only through the SSL encryption umbrella.

There are some subtle points with validation of the certificate. Revocation status will probably not be checked, because your device is trying to obtain its Internet connection, and thus won't be able to download a CRL yet. See the draft protocol for details. Also, it is a bit unclear how the client goes from "this is a valid certificate" to "this is a valid certificate for the access point I intend to talk to". I expect most WiFi/PEAP clients to record the certificate sent by the AP upon the first connection, and then to automatically reconnect (with the sending of username and password) only if the AP still sends the exact same certificate, or a certificate advertising the same server name.


A script or bot is probably probing for an Unvalidated Redirects and Forwards vulnerability.

The reason I say this over SSRF is because the target domain is pastbin.com, and not a domain under control of the attacker. The attacker will have no way of knowing if a SSRF attack worked without validating that the server-side request was made, therefore this is unlikely.

However, with Unvalidated Redirects and Forwards the attacker just needs to look for a redirect HTTP response such as 301 Permanent. If successful, they could then use your site in a phishing style attack using an obfuscated redirect domain (say percent encoded) in the hope their victim follows the link to your (trusted) domain.


How can someone access data that I am requesting when I use HTTP?

When you access a website, say Google, your request goes through multiple steps (nodes) until it reaches its final destination. The first node is your home router, then your ISP's routers, and then other big routers, and then Google's routers. At any of these nodes, your request is momentarily stored in the devices' memory, which means it can be accessed by an attacker. Of course, that's not a very likely situation.

The bad news is that an attacker could somehow trick your computer into thinking that his computer is a real node in the path between you and a legitimate node. This attack is called a man-in-the-middle (MiTM) attack. MiTM come in many shapes and forms, the most famous ones are:

ARP Spoofing
DNS Cache Poisoning
DHCP Spoofing

I won't go through each type because it will make this answer too big, but please have a look at pages and learn more about these attacks.

As a solution to this problem, we have HTTPS. It works by layering HTTP over SSL/TLS to make sure that your request is going from your browser to the intended server and making sure that anyone snooping around won't be able to see what the request or response you get from the server contain.


What are the areas to focus on to protect users and devices?

User education & training is huge.  Get the users to help you play good defense.

I always like to see the security programs that award spot bonuses to employees for challenging a person in a secured area without a badge.  You can be creative and extend this idea to phishing attacks, pretexting, etc; for example, send out a mock phishing attack and reward employees for calling it out and not falling for it.

Keeping up to date on patches is key - Secunia Personal Software Inspector rocks.


Different types of Tor bridges - implications for detection of Tor use

You have to understand that both transports have a different threat model than yours. They both address "blockability" while you need to address "detectability", or as meek's threat model docs put it: "observability".

You mention that:

  My primary concern is to avoid being flagged in dragnet surveillance by either my communications or by my Tor usage

Hiding the fact that you're even using tor is much more difficult than hiding the content of your communications.

Both bridges (and tor bridges in general) try to achieve the same goal: to not be blocked by standard detection methods. None of them are listed in the main directory. From the tor docs on bridges:

  Since there is no complete public list of them [the bridges], even if your ISP is filtering connections to all the known Tor relays, they probably won't be able to block all the bridges.

Using a bridge in your situation is better than not using it, but it might not be enough to hide the fact that you're using tor.

This are the protections offered by bridges:

Block by content: censor will not be able to see what the content of your communication is
Block by address: censor will not be able to know who you're talking to, or whether the other end is a TOR relay
Active probing: for obfs4 a probe would require the node ID and the public key, which can't be easily obtained because bridges aren't easily enumerable. For meek an active probe may be able to determine there's a domain-fronted relay, but not whether anyone communicating with the CDN actually used it.

They both try to provide some protection against fingerprinting of headers, traffic patterns, etc. But it's not their primary goal.

Even though with meek you're connecting to a CDN that's used by lots of sites, your traffic patterns may be very different from those of other users not accessing a tor bridge.

Also, with meek you mostly depend on HTTPS and its PKI. If your government controls a trusted CA you will have to take extra care of not being MITMed on your way to the domain front. This might mean removing their CA from your trust store, and doing that might give away that you're doing something private.

Conclusion

Both bridges will offer you similar protection, but they aren't specifically designed for your problem (hiding the fact that you're using a private communication channel).

They do, however, hide that fact from most automated detection tools, because that's a precondition to bypass blocking.

This might be enough for your case, but be very careful and implement additional measures where possible.


Has a remote rogue DNS client managed to slip through the first iptables rule of a Linux DNS server?

pktstat sniffs on packets before iptables filtering takes place, which I doubt is possible

This is what happens. pktstat, tcpdump etc get the unfiltered data on the interface. See also Does tcpdump bypass iptables?.


Would AES encryption of a small number of blocks be less secure than encrypting a large, fixed-size padded buffer?

According to NIST, The AES algorithm is capable of using cryptographic keys of 128, 192, and 256 bits to encrypt and decrypt data in block sizes of 128 bits (16 bytes). it means each block that goes as an input to the AES algorithm will be 16 bytes, so if your BUF_SIZE is 16 KB, when it wants to go to the AES, again it will be split to a blocks with 16 bytes size, and at the end if there are a data with less than 16 bytes it will be padded.(for example you want to encrypt 35 bytes,(2*16)+3, the remain 3 bytes will be padded with 13 padded bytes).

However your AES mode is important, for example if your mode is CFB, OFB or CRT, it does not require any padding and can be parallelized. CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples of the block size, since the modes work by XORing the plaintext with the output of the block cipher. The last partial block of plaintext is XORed with the first few bytes of the last keystream block, producing a final ciphertext block that is the same size as the final partial plaintext block. This characteristic of stream ciphers makes them suitable for applications that require the encrypted ciphertext data to be the same size as the original plaintext data.

But some modes (namely ECB and CBC) require that the final block be padded before encryption.

also you need a IV (Initial Vector) to produce distinct ciphertexts even if the same plaintext is encrypted multiple times.

so according to your example:

BUF_SIZE= 16 KB ==> 16*1024= 16384 bytes ===> 16384 mod 16 = 0 , it means each BUF_SIZE does not need to padding. and a remain one (14KB) ==> 14*1024=14,336 bytes ==> 14,336 mod 16 = 0 , so also the remain slice does not need to padding and it will be splited to 896 block as input for AES algorithm, that creates same size of input as output.

Or for example for 310 bytes, you do not need to pad it to 16KB, you only need to create 19 blocks with 16 bytes, and 6 bytes remains and that one is padded with 10 bytes. with together are 20 blocks.

310 = (19*16)+6.

Therefore, you must be concerned about the key strength and the size of that and manner of protecting it and also use standard AES not yours, because if only 1 byte remains it will be padded with enough padding bytes.

So in this situation there is no difference between encrypting 1 byte or 1024000 bytes, attacks are perpetual, the size of data is not important.