Algorithm used in grid card authentication

Grid authentication isn't standardised in the same way that TOTP/HOTP is: you can find grids which contain anything from 9 spaces ("keypad" style) to 260+ spaces (Lastpass style), and which require anything from a single character to a whole string formed from some kind of pattern. As a result, it's impossible to give a general answer to the question.

However, the security of these systems doesn't come from the specific position of requested characters, but from the fact that the requested characters should be known only to the grid holder. From an attacker point of view, there is no difference between a system which asks for characters found in spaces A1, B1 and C1 and one which randomly selects from the whole grid, unless they only have part of the grid, or some way of verifying specific characters (whether individually, or as a set).

In all following, the attacker is assumed to know the account details other than the grid contents - remember that grids are usually a second factor, so the attacker first needs to get the password

To give an example, if you have a 5x5 grid containing 25 digits, which were generated randomly and independently (e.g. the presence of a specific digit in one space doesn't have any impact on the contents of other spaces), the chances of guessing the value of any single space is 1 in 10. If you prompt for a single value, request the same value if it's incorrect, and allow 10 guesses before locking an account out, an attacker will always be able to get into the system, unless they're daft enough to try the same digit multiple times. If you prompt for 2 values (again, asking for the same pair if either or both is incorrect, and giving no indication of which is incorrect), the attacker has a 1 in 100 chance of getting the right pair. They might get in given 10 attempts, and have a pretty good chance of getting in given 50 attempts (50%, clearly!).

This is the same no matter how you select the values to ask for, as long as you always pick distinct values - if you use a method where you can ask for "A1" and "A1", the security drops to whatever the security of asking for a single value is in those cases.

If the grid isn't random, though, you can end up with problems. For example, if you generated it by permuting the digits 0-9 into columns labelled A-J and then provide 5 rows, labelled 1-5, you'll have 50 values. If you ask for A1 and B2, you've got a 1 in 100 chance of getting them both right. If you ask for A1 and J1, though, you've reduced the search space. If A1 is 0, J1 isn't - there are only 9 possibilities. The attacker has a 1 in 90 chance of getting the right pair in this configuration. In this case, you'd actually be slightly better off with a less random selection for the requested grid positions...

If an attacker has partial knowledge, however, you clearly want to make it difficult for them to use that knowledge. A system which always requests A1 and B2 doesn't help an attacker with no knowledge much, but falls to an attacker who knows only the contents of A1 and B2, even if the grid is perfectly generated. Therefore, you ideally want to make the values requested for distinct login attempts different (e.g. when someone logs in successfully, the next login attempt should ask for different values). It doesn't matter much how they are different, if the grid is truly random: moving from A1, B2 to A2, B3 would stop an attacker who only knows A1 and B2, after all. However, you then need to think about whether you are providing information which might allow them to log in at some point in the future. For a 5x5 grid, the incremental approach, wrapping at line ends, will mean that the 1st and 26th logins will require the same values to be provided. If you just put all the possible grid positions in an array and randomly shuffled them, you've not got that problem, and you've avoided the same grid position coming up twice.

It would be preferable for any given combination of values to never be requested again. However, this puts an upper bound on the life of the grid - you can only have as many requests as there are combinations of grid coordinates. For one value, that's the number of values in the grid. For 2 values, that's the square of the number of values in the grid. For n values, it's (number of values in grid)^n. You can increase this even more if you care about order, as well as specific values. In order to prevent repetition, you'll need to monitor which combinations have been used already, in some way, and, ideally, avoid any link between requested combinations. If you want to protect against an attacker who has been monitoring data, it's bad if they can intercept A1,B2 and C1,D2, then they get B1,C1 as the next request, predictably. That combination might come up naturally (that's random for you), but that's always a potential flaw here - in theory, you could get two TOTP values in a row which are the same, but it's unlikely. Specific grid authentication methods take steps to avoid repetitions, but again, it's not a single method - it depends on the other properties of the grid system being used.

TLDR: there isn't a single method, but it doesn't really matter, since the selection process for the position shouldn't make as much difference to the security as the contents of the grid itself.


How do I report a security vulnerability about a trusted certificate authority?

It sounds like your issue is that this vulnerability is bigger than you know what to do with.

The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue certificates, publish security bulletins, etc, before you go public with your findings. The intention is that at the end of the negotiated period you get your public recognition, but your going public can't do any more harm - if the vendor has done their job properly.

If figuring out how to contact them / negotiate a Responsible Disclosure period, go public with your results at the end, etc, is too big for you, or you don't know how to get started, then I suggest contacting and partnering with a well-known security researcher who already has established publication channels. Find a big name who has already published similar vulnerabilities and call them up! It sounds like you won't have any problem getting their attention.

Also congratulations! I look forward to seeing your name on a paper in 6 months!


Modify the hosts file of the router and redirect trafic

It depends a lot on the router. Most household/everyday routers don't have the capability to implement local DNS like you're referring to.
See here: https://superuser.com/questions/311877/why-do-most-routers-not-include-local-dns

If you want to do something client side, you could play around with network shortcuts that map to media servers and the like when you enter in the name of the shortcut in your web browser. Although this doesn't really make sense for large networks, at that point you should have a router that has this kind of functionality built-in already.

Also, this general sort of thing can be exploited in dns redirect attacks, which I feel like you may be alluding to. In the attack, a computer connected to something like a coffee shop wifi network can spoof the router and provide a fake dns/hosts file. This allows an attacker to redirect users, but remember that the attacker's machine is handling redirects, not the router. Not to mention most people use https and verify site security certificates to minimize risks like these.

And when you think about it, the world would be that much more scary if the average router could have its own hosts file. You could be on some coffee shop's WiFi and the sites you visit could be fake copies designed to steal your personal data. Sure, the store owners wouldn't do it, but someone could hack their fifteen year-old router and exploit the theoretical hosts file, or connect their own WiFi router to some unsuspecting company's LAN and cause all sorts of chaos.


Can wifi network administrators see if you are using a proxy?

If your friend is using a proxy, all the requests will look as requests towards the IP of the proxy. Depending on your friend's parents' knowledge of networks, they might find that as a suspicious behavior. In normal cases where the average parents don't know much about proxies, there should not be any problem.


Encrypted access tokens - expiration date

You could encrypt the userid:timestamp:hash, base64 it, and send it as a cookie. On every token validated, recalculate a new one with a new timestamp and send back.

Record every invalid token for a user, and invalidate every token coming for the same user and same IP address for a period. This complicates the life of anyone trying to bruteforce tokens.

You don't have to care too much about a user having more than one valid token, only that you are talking to the same user. If a user opens multiple tabs on your site, multiple valid tokens will happen.


How do I know a piece of software only does what the author claims?

You can know whether some software does only what it announces in the same way that you can know whether the food they serve you at restaurants is poisoned or not. In plain words, you cannot, but Society has come up with various schemes to cope with the issue:

You can listen to friends and critics to know if the food at a given restaurant has good reputation or not.
You can take a sample and send it to a lab which will look for many (but not all) known poisonous substances.
You can ask nicely if you may observe the cook while he prepares the dishes.
The cook has a vested business interest in his customer being happy with the food quality, and happiness includes, in particular, not being dead.
Society punishes poisoners with the utmost severity and it can usually be assumed that the cook knows it.
You always have the extreme option of not eating there if you are too worried.

All of these can be directly transposed into the world of software. Extreme methods of ascertaining software quality and adherence to its published behaviour include very expensive and boring things like Common Criteria which boil down to, basically, knowing who made the program and with what tools.

Alternative answer: every piece of software has bugs, so it is 100% guaranteed that it does not do exactly what it is supposed to do. (This assertion includes the software which runs in the dozen or so small computers which are embedded in your car, by the way.)


CERT recognizes this as a vulnerability in DNS.  As it stands there are about 27 million misconfigured (read: Default!) DNS servers that can be used in this attack.

Ideally you want to prevent these UDP packets from reaching their destination by filtering them at the edge router (which is your provider).  Unfortunately not many providers offer this service.  Cloudflare  uses this method to help mitigate this attack.

Another method is using GEO IP based load balancing.  This is the magic behind many CDNs in that,  DNS resolves the server closest to you.  In a DoS attack this helps distribute the load,  and isolate outages to a specific region(s).  There is also some elegance in using DNS to help prevent DNS amplification attacks.

Eventually the servers used for DNS amplification will be configured properly.  But this solution is likely more than 10 years from coming into fruition.

For most people, using a service like cloudflare or akamai is the best solution.


I forgot my encryption password on my Z667T after several attempts, the phone reset itself

Contacts were likely backed up to an online service (Google, possibly others) and should still be available through that service. Just add your account on that service to the phone again, and tell it to sync contacts. If they were stored on the SIM card (does anybody do that anymore?) you could recover them from there, too.
SMS / MMS might (no promises!) also have been backed up to some service. For example, if you use Google Voice, I believe it backs them up. Some messaging apps will also provide backups, either to an account associated with the app or to Google Drive / Dropbox / whatever.
Anything that wasn't getting synced / backed up is gone forever, though. The encryption key is randomly generated when device encryption is enabled, and it is never stored in plain text anywhere readable (it might be stored in encrypted form, where the key-encrypting-key is derived from your passcode, or it might be stored in a hardware security module, or both). When the phone detected what it thought was an attempt to brute-force the passcode, it will have deleted that encryption key. In theory, sufficiently-advanced data-recovery tools might (depending on where it was stored and how it was erased) be able to recover the encrypted key, but the automatic wipe should be secure against any practical recovery.


