Why fingerprint scanner doesn't work after reboot on Mi phones?

There is a secure enclave that stores your biometric data. It has to be given your passcode in order to decrypt your biometric data on reboot.


Can a PKCS12 file be distributed over insecure channel?

I wouldn't do that, since if someone manages to sniff your file it is then subject to brute forcing the password - which is a matter of time.

Let me correct myself and ask a more accurate question: what does your p12 file contain?
If it contains your private key, I would not distribute it over an insecure channel and I would even question the need to distribute it... your private key usually stays in one secure place and should not be distributed.
If the p12 only contains public keys (certificates) it is fine to distribute it, even on none secure channels, since it is public in its nature.


Can a mobile operator assign traffic to every SIM card in their network?

All the things in mobile operators are assigned per SIM card. You have stored in HLR 3 parameters: MSISDN (your phone number), IMSI (internal customer identifier) and ICCID (SIM card serial number). Based on those parameters in different subsystems of mobile operator are created CDR (call detail record) for voice and data traffic. Once per month (for postpaid) and in the moment of usage (for prepaid) those CDRs are used to generate billing information for your account

IMЕI is not used for authentication/billing. The only moment when IMЕI is in charge is when this number is in black list of stolen or lost devices and depend of policies provider can permit or deny traffic (voice and/or data) to the device

P.S. And for each call, SMS, data packet is created such CDR. Sometime is possible mobile operator to sniff for data traffic (in charging proxy for example), but this depend of operator, law, etc.


What to do with possibly infected files that need to be kept

Media files should be relatively safe, because they usually don't contain any executable code.

There have been a few exploits in the past which caused specific media players/viewers to do unwanted stuff when opening an especially crafted file. But...

these exploits usually target very obscure formats which often aren't properly tested and
when you keep your software (including video and audio codecs) up to date, they are unlikely to be vulnerable to an exploit used by a malware several months ago.

So when you only copy media files with well-known formats, it is very unlikely to get infected.


Are hosted bare-metal servers more secure than VPS against unauthorized disclosure?

Our threat model includes malicious sysadmins working at the hosting provider and this is what we are focusing on ...
If this is truly your primary threat concern, then Virtual vs Physical is a false dichotomy. Nothing short of physically hosting and protecting it yourself is going to address that threat.
FDE protects dead, as in non-running, systems not running systems. Servers in particular need the ability to restart. This means either manual intervention or stored keys at the server. This requires a trusted admin, which is counter to your primary concern.
You mentioned cost as the driver to a hosted system. If cost is overiding trust, your best bet is to use what you believe to be the most trusted provider. Many companies and organizations already do this, but you have to make the decision as to which is more important.
You simply are not going to be able to have a secure untrusted provider.,


How secure is it to use an open-source software

Backdoors in open-source software where discovered, yes.

Generally speaking open-source does not automatically mean the software is secure or free of bugs. Just remember Heartbleed in OpenSSL.

One of the main problems is that everyone could take a look on the source but often no one actually does thinking someone else surely did it before. So it is possible that there are bugs or backdoors for a very long time hidden in some project.

Another Problem may be the complexity of some projects, it is just not possible for a single person to look at the source and know it is safe or not - you would need a long time to accomplish this just see the security audit of TrueCrypt for example.

In this context a main problem of open-source is that everyone can modify the code and share his own programm. There are many cases of this, manipulated versions of big open-source programms like Firefox, PhpMyAdmin etc. The normal PC-user won't ever notice that there is something wrong but he is happily using a big backdoor.

So open source may be a little bit more secure because in theory everyone could check the code but in practice bugs or backdoors may be undiscovered for a long time. And please don't get me wrong, I'm a big fan of open-source software but I am aware of the risks and so should anybody else.


In addition, I would add that most attackers don't directly log in via the console or ssh, but instead use bugs in other software in order to break out into a root shell or elevate their privileges. Adding 2-factor authentication or other mechanisms will definitely improve your security posture, but must be viewed as part of a larger overall hardening strategy.


Indirectly relaying intranet server to outside world

Proxying as you propose doing gives you the ability to add additional authentication and encryption, but nothing else.

IP cameras have terrible interfaces and terrible code. If you simply proxy the requests you will be proxying every possible exploit in the camera. If authenticated user sessions are considered a potential attack vector in your risk assessment, you shouldn't simply proxy, you need at the very least to validate every request is expected.

If authenticated user sessions are not considered an attack vector in your risk assessment, then that's a problem you should fix first.


Why would legitimate programs have a `jmp esp` instruction?

The instruction jmp esp is encoded as FF E4. It’s not necessary to find an actual jmp instruction, just those bytes in the middle of any other code or data.

This is the basis for return oriented programming (ROP) and these small sequences of useful instructions are often called “ROP gadgets”.

Note this particular technique is easily broken by a non-executable stack. Requiring an executable stack is quite rare (outside specific cases like a JIT compiler) so this is a simple and effective mitigation. To get round this there are techniques like return-to-libc which chain a number of these small ROP gadgets to build a longer sequence of instructions.


How to go about an SSL certificate renewal

Digital certificates as used for SSL/TLS have multiple components. While there are lots of details that we could examine, all we really need here is a high-level overview, but each piece is important to understand what you should do and why.

When you began the process of obtaining your certificate, you first issued the command,

  keytool -keystore keystore -alias myalias -genkey -keyalg RSA -keysize 2048

You described this as "creating your keystore," which is accurate, but it did something much more important also: it generated your private / public key pair. In this case, the new keystore contained a key pair using the RSA algorithm and with 2048 bits of entropy (a fancy way of saying how strong the key is, or how long it might take to break relative to other keys). This is important because the key pair is how you will demonstrate to the Certificate Authority (CA) that your next request is a renewal, is really from you, and is for the same certificate.

When you generated your certificate request,

  keytool -certreq -alias myalias -keystore keystore -file myrequest.csr

you created a file that contained your web site's information (foo.com), along with a bunch of other stuff - including your public key. It all got encoded into a well-known format and sent off to the CA. The CA generated your certificate using your public key and their private key, which is how some random web browser can use this to know that they are on your web site and that it's safe to send data. Your certificate gets validated by your private key, which only you have, and by the CA's public key, which only works if it matches up with the private key that signed the certificate.

So, how does all this play into accomplishing your goal of renewing your certificate?

The short answer is, you don't renew, because a renewal isn't really a renewal.

A "renewal" is just a fancy way of saying that you're requesting a new certificate, with a new expiration date, using the same private key as for the old certificate. If you use the same command as before (with the -certreq option), it will create a new certificate request using your existing key pair. Send that off to GoDaddy (or any other CA) and they should be able to process your request with no problem.

When they send the certificate to you, issue the import command and you're good to go:

  keytool -keystore keystore -import -alias myalias -file example.com.crt -trustcacerts

You should be able to import the new certificate into the same keystore as the old certificate, since they have different serial numbers. If you run into problems with the import, try using a new alias. Since an alias is usually just for your own reference, you can change the alias or go in and remove the old certificate from the keystore. It won't be used anymore, so it's safe to remove, but it doesn't usually hurt anything to keep it around either.

Note: you won't have to run the CA root import again unless GoDaddy updated their root certificate (it does happen, but not very often). This was the command you used to bring in the root certificate:

  keytool -import -trustcacerts -alias myalias -keystore keystore -file gd_bundle.crt

Since you mentioned that you're using GoDaddy, here's the link to their renewal page. The only instructions they have that are close to the Jetty server you're using are those for Tomcat. While those aren't exact, the Tomcat page does include some instructions on the use of keytool.
GoDaddy Certificate Renewal support page


I think you have a slight misunderstanding -

root is generally disallowed to login via SSH, but is still a valid user once on the machine.

When executing simply su, a user will be prompted for the root user's password in order to continue; sharing a password like this is bad practice.

If a specific user has access to sudo su, then only that named / user my become root. Again, sudo su will only work for the users / groups that are explicitly defined in /etc/sudoers.

The this link on why allowing root over SSH is bad practice.


File upload security in webapp - overview of setup

I think the only way to answer this is through a collaborative commenting effort, so here goes a community wiki:

Of course only registered users can upload, but I know that doesn't mean anything.

Agreed.

The site is exposed via nginx.

Which means you have the actual web application running behind that – make sure that your adapter (WSGI? fCGI?) is securely set up.

The machine on which the webserver is hosted only accepts incoming connections from the nginx machine.

clever move!

The image upload link (nginx directive) is rate limited (in a way that generously accounts for a legitimate user spike).

Make sure this doesn't make it easier to DoS-attack your site.

The webserver accepts only jpg/png/tiff/webp image formats (it derives the mime type using the magic library).

magemagick is a very well-maintained library, but it's also a very large attack surface, and there's been a lot of critical breaches happening through it. Using a much more restricted library for validation might be a good choice.
ensure that uploaded file extension always matches the detected format, and the file can be properly decoded as such. You can also consider stripping various metadata, like EXIF tags - basically, add a processing step, that takes only what's necessary (only image data) and save as a new file, with this step running as much isolated as possible (so RCEs in image decoding libraries won't get attacker any much access). After this, ensure that nginx always responds with the correct Content-Type and all the safety headers, X-Content-Type-Options etc.

Both nginx and the webserver have a limit on the accepted file size.

good.

All uploaded files are saved using a filename which is a hash of the contents.

Make sure to salt that hash; hashes are crackable (within limits), and you don't want an attacker to control the file name of their uploads. Don't just use MD5, but a less broken hash.

By default, they are saved with only rw permissions, not rwx.

Save them with read permissions. Once they are saved, they never need to be modified again.
Also, use SELinux (or your server OS'es equivalent) to make sure your web application can only write and read that directory, never execute files in it.

The images are stored on the same system as the webserver.

Might very quickly become a scalability issue: Server software would these days preferably run on fast reliable storage media (SSDs with hot fallover), whereas your user pictures would sufficiently be stored on cheap storage media with slow backups (i.e. if two hard drives fail at the same moment, OK, you'll need 15 minutes to restore from your redundancy and might lose a couple minutes of new user images).

They are saved directly to the final location (there's no intermediate staging location) but the images are not available for viewing until a specific database column is updated (see next point).

A periodic virus scan is completed on the newly uploaded files (and any malicious files are removed to a different directory to which the servers have no access) and then the aforementioned database column is updated to make the files available for viewing.

There's no computational advantage to doing that periodically instead of instantaneously after uploading the file. So, do it instantaneously, and keep your storage load constant as possible. Running the antivirus as a daemon avoids having to load up the virus definitions into memory for each scan.

Lastly, a tiny amount of random noise is added to each image by doing something like magick image.jpg -evaluate Add 0.1 image.jpg

That is a very compute intense step, which uncompresses images, adds noise, and that's the worst part, which in case of JPEG leads to maximum quality loss if you want to keep the original file size. (noise is very hard to compress, unless it's so weak that it actually gets compressed away and the resulting image is actually as if you never added noise.)
I don't see any security advantage of this step.
Further points

Containerize your web application.
Use a separate logging server
Monitor for sudden increases in storage consumption – in case someone abuses your site automatedly e.g. to host pictures for their own gain


Preventing phishing / spear phishing of employees

Big companies themselves send phishing mails to their employees on a regular basis in an semi-automated fashion. If an employee is trapped then he/she is informed like "what did you do? vs. what should you have done".

The problem is that the weakness phishing targets is not a technical weakness, it is a human non-technical weakness. So in my opinion you will only have limited success if you try to address this with a purely technical solution. I would try to invest as much as possible into awareness training and make sure employees stay aware through training, training, training.

The training can be backed up by a couple of simple very concrete rules like:

if someone calls you and asks for something that looks fishy, try to identify the caller through the enterprise phone directory and call him/her back
never hand out confidential information (like passwords) over phone, email
if network / phone support calls you surprisingly saying they need your support get in contact with phone number XYZ to confirm this is REALLY network / phone support (in this case you need to set up some service at number XYZ that is aware of all maintenance activites in your company)
TBC

Make sure every employee reads and understands this and have them sign off that they did.

My bottom line: Investments in organizational setup to prevent this from happening are probably at least as important as technical counter measures.


Securing client side code of react application

No, there isn't any foolproof way for securing your code client-side. This is essentially the same problem that DRM has tried and failed to solve. You can obfuscate your code, but that will only make it more difficult to reverse-engineer. With sufficient skill and effort, someone will eventually be able to crack it. And the crackers only have to win once - as soon as one person manages to bypass your client side checks, they can publish it on the internet and everybody else can profit from it (except you of course :).
The solution is simply to move (at least some critical parts of) your code server-side.


Can we decrypt captured malware (Meterpreter) HTTPS/SSL traffic with the keys from memory?

Yes, you can extract the keys. The private key and symmetric key are present in the memory of the crypto library (e.g. OpenSSL). You have to extract the symmetric key in order to decrypt the TLS traffic. OpenSSL keeps this in the struct SSL->session->master_key. If you don't know exactly what library is being used, a simple brute-force approach would be to extract all buffers of appropriate size from memory, and attempt to decrypt the TLS stream with each one until it succeeds.

You can also use GDB, as described in Extract pre-master keys from an OpenSSL application, which can provide you with the pre-master secret that you can plug into Wireshark. While that answer focuses on live memory dumps, it should work just as well if you have a coredump. Use Volatility to dump the process memory which is linked to the TLS library, which you can then use GDB on. If OpenSSL is not compiled with debugging symbols, you may have to resort to a brute force method.


Improving security by altering size of hash strings

First of all, don't use SHA-1 or MD5, as they are both deprecated (see this IETF draft).
As @dandavis has correctly noted, security through obscurity does not make your system more secure.
Actually, the post that @Steffen Ullrich shared in his comment is excellent and thoroughly explains why you shouldn't focus on keeping the algorithm you used a secret, but rather on how secure the algorithm you're using is.
[Bonus] Here's a cartoon I like:

Lastly, if you want to store your list of hashes securely (assuming passwords!?), then you should store each password with its own salt, together with a system-wide salt (called 'pepper').
You can have a look at this paper from 1979 for a more 'in-depth' explanation.


Metasploit wmap_run -e hangs with Using code '404' as not found

I had the same issue. My resolution was to reload the modules.

You can do that with the following command:

wmap_modules -r


Handshakes are different for WEP networks. The handshake you expect to capture is the "four way handshake" and that is only existing on WPA and WPA2 networks.

On WEP networks the handshake is different, is a challenge response handshake. This is how it works on WEP networks:

  In Open System authentication, the WLAN client need not provide its credentials to the Access Point during authentication. Any client can authenticate with the Access Point and then attempt to associate. In effect, no authentication occurs. Subsequently, WEP keys can be used for encrypting data frames. At this point, the client must have the correct keys.

  In Shared Key authentication, the WEP key is used for authentication in a four-step challenge-response handshake:

  The client sends an authentication request to the Access Point.
     The Access Point replies with a clear-text challenge.
     The client encrypts the challenge-text using the configured WEP key and sends it back in another authentication request.
     The Access Point decrypts the response. If this matches the challenge text, the Access Point sends back a positive reply.

On WPA/WPA2 networks is working in a different way. Look at this:

Extracted from here. On that link there are a lot of more info about it.

To crack a WPA/WPA2 key you need to capture the 4 way handshake, but for WEP is not needed. The WEP algorithm is bad designed and with enough captured traffic you can get the key. There are a lot of tools which can manage all of this (capturing WPA/WPA2, WEP decrypting, etc). I'll recommend to you this complete tool: airgeddon.

Hope it helps.


What makes it illegal to use the information learned by exploiting a bug?

The fundamental question here is authorization, not access.

If you break into your neighbor's house, clearly you are in violation of the law. But if he lets you in, then you are not.

So what if you have a key? If he gave you the key along with permission to enter (to feed his dog while he's away), then you have authorization to enter. No trespass there.

On the other hand, if you find the key under his doormat, that does not imply authorization, even though it grants you access. You can get in easily enough, but it's trespassing.

Now, say you go door-to-door checking to see if anyone left a key under their doormat. You just go inside the vulnerable houses and have a look around; you don't steal anything, you're just looking. That's what's happening here with the Heartbleed problem. Someone is using their knowledge of a vulnerability (e.g. key sometimes appears under the doormat) to gain access, but they are not authorized to have access.

Yes, the keys they retrieve are accessible to anyone who understands the vulnerability, just as a key under a doormat is likewise technically accessible to the public. But that doesn't make it legal to use it.


Can you make a digital signature using the receiver's public key?

Yes, this could be done, but what would the point be?  It wouldn't verify anything about the document.  A signature (slightly simplified) is just an encryption of a secure hash of a document using one of the keys in the pair.  The private key is used to prove that only the private key holder could sign it.  In the case of signing with the public key, anyone could alter the document and sign it, so it doesn't prove anything.  Not only that, the only person who would be able to verify the "signature" would be the holder of the private key, so there is absolutely no use to it.

Reading the paper, I can't see how they expect the process to work and it appears to be using the term signature in error.  What they are likely describing is protecting the session ID as a secure token by use of encrypting with the public key and then decrypting on the server with the private key.  The use of the term signature is incorrect and would not provide the necessary security in their use case.  The paper isn't very well written and has some other poorly worded sections.  I wonder if it may be a poorly translated paper where English wasn't the original language since I see one author is from Taiwan.  Though the US co-authors should have proofread it so I wouldn't trust the paper too much.

Update: On further reading I now understand what they are saying in the paper.  It is a very poorly worded summary.  They are using a system where both the merchant and the purchaser have a key pair.  The merchant provides a signed invoice which the client can verify is from the merchant.  They then sign their purchase order which includes the invoice which they are ordering.  The merchant then verifies that the client signed the purchase request and verifies that their invoice was unaltered.  It's rather a bit more convoluted than it seems to need to be, but it is accurate when you take the appropriate instances of public and private keys.


How does Mail.app handle account credentials?

The default mail app's credentials are stored on the device but could leak to either a local (iTunes) backup if backup encryption is turned on or to iCloud if cloud backup is enabled.

For third-party mail apps there are no ways to prove they aren't malicious besides disassembling it and reading the whole disassembly (good luck!).

Now your second question seems a little absurd. Obviously for a mail app to work it needs to have access to the content of your mails, so all mail clients do have access to that. I assume you wanted to ask about whether the app's developer had access to your mail contents, and that also depends on whether the app binary has any "feature" that would upload email contents or credentials to the developer.

Push notifications are a reasonable excuse to share account credentials with the developer (due to Apple's stupid policy about not allowing apps to run in the background for more than 5 minutes) however if the developer is malicious they could upload the credentials even though you disabled notifications.

In the end, if you don't trust an app's developer, don't install it.


How to get more information on TermDD Security Layer Disconnects (Event 56)

This USUALLY happens during times of heavy traffic to the terminal server.  The connection to the server gets corrupted as traffic becomes too heavy to handle.  I had this happen with my users at a former job quite a bit and almost every time I would see one of these in the Event Viewer I could talk to the user with the IP in question and correlate it to the time when they got disconnected from their terminal session.

See this for a very detailed explanation.

Mostly, it's not of malicious intent, but there is always the chance that an attacker is trying to DoS certain aspects of your systems, including your terminal server; to what end or goal they would do this, I cannot say, other than the usual buffer overflow type objectives.  Again, we could go on forever about potential objectives.  Mostly I wouldn't be too concerned as this is a very common occurrence on RDS/Terminal servers for Microsoft.

I would, however, validate the IPs listed in the log and make sure they are authorized IPs that your private IP scheme allows for and that they were in fact from legit users on your network connected to the server.

You can also check the RDS/terminal server settings and see if there is a timeout set on sessions; there usually is a default one, so I'd look for that first.


What is the difference between ordinary XSS and Dom XSS vulnerabilities?

Ok so at a basic level there are three types of Cross-Site Scripting.

Reflected - You enter data to the application, which is then echoed back without escaping, sanitization or encoding and it's possible to include JavaScript code which is then executed in the context of the application

Stored - You enter data which is stored within the application and then returned later on in response to another request.  This data contains JavaScript code which is executed in the context of the application

DOM based - You enter data which modifies the DOM of the web page, this data contains JavaScript which is executed in the context of the application.  It's relatively similar to reflected XSS but the difference is that in modifying the DOM the data might not ever got to the server (which changes how it can/should be mitigated as server-side filters might not be effective).

An example would be web applications which make heavy use of client-side JavaScript and which take user data and update the DOM without ever actually sending the data to the server. If you see applications which make instant changes to the page you're viewing when you enter data, it's likely that they're using client-side JavaScript to update the DOM.

In terms of finding them, that's kind of tricky, as the tools to find DOM based XSS aren't as developed as the ones for Reflective or Stored XSS.  The only tool which specifically addresses it, which I'm aware of is Dominator.  There's also information on the DOM XSS Wiki which could be useful.


Black box testing javascript MVC web applications

I have found out that there are a few solutions to this issue. First is to use Burpsuite to index the website. It will function as a proxy and will register all calls made to the website, while you are browsing the website through your web-browser.
This proxy technique can be also applied to other pentesting tools, if supported.

The next step would be to write your own interface to these calls and use the pentest tool from there.


who signs the certificate (Root CA or an intermediate authority?

If the certificates are directly issued by the Root CA (which is usually only Intermediate CA certs) then they are signed using the Root CA private key.  The certificates typically issued to servers or users are signed with an Intermediate CA private key one or two levels down from the root.


Does PA-DSS apply to a SaaS eCommerce system?

PA-DSS does NOT apply to payment applications offered by application or
  service providers only as a service (unless such applications  are also
  sold, licensed, or distributed to third parties) because:

  The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install,  or control the application or its environment;
  [does not apply by my reading]
  The application is not sold, distributed, or licensed to third parties.

They cannot deploy on their own hardware; they have to lease the software from us.

Also note: third parties means your clients clients. You're not exactly letting your clients clients use the software in question are you? (ignoring the shopping cart function, that's not the part that is in question here)

  Our clients can of course use the application to create products and view their orders, however all installation and server maintenance is done by us.

It wouldn't really be a product if this weren't true. IE: all products must have this capacity, so that can be dismissed from the consideration.

I believe, from reading your question/claims, that the product you're using is indeed covered. If you ever let the customer's see the entirety of the billing process then it would not be, in my opinion. But because you control the infrastructure and just give them access to the pertinent parts, you're covered.

That's my lay-person's reading.


In the era of cryptolockers, is it possible to prevent Windows from modifying your Linux partition?

Unless virtualization physically prevents the opreating system from seeing the device as such (e.g. the "disk" really being a VHDX or similar), the answer is "yes, of course". There is nothing special needed for that, and nothing you can do to prevent it from happening, once malware has gained admin privileges.

I wouldn't know by heart how to open the device under Windows (something like \device\harddisk1 or such?), but sure enough I've overwritten the raw device under Linux more than once. Something like cat /dev/random > /dev/sda has been "working fine" for, like... forever, assuming you logged in as root. That's poor man's secure erase in lack of something better.

Installing a boot loader (which is part 1 of the ransomware) is nothing but doing just that, only with not-so-random data. Overwrite the boot loader with a binary of yours that shows the "pay me, sucker" text.
Note that this bootloader (nor the encrypt/decrypt portion, if there is a decrypt portion at all) needs to be able to access the partition or the filesystem in a meaningful manner.

Encrypting (or garbling, the user cannot really tell a difference) is the second part, and that is similarly easy. If you can write a boot loader, you can write sectors. So, instead of files, encrypt sectors on the raw device. Who cares about the logical structure inside those sectors when you can make them unusable either way? Different partition type, different filesystem? You couldn't care less. Someone who wants to use them needs to know, you don't need to know.
This is something the malware can do in a few seconds, there is not even much of a need to be secretive or super smart. You do not need to keep a low profile to avoid detection. By the time the user even notices the furiously blinking light on the computer and wonders what may be going on, the malware will already have overwritten hundreds of megabytes (dozens of gigabytes) of data. If the malware writer possesses only a minimum amount of smartness, this is sufficient to overwrite the filesystem metadata on every partition including backup metadata at their respective well-known offsets, and a couple of hundred megabytes of actual file contents.
Certainly, with only the metadata overwritten, it is in principle still possible to recover the contents of the not-yet-overwritten files, but this is an excessively expensive thing to do, and well beyond the average user's capabilities (and may be impossible for small files on some file systems).

You need not even properly encrypt, you can as well just overwrite sectors with garbage data. The user cannot tell a difference, they only realize after having paid if they are so stupid as to pay a criminal in hope the criminal will stand up to his word.

So... yes, technically this is absolutely no problem (for most computers owned by most people).


Understanding cross origing requests from a web page

If you use CORS  for anything else then XMLHTTPRequest (which historically defaulted to only allow same origin) it has to be supported on the client side (browser) and it also has to explicitly used on the server side.

By default cross origin requests can be done simply be including an image, stylesheet, script etc from another site and if you have a successful XSS you can use it to send for example the session cookie inside such a request. To make this impossible you would need to check each request at the server side (e.g. requesting a same-site Origin or Referer and do not allow empty Origin/Referer) or limit cross-site requests at the client side (using Content-Security-Policy, not supported by all recent browsers).


A replay attack at the TLS level (and thus HTTPS) as you imagine would mean that some attacker could simply replay a captured TLS session or inject a previously captured packet into an existing TLS session.
None of this is possible: Replaying a full session cannot be done since the master_secret as the base for encryption includes both client and server random data, i.e. the master_secret does not depend on the client alone. Injecting a previously sniffed record is not possible since each record has a sequence number  and simply replaying a record will be detected due to an old sequence number. Changing the sequence number will not work either since it is protected against manipulation like the rest of the record.
But if an attacker has access to the plain (unencrypted) request he can simply replay this request within some new TLS session. This would be HTTP level replay though and not TLS or HTTPS level replay.

My client relies on the hardware information from the system to validate one-user-per-subscription ...

Based on this your client relies on the client not cheating in the first place - which is contrary to the attack vector you describe. But a client could do cheating: for example the client could run in some emulated environment which can be cloned and exhibit the same behavior in another system.
The client could also partially reverse engineer or hook your app to capture and modify the plain request before it gets send. This way it can capture the plain (unencrypted) request on one system and make sure that the other system uses the same request.


How do JavaScript (and mobile) APIs keep user data clean?

I don't know of any protection mechanism and I have never seen anything in existing web apps. This is kind of an inherent problem of your client sending requests directly to the third party. In this case a tracking/analytics service.

You can try to obfuscate the JavaScript which creates the request but platforms such as Google have a clearly documented API.

There is even a blog post on how to corrupt this data by using the account on another website which also uses Google analytics.

You can try to track users serve side. Certainly when they have been authenticated, you can track the session across requests. But this does not give you as detailed info as you would get with some JavaScript features. Unauthenticated users could keep requesting new sessions and you wouldn't know.

You will never be able to tell with a 100% certainty if your data has been generated by a bot. Someone can also crawl your website or use a tool like selenium to automate certain user behavior. Some metrics like user agent, timing and HTTP headers could help identify these automated visits.


Why CA's baseline requirement have 22 on Authorized ports while there is no allowed way to use it?

You wrote:

  (unless you are weirdo runs a webserver on port 22)

It sounds weird but I think that is exactly what this is about.

Ryan Sleevi of Google had this to say:

Ryan Sleevi sleevi at google.com
Fri Mar 2 08:51:19 MST 2018
Previous message: [cabfpub] [Ext] BR Authorized Ports, add 8443
Next message: [cabfpub] [Ext] BR Authorized Ports, add 8443
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Mar 2, 2018 at 10:08 AM, Paul Hoffman via Public <
public at cabforum.org> wrote:

> On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public at cabforum.org>
> wrote:
> >
> > Forwarding from Richard Wang:
> >
> > The current BRs say:
> >
> > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25
> (smtp), 22 (ssh).
> >
> > But many internal networks use the port 8443, broadly used in Apache
> server, today, one of our customers uses this port and can't change to use
> another port, I wish you can help to add this port 8443 to be allowed in
> the BRs, thanks.
>
> It appears that the BRs currently are talking about authorizing
> *services*, not ports. That is, I would not expect to be able to put a HTTP
> server on port 22 on my system and have that considered authorized by the
> BRs.
>

That is intentionally permitted.
[...]


Difference between confidential, protected, and restricted data

Nevermind, those terms are depends on the data classification stated by the company (in this case NYU). Different company has different data classification so the term maybe should not be generalized.


The story below maintains a link to the testimony given by Equifax CEO Richard F Smith. In his testimony he admits that it was indeed the Apache Struts vulnerability that was used.

However, what is not revealed is how the instigators pivoted to escalate their privileges.

https://www.theregister.co.uk/2017/10/02/equifax_ceo_richard_smith_congressional_testimony/

This flaw has been exploited before, so there are some examples.

https://www.bleepingcomputer.com/news/security/equifax-confirms-hackers-used-apache-struts-vulnerability-to-breach-its-servers/


You could take a look at the GWT Crypto package.  Its a port of some of the BouncyCastle stuff into GWT, so you should be able to take the compiled output and massage it a bit so you can call it from your current Javascript.  It currently supports RSA keypair generation and encryption/decryption, as well as AES and DES.  I think that's about it though.

I personally have not used this library, but since it was ported from BC it should be safer than writing your own implementation.  That said, I dont know where they sourced their SecureRandom implementation from.  You may need to look to see if its actually a cryptographically secure implementation or not.  I took a quick look and they are just doing something with SHA and the seed bytes, but I dont know if that qualifies or not.

One last thing.  I have found using RSA to encrypt large amounts of data to be quite slow.  Perhaps you may want to use a hybrid solution of some sort where you encrypt an AES256 key using the RSA keypair and then use AES to encrypt the data?  Could be faster...


relationship between anti-spam solutions and whois databases

Not sure if helps, but I have used RBL lists for a long in my mail servers and they do a pretty decent job (they take care about 90% - 95% of the spam).

It works much better than SpamAssassin (and without hassle). Still, I use SpamAssassin for the rest of the spam.

Now, about your specific question: If I understand correctly, what you want is to block complete segments automatically, right?

I think Whois inetnum and route are the same, just different representations. Don't take my word as the holly truth, as I have no so much experience with those values, but that is what I believe.

I think this question and this one may give you some clue on how to achieve what you want.

While I see an advantage on blocking entire segments, I think you won't get so much benefits from that. The reason is because spam comes from many different segments and blocking one segment will only block very few positive IPs.

One problem I see, is that you may over-block IPs:

I will give an example in real life: Here in Japan the company NTT owns a mail service with the "ocn.ne.jp" domain. It has several smtp servers which are originated in the same segment (randomly assigned to their customers). Sometimes one of those servers gets black listed (RBL) and my servers block emails coming from there. Sometimes they are blocked for hours due to some misuse in some account. But that doesn't mean I should block all the segment. If I do that, it would be a big problem as its commonly used here in Japan.

OCN is not the only case, I have seen it too with yahoo servers and others.


Basically, the NSA is able to decrypt most of the Internet. They're
  doing it primarily by cheating, not by mathematics.

-- Bruce Schneier

Now, your question is "So is HTTPS still a solution for secure web-browsing?"

The answer is, as safe as it ever was, unless your opponent is the NSA.  The reports you're referencing do not identify a generic weakness that can be taken advantage of by random actors, by organized crime, by your ex-wife.  There's no systemic failure here, just proof that a sufficiently funded, authorized, and skilled attacker can compromise lots of endpoints.  And we knew that.


The same way you trust GPG running on your Intel or AMD CPU.

You either trust the vendor or audit the code and hardware yourself.

In practice, probably a bit of both. e.g. you trust the vendor of the micro-controller but audit the software running on it.


How do high-performance web applications control permission to their content?

Every article has an associated permissions object attached to it. That permissions object describes the code to be evaluated and any possible parameters. Most contexts are fairly normalized, such as in Facebook where the context might be friends.

Thus, the viewer's control evaluates its attached rules: if you're a friend, it succeeds. That's a pretty fast operation. You can go further, attaching specific data to the control (I share something with all my friends except Eve, or with a specific list). You can also set rules for a viewer: an editor might have a privacy controller attached to their context that returns true for all calls.

There are two good examples off the top of my head that can see some of the workings of. The first is Amazon AWS permissions: policies are attached to both users and objects and they describe permitted actions on AWS. In the case of AWS, the rule starts off with implicitly deny. All rules attached to the user and the service are evaluated, and the boolean logic is if permitted and not explicitly_denied. Check out the IAM policy simulator for a graphical view of how things evaluate.

The other view is PAM services for Unix, which lets you write any code you'd like taking the user into account and marking the result of that as required, sufficient, or a few other options.

For your specific case, every you might setup an evaluation for RBAC, an evaluation for specific

By the way, both Facebook and Twitter use stateful authorization. At least in Facebook's case regarding images, the actual access to a cached image isn't checked to allow remote caching, but it is during page generation. It is a database call every time. A typical page load on Facebook can generate over 100,000 database calls. Simple KV type stores, memcache, and strong parallelism really help make that work.


Hashcat: How to discard words of length less than N after rules have been applied?

The answer depends on the "speed" of the target hash:

If it's a fast hash (like MD5), Daisetsu is roughly correct - that it's not worth the trouble to worry about it (though it can vary based on attack and targets);
If it's a slow hash (like bcrypt), the GPUs won't be starved for candidate passwords, so you have the luxury of generating candidates externally (off-GPU) without slowing down your attack.

A common technique for the latter is to combine hashcat's --stdout option with your attack to generate your candidates, and then pipe that hashcat to another instance of hashcat (which does the actual cracking).

To inject length requirements into that pipeline, the hashcat-utils len utility works this very efficiently. If there are complexity requirements, the req utilities from hashcat-utils is also very efficient.

So you could do something like this to generate the candidates:

$ hashcat rockyou.txt -r rules/best64.rule  --stdout
123456
654321
123456
123456
1234560
1234561
1234562
1234563
1234564
1234565
[snip]

... and then pipe that to another hashcat (for example, assuming a requirement of length minimum of 8, and maximum of 11):

hashcat rockyou.txt -r rules/best64.rule  --stdout | len 8 11 | hashcat -a 3200 targets.hashes

... but keep in mind that this is useful only for slower hashes.

Note that if the hash is slow enough, you can use anything (Perl, shell scripts, crunch, etc.) to do whatever fancy candidate generating and sifting that you want. As the speed of the hash starts to increase, you'll want to benchmark your pipeline to make sure that you're not starving the GPUs (they should usually show 100% in hashcat's status output). hashcat and len are very fast, as are the other tools in hashcat-utils, so I usually point people there.


Does a CAA record on a local hostname in a LAN offer additional security?

Using CAA DNS records for internal networks doesn't really make sense, especially when you're using a .local domain.

Simply put: The way CAA records work is that an issuing CA will check the CAA records of a domain through public DNS records but only if the issuing CA is told to do so.

Public CAS are required to do that. But a public certificate authority cannot issue to a .local domain anyway since domain control is not verifiable.

Someone who set up an internal CA however could still issue to your contoso.local domain since his CA would not have to be configured to check public CAA records.

Hope that helps!


Ways to exploit AD in context of Domain Computer account not as Domain user account?

I will answer the following question:
"You got ACCESS to AD Joined Domain Machine but the user you compromised is Local Administrator NOT Domain User/Administrator?"
Before starting, I think that this is a very interesting question and not wide at all.
Here is the deal, you started as a LA which basically means that you can perform almost anything you want on the current BOX. Great! Let's analyze this:

You are LA therefore you could have a look at the secrets stored in the computer. This includes tickets from the users that logged there, the LSASS process (and the users that interacted there), and of course the NTLM of the machine account ( you can identify these because they have a $ at the end of their name, like WS001$ , also it would be possible to check for PowerShell history files, or browser's bookmarks. Basically run local checks in order to enumerate local information that might be useful to elaborate further attacks
Now I assume that the computer where you are working from is domain joined. Lucky you, you have the NTLM of the local Administrator account and therefore you can perform actions like if you were the host. This is your lucky day because AD treats computer accounts and user accounts very similarly, therefore you can perfectly execute bloodhound and obtain relevant data! Thanks to a bloodhound, you discovered that one of the users that had a Kerberos ticket in memory, Larry has GenericAll permission over the user ADM-Larry which is a Domain Admin! Then you will grab the ticket, inject it with Rubeus, modify the password of ADM-Larry and finally impersonate ADM-Larry.  Now you are free to do whatever you want including a DC-Sync in the DC!

Reference about the GenericAll attack:
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces


Why shouldn't my client just send the user's username and password with every request?

If you prompt the user to newly enter a Username and Password every single time the application needs to make an API call, they're gonna have a bad time and stop using it. Especially if a situation arises where a single "action" from their perspective kicks off multiple API calls that would need authentication separately. That's just not workable. That isn't the only way that "

The alternative is having the user's Username and Password stored on their device so the application doesn't need to prompt in order to send the request. The user can't tell the difference between the application holding an arbitrary token that enables access compared to username + password that enables access, so that's good. Unfortunately, there are some flaws in that as well, and those flaws are more security-relevant.

First, unless your application does internal encryption the username and password end up effectively stored right next to each other in plaintext. Even if there is encryption, the encryption key pretty much has to be stored close to what it's encrypting which isn't really much better. I can't say with precision how much of a vulnerability this is, and a token is likely to be just as vulnerable, but an attacker getting hold of a single token is likely less damaging than one getting the full username + password.

Second is, as you are aware, tokens are expected to expire with relatively high frequency compared to usernames and passwords. From the way your question is worded, you seem to be considering username + password in every request as the "highest level" of tokens expiring quickly, but it's actually the opposite: with no token in between, username and password become the token and only expire when changed. That makes the application somewhat more vulnerable to replay attacks, and makes it much more inconvenient to the user if you ever implement controls to detect malicious behavior: with a token, you can expire the token immediately but a real user can provide username and password to get a new one while an attacker who obtained just the token is blocked. A user entering their credentials every now and then is pretty minor, but forcing random password resets is significantly more burdensome on and it leans a lot on a secure password reset function.

Last, the username and password would be transmitted a lot more frequently. Ideally the secure connection is perfect and that's not a problem, but in practice there are some vulnerabilities that are more likely to be exploitable. For example, the CRIME vulnerability exploited the size of messages sent to leak pieces of information but required a constant value exist across many messages. That exact vulnerability is probably patched, but similar ones could exist in the future and if your requests are a little leaky then always having the username and password in them lets an attack piece-together that information over a long time, compared to a token which is less impactful to leak as well as limiting the time that an attacker has to obtain it.

All of that might not add up to a large security compromise, but I wouldn't risk it.


Are Security Auditors liable for breaches?

Professionally competent auditors having exercised due care generally
  cannot be held liable for a security breach due to undiscovered
  vulnerabilities

The main reasons for this are explained below.

  Reasonable assurance vs. absolute assurance

An inherent limitation of any audit is that assurances they provide are reasonable and not absolute based on the evidence gathered by the auditor. It is not possible to achieve absolute assurance. As long as auditors follow professional audit guidelines and properly document their work, they are ordinarily protected. It would be not be feasible for an auditor to guarantee absolute assurance in that all security vulnerabilities will be found, due to constraining factors such as audit resources allocated, management cooperation etc.

The same can be said for security controls in that such controls only mitigate but not completely eliminate risks, otherwise defined as an threat exploiting a vulnerability. The extent to which risk mitigation is achieved is mainly a function of how well the control is designed and operating. I said mainly in the previous sentence because even if a particular security control (example: Segregation of Duties) is both designed and operating effectively, human collusion or management override can render the security control ineffective.

  Management Control over security controls

A security audit (or any audit) cannot by itself prove anything other than an audit was done. The main reason is that security controls, as a subset of the internal controls of a company, is overseen and owned by management of that company. Auditors, as external independent actors, cannot attest to security controls not subscribed to by management. Therefore, auditors may only attest to the assertions of company management  management, and if necessary security controls to achieve particular principles are missing or inadequate, should qualify their opinion issued to management. It is management who ultimately can decide to secure an organization, not the security auditor.


How should I construct a secure redirect_uri?

UPDATE: after clarifications added to the question following comments, the "redirect" part is actually part of oAuth in the provider's API and not related to the OWASP section I initially pointed to. I leave it nevertheless for the record.

There are certainly security elements to take into account writing this redirect page (as with other exposed pages) though.

When you allow a page redirect you basically put your reputation at stake. Someone seeing http://myserver.mycompany.com/whatevercomeshere expects whatevercomeshere to be trusted.

How to do that is introduced in the OWASP Unvalidated Redirects and Forwards Cheat Sheet.

  Simply avoid using redirects and forwards.

  If used, do not allow the url as user input for the destination. This
  can usually be done. In this case, you should have a method to
  validate URL.

  If user input can’t be avoided, ensure that the supplied value is
  valid, appropriate for the application, and is authorized for the
  user.

  It is recommended that any such destination input be mapped to a
  value, rather than the actual URL or portion of the URL, and that
  server side code translate this value to the target URL.

  Sanitize input by creating a list of trusted URL's (lists of hosts or
  a regex). Force all redirects to first go through a page notifying
  users that they are going off of your site, and have them click a link
  to confirm.


reading/downloading big files in metasploit module

This is no hard limit on downloads in any of the meterpreters, but if you are using PHP meterpreter it will have to conform to the PHP.ini that is running on the server that it was installed on.

You may also be running into other connectivity or lag issues. Can you perform downloads of similar sizes over similar protocols?


Why Parallels 8 installer looking into my Chrome's Cookies?

Parallels Desktop is a closed-source application, so the community isn't going to be able to help you out much here other than offering rumor and conjecture.

Your best bet is to contact Parallels to see if you can get them to explain themselves.


Possible way to extract sudo password from running system via the clipboard

Yes. In fact this is a common feature of keyloggers. They will often take screen captures every X seconds, monitor the clipboard, and log key strokes. These features pretty much defeat your strategy of typing rather than copy/paste.

However you mention you're using keepass. So you may be protected. Take a look at this information from their FAQ

  Because we are heavily using the clipboard, it is useful to block all current clipboard monitors. This means that no other applications will get notified when KeePass changes the clipboard.

  For this, an invisible window is created and added to the top of the
  clipboard event handler chain. This window simply throws away all
  clipboard change messages it receives, practically blocking all other
  applications from receiving any events.

It also details another feature to defeat keyloggers:

  The Auto-Type feature of KeePass is very powerful: it sends simulated keypresses to other applications. This works with all Windows applications and for the target applications it's not possible to distinguish between real keypresses and the ones simulated by Auto-Type. This at the same time is the main disadvantage of Auto-Type, because keyloggers can eavesdrop the simulated keys. That's where Two-Channel Auto-Type Obfuscation (TCATO) comes into play.

  TCATO makes standard keyloggers useless. It uses the Windows clipboard
  to transfer parts of the auto-typed text into the target application.
  Keyloggers can see the Ctrl-V presses, but do not log the actual
  contents pasted from the clipboard.

The bottom line, as you may gather, is that as new attacks arise so do new defenses (and vice versa).


Should I obscure database primary keys for the frontend even if these ids are uuidv4 Ids?

Protecting the key ("obfuscation" might be the wrong word) assumes that there is some attacker which should not see the real key and/or should not be able to use the key. Without such potential attacker (which might be the user itself) there is no need to protect the key in the first place.
Just guessing the key is in your scenario kind of impossible since the key is randomly chosen and large enough. But the key might somehow leak to somebody who should not be able to see the key in the first place or who should not be able to associate multiple uses of the key with each other.
For example it could be that the key represents some user, and that user details could be accessed just by knowing the key. In this case it might be a problem if the key gets exposed in the URL and ends up inside a Referer header when doing some cross-site request. Or it might be that the key represents a user profile. Here would it be a problem if the same key is used on different sites, so that the user can easily realize that it gets tracked.
In these cases it might be useful to somehow protect the original database key. But simply using a fixed hash will not help: a specific key will always be mapped to the same hashed key. And when every access to the database will be based on the now protected key, then knowing the hashed key allows the same kind of access or associations than with the original key.
It would be different if the protection of the key was based on some additional and variable context. Such a context could for example be the current session id, in which case the protected key could only be used if the session id is also known. This would help against accidental leaking the key inside a Referer. Or the context could be the current web site. This would help against the user realizing that no matter which web site they visit they will be tracked and it will always add up to the same user profile. Or the context could be the time so that the key could only be misused within a short time frame etc. If such protection is needed and how it should be implemented depends on the details of the specific use case.


What is "Your Phone" in Windows 10 Advanced Firewall?

It's a Windows Store app, installed by default with at least some Windows editions, that is literally called "Your Phone". I don't know why it needs such a wide hole in the firewall, that seems excessive, but at least that access is specific only to the one app package. It's a handy app, by the way; lets you do things like see phone notifications on your PC and send SMS from a real keyboard.
The long identifier (starting with "S-1-15-") is a text representation of a SID (Security IDentifier), specifically one for an "AppContainer" sandbox (all Windows Store apps, plus a bunch of built-in apps, run in AppContainers and have since Windows 8). Every app on the Store (or built in) has a unique AppContainer SID that is the same for all copies of that app, no matter where they are or whether the app is deleted and re-installed.
SIDs are in the registry but in a part that Regedit cannot read by default unless you change the ACLs or run it as SYSTEM (it's not readable, by default, even to Administrators). Every running process on Windows has a security "Token" and the token contains (among other things) a set of SIDs (for the user, for the user's groups, for the desktop session, for the mandatory integrity level, and potentially for any sandboxes such as AppContainers). Limiting the firewall rule to that SID, rather than to a specific executable, means that if the app ("Your Phone" in this case) has multiple processes running in the sandbox, they are all allowed through the firewall without creating multiple rules.
You can also use the firewall's Block rules to prevent apps from reaching some (or all) of the network / Internet, incidentally, without doing something as brittle as blocking by port or executable name.


File encryption with AES-256-CBC vs Chunk encryption

Security wise, I don't see there is any difference.

Since integrity and availability are assumed to be handled properly, the only concern is confidentiality. Solution 1 uses only one IV, assuming you can generate good IVs (random and long enough), then that is fine. Solution 2 uses multiple IVs but they don't add more to security (IVs are all public). Indeed IVs are used to randomize ciphertext so that the chosen plaintext attack is not possible. One IV for the whole file is sufficient for this purpose. In solution 1 all data is encrypted under one key. This is the same in solution 2. Then confidentiality boils down to the security of this key. There is no difference in both solutions.

There might be some difference when it comes to performance. Solution 2 allows encryption and decryption to be done in parallel. This is not the case in solution 1. On the other hand, solution 2 requires slightly more space/computation/bandwidth due to the additional IVs.


SQL injection -- why isn't escape quotes safe anymore?

Why can't we escape all user input using "magic"?

At the time the magic is applied, it is unknown where the data will end up. So magic quotes are destroying data that, unless it is written unescaped to a database.

It may just be used in the HTML response sent back to the client. Think of a form that has not beem filled in completely and is therefore shown again to the user. With magic quotes, the data entered on the first attempt will now be SQL escaped, which is meaningless on an HTML page. Even worse: on the second submission the data is SQL escaped again.

  Why wasn't addslashes "good enough"?

It has issues with multibyte characters:

' 27
\ 5c
뼧 bf 5c

Those are two bytes, but only one Unicode character.

Since addslashes does not know anything about Unicode, it converts the input bf 27 to bf 5c 27. If this is read by a Unicode-aware program, it is seen as 뼧'. Boom.

There is a good explanation of this issue at http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

  Whats wrong with using DB-specific escape functions, and why was it better than addslashes?

They are better because they ensure that the escaping interprets the data in the same way the database does (see the last question).

From a security point of view, they are okay if you use them for every single database input. But they have the risk that you may forget either of them somewhere.

Edit: As getahobby added: Or that you use xxx_escape_strings for numbers without adding quotation marks around them in the SQL statement and without ensuring that they are actual numbers by casting or converting the input to the appropriate data type /Edit

From a software development perspective they are bad because they make it a lot harder to add support for other SQL database server software.

  Why are prepared statements with frameworks and PDO being hailed as the gold standard of SQL? Why are they better?

PDO is mostly a good thing for software design reasons. It makes it a lot easier to support other database server software. It has an object orientated interface which abstracts many of the little database specific incompatibilities.

  Why can't I do an SQL injection with these [prepared statements], where as I COULD have with the previously mentioned means?

The "constant query with variable parameters" part of prepared statements is what is important here. The database driver will escape all the parameters automatically without the developer having to think about it.

Parametrized queries are often easier to read that normal queries with escaped parameters for syntactic reasons. Depending on the environment, they may be a little faster.

Always using prepared statements with parameters is something that can be validated by static code analysis tools. A missing call to xxx_escape_string is not spotted that easily and reliably.

  Can a programmer not somehow manage to still screw this up? What should they look out for?

"Prepared statements" imply that the are constant. Dynamically generating prepared statements - especially with user input - still have all the injection issues.


Akamai and Cloudflare provide DDoS protection services which will disperse traffic using DNS load balancing, blacklist bots, and filter attacks before they reach your server(s).

LOIC produces an HTTP GET flood, this is not an advanced DoS technique but rather a simple script to carry out a trivial attack.  Any worthwhile DDoS prevention product should solve this basic attack.  Until a certain point, of course, and then no one can solve it.


Simple explanation of how Dirty COW works?

You and 3 other people are studying for a test, using the same notes.

You say "I gotta go, I need to make a copy of these notes for myself that I can mark up... let me go make a copy!"

You take the notes to the photocopier, copy them, alter the original, and then take the modified original back to the rest of the group.  That modified version is bad; you've altered some answers to be wrong.

The rest of the group is left studying off of a bad version of the notes, while you take the good version home.

You pass the test.

They fail.

The only nuance between this example and Dirty COW is that in Dirty COW you aren't supposed to be handed the original; the kernel makes the copy for you.  But there's a race condition that mistakenly gives you access to the original when you ask for a copy.  "Race condition" means "you can sneak in access to something you shouldn't have access to."


How does the Subterfuge toolkit bypass SSL?

Subterfuge is a Man-In-The-Middle tool kit that allows you to intercept communication on a LAN. Generally this is done by ARP Poisoning, tricking the client into thinking your IP is the destination. From there the attacker could steal credentials, inject malicious code, or change data.

The tool does incorporate sslstrip, which is a tool that replaces all https:// instances in a website with http://. This would bypass SSL from the client to the attacker, and then relay the data to the destination server via SSL.

Client ->[plaintext]-> MITM ->[SSL]-> Destination

This only works if the original webpage was using http:// and then linked to https:// either via a hyperlink or a form. If the client tries to make a direct connection to the server using SSL (i.e: from bookmark), then you would not be able to force them into plaintext.


How to securely login over HTTP when you have SSH access?

Without SSL, your connection can be preyed upon by eavesdroppers: they can see the data, they can also alter the data, and generally hijack your connection once you have authenticated. They can do that regardless of the authentication method.

If you assume that there is no malicious individual who can see and/or modify traffic in-transit, then... there is no security problem, and basic authentication (as in "show the password") would work equally well.

So I can sum it up as: your one-time link obtained over SSH does not provide any significant improvement on security. Without SSL, the App was weak and is still weak. So I'd say, don't bother with it, in particular because forcing a SSH connection whenever a user wants to use the App is a big usability issue.

Instead, use SSL.


How to implement zero trust concept on a pod running in Kubernetes?

If you're looking to harden a Kubernetes cluster for east-west traffic, then you can generally use the Kubernetes Network Policy API.  This will allow you to restrict traffic to specific white-listed sources and destinations based on Kubernetes labelling and/or CIDR ranges.
In addition to base functionality provided by k8s, you can supplement this with additional policy options based on the CNI provider you're using. For example both Cilium and Calico, support the creation of global network policies to allow for the establishment of baseline security in the cluster network.


How to encrypt a short string to a short ciphertext using an asymmetric encryption?

"Encrypt with the private key, so that it is decrypted with the public key": this is a flawed analogy, by which RSA signatures were first described, but even with RSA it does not work.

What you want is really a signature algorithm, however you want to call it. It is possible to define signature algorithms based on the RSA core operation, and it has been done, and it is called RSA. Anything which is RSA-based will involve some modular exponentiations working on, and yielding, big integers of the same size as the modulus. So a RSA-based signature with a RSA key worth that name (i.e. at least 1024 bits) will necessarily include a 1024-bit integer, so its size will not be lower than 128 bytes.

There is a possible twist in that RSA is a signature algorithm "with recovery": though the signature will have size at least 128 bytes, it is possible to embed in it some extra data (part of the message which is signed). There is a standard called ISO 9796-2 which does that; it has some shortcomings but it can be used. However, though this standard will make the total signature size overhead rather small, it won't please you, because you want to limit the size of that which is entered by a human user. The benefits of ISO 9796-2 are for long messages.

Algorithms producing short signatures are an active research area. Roughly speaking, if you target a security level of n bits (meaning: an attacker would have to invest in a computational effort of size 2n to be able to produce a fake signature -- but the effort may possibly enable him to produce millions of fake signatures for the same cost):

With DSA and derivatives (e.g. ECDSA), the signature size is 4n bits.
With BLS, the signature size is 2n bits (but the maths are hard to understand and there is no standard yet).
There is an absolute theoretical minimum of n bits.
We don't know good algorithms between n and 2n bits, although we know some of questionable security.

You might be able to fix that, though, by changing your models. Signature algorithms are meant for one thing: to allow someone to verify a signature without giving him the power to produce signatures. Depending on your exact context, it is possible that you do not really need this separation of roles. Maybe it is not a problem if whoever verifies a "signature" could potentially create signatures of his own. If that is the case, then you can use a MAC which can be considerably shorter (e.g. 32 bits might be sufficient in your case) and also much easier to implement (hint: use HMAC/SHA-256 and truncate to the desired size).


Virus scanning uploaded images to database

Just to pull some of the comments into an answer:
Firstly, this shouldn't be your responsibility, so if you decide to implement controls, choose something manageable.

A basic scan on upload may be straightforward, as long as you aren't getting overloaded with images. SO perhaps look at scanning unless your scan load or number of images uploaded per minutes goes over a threshold
A scan on access, as @schroeder commented, gives you the most up to date scan and you aren't wasting resources scanning images that may never be accessed.
A basic sanity check on uploaded files - are they valid image files


TCP timestamps are only visible at the endpoints of the specific TCP connection and on every hop in between. If you are setting up a "hardware" Tor gateway (i.e. some software running on some gateway system) the TCP connection from your systems ends at this gateway. Who can then view the TCP timestamps depends on where this gateway is located. But if it is located inside your local network your ISP will not be able to see the TCP timestamps from your system. He might be able to see the TCP timestamps from your Tor gateway though.


How often do security patches break business applications

A more rational approach taken in same places, is not to avoid updates altogether, but rather to delay and test before applying. Big organizations like Microsoft, Apple, and Mozilla have put out bad updates in the past rendering devices or software unusable, or unusable behind a proxy/firewall, etc. It can be a good calculated risk to delay an update for a while to see if there are any problems that pop up soon after it is released, and then to apply the update to a few non-critical systems first to check for problems in the local environment, before a wider roll-out.


How do I remove my website from the malware database?

Your website www.sheba.xyz is hosted on a shared system together with lots of others. This means that all use the same IP address, 166.62.28.88. Unfortunately, not all of the sites on this IP address play nice, which means that this IP address got reported as a cause of trouble.

Unfortunately it is not only Checkpoint which reports this site as bad, but several others too; see report from cymon. There in the timeline you can also see why the IP address got put on the blacklists; namely because it was used as a target of phishing and a distribution point for malware on several domains hosted at this IP address.

Which means that the best way to deal with the problem is to talk to your hosting provider so that the bad sites get removed. If this does not help, change your hosting provider to one which cares more (and maybe costs more).


Is it safe to use 2FA within a password manager relative to using a separate app for 2FA?

What kind of security risks would I have if I have both my passwords and 2FA within the same app?

What is your threat scenario?
It's convenient. On my laptop, both are available without any external devices. If I log on a website on a computer I don't own, I look up the password and OTP on my phone. The attacker in this scenario will get password, but not secret for 2FA - thus it thwarts many attacks in case of key loggers.
It also thwarts password leaks. If my password is leaked from another site, due to password re-use, 2FA will thwart attackers.
It obviously provides less security than a physical token, as malware on my computer may access the secret - something which is impossible with for instance a Yubikey.
Like so many other security features it's a trade-off between usability and security. It's better security, especially in some scenarios, than no 2FA, and it's weaker than a proper hardware token. It's more convenient than a hardware token, but less secure. It's cheaper than a hardware token, but also less secure...
I use both. For some sites, that would be inconvenient but not fatal to loose access to I use Bitwarden. For others, I carry a Yubikey. So in short - carry out a threat assessment. Who are you protecting against, and what attacks can they mount against you? There's no universal answer; it's a trade-off you have to make for your use case.


If both the username and password are intended to be kept secret by the user and endpoint, there is no need to separate the two. There would be no difference compared to just logging in with an access key (no username, just a long password).

The reason we think a "secret username" does not add to security is because it is an oxymoron. A username, by definition, is a non-secret piece of information not intended to be kept secret.

Again, if the username was intended to be secret as well, then it would be no different than being a 2nd password, and having 2 passwords is no different than having 1 password if both are meant to be secret.

2 passwords is not more protective than just 1. Either you will be keeping both passwords secret via the same means (ie. the same password manager) or you will be splitting up your methods for keeping them secret (ie. password manager AND sticky note), in which case, you can achieve the same security by splitting up your single password into two parts and storing them as separate pieces.


So basically what the requirement is saying is that you need to assign one primary function per server.

The server you've described sounds like it runs a few applications for production users to utilize. This would be classified as an "application" server. However, you've also mentioned that there are multiple applications on that server, some touch the CDE indirectly and others do not. While this server would be considered to have one primary role, it brings the controls of the applications that don't touch the CDE into consideration.

If it were me, I would move the applications that don't interact with the CDE off of that box and move them to a different server, in a different segment if possible. If you don't have a segmented network (which you should really, really do) then everything is in scope anyway, so this advice doesn't matter.


First of all, I wouldn't recommend using disk encryption tools for this particular purpose as they are optimized for (surprise) hard disk encryption:

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

It is possible that some implementations can adjust themselves for "simple" file encryption, I suggest to consult the appropriate documentation about this matter.

If you don't want to expose your decryption key in any way to the machine to be backed up (that sounds like a good design decision) an obvious solution is using hybrid crypto-systems. An obvious choice would be OpenSSL that is easily scriptable as described here:

http://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/


You are looking for the ISO/IEC 27034-1:2011. The target audience is:

The following audiences will benefit from ISO/IEC 27034 while carrying out their designated organizational roles:
a) managers;
b) provisioning and operation teams;
c) acquisition personnel;
d) suppliers; and
e) auditors