Is it safe to publish something encrypted with a password if you make it insanely difficult to crack?

The reason for key strengthening is that passwords don't have as much entropy as is expected for the key. The time it takes to break a key is proportional to the number of possible keys. Strengthening algorithms used on passwords compensate for the poor entropy by increasing the proportionality constant. But the gap is so large that strengthening cannot compensate. A password with 64 bits of entropy is very hard to memorize — that's 10 random printable ASCII characters (if you start imposing memorable features, the entropy goes way down) or 14 random lowercase letters, but to reach 128 bits of “cracking difficulty”, which corresponds to the most common key size for symmetric encryption, you'd need a whooping 2^64 — about a century of CPU time.

In your scenario, a memorable password is the wrong method. It would be a password that you rarely use, yet needs to be very strong and thus hard to memorize.

Use a random key, instead of a password-derived key, and print it out. Store the printout in a secure place.

If the software you use requires a password, generate a random password with as much entropy as the key. 20 ASCII printable characters, or 28 random lowercase letters, or something equivalent, give you 128 bits of entropy. If technology progresses to the point that this is breakable, the key you're encrypting will probably not be secure anymore anyway. Since your password has enough entropy for a key, you don't need to strengthen it. Once again, print it out.

Once you go that route, you might as well print out the original key and forget about uploading it. But adding a level of indirection does have advantages. It means that an adversary needs to obtain both a copy of the encrypted key and a copy of the key encryption key. With this separation, if one of the parts is compromised, you may have time to act before the second one is also compromised. You can also store the key encryption key in several separate pieces. There are secret sharing algorithms that allow splitting a key in n pieces such that it can be recovered from any k pieces, but no fewer. If you want to keep things simple, you can generate multiple key encryption keys, upload the master key encrypted with each of these, and split the key encryption keys and dispatch the pieces so that it takes more than a single place to recover the whole thing.


The help for the "anti hacking" feature you show only describes some trivial attacks which are no problem for most modern systems anyway or, in the case of SYN flood, at most make the system very slow (i.e. denial of service). This feature in no way protects against the most common attacks against clients today, i.e. malware, ransomware, banking trojans etc delivered through phishing mails, malicious ads or malicious or hacked web sites.
In other words: it is more marketing than useful.


You have a unique requirement. But your basis may be off.

I'll use an incident I ran into this week as an example. I discovered an attack from 50 IP addresses from a block of IPs managed by a hosting company in Hong Kong. It would make sense, then, to block all IPs from this hosting company, at least temporarily. I believe this is similar to the scenario that you have in mind.

To accomplish this, you would have to run a whois on the IPs, link them to a common holder, and populate your list with the block of IPs. Programatically, this is trivial if the use case is as I defined.

But what if the owner of the IP block is AWS? Do you block all of AWS? For some sites, this might be a valid thing to do. Then what if the attacker detects the block (it's a common feature in botnets) and they switch to another hosting site; do you add this new block to the list? Project this process into the future where now you are blocking all major hosting providers and even a few ISPs (if the botnets switched to personal computers and your script added Comcast IP blocks). You have now DoS'ed your own service.

The problem, then, is not the process of adding IP blocks, but the problem is not adding too much.

The typical way security pros address this problem is to block each IP individually. Fail2ban is a common utility to do this.

Or, if you know that certain countries are not normally using your service, then you can use geo-IP databases and only allow (or block) certain countries.


Having problems with performing a JWT "none" algorithm attack

You have a typo in your header:

header = '{"alg":"none"","typ":"JWT"}'

none has two quotes at the end.


How does Algolia's virtual API keys work?

I think the trick here is that your application is referred to a small count of keys, therefore the server will quickly iterate over all keys, also server may store some cache of such computations, because random nonce is not used in the algorithm.

Let's see the way to initialize the Algolia search client:

client = SearchClient.create('YourApplicationID', 'YourAPIKey')

Their algorithm to generate a "secured API key" from the "parent key" is the following:

securedApiKey = BASE64(HMAC[parentApiKey + query params] + query params)

Note, that query params are concatenated to HMAC value as a plaintext. So the algorithm on the server side most probably looks like this:

Step 1: Select keys of 'YourApplicationID' only as "parent keys".
Step 2: retrieve HMAC and query parameters from BASE64 of securedApiKey.
Step 3: HMAC(adminApiKey, query params) == secureApiKey's HMAC?
Step 4: HMAC(searchApiKey, query params) == secureApiKey's HMAC?
Step 5: Try another key.
Step 6: Select the proper key, or else - error.

Once the proper parent key is found, HMAC is calculated, this information could be stored, so the next request is narrowed down to a memcmp instead of HMAC * count of keys.

I don't see another way to correlate different keys in this scheme. Please, correct me, if I'm missing something.


How do I release a self made program without it being tracked back to me?

This is an interesting question because it is almost entirely nontechnical. One presumes from your question that you are releasing something that would offend more than one national government.

Digital Opsec

Compartmentation: Only work on it using resources that are not associated to you. One cross-contamination will burn you (that is how DPR was sent up -- he once used his Silk Road laptop from home and once posted with a reference only DPR would know about Silk Road under his own name). This means a laptop only for this program that has the battery removed when you are within 200 meters of your home
When you compile it, run the compiled binary through "strings". If you see anything that is a word you use, determine if it can be removed
Use variable names, subroutine names, object class names that are consistent with another lexicon. Careto was attributed to the Spanish because the analyzed binary had names in Spanish, one of which was the word careto, meaning an ugly mask
Strip the executable and any libraries before packaging it

Offline Opsec

Compartmentation: As The Offspring said, http://youtu.be/G2gTFBhQ7Ko. That means EVERYTHING: cell phones, cell phone service (personal is Sprint, program is Ma Bell), laptops, usernames, passwords, email addresses, email hosting providers (personal is gmail, then program is hotmail), EVERYTHING

If it is used for the program, it is never used for your purposes
If it is used for your purposes, it is never used for the program
If you check your Facebook once from your laptop for the program, you have been made

BTW, members of APT1 used a hijacked machine to Twitter, to get around the Great Firewall of China, and that is how they were made
cf DPR above

Resources used for the development and maintenance of the program, the support of the program and the communication about the program should be owned by the non-natural person (see below) and should never be used for anything else (see compartmentation, above)
Plausible deniability: when something is going on with your program, be doing something else, have an alibi every time
Be blase and naive about the existence and function of your program. "Oh, did someone make that? Not sure why they would. It sounds interesting. Tell me about".
Create a legal fiction (read "corporation") to own your program, and do not have any ties to it. Some jurisdictions are friendlier to anonymous non-natural persons (a legal term for a corporation or trust). http://www.npr.org/blogs/money/2012/07/27/157421340/how-to-set-up-an-offshore-company.
Understand the difference between anonymity and pseudonymity
Keep the development of the program, the person who owns the intellectual property of the program, the assets of that entity (bank account, tax-filings, patents), and the servers that are used to sell / distribute it in different jurisdictions. This would mean that to discover the full extent of the involvement, your adversary would have to get cooperation and collaboration with authorities in more countries

Corporation in Belize, taxes filed as a Belizian corporation operating internationally
Software development in Canada
Bank account in Dominican Republic
Assignment of intellectual property to an Irish subsidiary of the corporation
Web servers in multiple countries

Have a plan in-place for when you are made. There is no such thing as a fool-proof plan


What is the purpose of time-dependent form input names?

Your example is a banking app.  Many banks are facing trouble with "scraping" tools which collect information from the bank.  Basically, the banks are so far behind on APIs for accessing our information that customers are choosing to give out their usernames and passwords to third party sites which then go scrape their financials and present them in a usable format (such as a CSV file).

Several banks have made the decision that this is a problem, and rather than build the API's, they're just trying to make it harder for scrapers to do their job.  Dynamic fields like this are one tool they can leverage.  Others have some token encoded into javascript which must be decoded and passed along.  The idea is that if they can make it difficult enough for a 3d party to scrape your data, you'll stop giving out your password to make up for their failure to provide the services their customers are asking for.


No, all of that is pointless. An attacker could reverse engineer your program and nullify all of your security checks, even with all of the efforts you described. Any code or data that you don't want the user to have 100% full control over needs to live on a server, period.


Are sqlcmd parameters inherently at risk of SQL injection?

If the attacker controls SQLCMD inputs, then they can do anything their login credentials (authorized or stolen) can do.  That's just normal functioning.

Don't do this.  This is a bad practice if there's any input from the outside going into your SQLCMD.

If you insist on this, then if you want to use SQLCMD with parameter substitution from environment variables (perhaps), you probably want to experiment with credentials that can only EXECUTE within a certain, limited schema

CREATE SCHEMA FromSqlCmd AUTHORIZATION myuser

GRANT EXECUTE ON SCHEMA::[FromSqlCmd] TO [myschema_execute];

Within each stored procedure, NEVER concatenate what's passed in to dynamic SQL.

NEVER put the results into a table without a whitelist; otherwise you're opening yourself up for second order sql injection.

If you're consider Powershell, then cjsommer.com has an article about this - he found that neither powershell SQLPS command protected against injection, even with parameters.

It's worse than that

If you actually let input - validated or not - from others be part of your command line for SQLCMD, then you're opening yourself up for command line injection!!!  The & character is one way for a command prompt to run multiple commands; try it with

C: & cd \ & format /? & del /?

Now imagine this in the middle of your sqlcmd.

Also note that Powershell uses ; to separate commands.


how do you find all upd connections a remote server has?

Just by having the IP of a server it is not possible to find out which connections the server has to other systems. To get this information one either need to have access to the server itself or to some system which is in the path of the traffic and the ability to capture traffic there, have a look at the firewall states or similar.


No, this is not a security vulnerability.

HMAC requires a key of the underlying hash algorithm's block size. In general, you should provide a key which is of the underlying hash algorithm's block size.

If you forget to provide a key of this size, then there are two options. The first option is that HMAC fails hard and fast, informing you that your key is of the wrong size. The second option is that HMAC simply assumes that you meant to provide a key of the right size, but that you just left off all the trailing zero bytes by accident that were supposed to be there.

The second option above accords with the policy of being liberal in the inputs one will accept but being strict in the outputs one will generate.

So HMAC is not losing information with the second option, because a key of a smaller size is not a valid key. There is simply a policy of taking invalid keys and somehow making them valid for your convenience in a deterministic, documented way.


Data integrity of malicious content in the database

Since injection attacks exploit control sequences in the way the output is interpreted, and since different output formats use different control sequences (think JavaScript versus SQL versus HTML), your sanitization technique needs to reflect where the output is going. If you sanitize for output upon input, you're making an assumption about where that output is going to be sent, which may prove to be incorrect, perhaps due to some future change or some usage case you didn't think fo.

Therefore, as a rule I would suggest sanitizing on output to reflect the specific injection sensitivity for the format you're outputting in.

Note that if you're storing pre-formatted input and the context of the formatting is not available upon output (such as storing HTML for a blog post), you may do some checks upon input, but this is a slightly different scenario than just general escaping.

So again, as a rule escape your output rather than your input, but make exceptions as necessary with the understanding that those exceptions need to be watched with extra scrutiny as you're creating a hole in your app that you need to carefully guard.


Let's get this out of the way first: DRM is not a solvable problem.

Simply loading the flash player into a reverse engineering tool and reading the code will reveal what you did, and since you're giving them the key they can just decrypt the video. It's something anyone familiar with Flash reverse engineering could do, and it's probably something you could pick up from Google if you've got a background in general code and security concepts.

If you're looking for something more solid, you could look into solutions which use HDCP, which essentially provides end-to-end encryption of content up to the actual display device (e.g. a computer monitor). However, this may limit your userbase, as the HDCP feature was designed primarily for use in devices like BluRay players where TVs are known to support HDCP, rather than cases like computer monitors which may not (though many do).

All in all, you just have to decide how much effort you want to put in as a deterrant. If someone wants your video, they can capture it just fine using a screen capture application (e.g. Fraps) or exploit the analog hole.


Store PCI DSS data in an encrypted form in non PCI DSS scope

Using that external storage effectively brings it within PCI scope, however you are correct:

If you have strong encryption sufficient to protect the data, and can evidence that, storing it on an archive should be allowed.

Don't try and word it as outside PCI scope though - account for it in the usual way when speaking with your QSA, and include the info you have presented here.


Is "non-repudiation" automatically proven, given the other three tenets of info security?

One simple protocol that can be verified by a certain target user but not by third party:

Use a Diffe-Hellman keyexchange on your key and the receivers key
Use the shared key to encrypt a message and add a MAC

This protocol offers the first three properties, but not the fourth. So the answer is NO.

Everybody who knows the shared secret can forge the MAC. But since by default only the sender and the recipient know it, the message is still authenticated as coming from that sender as far as the legitimate reception is concerned.

But the reception can't prove who sent the message, so the scheme doesn't provide non-repudiation.

A popular protocol that is signs its data, providing (technical) non-repudiation are GPG encrypted emails, a popular protocol that only uses MACs for the user data is TLS. Some protocols like OTR go out of their way to increase deniability as much as possible(e.g. by leaking obsolete MAC keys) while still providing the first three properties to the two legitimate users.


Multiple wp-login.php attack on shared hosting

Although you don't provide this level of detail in your question I'll assume that the WordPress sites you host are publicly accessible and that they either have their own domain name or that they are linked from somewhere else. What you might see then is not that an attacker specifically attacking your IP address, but an attacker addressing lots of publicly known sites. Only you have a limited view into this attack, i.e. you only see the attacks targeted at your specific IP address and thus assume that you are the main target of this attack.

Of course, there might be other ways the attacker might specifically address all sites on your IP address, like having access to backups of your server configuration, to passive DNS data or by using services like domaintools. In general these information are not secret so they cannot be relied on to protect sites.


There is typically no reason for programs not to interact when the programs offer some sort of API - in the case of the linked product, it answers your

  how?

In the readme:

  It uses, with the only exception of ClamAV, the command line AV
  scanners and extracts the malware names from the output of the command
  line tools (for ClamAV it uses the https://code.google.com/p/pyclamd/
  extension).

As you asked for an actual example: let’s say a anti virus solution has a CLI that works like this:

av file returns either ok or bad.

A program can now call av file, for example via a system call and read the output of that CLI, then decide with a string matching on ok or bad to decide what to present to the user for this particular file for this anti virus.

This can be repeated for as much CLIs as supported.

As to the licensing: of course the supported AV solutions must be present and functional on the machine, leaving this to the user.

In an attempt to make this on-topic, I will highlight why it is useful to use different AV products on files.

As some examples on virus total show, individual anti virus solutions have vastly different results in identifying malicious files.

This for example comes from:

different paces and update cycles of different vendors due to different office hours and analysis priorities
different approaches to heuristics and sandboxing.
different niches, one might find windows malware, one might find Mac malware.


Reason to ban digits as first character in passwords?

Is it possible that you're over thinking it and they are just trying to weed out a lot of common easy-to-guess passwords?


attacked by a virus on my system. keyboard not working properly

I would take those steps:

1)Login on safe-mode.