To understand what this norm is actually for, read the following quote:

The purpose of ISO/IEC 27034 is to assist organizations in integrating security seamlessly throughout the life cycle of their applications by:
a) providing concepts, principles, frameworks, components and processes;
b) providing process-oriented mechanisms for establishing security requirements, assessing security risks, assigning a Targeted Level of Trust and selecting corresponding security controls and verification measures;
c) providing guidelines for establishing acceptance criteria to organizations outsourcing the development or operation of applications, and for organizations purchasing from third-party applications;
d) providing process-oriented mechanisms for determining, generating and collecting the evidence needed to demonstrate that their applications can be used securely under a defined environment;
e) supporting the general concepts specified in ISO/IEC 27001 and assisting with the satisfactory implementation of information security based on a risk management approach; and
f) providing a framework that helps to implement the security controls specified in ISO/IEC 27002 and other standards.
ISO/IEC 27034:
a) applies to the underlying software of an application and to contributing factors that impact its security, such as data, technology, application development life cycle processes, supporting processes and actors; and
b) applies to all sizes and all types of organizations (e.g. commercial enterprises, government agencies, non-profit organizations) exposed to risks associated with applications.

But:

ISO/IEC 27034does not:
a) provide guidelines for physical and network security;
b) provide controls or measurements; or
c) provide secure coding specifications for any programming language.

All controls can be found in ISO/IEC 27002 and other standards. Read more towards that in ISO/IEC 27000 and 27001.
All quotes are taken from: ISO/IEC 27034-1:2011(en)
Information technology — Security techniques — Application security.


Understanding a TLS 1.3 0-RTT replay attack

You aren't missing that much. I think this cloudflare article near the end outlines possible attack vectors and scenarios quite nicely. Depending on the security of the networks and web apps, 0-RTT may not be responded to pending what kind of parameters or certain types of headers. If an attacker has already figured out how to insert himself and gain visibility to what he would want to replay on a vulnerable host, there are worse risks elsewhere to look out for first. Something like a 0-RTT replay that has parameters and an authenticated session cookie and a HTTP downgrade could be plausible. But in the pentester's world, that's alot of work.


What it takes for someone to enter your machine over a public wifi network?

The typical scenario is not to attack the machine directly but instead let the user retrieve the malware itself, i.e. send mails containing malware, make the user visit web sites containing malware (for example link in phishing mail, malvertisement, ...) or attack the user at the network level to inject malware into unprotected (i.e. HTTP not HTTPS) traffic.

Doing such man-in-the-middle attacks to inject malware is not hard for most public WiFi. And it is trivial if the attacker fully controls the access point, for example by simply setting up some trustworthy sounding WiFi (like "PublicWifi", "Telekom" ...) and let the victims gullibly connect to it.