2)Scan computer with "Malwarebytes".

3)Try Scan with other Anti-viruses.

If neither of that won't work try backing-up your drives and format your computer...


Logging and FIM must be enabled on all systems within the in-scope network segments. If you've a call centre, this will mean at least the users' desktops as well as the servers supporting the infrastructure. Ideally, your customer service agents won't have administrative profiles on their systems so the number of logs you'll receive related to privilege escalation will be limited.

While Splunk agents will gather and ship logs for central analysis, it's not really a File Integrity Monitoring solution. You could use software like OSSEC or Wazuh or implement similar functionality using Microsoft's AppLocker which would allow you whitelist applications and monitor changes.


Should I ask a user to re-authenticate if the browser thumbprint changes?  Is a server side library available?

Many things on which the thumbprint is defined may change quite often. For instance, the list of supported fonts. Also, some browsers implement transparent updates; Chrome is notorious for that: some updates can be even applied without requiring the user to restart his Web browser. Any such update can change the thumbprint.

As a user of a "secure" site (i.e. a site where there is an obvious need for security, such as online banking), any such apparently spurious "security reset" would make me nervous and jumpy. I do not think making your user nervous is a good thing; also, this would train them to reenter their credentials at random moments, which is bound to make them careless and vulnerable to phishing.

Therefore I advise not to deactivate a session because of a thumbprint change. Anyway, if an attacker can steal a session, he can probably mimic the thumbprint as well, so the envisioned security feature would catch only non-attackers, which is of questionable overall efficiency.


Online backup : how could encryption and de-duplication be compatible?

I haven't thought through the details, but if a secure hash of the file content were used as the key then any (and only) clients who "knew the hash" would be able to access the content.

Essentially the cloud storage would act as a collective partial (very sparse, in fact) rainbow table for the hashing function, allowing it to be "reversed".

From the article: "Even if the RIAA and MPAA came knocking on Bitcasa’s doors, subpoenas in hand, all Bitcasa would have is a collection of encrypted bits with no means to decrypt them." -- true because bitcasa don't hold the objectid/filename-to-hash/key mapping; only their clients do (client-side). If the RIAA/MPAA knew the hashes of the files in question (well known for e.g. specific song MP3s) they'd be able to decrypt and prove you had a copy, but first they'd need to know which cloud-storage object/file held which song.

Clients would need to keep the hash for each cloud-stored object, and their local name for it, of course, to be able to access and unencrypt it.

Regarding some of the other features claimed in the article:

"compression" -- wouldn't work server-side (the encrypted content will not compress well) but could be applied client-side before encryption
"accessible anywhere" -- if the objid-to-filename-and-hash/key mapping is only on the client then the files are useless from other devices, which limits the usefulness of cloud storage. Could be solved by e.g. also storing the collection of objid-to-filename-and-hash/key tuples, client-side encrypted with a passphrase.
"patented de-duplication algorithms" -- there must be more going on than the above to justify a patent -- possibly de-duplication at a block, rather than file level?
the RIAA/MPAA would be able to come with a subpoena and an encrypted-with-its-own-hash copy of whatever song/movie they suspect people have copies of. Bitcasa would then be able to confirm whether or not that file had been stored or not. They wouldn't be able to decrypt it (without RIAA/MPAA giving them the hash/key), and (particularly if they aren't enforcing per-user quotas becausrer they offer "infinite storage") they might not have retained logs of which users uploaded/downloaded it. However, I suspect they could be required to remove the file (under DMCA safe harbour rules) or possibly to retain the content but then log any accounts which upload/download it in the future.


IMEI and phone number given to unknown sources. What are the risks?