Why don't web interfaces on consumer routers trigger untrusted certificate warnings?

The other answer is not completely right, hence I‘ll try and fix that.

There are two different types of web interfaces for routers:
The internal and the external web interface.

While the external should be disabled for many reasons, the internal one does not need https to be deployed: as you are accessing the router from your LAN (let‘s just assume, CRACK might be fixed some day and WiFi is considered secure again), a MITM can only operate locally, which is not a big threat in most consumer cases.

Yet, generally it would be desirable to have https on COTS routers. This poses significant problems. While the IP itself would not be a huge problem as the actual IP is only checked when accessing directly via IP (as the IP is taken to be the domain), there is another problem: most SOHO routers either have no DNS zone for the devices or they can be configured.

Even if all routers of one model were to be configured with a not-changeable local domain name like „routerxy.local“, .local is a domain no CA would ever create a certificate for. This is the point the other answers misses. It’s not the storage of the certificate and key that is the deal breaker (it is one as well though, but could be mitigated with an HSM), it is the local domain and how CAs work.

There would be a way to mitigate this problem as well:

Maker x can create routery.x.tld and obtain a certificate for that - and distribute that in the HSM of every box they ship. If this gets leaked (by a vulnerability in the HSM, for example - they are now in the hands of the potential attacker), you are in huge trouble all over again.