Firstly and most likely, the phone number may be sold to lists that are bought for spamming, spoofing, phishing schemes, etc. There are quite a few 'bad' consequences to having your phone number leaked but none that are particularly nefarious (although attackers can try to infect your phone via an sms'd link).

In regards to the IMEI, this is just a device ID and really doesnt mean much if you are trying to 'clone' someones phone (instead you need the IMSI number for that). The article you linked to says:

  Picture this scenario: You post your IMEI number on a website looking
  for an unlock code. Several months go by and you get a phone bill for
  $3,000 and details of calls that you've never made. Someone has cloned
  your phone and has been using your account, unknowingly to you.

That's not entirely accurate because it leaves out how the attacker actually clones a device. To clone a device, one must identify the device to clone. On a GSM devices, this is done by copying the SIM card and obtaining the IMEI number. The SIM card contains the IMSI number and together with the IMEI number, the attacker must listen and decode a the transmission key also known as the 'KI'. Once all of that is completed, you then could have a cloned device (well you still need to put it on a modified phone but that's a different story).

Bottom line, I would be far more concerned about my phone number being leaked as a privacy concern than my IMEI being leaked.

Also bear in mind that IMEI numbers change with each phone and that changes quite often for many people. If you are really concerned, change phones and get a new phone number.


Modify Certificate Subject using OpenSSL x509 Command

My example:

Generate a self-signed certificate (and private key)

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -sha256 -keyout mydomain_rsa.PEM.key -out mydomain.PEM.csr -subj "/C=CN/O=Company Inc."
   Generating a 2048 bit RSA private key
   ..........................+++
   ........+++
   writing new private key to 'mydomain_rsa.PEM.key'
   -----

View the subject

$ openssl x509 -noout -serial -subject -in mydomain.PEM.csr
  serial=CCC8F2F4B4BEDBAC
  subject= /C=CN/O=Company Inc.

Modify the subject

openssl req -x509 -in mydomain.PEM.csr -subj '/O=Company2 Inc.' -key mydomain_rsa.PEM.key -out new_mydomain.PEM.csr

View the subject of the new certificate

$ openssl x509 -noout -serial -subject -in new_mydomain.PEM.csr
  serial=A873BD71BCD0DFF7
  subject= /O=Company2 Inc


Forgot OpenPGP key's passphrase, can I recover key or files somehow?

The short version

You won't be able to decrypt the files unless you can either brute-force the passphrase, or some future changes to the subject enable you to do so (new cryptographic findings on exploiting the used cryptography, more computing power, likely a combination of both).

The longer explanation

The private key is encrypted with the passphrase. The passphrase protection is to meant to be and implemented as an actual protection -- without the passphrase, you will not be able to decrypt and use the private key. The same applies to the encrypted files.

Without the passphrase, you're in the position of an arbitrary attacker getting hold of the encrypted copy of the key and the encrypted files. To access the files, you have following chances:

Brute-forcing generally requires vast computational power. You could brute-forcee

the passphrase (for a reasonable passphrase, this will be out of scope, especially for a home user without access to a whole data center) -- but might be a thing to try if you know parts of the passphrase and can somehow prune the space of possible passphrases
the private key (for RSA 1024 and larger out of scope for the time, might change in future if computing power heavily increases)
the session key of each file (considering the computational effort, even worse)

Exploiting cryptographic weaknesses that might arise in the future.


Main Reasons for GPG over hashing for verification

As you have identified, hashing does not verify who created the data, but GPG signing does. You are also correct that an attacker could also put their own GPG keys next to the compromised download, and it would be no good to verify the download.
However, you would be protected in the following scenarios:

The key fingerprint can be confirmed somewhere else; perhaps on a different website or using an out-of-band method.
You previously had downloaded the correct GPG key and use it to verify.

In either scenario, you'd have the correct key, and the attacker's signature would not match, tipping you off to the potential compromise.
The key's signatures could also be examined. Perhaps you know the real keys are also signed by sponsor companies A and B. In this case, you could obtain company A and B's keys and verify that correct signatures exist. Since those companies may be separate entities, it is very unlikely that all keys were compromised simultaneously.


Is it possible to disable all PHP functions not used in my application?

To hook into @UTF-8's comment, using PHP_Parser, you can fairly easily generate a list of default PHP functions not actually used by your application which you can then store in the disabled_functions configuration option:

<?php

require 'vendor/autoload.php';

use PhpParser\Node;
use PhpParser\NodeTraverser;
use PhpParser\ParserFactory;
use PhpParser\NodeVisitorAbstract;
use PhpParser\PrettyPrinter\Standard;
use PhpParser\Node\Stmt\Class_;
use PhpParser\Node\Stmt\Function_;

class Collector extends NodeVisitorAbstract
{
    public $functions = [];
    public function leaveNode(Node $node)
    {
        if ($node instanceof PhpParser\Node\Expr\FuncCall)
            $this->functions[] = (string) $node->name;
    }
}

$sourcePath = __DIR__ . '/test/';

$files = new \CallbackFilterIterator(
    new \RecursiveIteratorIterator(
        new \RecursiveDirectoryIterator($sourcePath),
            \RecursiveIteratorIterator::SELF_FIRST
    ),
    function($current, $key, $iterator) { return preg_match('~.php$~i', (string) $current) > 0; }
);

$nodeTraverser = new NodeTraverser();
$nodeTraverser->addVisitor($visitor = new Collector());
$parserFactory = new ParserFactory();
$parser        = $parserFactory->create(ParserFactory::PREFER_PHP7);

foreach ($files as $file)
{

    $stmts  = $parser->parse(file_get_contents((string) $file));
    $nodeTraverser->traverse($stmts);
}

$defined_functions = get_defined_functions();

$blocked_functions = array_diff($defined_functions['internal'], $visitor->functions);

echo 'disabled_functions = "', join(',', $blocked_functions), '"', PHP_EOL;

Something similar can be created for disable_classes, just look for PhpParser\Node\Expr\New_ instead.

Some things to consider:

Your first step should be to reduce the amount of modules your instance of PHP is loading.
It's going to be annoying to manage this.
You're going to have a bad time if you use anything dynamically.
Having a large disable_functions setting may have a performance impact. You may want to consider using Suhosin's whitelist functionality as suggested by https://security.stackexchange.com/a/122471/242.


Can shellshock be used on a system with public webpages but restricted server access?

To answer your question:
1. There is no SHELLSHOCK threat as long you and your co-developers are aware what environment variable you are putting in or modifying (if any).

By enabling executables, do you mean you call system binary via shell? If your Python or PHP is running via mod_cgi, there is vulnerability even if you don't use GET or POST data. To my knowledge, mod_python, mod_php is not compromised to the threat.
Exposing public page opens the same vulnerability as mentioned in point 2 as long as they run via mod_cgi.


You don't punish the hacker. The law does. Just report whatever pieces of information you have to the police and let them handle it.

However, it is very unlikely that the attacker will be caught. The IP address you posses most likely belongs to another system that the attacker has compromised and is using as a proxy. Just treat it as a lesson learnt and move on.


User input is a string. Escaping is done when you want to insert some characters into some HTML / SQL / Whatever code which insists on interpreting some characters into special functionalities. For instance, you have a '<' and you want it to be shown back to the user as a '<', but if you brutally paste the string inside the HTML then the Web browser on the client side will look at the '<' and think that it begins some HTML tag, instead of representing a simple '<'.

In general, you want to keep strings as strings, and delegate any encoding or escaping to specialized functions which do that well. For instance, for SQL, you use prepared statements. With HTML from a PHP context, you would use htmlspecialchars().

The point to notice here is that the kind of conversion, encoding or escaping that you need to perform depends on what you are trying to do with the string. If you need the string to put it in some HTML then you'll use HTML entities (the &lt; for '<' and so on). If you store in the database the already escaped string, then you are betting that you will use the string only by including it in some HTML.

So you should strive to apply encoding/escaping only upon usage. It is more flexible and makes semantics simpler. Within your database, store the string as a string.


Is my Java code still vulnerable to SQL injection?

Yes, your filtering on userinput2 is insufficient, the use of a single quote is not necessary for exploitation with that syntax. I didn't analyse the code any further. "Blacklisting" characters is not a reliable defense against SQL injection. You should alter the code to use parameterized queries instead.


If a Windows laptop with an encrypted hard disk is stolen, can the contents be accessed by a professional hacker?

The answer to your question is that it depends on a number of factors.

What disk encryption product is in use?  Does it make use of full disk encryption, or does it just encrypt parts of the disk (e.g. the users home directory)
Are there any known vulnerabilities in the disk encryption product in use?
What strength of password was used by the user of the stolen machine?
Did the user do anything very daft, like having the password on a bit of paper in their bag.
Does the disk encryption product allow for effectively offline attacks, or can it enforce a lockout policy such that only a limited number of guesses are allowed before the data is destroyed?
How determined and well funded are the attackers?  In the case of government level attackers they may have a means of bypassing/backdooring the software.

So ultimately it depends.  In the general case an unsophisticated attacker getting access to a full-disk encrypted drive protected with a strong password that he doesn't have, probably won't be able to compromise it, but there's a lot of variables at play.

Edit : per the comments below the list above isn't exhaustive, but hopefully provides an idea of some of the potential variables at play.


How to prevent user's mobile phone position tracked

Your question presents a number of interesting issues. I hope you are asking this question out of general concern for your privacy and not for an illegal purpose.

First and foremost, what countermeasures (if any) you would use depend on your security requirements. Your level of paranoia/fear will vary according to whether you are seeking to avoid detection for activities that are merely embarassing (i.e. cheating on your spouse), or mildly criminal (you sell bags of weed to your classmates) or very criminal (you are a member of the Mexican drug cartel). An adversary in a civil lawsuit might be able to subpoena your cell tower records; it would be trivial for a government agency such as the DEA or NSA to get these records if you were of interest to them.