Additionally, most CAs might revoke the certificate when they see abuse like that (as the entity the certificate is for is not the one using it)

All in all: there are technical difficulties that hinder usability (we do not want certificate warnings on our COTS router) and there is little benefit from using TLS on a connection that is merely within the LAN.


Why is public free Wi-Fi available even though many people say it's dangerous?

The companies providing free WiFi are doing that usually for one reason: Profit. And that is usually done by

Make people stay at their place
Make their place attractive (for tech
users)
Create a modern image of themselves

And risk is not a big issue for the users as well as for the company, because the just are not aware.

And as the biggest risk is the access point itself (which is owned by the providing company) as it has the ability of a MitM, the company will perhaps not perceive it as a risk. (Because they trust themselves)

Organisations usually also overestimate their abilities. So there are also risks by poor configuration (e.g. network devices can communicate with each other; faulty encryption -> here even other users can interfere network packets).


Why is the code CVE-2010-5298 used for a vulnerability discovered in 2014?

It's because the vulnerability was actually first discovered in 2010 (even if it wasn't reported as a security issue back then, just as a bug), and rediscovered again in 2014 by Ted Unangst after heartbleed became the straw that broke the camel back, and this time correctly identified as an issue with security implications.

Original bug report : https://rt.openssl.org/Ticket/Display.html?id=2167&user=guest&pass=guest