Phones that connect to the cell phone network must connect through a cell site, and the location of the site is recorded and correlated with the serial number of the phone. Many phones can be used without connecting to the cell phone network by using only public wi-fi connections. Telephony apps exist for phones having only wi-fi connections. However, your phone might generate and transmit GPS coordinates (attached to Tweets or Facebook posts) and the phone's location would be somewhat trackable by IP address.

The DEA and NSA are known to be able to detect the use of a newly acquired "burner" phone by correlating metadata among the people you regularly contact. If you are in contact with the same phone numbers as with your old phone, for example your fellow gang members or dope dealers, it is trivial for a law enforcement or intelligence agency to discover your new phone. A CIA official recently gave a presentation in which he stated that phones can be tracked if turned off provided the battery is still attached; and that some phones having kinetic input can be tracked according to the user's gait as she walks down the street!

The key question here is whether it would be worth your while, or that of your associates, to use unusual or "tinfoil hat" methods of attempting to mask your location or the phone's serial number. Unless you are doing something that is certain to attract serious law enforcement interest, and even if you are, you are probably better off not attempting to use methods such as using and repeatedly switching "burner" phones. You might well become more visible than if you did nothing.

Finally, don't forget that your movements can also be tracked through fixed and mobile license-plate recording cameras, and GPS-based vehicle systems such as OnStar. It sucks to be a criminal, or to value one's privacy, these days.

For legal advice consult a licensed attorney.


File upload vulnerability: rename solution?

You need to do a few more things:

Check the file size of the image and enforce a limit (prevent overflows from happening)
Along with renaming the file (and storing it with a different name and path than the uploader can recover, preferably on a separate domain), you should also rewrite the file in some minor way (add a bit of random noise) with a tool like ImageMagick.
Extract EXIF (and any other similar meta-data) from the file, or just consider converting every image to a bitmap.

Most important -- understand how the executable image exploits work:

http://www.stumbleupon.com/su/1q3iyy/video.google.com/videoplay?docid=4221457095668033104


How to hack linux via Local File Inclusion vulnerability?

It can be exploited by log files injection. it might be possible to inject Apache log files, but these files needs root access to open, so it will not be possible to open them via LFI. to solve this problem, we inject temporary Apache log files, which are existed under this path:

proc/self/fd/12

or

proc/self/fd/14

or

proc/<apachi pid>/fd/12

or

proc/<apache pid>/fd/14

we nject log file with php code enables us to do whatever we want.


T-Mobile WWAN IP address is DoD Network Information Center?

Check the WWAN IP gained from a external site like visiting www.whatismyip.com from your iPhone.
Chances are that the carrier are doing a NAT444/CGN on your connection, but not obeying RFC 6598, but using live adresses as NAT adresses to avoid breaking customer's routers (which would happen if they would use RFC 1918 adresses).

If you get the DoD IP there, it might just be outdated WHOIS data for the IP in question, eg that the IP is no longer in DoD's ownership, but WHOIS hasn't been updated yet.


How can I read local files from blind XSS?

<iframe src=file:///etc/passwd></iframe>

This displays a local file in the browser inside a separate iframe. This iframe has a different origin than the main frame. Due to same origin policy it is not possible to read the iframe content from the main frame, no matter if XSS or not.


Using Secure Remote Password without embedding the modulus

You may want to use RFC 2945 and 5054 (description of SRP, and of how to use SRP with TLS, respectively); they are a bit more "down to the wire" than the mathematical description from the author.

When the SRP author states that the server may choose the prime n and send it to the client, he does not mean that the server may choose a new prime n for every session; the same n must be used when the user password is first chosen (and v stored by the server) and when a key is exchanged. What the SRP author means is that an authentication session can begin by the server sending a n-value to the client and telling it "we shall use this n, which is the n which we used when the password was chosen". The client needs not be sure, security-wise, that this is indeed the same n, and not another n crafted by a fake server. In that sense, the value of n needs not be hardcoded in the client.

However, if the client needs not check that the value of n is the same than used beforehand (it will have to be the same for the protocol to succeed, but a distinct n sent by a fake server will not endanger the password confidentiality), the client must still make sure that n is proper, which implies, at least, to check that n and (n-1)/2 are prime. See for instance section 3.2 of RFC 5054. The bottom-line is that, for an efficient use of SRP, you really want to use a few hardcoded n values, which both client and server know.

Possibly, you could precompute 3 or 4 sets of parameters (values of n of distinct sizes, for paranoia/efficiency trade-offs), that the server stores, and in the client you store only the hashes of those values; when a password needs to be exchanged, the server sends n and the client verifies that its hash matches one of its hardcoded hash values. Alternatively, have both client and server store the values of n, and simply use short identifiers so that both client and server use the same value. Note that if the value of n depends on the user (a given server using several values of n concurrently, and must send the "right one" for a given user), then the protocol must arrange for the user to first state his name; this is the point of the "srp" TLS extension (section 2.8.1 of RFC 5054).

You cannot have the server change n for a given user after password choice, unless the server stores the password-equivalent value x = H(s, P), and SRP was designed precisely to avoid such storage.

Note that there is no security issue whatsoever of having several distinct users on a given server or distinct servers use the same n. A single n can be fit for the whole world. RFC 5054 (appendix A) lists a few n of sizes 1024 to 8192 bits.


How to extract information using a SQL injection on PHP?

There is no problem into being new to SQL injection (this one seems quite a classical example and therefore constitute a perfect start :) ), but I think it is very important to have some reliable background on SQL requests: syntax, tables, results sets, what are they and how they are processed, etc.

The goal in SQL injection is indeed to manage to figure out what is going on server's side by twisting the request in every possible way (no holds barrels when the situation deserves it!) and, eventually, gain the ability to actually control server-side processing.

Find an easily exploitable SQL injection

For the sake of illustration, I will reuse the example given in the main answer of "What is SQL injection?". If you need more background information on SQL injection, it might be a good place to start.

I will therefore imagine that the server is executing the following code:

sql = "select id, username from users'
      + ' where username='" + username + "' and password='" + password +"'";

Upon successful authentication, this request will return a result set similar to this one, with a single row:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+

Failed authentication produce an empty result set, no row:

+----+----------+
| id | username |
+----+----------+
+----+----------+

Now what you already managed to do and which shows that the server-side code is vulnerable is to bypass the authentication by setting the username to ' OR 1 --.

Still taking the same example as above, the code would produce the following SQL request:

select id, username from users where username='' OR 1 --