Why would I use at-rest encryption over a DB's key-based encryption?

Transparent vs manual encryption

Transparent encryption can be easier and safer, because the provider is responsible for key management. To them this is just another operational duty, along with backups and monitoring and replication and so forth.

It is very easy to screw up key management- from picking bad keys to losing them to exposing them to failing to rotate them properly- just like it is easy to screw up other operational activities. And as with backups, if the keys are lost then the data is lost. Which problems does one want to spend one's time solving?

In terms of attack scenarios, there are many to consider- attackers could have the ability to passively monitor traffic on the network between the application and the database; could have the ability to read data from application or database file systems; could have access to physical disks; could have access to account credentials; could have a webshell operating in the application. Under most scenarios, transparent and manual encryption are equally vulnerable.

It is certainly possible for an attacker to have access to database credentials but not the application, so there is potentially some additional hurdle for them to overcome in the manual encryption case. But someone doing manual encryption has to have done a lot of things right, and a determined attacker with access to encrypted data has a lot of potential paths forward. The number of data breaches where data has reportedly been encrypted or hashed but then is later exposed is uncountable.
Query access and query logging

Query access to a database is not the same as administrative access, which is usually required to enable logging. However, when talking specifically about provider offerings, credentials for query access can perhaps also be used to configure some control panel from the provider, which would likely allow for enabling some sort of query logging.