(-- effectively comments out the rest of the request's line which is therefore not shown here)

Here it's time to understand what this request does: this request fetches the ID and username of every user (every user with an empty username or true, which practically means every user).

This is not a good news for you (unless the first row in the result set happens to be the website administrator, but this is out-of-scope for this post where we want to focus on information extraction).

Why? Here again, you have to try to imagine what may be going on on server-side.

This is not a good news for you because this means that what you see displayed on the "You are logged in" web page:

Is not extracted from the database query result ($result[0]['username']), as otherwise you would see some random username displayed instead.
Is instead most likely directly directly taken from the form's field value received by the server (getPostData("username");).

On legitimate use cases, this does not change anything since both should return the same value. In our case this is bad because this means that we will be most probably unable to extract and display database information in this place.

There are more advanced SQL injection methods (error-based SQLi, blind SQLi, ...) which allow you to extract information from the database when the website does not intend to explicitly display it. However, they come with their own set of issues and I will consider them out-of-topic in this post. Indeed, given the care given by the website developer to secure the authentication page, most chances are that other pages are also vulnerable, other pages which this time will display information fetched from the database (the user's profile page may be your best friend :) ).

(If some pages are not happy with the fact that your forged username returns several rows instead of a single one, just add a LIMIT statement to you username: ' OR 1 LIMIT 1, 1 --, and of course you are free to modify its parameters to switch from one user to another... If you happen to know some valid username, you may try to use it as well : admin' --.)

While in this post I will continue to take the authentication page as an example, this will work the very same way on SQL injections affecting any other pages.

Determine the result set layout

At the beginning of this post we assumed that the result set was a two-column table with the username stored in the second column:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+

However, until know this was just some supposition and we didn't care. Unfortunately we will now have to know this:

Knowing the exact number of columns is required for technical reasons, otherwise the UNION statement we will use later will not be happy.
Knowing from which column the server fetches the displayed data will allow us to put the injected value at the right location in the result set (we won't need to know the actual column name, only its position).

(If the server happens to use PostgreSQL instead of MySQL, you may even have to determine the correct column types to satisfy UNION, more a nuisance than a real issue but it is something to keep in mind.)

Determine the number of columns

The easiest way is to ask the server to order the result as below:

username: ' OR 1 ORDER BY 1 -- -

Increment the clause ORDER BY 1 until you get an error, the last working value corresponds to the number of columns in the result set.

If I would run this against the example result set, I would obtain:

username: ' OR 1 ORDER BY 1 -- -: OK
username: ' OR 1 ORDER BY 2 -- -: OK
username: ' OR 1 ORDER BY 3 -- -: error, so the example result set contains two columns.

Determine which column(s) is/are usable

Now that you know the correct number of columns, you can go a step forward and inject a command like this one:

username: ' OR 1 UNION SELECT 1,2 -- -

If you had three columns, you would do SELECT 1,2,3, for five columns SELECT 1,2,3,4,5, etc.

The goal here will be to inject the actual numbers into the result set, and check in the web page (either the rendered one or its source-code) which one is displayed by the server.

The advantage of using numbers is that they are easily casted as string by MySQL if the columns type requires it. While "1,2,3" is given as example here, feel free to use the numbers you like ("1234,2345,3456" would work as well and produce results easier to spot).

In the example, would the resulting web page say "You are logged in as: 2", you would know that the username is fetched from the second column in the result set.

Attention: Understand how the UNION operator works: would the server only use the first row you may need to ensure that the left-side request does not produce any row!

In fact, the UNION operators concatenate two result sets:

+----+----------+         +----+----------+
| 42 | jdoe     |  UNION  | 1  | 2        |
+----+----------+         +----+----------+

Will result in:

+----+----------+
| id | username |
+----+----------+
| 42 | jdoe     |
+----+----------+
| 1  | 2        |
+----+----------+

Which may not be the expected result.

To get:

+----+----------+
| id | username |
+----+----------+
| 1  | 2        |
+----+----------+

You may want to ensure that the left-side query does not return any entry:

username: ' AND 0 UNION SELECT 1,2 -- -

See how OR 1 has been inverted to AND 0 to ensure that the left-side query will be evaluated as false no matter the database rows content.

Exploit the SQL injection

And now the fun begins :) !

With all this information in hand, you are now free to extract the information you want from the database.

For instance:

To get MySQL version:

username: ' AND 0 UNION SELECT 1,@@VERSION --

To retrieve table and column names:

username: ' AND 0 UNION SELECT 1,GROUP_CONCAT(table_name,0x2e,column_name) FROM information_schema.columns WHERE table_schema=database() --

There are a lot of websites out there referencing SQL requests suitable for injection. Pay attention to the version of the MySQL server you have in front of you as some syntax may be version dependent.

Conclusion

SQL injection easiness can vary a lot depending on the details of the server's SQL request and the processing applied to the result. It's all up to your luck factor here.

Nevertheless, manually building a successful SQL injection string always boils down to this loop:

Inject a request in the server.
Observe the result.
Try to interpret this result from the server's perspective: what kind of processing could have lead to such result? (this is were your knowledge about SQL really matters)
Create a new injection string designed either to solve your issue or check some hypothesis on server's behavior.
Go back to step 1.

At last, doing this manually may not scale very well. Depending on your needs, you may find some tools like sqlmap helpful to automate all this .


Anonymity of ballots when voting with BYCRYPT hashes

You shouldn't make public your users' hashed passwords, even if they were hashed using a strong algorithm like bcrypt. An attacker could easily download them and bruteforce them, and recover some of the passwords.

The bcrypt "seed" is the salt used to protect against rainbow table attacks. A salt MUST be unique, so using the same salt for every hash is a really bad idea.

You should look at this question who faces the same problem than you, and has already some answers.


How was the Apple Hacker caught? How can meta data be used to identify users through chained VPNs?

Very good question. Metadata is insanely powerful, and most people just don't realize how powerful it can be. Fortunately, it's not that hard to discover if you do a little digging into how technology and the internet works.

I'm of the opinion that it's not very easy to hide online. In most cases, if you're a small fry, nobody's going to pay attention to you much beyond the first investigation into your activities if nothing shady comes up.

National Security Letters and Subpoenas

Thanks to National Security Letters, the NSA, FBI, DEA, CIA, and other alphabet agencies can work together to request lots of data from American companies. If you wish to operate on U.S. soil, you are subject to U.S. laws and regulations.

Due to the Stored Communications Act, while companies aren't required to store information on users, they are required to handover any kind of information that they've stored.

In some repressive countries, the police just need to show up and force you to do anything they want, and you'll have no choice if you want to live. Worse still, the government may own those internet service providers.

What is a Device ID?

When I talk about "Device IDs" in this post, I refer to anything that can uniquely identify your machine: Operating System keys, hardware Device ID enumeration, browser fingerprints, accounts that you're logged into, et al. Assume it's a piece of information that uniquely identifies you.

Device ID Correlation

Many VPN users think that they can chain multiple VPNs on a single machine, and that they're "safe." They are usually reconnecting to multiple services under different IP addresses, but their Device ID remains the same.

Even if they were to shut down their service accounts (Skype, Steam, Battle.net, et al), they're generally still leaking information to Microsoft, Apple, et al. You're requesting updates periodically from Microsoft. You're also often sending packets to Microsoft servers every now and then.

And if you shut down your service accounts prior to performing illicit actions, it points to a clear pattern of trying to hide yourself, and will help give you away. In many cases, you're damned if you do, damned if you don't.

Even if you use Linux, you're usually requesting information from update servers periodically. For example, Ubuntu frequently phones home to get information. Ubuntu will use whatever IP address you happen to be using at the time.

Most major service providers record every single IP address that you've ever used to connect to those servers. Either you, or someone else using your account. When you use Windows or OSX, the information about your computer is sent to their servers. All IP addresses associated with that device ID will help investigators find you.

Note that most of the IP addresses in these images are local IP addresses so I don't end up posting someone's address and causing them annoyance.

These investigative methods are used by good guys, and bad guys. In some countries, having the wrong beliefs, being the wrong race, or opposing the wrong people will usually result in your death.

Real World Example of Successful Device ID Correlation

It appears that with the recent Apple Hack, the attacker attempted to hide his identity behind proxies, but connected to an Apple server via SSH, which somehow revealed his actual Mac serial number during the connection process:

  "Two Apple laptops were seized, and the serial numbers matched the serial numbers of the devices which accessed the internal systems,"

IP Address Correlation

Another method, which usually always assists Device ID analysis, is the IP Address Correlation. I called it an attack in the picture, but it's really an investigative method. And a damn good one at that.

It isn't just your IP addresses used. It's the time range that such IP addresses are used.

This can be used to detect those who are clever enough to hide behind multiple proxies without leaking any additional information, other than the IP address itself.

Quantum Insertion

This is likely just a classic Man-in-the-Middle (MITM) attack on non-HTTPS websites, or HTTPS websites with improper configuration, which was given a fancy name. Nothing more.

This may only reserved for high-value targets, or abused with reckless abandon; using this attack against security researchers is actually a painfully stupid thing to do. It's best if the target is completely unaware. With the Snowden leaks, any researcher worth their salt will be reading about these kind of attacks because "bad guys" will be doing it too.

Quantum Insertion is just a MITM attack which could allow a threat actor to intercept a request to retrieve a file from a website, or even a fake website, and then replace it with another one entirely. For example, if you're downloading known hacking tools, a man in the middle attack, if successful, will redirect your download and replace it with an infected variant of the same file.

In other cases, a threat actor could insert infected Flash or Javascript files into the page and exploit a vulnerability.

With a successful MITM attack, an actor can gain access to the machine you're on, and easily find out who you really are by unraveling your VPN chain from the source. At the very least, they can get the first entry point of your IP address in the proxy chain.

They could also steal your password through unencrypted or intercepted connections. Password re-use can help reveal your identity as well (see page 57 in the document, or 59 if using "go to page").

Examples of things Vulnerable to Quantum Insertion / MITM attacks

Typical targets would tend to be high-traffic downloads or websites that are unencrypted. This could include websites that only provide insecure methods for downloading the files.

For example, Nvidia drivers default to non-https downloads with no verifiable hashes or signatures available on their HTTPS site, and many Linux distributions also serve ISOs over unencrypted connections - some of which even fail to provide verifiable hashes. What's more, Nvidia drivers frequently phone home with device IDs.

Popular security products such as Burp Suite require Jython to run modules. Jython has no https certificate on their website, does not provide hashes for the latest version of their software, and they only provide SHA1 and MD5 hashes for older versions. Given that Jython has no actual https certificate, these hashes could easily be modified to give you a false sense of security. Older versions of software are frequently outdated and may lead to compromise of your system, or further compromise through privilege escalation.

XKeyscore and PRISM

XKeyscore and Prism have all of the abilities I've mentioned here, and much more. Say what you want about the NSA and their generally ineffective dragnet surveillance: they are damn good at figuring things out after the fact. This helps prevent people from getting away with committing crimes in the long run. It also helps bring the bad guys to justice... do what you want with that information.

Is it just the government that can track you this way?

Unfortunately, no. Repressive regimes, corporations, advertisers, and the like, are able to create and maintain such databases in order to track users around the web.

Many companies also share your data with third parties. It's even there in the EULA. Read the EULA next time, and it will reveal connections to many of the things I've mentioned here. Remember, if it's free, then you are the product. And in many cases, even if it isn't free (Windows, et al), you are still the product.

And in repressive regimes, if companies such as Apple and Microsoft wish to do business, they are required to adhere to the laws of that country. This is one of the many ways that repressive regimes can track down individuals behind Yahoo, Hotmail, Google, and other accounts. And if those companies refuse to provide information, then they'll face fines, expulsion, or worse.


how can we find the CSRF vulnerability in a website?

I would probably take the following steps:

Identify a URL on your site where a CSRF attack could have a negative effect on your site.  For this example lets say a GET request to http://mysite.com/account/del will delete the account you are logged in as
Next create a basic HTML page that is totally separate from the site you are testing.  On this HTML page include the following <img src="http://mysite.com/account/del" width="0" height="0">
Next create a dummy account on the site you want to test, and log into that account.
With the session still active open the basic HTML page you created in the same browser.
If the account gets deleted, you have a CSRF vulnerability

This is a deliberately simple example, but it should give you the idea of how you can test for CSRF.

You can find resources on preventing CSRF attacks here.  Good luck!


Client is not storing Credit Cards Securily (near plain text). How do I convince client to be more secure?

You tell them what you know, and then you let them make the decision they want to make. Unless you've been hired to do their PCI audit, this probably isn't your fight. Put together a report explaining the relavant threats and potential issues so that both you and they have it in writing, and then you're done. Specifically, you may want to let them know what sort of attacks they're properly defending against, and what sort of attacks they are not properly defending against as well as what the ramifications may be.

In the end, though, your role is as a consultant, not any sort of enforcement capacity. If you push any further than just giving them advice, you put yourself at significant risk with really zero reward.


Can I use AES CTR mode to encrypt files with same key and nonce?

You must not do this.

AES in CTR mode turns it into a stream cipher, such that AES is turned into a cryptographic pseudorandom number generator (PRNG) which generates a sequence of pseudorandom bits to be used as a keystream. This output keystream is simply xor'ed with the plaintext stream to produce ciphertext. Using the same key and IV produces the same keystream each time, so by re-using the key and IV you're essentially using a many-time pad.

So, you get:

  C1 = M1 ⊕ K

  C2 = M2 ⊕ K

Where C is ciphertext, M is the plaintext message, K is the keystream produced by AES-CTR, and ⊕ denotes an exclusive-or (xor) operation.

By computing the xor of those two ciphertexts, you get:

  C1 ⊕ C2 = M1 ⊕ K ⊕ M2 ⊕ K

which, after cancelling out the two K values (since x ⊕ x ≡ 0) gives us:

  M1 ⊕ M2

This allows an attacker to know which bits of M1 are equal to M2. If you know any bits of one message (known plaintext), you can then recover the corresponding bits from the other message. You can also employ techniques such as crib-dragging to fully decrypt the entire message.

There's a great answer on Crypto SE about exactly how this attack works.

You should always use a unique IV per message to avoid this problem.


By adding more algorithms, you do two things:

Potentially increase the strength of the encryption.
Increase the attack surface of your application.

AES128-CBC is strong. If you're implementing it properly, and using strong random keys and unique random IVs, you're very safe. The US government (NSA) certifies AES for use in securing top-secret documents. I somewhat doubt that your security requirements are anywhere near theirs, so you should consider AES more than strong enough alone. If you're really paranoid, move up to 256-bit AES.

Chaining algorithms only provides more provable security if you use independent keys for each. Using the same key for all ciphers means you still only have to bruteforce one key, though at 128 bits it's been predicted that we might never posess the equipment to do so.

Chaining multiple algorithms makes some sense in ridiculously high-security high-paranoia long term storage situations like TrueCrypt volumes, where the deployment environment is completely unknown. However, unless you're likely to be storing military secrets that'll be shipped into a hostile country, and happen to be a professional cryptographer, I'd stick with just using AES.


Are there any known examples of companies who were successfully breached using POODLE, BEAST or SWEET32?

It is unlikely that there is public knowledge about use of these attacks in the practice. These issues are far from  simple to exploit. It is usually much easier and cheaper to use the more common attacks and only fall back to the complex and expensive attacks if there is no other way but the target is still worth the effort. This means one can expect that only high-value targets will be affected by this and reports of such attacks will thus not be publicly available.


No, there is no sanitation or escaping of quotes found in your snippet assuming $firstname is user provided input. Nothing is stopping me from modifying your query. This OWASP article will explain how easy it would be and their example closely resembles what you are trying to do.

You should consider reading up on how to use prepared statements and filtering your input to harden your code.


Find out the IP or hostname of the firewall?

If the firewall is operating in transparent mode at the IP level and does not decrease the TTL of the IP packet, for example, it is not going to be possible by TCP/UDP tools to know which exact router/firewall is blocking/dropping.

You can guess that there is something that is blocking/dropping the packets but if the firewall is in transparent mode I would say that the response is 'no'.

Also consider that your connection can receive RST packets that reset the connection from any router/firewall on the path.


Why refresh token if I can reauthenticate?

It's a matter of user experience since tokens are usually stored (in the browser's local storage for example). When a user goes back to a site, their browser can fetch that token (locally) and ask for a refresh.

That way they don't need to re-authenticate unnecessarily (provided that the token has an expiration).


How secure is internal data on the internet with IP authentication?

If you have shown the stakeholders the risk and they have decided to accept the risk as "not likely", then the decision is out of your hands. You need to continue to educate, educate, educate, but you need to understand that it is management's job to manage the costs and risks to the company. InfoSec's job is to serve the company, even if the decisions the company makes is not "best practice".

Your job now, because you understand the threat, is to come up with ways to mitigate the risk that you identified and present that plan to the stakeholders. "If someone like me were to want to get the data, they would to X, and this is how we can mitigate that breach."


Sulley - optional element and command check

Since both of your questions relate to groups, we should look at how they're used first. The purpose is to bind block data to a set of static values -- sulley iterates through the list of values and generates block data for each one.

The example in the docs uses HTTP, where the block data is a simple HTTP request and the group values are HTTP verbs ('GET', 'POST', 'PUT', etc). In the example, sulley generates and fuzzes the data block (the request) for each HTTP verb in the s_group:

# define a new block named "HTTP BASIC".
s_initialize("HTTP BASIC")

# define a group primitive listing the various HTTP verbs we wish to fuzz.
s_group("verbs", values=["GET", "HEAD", "POST", "TRACE"])

# define a new block named "body" and associate with the above group.
if s_block_start("body", group="verbs"):
    # break the remainder of the HTTP request into individual primitives.
    s_delim(" ")
    s_delim("/")
    s_string("index.html")
    s_delim(" ")
    s_string("HTTP")
    s_delim("/")
    s_string("1")
    s_delim(".")
    s_string("1")
    # end the request with the mandatory static sequence.
    s_static("\r\n\r\n")
# close the open block, the name argument is optional here.
s_block_end("body")

From the doc:

  When this defined request is loaded into a Sulley session, the fuzzer
  will generate and transmit all possible values for the block "body",
  once for each verb defined in the group

Now for the first question, you're getting only the 'STRU F' 'STRU R' and 'STRU P' strings because each value in the list supplied to s_group() is treated the same as a string created with s_static() -- they aren't mutated.

You can try this:

s_initialize('DataSTRU')

for op in ['', 'F', 'R', 'P']:      # trying to include your missing-arg case
  s_block_start('stru-%s' % op)
  s_static('STRU')
  s_delim(' ')
  s_string(op)
  s_static('\r\n')
  s_block_end()

Which is closer to what you were aiming for, but you can probably get away with just this:

s_initialize('DataSTRU')
s_block_start('stru')
s_static('STRU')
s_delim(' ')
s_string('F')
s_static('\r\n')
s_block_end()

Which fuzzes the space (s_delim()) and the parameter (s_string()).

For your second question, you don't need to check which command is being used. If the blocks are specific to a command, just define them separately:

s_initialize('DataSet')
s_block_start('mode')
s_static('MODE')
# MODE-specific primitives
s_block_end()
s_block_start('prot')
s_static('PROT')
# PROT-specific primitives
s_block_end()
for op in ['', 'F', 'R', 'P']:
  s_block_start('stru-%s' % op)
  s_static('STRU')
  s_delim(' ')
  s_string(op)
  s_static('\r\n')
  s_block_end()


Proving that a MongoDB is misconfigured and publicly accessible

If it is publicly facing and unauthenticated it is as easy as using a MongoDB administrative client, plugging in the server details, and connecting. Depending on the client's response would prove it is definitive.

This is exactly what Shodan is doing. They spider the internet making connections with everything. And try to dump whatever information they can get into their database. During this process they have it attempt a connection to the server as a MongoDB client and if their client responds successful they collect data such as DBs, size, server info dump, etc.


The term "hack" has many meanings depending on context and popular use and has both malicious and benign meanings.

In general, it means that someone intentionally circumvented system design or controls in order to get the system to do something the designers did not intend.

You can hack a system to provide new, helpful functionality, or you can hack a system in order to let it permit you access to something it was designed to keep you away from. There is a desire in many circles to call a "malicious hack" a "crack" so that there is a clear distinction.

In your scenario, you see the effects but you have no idea about the intent. Therefore, you cannot conclude from the effects alone that there was intent or what that intent was. If the user permitted the malicious activity, then it is no longer a "hack" or a "crack".

So, no, I would not be comfortable with concluding that a system has been "hacked" because I saw pop-ups. Yes, there is undesired system behaviour, but there could be a number of reasons for it.


If the encryption algorithm broken or analysed, can an attacker find my password?

One of the rules upon which cryptography is based is that everything must be supposed known to the attacker. The only thing that is secret is the key. Some famous algorithms which follow this principle are DES, AES and RSA. So an attacker can't find your password only by studying the encryption algorithm.


I think it would be enough if you can actually restrict the Sign up process to  specific domain(s) in the Application itself.

Three very important security points I can think of are below

You can actually have a list of allowed domains for signup and thoroughly check every signup email against this list.
Also should verify the signed up email by sending a activation link with unique and long(>32 charterers) random token. This verification should be mandatory before granting access to prevent abuse by others.
You are right about DNS. The activation mail you send will be delivered after doing a DNS lookup for the MX record of domain. So,you have to be sure that you use very secure DNS servers like Google public DNS . A wrong DNS look up can make the email delivered to wrong inbox.

In the answer i mentioned the mandatory checks which have to be done as per your question.

You can have additional security measures in place like encryption(HTTPS) and Two Factor Authentication etc depending on your business needs.


Security risks of OAuth vs a password manager

Neat question, I had not thought before to compare those as competing solutions, but I suppose they are!
I'll answer this from the perspective of the Confidentiality - Integrity - Availability security triad.
Integrity for the OAuth case is a one-shot deal; you lose your main password and you're toast everywhere; your accounts now belong to the attacker, good luck getting them back. That may also be the case if you're using a cloud-based password manager, but offline file-based password managers give you more control over where your password data is stored (ex.: if the only copies are on your phone, your laptop, and a USB hard drive, then that's harder for an attacker to get their hands on).
Availability boils down to what happens if you forget your main password, delete your password manager db file, lose your phone and don't have a backup, or otherwise lose access to your account. Here the OAuth providers probably win because it's generally easier to recover your account with one of those services than with a password manager.
Last but not least, to me the big difference is Confidentiality -- You will notice that, in general, the companies providing free large-scale OAuth services tend to be advertising / user analytics companies. They directly benefit from being able to track you across 3rd party sites. So if you're even a little bit interested in anonymity, then making separate isolated accounts on different sites, you're making it one step harder for people (either other end-users, or the networks themselves) to correlate all your accounts.


Single web application - security advantages to two server model?

In general, I agree with your implication that if you only have a single web application there is little security benefit to moving the DB onto a separate server. That being said, there could be some contrived scenarios where there might be a security benefit. For example, if the web application does not have full admin rights to the DB, then a compromised web server would reveal credentials for some access to the DB, but not all. If the DB resided on the same web server presumably the attacker might be able to gain full access to the DB too, rather than just the limited access for the found credentials. An example of partial DB rights might be giving the web application write access to a logging table but not read access.


Storing random initial (one-time) passwords in plain text

I would say, it depends.

If the Creation of this account is triggered by some external means, for example payment, or signing up for some other service, such as so if any unauthorized person access the new unused account on your site would cause a security breach, then it can be a security risk if the database leaks.

If however, the account Creation is directly triggered by the end user, and the account is plainly unuseable without setting a password, then a attacker could gain the same access by signing up himself, thus it would not create any security risk if a initial password leaked.

If you really dont want to store unencrypted passwords in database, I would suggest hooking up a network printer to your service. If the service reside on a web hotel, you could put up some sort of tunnel or Connection between your printer and web service, so the web service can print anything on your printer.

Depending on the security settings and security policies of your server host or web hotel, you can either have it that your web service Contacts your printer via ipp and prints password, or you could have that your print server "polls" the web site for any new accounts and prints them.

As soon as a user signs up so password should be distributed via snail mail, then the web service immediately send this to printer, and then stores the password encrypted in database. This means you can still batch process the snail mails, by putting them in envelopes.
The papers with initial passwords and adresses and such just is there sitting in the printer output bin waiting for being processed, and can sit there for months.

A good thing with IPP is that its based on HTTP, so your can for example tunnel IPP in a SSL tunnel by using stunnel on the gateway or print server, and then on the client site, you simply encapsulate Everything in a HTTPS request instead of HTTP request.

This means the password will never be stored in cleartext anywhere on the server harddrive, it will only be available in cleartext on the paper, a paper that once sent away with snail mail, will no longer be available to you or any adversiary physically breaking into your location.


What can an attacker do in this scenario? (unwritable bashrc, profile, etc.)

Path is defined in bash profile so that ~/bin comes last, so running "firefox" should run the default firefox and not a custom "firefox" installed by the user in their home directory.

Variables can be overwritten in runtime. Shortcuts on desktop and in menus can be overwritten. Aliases can be defined. Instruct the desktop environment to start your code every time it starts... As forest writes; there's too many to list them all. Consider your account compromised!

  .bashrc, .profile, .bash_profile, .bash_logout, etc. (all those kinds of files) are only writable by root, so the user needs to use sudo to edit them.

Let me show you something:

[/tmp/foo]$ touch bar
[/tmp/foo]$ sudo chown root bar
[/tmp/foo]$ ls -la
total 24
drwxr-xr-x   2 vidarlo users  4096 Jun 17 14:13 .
drwxrwxrwt 131 root    root  20480 Jun 17 14:13 ..
-rw-r--r--   1 root    users     0 Jun 17 14:13 bar
[/tmp/foo]$ chmod 777 bar
chmod: changing permissions of 'bar': Operation not permitted
[/tmp/foo]$ rm bar
rm: remove write-protected regular empty file 'bar'? y
[/tmp/foo]$

As long as you have write permission for the directory (which you pretty much need for ~), you can remove files you do not own. An attacker can trivially do cat .bashrc > /tmp/foo && rm -f .bashrc && cat /tmp/foo > .bashrc, effectively recreating the files.

In addition, local privilege escalation attacks on a desktop solution is not exactly unheard of.


are session key generated during RSA key exchange mode ephemeral

The question is not very clear but let me try to provide an answer it from what I get.

The RSA exchange method is used to establish the pre-master key. The client generates a random value, use the server public key from the Server certificate from the Server Hello message to encrypt the pre-master secret key and send it to the server. Then the server can use its private key to sign a sample message to send it to the client so that the client can verify it to establish the identity of the server.

Since, the client sent a random value encrypted with the server's public key that can only be decrypted by the server, they now have a common random value that can server as a pre-master secret. Both, client and server can now derive their session key from it.

Since, the client generates it at every new handshake (not TLS session resumption), it's ephemeral.

You are right that the public key of the server never changes, and if the private key of the server gets compromised then anyone with the recordings o the messages over the wire can get the pre-master key and decrypt it, that too for all sessions hence NOT providing Perfect Forward Secrecy.


Are WoSign S/MIME certificates generated on the server side and therefore unsafe to use?

These certificates are of very little value. First of all, allowing them to generate the private key is very questionable. We have no details on how they do this or whether they retain this information - for all we know, they use the same private key for all certs or retain the key information, which may not be done in a secure manner (imagine what a rich target that datbase would be!).

the other problem with this service is that it has very weak vetting processes. The only real benefit of using a certificate service is to give your certificate an additional level of trust. If I receive an email or visit a site with a certificate, the degree to which I will trust that certificate is determined by the level of trust I have in the issuing authority. Certificates issue by this 'authority' have an extremely low level of trust because the issuer does not do any real vetting to ensure the certificate is being issued to the 'real' site or address owner.

Essentially, all this service is doing is making it easy for someone to get a certificate who doesn't want to learn how to create their own certificate using something like pgp. Of course, certificates you create yourself don't have much trust, but that is why you would normally grow that trust through key signing parties or using a recognised CA which does adequate vetting. Combine that with the fact you don't know who has access to the private key (assuming you allow the site to generate that data) and the certs provided by this service are possibly even less trustworthy than even a self signed certificate.


Security risks associated with embedding YouTube videos in a web application that needs authentication

... and given that the content is controlled by us, ...

It is not. You embed content from an external site. While you've uploaded the content to this site with the intend that it will be shown in your site, this is only a wish and the third party site is actually free to do what it wants.
Still, a cross-origin iframe provides usually a solid separation and protection against injection into the embedding page, as long as there is no explicit data exchange (postMessage etc) going on with the iframe content.
But, the shown content of the iframe may change to something different and this is out of your control. This might just be irritating (like video not shown and instead error message) but it might be also used for phishing (like asking for credentials) since from the point of user it is not clear that this content of the page is not controlled by the trusted party (i.e. you).


It sounds to me as though your router might have it's DNS server setting compromised with malicious servers. The reason you might be getting sent to the malicious IP address when you ping facebook.com is because that lookup is being referenced to either a rogue DNS server that serves bogus requests, or you have a hosts file that's been overwritten.

I would try manually changing the DNS servers on one of the devices within your network to simply use 8.8.8.8. Try pinging again and see if you get the same address.

You might also use an nslookup to see what DNS server you currently have responding to the request.

> nslookup
> facebook.com


Credit Card Tokenization and multiple parties

Is this a viable scenario? In other words can a business just forward
  the token and have the partner add transaction information for
  processing?

Generally, no - not because DSS prohibits sharing of a token, but because the token is only useful in the context of the relationship between the processor and the merchant.  Random parties P1 - P3 cannot present the token to the processor and have the processor do anything with it; they must themselves have a business relationship with that processor.  And the tokens provided by a processor to one merchant may not be portable to other merchants using the same provider.

  If not, how does the business that essentially acts as an intermediary
  process payment through partners?

It sounds like you're looking for something like the Payment Facilitator, or PayFac*, model.  It allows merchant B to act as a middleman between P1/P2/P3 (who are "sub-merchants" in this model) and processor P.  The PayFac B will generally work to provide interfaces for sub-merchants to route their payment flow through processor P under the auspices of B, and then will take the aggregated monetary distribution from P and distribute the correct breakdown to P1/P2/P3.  The Card data and the tokens will stay with B; customers of P1/P2/P3 will flow through B for future transactions (usually without it being obvious that they're doing so).

"Payment Gateway" is one of the terms you might hear used to describe Payment Facilitators, although I will caution that "Payment Gateway" as a phrase also includes a lot of different non-PayFac setups and means different things to different people.

Essentially, P1/P2/P3 are handing over the complexity of dealing with the cards to the PayFac, B.  But they have the benefit of enabling their business by accepting cards.

*PayFac is the Vantiv term for this sort of setup; I don't know if there's a generic term or what the names of competing offerings are.  Full disclosure, I am a Vantiv employee.  Limiting the example to Vantiv is a sign of my ignorance rather than bias per se :).  If anyone names competing equivalents in the comments, I'm happy to bubble them up into the answer itself.