But take a step back- in the common case, the impact of an attacker achieving access to the database, especially write access, does not change depending on whether data is encrypted or not. Taking a page from ransomware attacks, they could run their own "UPDATE $table SET $encrypted_column = aes_encrypt(encrypted_column, 'attacker-key');" and require the victim's decryption key, or just money, to return custody of the encrypted data.
Access to data outside of sql injection or the query engine

As above, there are many scenarios in which an attacker may be able to view what's in the database without going through the query engine. Someone may have visibility on the network. Someone may be able to see the data files the database is using. Someone may be able to get to the physical disks as they get rotated out of service. Someone may be able to get to backups. All of these things happen every day.

Recommendation: absent a requirement for encryption at rest and specific scenarios that have to be defended against and need special handling or consideration, just let the provider run the show.


As tempting as it may be to try to use tools to defend herself (i.e. using personal equipment) or to catch the rogue admin in the act (logging, file integrity monitoring, etc.) many organizations have policies prohibiting these activities.

Your friend should be careful not to compromise her own integrity in response to this individual's actions.  This is not a technology problem.  In fact, it's one of the rare situations where removing the threat (the rogue admin) is easier than trying to defend against it.  Most organizations should have a policy that protects employees from retaliation when they raise a concern.

My advice for your friend would be to formally report the concern to a manager, HR, etc.  A forensic investigation should quickly reveal what the admin has been doing and would likely result in him/her being fired.


Is it insecure to publish the private IP addresses of my devices?

If you are behind a NAT, which you assume in your question, it's not a problem to publish your private IP. Only devices in your private network can use your private IP to connect to your device.

If someone tries to connect to your private IP from outside your private network, he will reach someone else (or not even that), because there is no relation between your private and public IP.


You can't secure this. There's no way to ensure that your web app is on the other side of a connection. Even if you come up with (convoluted) methods of trying to checksum and sign your requests in the JavaScript, a user could simply use your JavaScript to sign their own requests.

You can probably secure this by changing the format of what you pass to the server from being free-form Python into something much better specified. For example, perhaps you pass an array of N numbers and N-1 operators. Your server would then validate (using a whitelist) that the numbers are numbers and the operators are in the allowed set of mathematical operators. If this passed, then you could reconstruct the Python code and execute it.

Another solution is to run the JavaScript on the server and have that data directly passed into the Python. In this case, you need to validate the input to the JavaScript in a manner similar to that described above.

Reference: OWASP Input Validation Cheat Sheet


What is the most secure way to set up web server user permissions?

Personally I like to activate HTTPs, turn on SElinux, and do something like this in the vhost file:

## Deny access based on HTTP method
if ($bad_method = 1) {
        return 444;
}

location = /robots.txt  { access_log off; log_not_found off; }
location = /favicon.ico { access_log off; log_not_found off; }
## Disable access to hidden files
location ~ /\.          { access_log off; log_not_found off; deny all; }
location ~ ~$           { access_log off; log_not_found off; deny all; }

Also trying to control buffer overflow attacks from the nginx.conf

 ## Start: Size Limits & Buffer Overflows ##
  client_body_buffer_size  1K;
  client_header_buffer_size 1k;
  client_max_body_size 1k;
  large_client_header_buffers 2 1k;
 ## END: Size Limits & Buffer Overflows ##

And then :

NginxHttpLimitZone module should be activated.
Restrict Outgoing Nginx Connections
Directory Restrictions (configure your CMS so that it is only able to read the files it needs; or whatever you need)

The list is long, and this is just a precaution.


Why should I need to sign in to a (school) wifi network every time?

Yes, I guess your login is not to the wireless network. The network is open, anyone can connect and probably to surf you have to validate against some captive portal by radius or whatever security mechanism.

So the answer is yes, it is because a security concern. And to know exactly why your login is not remembered we need to know all the details... what kind of login is, etc.

EDIT Probably after login you have a session cookie. That cookie has a life-time. Maybe is expiring after some hours. Is the most common option and probably what is happening to you on that network.

Regarding the kind of logins... There is a lot of web authentication methods (one time passwords, signatures, tokens, cookies, etc). Look at this.

Is not the same a basic HTTP RFC 2617 auth than other login for example and you can make a differentiation only watching it.

First picture is a basic HTTP RFC 2617 login and the second one is an standard form.


If you can update the version of PHP it's best to do so, but sometimes shared hostings have older versions of PHP like yours which do not support password_hash().
Phpass seems to suit well in this case.

phpass (pronounced "pH pass") is a portable public domain password hashing framework for use in PHP applications. It is meant to work with PHP 3 and above, and it has actually been tested with at least PHP 3.0.18 through 5.4.x so far. (PHP 3 support is likely to be dropped in next revision.)
The preferred (most secure) hashing method supported by phpass is the
OpenBSD-style Blowfish-based bcrypt, also supported with our public
domain crypt_blowfish package (for C applications), and known in PHP
as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based
hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to
MD5-based salted and variable iteration count password hashes
implemented in phpass itself (also referred to as portable hashes).

Note: if you happen to have PHP version >= 5.3.7 you can also use password_compat


Short answers:

Adding or revoking signing or encryption subkeys does not affect signatures on your public key.
Revoking a subkey or letting it expire will have the same effect of marking that subkey invalid for all users.

Longer answers:

Technically, your entire PGP key consists of subkeys, but the certification ("C") subkey is considered the backbone of your PGP identity and is often referred to as the "primary" key. When you give out your public key to others, it's the fingerprint of the "C" subkey that you pass around. The "C" subkey is used to cross-certify other keys -- either your own subkeys, or public keys belonging to others. If you add or revoke any signing ("S") or encryption ("E") subkeys, this will not affect the signatures on your "C" subkey, and therefore your cross-certification data is not impacted by subkey changes.

In general, PGP will only care whether a subkey is "valid" or "invalid". Expired or revoked keys will be equally treated as "invalid", and it's up to the UI to display the reason behind it ("expired" vs. "revoked"). Actively revoking subkeys requires that you republish your public key and convince your correspondents to apply the updates. There is no universally established mechanism for receiving timely key updates, so many users choose to create shorter-lived subkeys that will force their correspondents to refresh the entire key when the subkey expires ("passive nudge") instead of creating long-lived subkeys and then notifying everyone to fetch key updates in case of key revocation ("active nudge").


Bidirectional encrypted communication between two systems

all traffic is encrypted using RSA 4096 key pair

So you don't like performance?

  HMAC

Wait, HMAC — that requires a shared key. If you have a shared authentication key, why are you using RSA at all? Use a shared key for confidentiality as well.

  A time stamp

What if the clocks diverge?

  Because of this, full-fledged TLS is not needed, RSA is sufficient.

You've got it backwards. What, in your scenario, requires using a non-standard protocol? A non-standard protocol means:

More bugs because it hasn't had as much review by experts.
More bugs because you had to write custom code instead of using well-tested, maintained libraries.

Note that I haven't reviewed your protocol, 1. because you didn't tell us what your protocol is, and 2. because reviewing a protocol is rather more work than expected in a Stack Exchange answer. But just spending one minute with the things you mentioned raises several red-orange flags.

Use TLS with a pre-shared key unless you have a good reason to do otherwise. One good reason not to use TLS is if you want to exchange individual messages rather than maintain a session. In this case, the round trips necessary for TLS are a waste, and you should probably use DTLS instead.


Could my computer be infiltrated if someone knows my external IP?

Your external IP isn't technically your machine's external IP, it's your router's external IP. So your machine wouldn't directly be the target of any attack: your machine doesn't have an external IP.

Instead, attacks would be targeted at your router. The success on that front depends on your router. Some are quite secure, some are known to be horribly broken. Search for your router's product name online to see what people have to say about it.

If your router can be broken, then the attacker could use it as a stepping-stone to get to your computer and all other computers on the network.

Another possible vector is forwarded ports. If your router is configured to forward traffic on a specific port to your computer (either manually configured by you or automatically configured through UPnP), then any attacks that use that specific port will be forwarded to your computer as well. If your computer is running a vulnerable service on that port, then that could prove problematic for you.