Four ECDSA P256 CSPs are available in Windows. Which one should I use? According to Azure support case #116120515025419, the public datacenter only supports the following

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Since my goal is to use ECC with Perfect Forward Secrecy, I think these are my best options.

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

The cheapest EV cert I can locate is at Namecheap/Comodo, and they support the following curves:

 prime256r1, secp256t1, secp384r1, secp521r1.

I am using this guide to generate my certificate, but I'm not sure of which of the following to choose from

ECDSA_P256 Microsoft Software Key Storage Provider
ECDSA_secP256r1 Microsoft Key Storage provider
ECDSA_secP256k1 Microsoft Key Storage provider
ECDSA_nistP256, Microsoft Key Storage provider

Rationale for wanting ECDSA 256

My choice to use the P256 cert will allow developers to use CBC in addition to GCM.  I could choose a higher bit length, but the more secure ECDSA CSPs don't support CBC.  Is it wise of me to support CBC?

In case it matters, my target clients are mobile apps, browsers, and IoT devices.

Question

What is the difference between the curves available in Windows, and which is most appropriate for my use case? (why?)
If I do have a choice, which of the curves are least error prone in 3rd party implementations?

In a cipher suite like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, there are two involved curves:

One is used for the ECDHE part: a Diffie-Hellman key exchanged is used between client and server, over a given curve.
The other is for the ECDSA signature computed by the server: the server signs its ServerKeyExchange message. ECDSA is a signature algorithm that uses computations on an elliptic curve.

There is no requirement that both curves be the same; they are mostly unrelated and live in different worlds. On a conceptual level, the one used for ECDHE is more important, because it must ensure security for the lifetime of the data which will be exchanged over the wire (i.e. if the data is still important ten years from now, then the curve must still be robust ten years from now); the one used in the signature is only for now, and it does not really matter if it gets broken tomorrow.

Note that forward secrecy is all about the key exchange, i.e. the ECDHE part. This is the same idea: security of the signature system matters only for now. Thus, you could perfectly have ECC-powered forward secrecy with a TLS_ECDHE_RSA_* cipher suite, i.e. with an RSA key in the certificate.

Normally, the CSP choice (technically, "CNG key storage provider") is about the type of the private key that will indeed be stored, i.e. corresponding to the certificate and the ECDSA (or RSA) signature. The curve for ECDHE is chosen independently(*), between the client and server, with secrets which are kept in RAM only (and therefore never stored, which is the point of forward secrecy).

That being said, the one curve that is supported everywhere is NIST's curve P-256, also known as "secp256r1" or "prime256r1" (not to be confused with "secp256k1", which is a distinct curve). The NIST curve P-384 also has a fair share of widespread support, although maybe not as much as P-256. Also, P-384 implies a bit more computational work (about three times as much), which does not matter in practice except if some constrained embedded systems are involved (not smartphones; really small systems). An additional point is that P-256 already ensures more than adequate security, even with regards to technological improvements: as far as we know it, if a P-256 ECDHE key exchange ever gets broken, then it will be through use of an as yet mythical quantum computer, and if such a beast is ever built, then it will mince through P-384 with almost as much ease. In that sense, there is no security advantage of using P-384 instead of P-256.

Summary: for maximum interoperability, use P-256. Client and server SSL implementations may still decide to use another curve for the ECDHE part; unless specific guidance is applied, that other curve will usually be P-256 as well, or (depending on involved implementations) Curve25519, which is also a nice choice for security.

(*) Mostly. Some OpenSSL versions will try to match the ECDHE curve size with the curve used in ECDSA, which may or may not make sense since they relate to different operations with different security characteristics, especially with regards to future technological improvements.


Self-signed certificates and ephemeral Diffie–Hellman key exchange protocol If we use a self-signed certificate, is ephemeral Diffie–Hellman key exchange protocol vulnerable to a man in the middle attack?

Unless the users connecting to your site have imported your self-certificate from a trusted source, then yes, you will be vulnerable to MITM attacks. The reason for this is that an attacker could use his own self-signed certificate, and there would be no way for end users to tell that it is not the correct one.

Don't use a self-signed certificate. Teaching users to ignore the browser warnings and click through teaches them bad habits. If you don't want to spend money on a certificate, you can use a free service like Let's Encrypt. This is a CA which provides free domain validation-based certificates.


Vulnerability of Chrome's "Login Data" file after being orphaned from the host system Suppose someone were to knick a "Login Data" file from a Windows computer's Google Chrome profile.  They don't know the machine's user account password, but they may have some ideas as to what it could be, to try.

Is it at all possible for them to recover the plaintext passwords from the Login Data file?  Is it encrypted with any other entropy aside from the user account password?  Does the encryption method use any entropy from the hardware profile of the machine, or anything like that?  What if they were certain that the user account password was very poor? How trivially might they go about cracking it?

Note the host computer runs Windows 7.

Relevant links:

http://www.howtogeek.com/70146/how-secure-are-your-saved-chrome-browser-passwords/
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261.aspx

In Windows, Chrome uses the Data Protection API (DPAPI) to Triple DES using your Windows user's password. This means that every other program running under your Windows user is able to decrypt the login data. In fact, that's how tools like ChromePass and ChromePasswordDecryptor work. They only decrypt the file and reveal the passwords only if you run them on the same system that encrypted the file (or, perhaps, provide the victim's Windows password).

If the attacker was only able to acquire the Login Data file (for example, you had the file on your memory stick and it was stolen/lost), then your login data are protected as strongly as your Windows password is.


Penetration testing and report submission should be done by a certified CEH or CISSP Is it essential that a Penetration testing and report submission should be done by a certified CEH or CISSP? Or any knowledgeable person who has expertise on security & tools can perform? If any person can do, the same can be accepted as per the compliance requirement of any standard such as ISO 27001, PCI-DSS etc.

There are so many different certifications, that global regulations cannot require one specific one.

Also, certifications vary widely in what they cover. CISSP does not prepare someone for penetration testing. CEH can be seen as too 'light'. The organisation that offers the CEH has a separate certification for penetration testers (LPT).

In the UK, there is CREST for pentesters, which is required for UK companies in some regulatory situations.

At the moment, for standards such as ISO 27001 and PCI-DSS, one just has to prove that the tester was 'qualified' to perform the test.

But never just do something because a regulation said so. They are not supposed to be "check the box" exercises where you do the bare minimum. They are a guide to help you do what's best for the business. The goal is to implement the best form of the regulatory requirement in a way that meets the business goals.


Would verifying the integrity of my website by comparing digest on the client side work? So today I read about the sub-resource integrity attribute feature for browsers. And I though of using the same concept to verify the integrity of my HTML to protect against tempering by my web host or other MITM attacks that SSL was not able to prevent.

Basically I'm thinking of running my HTML through a hash function on load and compare the output to the correct digest that is sent along with the HTML file. If they do not match then I'll show a warning and offer to leave the site.

This is under the assumption that my website was not specifically targeted.

Now users might ignore my message just like they ignore certificate warnings but that is on them.

Personally I think this makes sense, but is it flawed and provide a false sense of security? At least I don't think it makes matters worse.

...to protect against tempering by my web host...

If you do not trust your hosting provider, all bets are off. They have full control over your website, and no clever tricks are going to change that.

  ...or other MITM attacks that SSL was not able to prevent.

TLS is not perfect, but it's good. You should focus your effort on using it properly (e.g. supported cipher suits, HSTS, etc.). Trying to build your own home brew fix for any weakneses in TLS is not a productive way to spend your time and energy.

  Basically I'm thinking of running my HTML through a hash function on load and compare the output to the correct digest that is sent along with the HTML file. If they do not match then I'll show a warning and offer to leave the site.

This offers no protection at all. If the attacker can modify the page, they can easily just disable this check or change the correct hash. Sure, that would require some special attention to your site in particular. But an attacker that can break TLS but not bypass this is not a realistic threat model. It's like assuming a bank robber will be able to cut through the steel door but not break a window.

  At least I don't think it makes matters worse.

In an of itself, it does not make things worse. But you have limited resources, and wasting them on things that are mostly pointless means you are not using them for things that would actually make you more secure.


Force a specific SSL cipher How can I connect to a HTTPS website using a specific SSL cipher, and view the output?

This would be useful when doing a vulnerability analysis and weeding out false positives, such as when a device advertises it supports a weak cipher but displays a page informing that a strong cipher must be used.

The easiest way to do what you're asking is simply to use openssl s_client to connect to the site with a restricted cipher list.  And, in fact, the same approach will work for a number of tools - certainly with most programming or scripting languages (Python (as @terry-chia suggests), Perl, tcl, C...) and with browsers (some useful commentary here).

Let's walk through how you can do this with openssl.

Determine ciphers you want to try

You can use the tool sslscan to determine ciphers that a given site accepts or rejects:

$ sslscan www.google.com | grep Rejected | head -1
    Rejected  SSLv3  256 bits  ECDHE-ECDSA-AES256-SHA
$ sslscan www.google.com | grep Accepted | head -1
    Accepted  SSLv3  256 bits  ECDHE-RSA-AES256-SHA
$

And this has told us one cipher that www.google.com rejects and one that it accepts.  Now we can test both with openssl s_client.

Testing a Rejected cipher

Simply use the '-cipher' argument to openssl to limit the cipher suite which your client will support to the one cipher you want to test.  Here I pick the one that is marked Rejected by sslscan:

$ openssl s_client -cipher 'ECDHE-ECDSA-AES256-SHA' -connect www.google.com:443
CONNECTED(00000003)
140465833367232:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 127 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$

We see a handshake failure near the top, and then we see "Cipher is (NONE)" which is a clear sign that the server was unwilling to agree with a client that was negotiating only the one cipher we specified.  I presume this is what you mean when you say you want to connect with a specific SSL cipher and "view the output."

Testing an Accepted cipher

Now if we do the same with the cipher that we know the server supports, we see a full connection go through and we can type in HTTP commands.  Below the output I'll list some things to have noticed:

$ openssl s_client -cipher 'ECDHE-RSA-AES256-SHA' -connect www.google.com:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIRYUpUVjSfHQwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
...
OEK3nH1sBk2Hy5ZBcyludHyUzqTHsXSjnIjwZNPpihVmFrs5I1Ma7iEj
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3750 bytes and written 277 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-AES256-SHA
    Start Time: 1385691323
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
TRACE / HTTP/1.0

HTTP/1.0 405 Method Not Allowed
Content-Type: text/html; charset=UTF-8
Content-Length: 960
Date: Fri, 29 Nov 2013 02:15:31 GMT
Server: GFE/2.0
...

Note the following signs:

We do not see the "handshake failed" error message
Instead of "New, (NONE), Cipher is (NONE)", we see "New,
TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA"
We also see the same Cipher listed under the SSL-Session section.
You can see where I typed in an HTTP command "TRACE / HTTP/1.0", and
where Google responded "HTTP/1.0 405 Method Not Allowed".  You would
not be able to do this or see this if the cipher had been rejected,
obviously; you can only talk to the HTTP server if the SSL connection was nailed up successfully.

Caveats

This is relatively easy in openssl command line.  Doing it in code may be harder, depending on the language and the library used.  Doing it in browsers may be painful, because such fine-grained control is not readily accessible - for example, if Chrome is using the OS for SSL on Windows, you need to figure out the registry keys used to manipulate SSL.

Another problem can be figuring out which cipher string you want to test.  If you're investigating the report of another tool, as your question suggests, it's probably not describing the cipher problem it sees in terms of an OpenSSL cipher string.  More than once I've ended up on the phone with support asking "What exactly are you referring to when you say 'weak cipher'?"


Techniques for ensuring verifiability of event log files Bit of newbie at the whole forensics stuff - but I'm trying to find out what I should have in place before an attack. While there is no end of material on the internet about forensics from seizure onwards, I'm trying to find out more about how I can make a secure record of events (specifically webserver logs) of adequate quality to be considered as evidence.

There are vague references to non-volatile media, hashing and signatures in the stuff I've read; these certainly provide a means for demonstrating a consistent snapshot - but do not intrinsically provide a mechanism for proving the data has not changed between initial capture and the snapshot, e.g. I could take today's log files and do a search/replace to overwrite the date with something else before committing the snapshot.

How does an electronic signature prove the data has not been tampered with between the initial capture and the signing - does it just support the signers assertion?

Must the integrity verification method be implemented in real-time? E.g. it's not very practical to write data directly to DVD, at best a track at a time is as near to real-time as you can get - but at a huge performance penalty.

Any pointers on content suitable for a non-lawyer? (pref with a EU/UK bias).

This is an excellent and important question.  There are several important techniques to know about:

Remote logging. Rather than store the log entries on the webserver, the webserver should be configured to send each log entry over the network to a log server.  The log server should be a custom machine, configured for a single use (log recording only), and hardened.  You should carefully minimize who has access to the log server, firewall it off from the outside world, and make sure it is running a minimum of services.  This will help prevent tampering with logs after they are generated.
Hash chaining. Another important technique is to use cryptographic methods to protect the integrity of log records, once they are stored.  A log entry should be a pair Xn = (Mn, Tn), where Mn is the nth log message received, and where Tn = Hash(Xn-1) is the cryptographic hash of the last log entry.  Use SHA256 or some other collision-resistant cryptographic hash function for this purpose.  What this does is ensure that an attacker can't tamper with entries in the middle of the log, without being detected.  The attacker can replace all the entries in the "chain", or throw away a suffix and replace them with something new, but this constraints what the attacker can do.  Importantly, the crypto ensures that if you write any log entry to write-once media, then the attacker can not change any earlier log entry without being detected.  That's huge.

For more, read about secure timestamping using hash chaining.
Write-once media. If you have write-once storage media, you can write the logs to the write-once media, and that will prevent tampering after they are written.  Unfortunately, the choices here aren't great.  As far as I know, they're basically:

CD-ROMs and DVD-ROMS are write-once, and allow appending if you use TAO mode, but also slightly clunky.
A line printer, printing onto paper, is a surprisingly effective write-once medium, as long as you keep the paper supply fed.
PROMs are write-once, if you use a Manchester encoding.  Unfortunately, PROMs have mostly been replaced by EEPROMs these days, so true PROMs are hard to find.
Wikipedia also has a list of write-once media.
SanDisk has a SD card with 1GB of write-once storage, which is specifically designed for forensics and log storage purposes.

Write-once media complement hash chaining extremely well.  What you can do is store all log entries on some ordinary storage medium (e.g., a hard drive), and then once an hour store the latest log entry (or just its hash) to write-once storage.  This ensures that an attacker who compromises or otherwise tampers with the log server can only modify records going back an hour, as well as (of course) all future records, but not records that were logged more than an hour before the compromise.  That's huge.
Replication. You can store multiple copies of the log entries on multiple servers, to provide redundancy and protect against tampering.  An attacker who breaks into one server and tampers with it won't be able to tamper with the copy on the other servers.

For this to effective, you need the servers to be independent, so that it is unlikely that an attacker can compromise them all.  For instance, you might physically locate the servers in different locations or different machine rooms, set up so that no one person has physical access to all locations.  You might have separate individuals administering them, so that no one person has log-in access to all of the servers.  You might have one log server running on your system, and a replica hosted remotely (e.g., running in the cloud).

Replication complements hash chaining very nicely.  For instance, rather than replicating every log entry, you can replicate just 1 out of every m log entries.  Also, if you don't want to expose private log data to some of the replicas (e.g., ones running in the cloud), you don't have to store the entire log entry: you can store just the hash Tn.  This hash value reveals nothing about the log entries themselves, since cryptographic hash functions are one-way.

I'm sure there is lots more that could be said about this, but I hope this helps introduce you to several technological methods that are available to protect logs.


Contents retrieved from a not protected url from content owner's server. Legal? Is legal to use contents retrieved from a not protected url (no authentication involved, just a public accessible URL) from the content owner's server?

Is legal to distribute urls pointing to that resources? Is legal to develop applications using that contents?

In the past I would have said, "All answers point to yes".

However, due to the somewhat recent sentence handed to Andrew Auerheimer last year, I would say the answer is "no".

http://www.net-security.org/secworld.php?id=14614

  "The facts are simple. In June of 2010, Andrew Auernheimer’s
  co-defendant Daniel Spitler discovered that AT&T’s servers were
  publishing email addresses of iPad subscribers on the servers
  authentication log in page when queried with a SIM card number that
  matched an existing AT&T subscriber’s SIM card number. Upon
  discovering this, Spitler wrote an iterative script that queried
  AT&T’s publicly accessible iPad servers and copied over 120,000 email
  addresses. No password or any type of security was ever hacked, nor
  was any attempt ever made to hack any password or bypass any existing
  security measures. In essence, what Spitler’s script did could be done
  by anyone with a web browser who entered in the right combination of
  numbers into a URL,"

http://www.forbes.com/sites/andygreenberg/2012/11/21/security-researchers-cry-foul-over-conviction-of-att-ipad-hacker/

  "If merely visiting an unrestricted web page to copy an email address
  counts an unauthorized access, the legal line between intrusive
  hacking and testing websites for vulnerabilities--or merely visiting a
  website at all--could be blurred"


Detecting DNS tunneling I have been trying to detect/establish DNS tunneling. First of all I logged out of my user account of the captive portal. Findings:

$ nslookup <somesite> // works fine
$ ping <somesite> // Destination Net Prohibited

Why the outputs of nslookup and ping are different. On the back they both are using ICMP protocol, I can't get that.

Moreover, since nslookup is working fine; so the DNS queries are working fine. I tried doing DNS tunneling by connecting to aVPN Server running over port 25000 using UDP. I was able to do netcat to the port and I was able to connect to the VPN while I am logged in. But when I am logged out it does not connect. So, what does it indicate ?

DNS does not use ICMP. It uses UDP (and rarely TCP) port 53.

The firewall/router the captive portal contols either does not block that port or it is the DNS server and is responding.

All other traffic are of course blocked until you log in.

Response to comment:

For 2), UDP has no session control, i.e. it just sends a packet without checking if it has been received or if there's even any one to receive it. So it's impossible to know if a connection worked unless you managed to receive some response from the server based on the data you send.

If you did receive response, it is possible UDP packets are entirely unblocked (which I'd consider as a poor design for a captive portal.)

For 1), ping under different systems use different mechanism. Many use ICMP Echo messages, but some attempt TCP connections or send special UDP packets to force a response. Sometimes firewall rules are not set up to block them consistently, so ping is not always trustworthy in unusual network setups.


Why would my firewall show that my computer connects to DNS servers other than the ones I have defined? I'm looking at my firewall logs and even though I have my computer set to a static DNS, the logs are showing that my computer is reaching out to multiple DNS servers via port 53.  I am worried about botnet activity.

Your firewall logs requests to DNS servers other than those defined in the OS because an application is making requests to its own configured alternative DNS servers. Google Chrome, for instance will make requests to 8.8.8.8 despite your OS configuration.

You can verify this with tools like Fiddler or similar. If these requests are a problem for you, block them at your local system or network router/firewall.

Incidentally, monitoring DNS requests on a network is an effective detection practice for this reason.


Google safe browsing vs traditional anti-malware scanners What is the difference between using Google Safe Browsing and using other traditional anti-webmalware tools ? Which one is more efficient to protect against malicious web content ?

"Google Safe Browsing" is mostly a large directory of Web sites which appear to contain malware. When you use Safe Browsing, your client is talking to the Google's dedicated server, with a question like this:

  — Tell me, mighty Google; I am about to visit evilhackerzfrompatagonia.com. Is that safe ?

To which Google will respond either:

  — Do not fear, friend browser. I went to that site myself yesterday, and nothing on it appeared amiss at that time.

Or:

  — Stay your network packets ! That site is a malware-infested hellish server; or at least so it was when I last had a look. Steer away from it !

So that service is really relative to what Google's systems so when they last visited the same site. However, a site owner may detect whether a given visitor is an actual human, or Google's automated services; therefore, an evil site owner may elect to show a collection of pictures of cute kitten to Google, while sending malware to everybody else. Google Safe Browsing would be none the wiser.

Other anti-malware tool inspect what you actually download. They don't prevent the fateful connection, but they see exactly what is entering your computer, and they sit sufficiently early in the input data flow that they may prevent incoming malware from harming your computer, if they detect it as such.

Such tools are in a better position to make an accurate diagnostic of the malwareness of incoming data, since they work, by definition, on that exact incoming data, and not on what was sent to another system the day before. In that sense, they seem "more secure". On the other hand, all the detection must be performed by your computer, which may not necessarily have a lot of available computing power for the job. More importantly, Google's systems have a worldwide view and thus a lot of data to cross-correlate with.

So the answer is mixed: though Google Safe Browsing is easier to fool by sending it innocent harmless files, it is also much better at deciding whether a given file is malware or not. So the two kind of services are really complementary. You don't have to choose between Google Safe Browsing, and a local anti-malware tool; just use both !


Is CBC mode for AES still safe to use in 2018? I'm using AES-256 CBC mode in C# to encrypt various amounts of texts. The key and IV are always generated properly randomly. However, would GCM mode provide any noticeable security gains over CBC?

It's a little hard to say without knowing your exact set-up, but CBC may well be fine, especially as it is available in .NET as is.

The main risk of CBC is the padding oracle attack here are some good links:

https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

https://docs.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode

If you can be confident that an attacker cannot modify the cipher text then you should be alright. You could also go down the route of encrypt-then-MAC to ensure that the actual ciphertext was unaltered.


Unidirectional Data Transmission to a Smartphone Unidirectional Data Transmission to a Smartphone

I'm going to use an old Android phone to store sensitive data (e.g., Bitcoin wallet private key), with no SIM card and WiFi and Bluetooth turned off. I could disable wireless connections physically if I get paranoid enough. This way, even if the system is compromised, it won't leak any data to the outside World.

The question is, if I want to install or update software on the phone, how can I send the apk files? The obvious way is through SD card, but what if some malware in the phone writes the key to the card? I'd have to dispose of the SD card every time, which can be costly and inconvenient.

I guess there may be microSD cards with a write protection lock switch, but I've never seen those before.

Ideally, I'd like to send something like audio signals or series of QR codes which the receiver will decode as a binary file.

You can use for example Soft Modem for Android, such as one based on this library. This can be made completely unidirectional if you do not connect the L/R pins and only connect PC audio output to Android MIC through a divider. Of course you would have to manually verify the integrity of the content you have sent, since in this case you will not have automatic retransmission.

However using an Android phone - especially old one - to store anything important is a bad idea. Basically while you only need the phone's memory component, you depend in many other components to access this memory - and many of those components are way less reliable than memory (display and USB charging port are probably the weakest).


Is there an entropy difference between hashing an encoded string? Of course if I apply (for example) SHA-2 to a base64 encoded string it will give me a different result versus the original data, but from a strength-perspective in terms of entropy, is there a difference?

Does having a fixed input (on a bit level, like in base64: the MSB is always 0, or byte: say, appending a bunch of 0's) to a hash reduce it's strength?

It does not increase the entropy.

An attacker performing a brute force attack can simply apply the same encoding you are using before hashing.


Authentication to offline device I have an offline safe at a remote location that I want to give people access to at my discretion. I would like to control who and when they have access, without having to travel to the safe.
Example:

I would like "Peter" to be able to open the safe, which is at a remote location, tomorrow.
In my office, I sign the text "January 30, 2021" with my private key and give it to Peter.
Peter travels to the safe and enters the signed text into the safe.
The safe verifies the signature with a corresponding public key.
The safe checks the current date and opens itself.

Problem:
The signed text is very long. The safe would have a keypad and a small screen, but entering more than 10 or 20 characters would be difficult.
To solve it, I'm thinking about e-banking solutions. They started with cross-off-lists. Such a list could be used where each number on the list could be assigned to a date. Now, I'd like to avoid shared secrets and cross-off lists.
Banks moved to mechanisms like photoTan where they display a QR code to the user; the user scans it with their smartphone, then get a short sequence which they enter back into the banking website.
Such a thing would work. I would like to perform such a "proof" where the safe can send a long challenge to the user, but the user can only respond with a short challenge-response. What are those algorithms?

You could use OTP for this.
Create a random secret and add it on the safe and your phone. When you want Peter to access the safe, you use your phone to pick a future date and generate the token, and send it to Peter. That token could be valid for an hour, or six, or a day, so adjust your generation algorithm accordingly.
That would create an issue when you want two or more people to access the safe at the same time. This could be adjusted by having 10 OTP secrets on the safe (0 to 9), and you concatenate the index of the selected key to the password.
Let's say the OTP for "January 30, 2021" on the secret 2 is 83641398, so Peter would have to enter 283641398 on the safe, and Jane would have secret 1, and her token would be something like 1977433. The safe would get the first digit to identify the secret, calculate the token, and authenticate the user. 9 digits is long enough to deter bruteforce, and short enough to be entered on seconds.
As an OTP is time-dependent, you have to keep a clock on the safe. It does not need to be accurate to the second, because the token life would be at least a couple hours, so even a 15 minute drift would not bring much difficulties to Peter or Jane.
And being time-dependent, the password don't have to be revoked later, and it would be useless on the next day.


What kind of printers do the most secure companies use? If wifi-enabled printers are a bad idea, I'm wondering what kind of printers (brand even perhaps) that secure companies use, such as banks or financial institutions. I would assume these printers don't even have the capability of wifi, that is they are ethernet-only. But searching around I haven't really found anything to start on ethernet-only printers with all the standard security features of secure printers (password protection, encryption, lack of hard drives, etc.).

Mostly they use multifunctional printers of major vendors (I worked for few and I installed printers in banks, government offices, police etc.).
They have turned on every possible security features like HDD encryption, SSL communication, password/chip authentication, disabled USB ports etc. Sometimes even customized firmware. As "normal" installation took few minutes, at those places it usually took ten's of minutes.
There is also special procedure of replacing old/faulty machine including formating and (multiple) rewriting data on HDD and then certified destruction of HDD.


Difference between OpenSSL and keytool I was wondering about differences between using OpenSSl or Keytool and generating certificates by them. I think  Keytool is used by Java community but for someone who is not remotely connected to Java uses OpenSSL for generating stuff. I mean public key, private key and certificates.

I assume with using OpenSSL you have to generate keys and certificates individually but keytool can generate a keystore that will give you a sort of briefcase that can contain keys+certificates.

Question is: is what I think  correct or not?

If it matters, I use windows. And I am referring to: How do I use OpenSSL with the Java Keytool?

In short, they're both crypto key generation tools, but keytool has the additional feature of manipulating Java's preferred key storage file format, the KeyStore.

Java strongly prefers to work with keys and certificates that are stored in a KeyStore (also called a TrustStore when it's only got certificates in it).  It is possible, but not trivial, to get Java to work with straightforward PEM/CER/CRT/PKCS/etc files, so for all intents and purposes if you're coding crypto in Java you're going to use a KeyStore.

Keytool is a tool that comes with Java that works with KeyStores - it can create KeyStores and manipulate keys and certificates inside them.  It can also create keys and sign certificates.  So it is both a key generation and a KeyStore-file-administration tool.

OpenSSL works with standard formats (PEM/CER/CRT/PKCS/etc) but does not manipulate KeyStore files.  It is possible to generate a key and/or certificate with OpenSSL, and then import that key/cert into a KeyStore using keytool, but you can't put the key/cert into the KeyStore directly using OpenSSL.

(OpenSSL also has a wider array of functionality than keytool - performing symmetric encryption, acting as an SSL network client and server, handling more formats.  It just doesn't happen to speak KeyStore.)


Refreshing access token using access token Is it safe to refresh your access token using your access token (assuming of course it is still valid)?
And, if not, what makes a refresh token that much more special that it is safe to be used as a means of refreshing access tokens?

From my understanding, token is a stateless credential of access control, as such, tokens for accessing a particular service must have a reasonably limited lifetime.
Therefore, to gain such access, login and refresh tokens needs to be generated from a better-protected master key. This master key is typically the user credential (in the case of automated bots, application credential), and must be revocable should the service determine that it's being abused.
That's based on my experience of designing in-house applications, others may have better answers.


Certificate binary matching Is it an industry practice to do a binary matching of client public certificate when doing SSL with client authentication?
I was thinking that if the client can successfully do the SSL handshake, there is no added security by matching the certificate binary to one that is stored, but I heard some places do an extra layer of check by storing the client certificate and doing a binary matching of the whole certificate.
What is the added security in this?

I think you are referring to certificate pinning in the context of client authentication, where the server not only checks that the client can successfully establish the SSL handshake with the certificate (which means the client knows the private key) but that the certificate is exactly what the server expects (or one of the expected certificates).

The check that the certificate is exactly the expected is useful if you deal with self-signed certificates or if you want to add an additional protection on top of the existing validation to make sure that no attacker was able to get a certificate for the same subject from a trusted CA. It is typically not done by comparing the whole certificate as binary (although this is possible) but by comparing the fingerprint of the certificate or of the public key inside the certificate. In the latter case this is known as public key pinning.

This technique is more commonly used in the other direction, i.e. to make sure that the server certificate is the expected. This is used in today's browsers to protect important domains like google.com by embedding the expected fingerprint of the public key into the browser. With the HTTP extension HPKP any other sites can do public key pinning too.


Can security devices (e.g. Snort, Splunk, WAFs, etc.) generate alerts when they aren't working as designed? APRA's CPS 234 regulation section 56 states:

An APRA-regulated entity would typically deploy appropriate
information security technology solutions which maintain the security
of information assets. Examples include firewalls, network access
control, intrusion detection/prevention devices, anti-malware,
encryption and monitoring/log analysis tools. The degree of reliance
placed on technology solutions for information security could
necessitate a heightened set of lifecycle controls, including but not
limited to:
...
"detection techniques deployed which provide an alert if
information security-specific technology solutions are not working as
designed."

Is this possible? If so, can I get a couple of examples?

None of these security devices you have listed have subsystems that can report on the integrity or availability of themselves. You will need to use an external piece of software to monitor your security devices.


Have there been any case studies on intentional vulnerabilities or malware in open source projects? In my experience, it's a common mantra that open source tends to be secure due to its availability for open scrutiny.  I tend to agree with this.  At the same time it's no secret that vulnerabilities are constantly discovered.

Moreover, I feel it's easy to imagine that developers very eagerly obtain libraries and tools and that are available in various repositories.  I believe that these resources are regularly grabbed hastily for experimentation, and sometimes adopted into larger projects without much scrutiny (maybe besides a license compatibility check, and some assurance that the feature set matches what's desired)

What comes to mind is PyPI, Dockerhub, etc.

I would like to know if there are many documented cases of things like:

Successful malicious contributions to prevalent open source software
Smaller projects that popped up that could be considered malware under the guise of providing some simple but appealing functionality
Reports of foul play on attempted contributions

I understand that be best FOSS projects have high quality maintainers, but I also see this current world of nonstop spamming, phishing, spearphishing, identity theft and aggressive governments.  I personally have a difficult time believing that bad actors would ever take a break from trying to make malitious contributions to these projects, given how they seldem take a break from their other nasty tasks.

Though your question is well formed and specific, the answers to them do tend to border on the 'generating discussion' side of things. I'm going to try and answer you as directly as possible.

  Successful malicious contributions to prevalent open source software

There does not appear to be much at all in the way of documented evidence of this. Surely it has happened, but due to the very nature of OpenSource, where anyone with any amount of knowledge can submit a request to update the codebase there will always be the question of whether something that ends up being malicious was intentional or simply a mistake. The Heartbleed vulnerability in OpenSSL went unnoticed for 2 years, but was ultimately reported as a slip up by the user who uploaded the change and the admin that approved it.

  Reports of foul play on attempted contributions

Back in 2003, there was an attempt by an unknown attacker to force a backdoor into the Linux kernel. They exploited the source-control practices at the time to insert the code directly into a secondary code repository rather than attempt to try and submit the code for peer review.

Because absolutely anyone can request a change to OpenSource code, there are going to be a huge amount of foul-play cases - Except all of the drama and reports of this happening will be within the message-boards and other communities for that software. The sort that you are looking for - news-worthy reported cases are much less likely. If the application is big enough to report on, then there tends to be plenty of approval steps in place to review the code first.

The bigger the application becomes the more 'potential' eyes on the code becomes. As a hacker, if you submit malicious code into a peer-review-based source-control such as Github, your going all-in and saying 'I hope you aren't reviewing this thoroughly, because I'm trying to do something nasty'. It would be much safer and less likely for you to be caught out (immediately, anyway) to try and get your malicious code out in other ways that aren't going to be audited such as a Man-in-the-Middle attack deploying a modified version of the application out to someone trying to download it. You would have greater control over the entire code-base and thus be able to hide your intentions all the better and - as you suggested yourself - very eager developers and users are much less likely to compare the digital signatures of what they are downloading than the app rovers who are the party that are the most-invested in the security of the code.

TL;DR - As an attacker, it's more reliable to push malicious code to an over-eager end-user than hoping that the admins who are passionate about their product aren't on the ball.


Fixed offset in linux ASLR? I just printed function addresses and offset between two functions, but the offset is fixed whenever the program is executed (base address is only changed).
Code (test.c)
#include <stdio.h>
#include <stdint.h>

void func() {
    printf("func!\n");
}

void func2() {
    printf("func2!\n");
}

int main() {
    uintptr_t main_addr = main;
    uintptr_t func_addr = func;
    uintptr_t func2_addr = func2;

    printf("main_addr: %p\n", main_addr);
    printf("func_addr: %p\n", func_addr);
    printf("func2_addr: %p\n", func2_addr);
    printf("offset (main - func): %ld\n", main_addr - func_addr);
    printf("offset (main - func2): %ld\n", main_addr - func2_addr);
}

Compile
gcc test.c

Result
(1st execution)
main_addr: 0x5578d1296190
func_addr: 0x5578d129616a
func2_addr: 0x5578d129617d
offset (main - func): 38
offset (main - func2): 19

(2nd execution)
main_addr: 0x55bf299d9190
func_addr: 0x55bf299d916a
func2_addr: 0x55bf299d917d
offset (main - func): 38
offset (main - func2): 19

(3rd execution)
main_addr: 0x55ba4767d190
func_addr: 0x55ba4767d16a
func2_addr: 0x55ba4767d17d
offset (main - func): 38
offset (main - func2): 19

My kernel version is 5.4 (i.e., ubuntu 18.04)
So, my questions are:

Is this expected behavior(fixed offset) in ubuntu 18.04?
How can I make a situation that randomizes not only base address, but also offset.

Thank you

ASLR is about randomizing the layout of dynamically-linked libraries used by your code, not about randomizing within your program.  The goal is to prevent an attacker from being able to simply hard-code the location of something like exec into a remote-execution exploit.
To illustrate, two different copies of bash from my computer have libc at different addresses according to /proc/[pid]/maps:
7fd647904000-7fd647a47000 r-xp 00022000 00:12 12970738                   /lib64/libc-2.32.so

7f2b574cd000-7f2b57610000 r-xp 00022000 00:12 12970738                   /lib64/libc-2.32.so

Instead of looking at addresses within your code, try checking the address of a library function, such as printf.


After exploiting a router using routersploit, what do you have control of? I've seen the routersploit program on Github. It's a similar program to metasploit in a way that it exploits vulnerabilities in network devices (or just routers I think. Not too sure). I see that I targets most routers and exploits their vulnerabilities, but I don't understand a few things. What do you get out of exploiting a router and what do you have control of?

Firstly, a router is a computer, so like any other computer, you get the ability to use its resources for your own purposes: processing power for cryptomining, use of its networking resources for DDoS attacks or spamming.
Secondly, a router sits across the network path of any computers on its network, so it provides the ability to man in the middle attack all network traffic from those computers. This allows you to attempt to steal data for identify theft and other forms of financial fraud.
Thirdly, in more targeted attacks, a router can serve as a jumping off point within the network of the target, allowing attacks onto other systems that may bypass firewalls due to the traffics origin from within the network. If the router appliance is also the firewall, exploiting the router may allow the attacker to completely ignore the firewall.


Bruteforce part of password in TrueCrypt I own a TrueCrypt container and I can't open it. I remember part of its password. So I want to bruteforce attack on it. I tried many parameters in oclHashCat but none worked (parameter problem). Can someone tell me please; how to pass correct parameters to oclHashCat to bruteforce my password?

Thank you

This is a good starting point to learn how the Mask Attack from oclHashcat works: https://hashcat.net/wiki/doku.php?id=mask_attack

You need to add the commandline-parameter -a 3 so hashcat knows your going to use a mask  attack.

Hashcat comes with some predefined mask's (you can define your own also):

?l = abcdefghijklmnopqrstuvwxyz
?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d = 0123456789
?s = «space»!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
?a = ?l?u?d?s
?b = 0x00 - 0xff

Example:

Lets take this as the password you are looking for: PASSWDfA89

You remember the PASSWD part but you didnt remember the other part: fA89

We see that the fA89 part has lowercase and uppercase letters and numbers,
then we need this mask: ?l?u?d, but hashcat doesnt have it predefined so we need to use a custom mask.

For this, we need to add another commandline-parameter: -1 [CUSTOM MASK HERE]

The custom mask permits us to create our own charsets (up to 4) but we only need one.

The custom charset should look like this: -1 ?l?u?d

At the end, our command should be something like:

./oclHashcat-plus64.bin -m 6211 test.tc -a 3 -1 ?l?u?d PASSWD?1?1?1?1 -n 32 -u 2000

This is the important part: -a 3 -1 ?l?u?d PASSWD?1?1?1?1


Protecting local admin password against 3rd party software I'm using a standard user account and then run whatever as administrator so that I type in administrator password...

I wonder if potentially undetected malicious software such as a trojan is able to log my administrator account password and use the logged password to gain privilege over the system? i.e. to setup a backdoor.

edit:
Assuming windows 7 with UAC control to the max.

Yes, it is possible. There is known Windows malware that can grab the Admin password hash from memory, even if you never log in to the Admin account after infection.


What exploit are these user agents trying to use? I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).

1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9\x22{${print(238947899389478923-34567343546345)}}\x22
1 Mozilla/5.9\x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9\x22

What exploit was attempted and how can I test to ensure these exploits are not usable?

It looks to be trying to exploit some form of command injection.  As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically.  The payload itself just appears to just be testing to see if the server is vulnerable to command injection.  It does not appear to have any additional purpose.

In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond.  Note, that I only say this because the payloads themselves are benign;  I do not recommend doing this with all payloads.

My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.


Why do firewalls focus on tcp and udp? From what I can see, most firewalls seem to focus on tcp and udp. Why is that? Is it impossible or at least very unlikely for malware to use other protocols/custom protocols?

In order to use a different protocol, your program must be able to open a socket of that type.

Typically, only TCP and UDP sockets can be opened by non-system programs.

When you try to open e.g. an ICMP socket as non-root, that will simply fail. Also, even if you could, chances are the network stack will just not know what to do with your packets and drop them on incoming.

Nor will routers even route these packets to you.

So, there's no attack or exfiltration surface here, because someone able to open a non-TCP or UDP socket can typically also reconfigure the firewall running on the same computer.

Non-TCP or UDP packets are typically not forwarded by routers, so that's kind of an inherent "drop all" firewall. ICMP is an exception, but that being pretty well-covered by firewalls, too.

There's a few speciality protocols (SCTP comes to mind) that are in use but neither TCP nor UDP, but honestly, when you're configuring your computer to allow a non-superuser to open such sockets, you might as well add specific rules to your firewall to allow these packets through: you're likely operating a backbone network.


export-secret-key after Yubikey is plugged in I have a Yubikey Neo and is running GPGTools (GnuPG/MacGPG2 2.0.28) on OS X (10.11.2). I have generated a master key with SC abilities and separate signing and encryption keys which I have moved to the Yubikey via the keytocard command. These are done on a separate offline computer.

On my day to day computer, I have only imported my public key. When I insert my Yubikey, and run gpg --card-status, as expected it shows two secret subkeys. However, once the Yubikey is removed, I can run gpg --list-secret-keys and it will show both my signing and encrypting secret subkeys. Furthermore, I can gpg --export-secret-key and also reimport them, although these secrets keys are unable to perform any signatures or decrypt any files (again, with the Yubikey removed from the computer). This is very strange behaviour as seems like the computer is reading private keys from the Yubikey and storing it locally (even though these private keys are invalid).

Steps to reproduce:

Start with empty GPG keychain, verify by gpg --list-keys.
Insert Yubikey with subkeys on it, verify these subkeys by gpg --card-status.
Remove the Yubikey.
Run gpg --list-secret-key and the subkeys from the Yubikey will appear.
You may also run gpg --armor --export-secret-key <key> and a private key will be printed (this private key does not seem to be able to perform any actions).

Am I misinterpreting any information?

After the private keys are on the Yubikey, they are not exportable.  What you can export are secret key stubs, which practically only say this key is on a smartcard.  They were the main method of making the key work on a different computer (with the smartcard), but these days, as there is sufficient information stored about the key, all you need is to use --card-status to fetch the same stub from the hardware key, and import the public key.

You can try to see what information is in the exported stub with

% gpg --list-packets --verbose <exported-stub.bin

# off=1796 ctb=9d tag=7 hlen=3 plen=294
:secret sub key packet:
    version 4, algo 1, created NNNNNNNNN, expires 0
    pkey[0]: [2048 bits]
    pkey[1]: [17 bits]
    gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
    serial-number:  <ELIDED>
    keyid: <KEYID>
# off=2093 ctb=89 tag=2 hlen=3 plen=293
:signature packet: algo 1, keyid <KEYID>
    version 4, created NNNNNNNNNN, md5len 0, sigclass 0x18
    digest algo 8, begin of digest 7c 79
    hashed subpkt 2 len 4 (sig created <YYYY-MM-DD>)
    hashed subpkt 27 len 1 (key flags: 20)
    hashed subpkt 9 len 4 (key expires after <TIME>)
    subpkt 16 len 8 (issuer key ID <KEYID>)
    data: [2048 bits]

While it looks like the "secret key sub packet" does have a pkey, but the gnu-diver-to-card entry signifies that there's no secret key present. The signature is the signature of the key, which is to ensure it can be verified with the public key, and does not contain the private key.

Another hint that everything is safe that gpg does not ask for a passphrase to export secret keys in this case.

Update: confirmed via the source that pkey is indeed referring to the public key, not the private key - those are called skeys inside gnupg.  A packet containing the passphrase protected skey would look like:

off=557 ctb=9c tag=7 hlen=2 plen=134
:secret sub key packet:
    version 4, algo 22, created NNNNNNNNNN, expires 0
    pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)
    pkey[1]: [263 bits]
    iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: HHHHHHHHHHHHHHHH
    protect count: NNNNNNN (NNN)
    protect IV:  <IV>
 >> skey[2]: [v4 protected] <<
    keyid: <KEYID>

So in conclusion, the private key is safe, the cryptographic content is not exported the way shown above when using a smartcard such as the Yubikey.


Does rendering of user supplied content imply an xss vulnerability? I am working on a chat program in my spare time.  If a user inputs html it will be rendered, for example, link will render a hyperlink.  At the same time, if you use a script tag, the script doesn't seem to be executed, but is inserted into the dom.  Should I be worried?

Edit:
As I fixed the vulnerability, here's the site for anyone interested.
wezelchat.herokuapp.com And the repo on github.

Yes, it sounds like you should be worried.

I suggest you take a look at OWASP's very extensive XSS testing cheat sheet and see if you can get a popup on your site (indicating that you're vulnerable to XSS).

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

A good one to play with is inserting javascript into an image tag:

or

If you need users to be able to submit HTML then you should build an allow-list to decide which HTML tags (and which attributes within those tags) are loaded into the DOM, and everything else is rendered as text. This can get really tricky though, for example  might be ok, but  is not. This quickly becomes a game of whack-a-mole that the OWASP cheat sheet is likely to win.

At some point, it may be simpler to switch from having users submit HTML, to some kind of standard markdown library (like stackexchange or github does) so that you avoid the whole white-listing game altogether.

TL;DR: if you are allowing arbitrary HTML, then you probably have an XSS problem.


AV detection of signed malware With the massive Sony leaks (including their private keys/certificate), i was wondering:

How do major AVs deal with signed binaries? ie:

Does it influence their detecting ability of the signed malware? If so, how? For example:

Do they check CRLs and get the binaries with revoked certificates under stronger scrutiny?
Do they only check if the certificate was valid at the time of signature?
If 1 or 2 is valid (ie certificate not revoked or binary signed when it was still valid), do the AV blindly accept as legit even if it's a well-known malware that already has it signature among most AV products?

It seems that windows rarely check CRLs and that it might sometimes be complex, inconvenient and expensive to revoke a certificate if it was widely used to sign legitimate binaries in the past. So if they do, is it worth it from the AV point of view?

The point of this question is mainly assessing this assertion from this article from 2012:

  Malware authors are interested in signing installers and not just the drivers, because some antivirus solutions assume that digitally signed files are legitimate and don't scan them, said Bogdan Botezatu, a senior e-threat analyst at antivirus vendor BitDefender.
  "Additionally, signed modules are more likely to be included in whitelisting collections meaning, the chance of them being fully analyzed is lower and they remain undetected for longer period of times," Raiu said.

i don't know much about code-signing, so the problem might be more subtle, thank you for correcting me i i ask the wrong questions :)

Source:http://blogs.mcafee.com/mcafee-labs/signed-malware-you-can-runbut-you-cant-hide

It’s been more than a year since McAfee became an Intel company, and the team and I have been privileged to be a part of designing and developing our DeepSAFE technology, as well as Deep Defender, the first available product that leverages this advancement. Recent threats in the news validate what we’ve been working on, and this blog serves an update to our followers.

Signed Malware Prevalence
Digitally signed malware has received a lot of media attention recently. Indeed more than 200,000 new and unique malware binaries discovered in 2012 have valid digital signatures.
Unique Malicious Binares Discovered With Valid Digital Signatures (cumulative starting Jan 2012)
Source: McAfee Labs Sample Database

Why Sign?
Attackers sign malware in an attempt to trick users and admins into trusting the file, but also in an effort to evade detection by security software and circumvent system policies. Much of this malware is signed with stolen certificates, while other binaries are self-signed or “test signed.” Test signing is sometimes used as part of a social engineering attack.

Test Signing
Test signing is particularly useful to attackers on 64-bit Windows, on which Microsoft enforces driver signing. By default such drivers will not load. However, Microsoft provides developers with the means of disabling this policy, and malware authors have learned to do the same. Rootkits on 64-bit Windows–such as Necurs used by Banker, Advanced PC Shield 2012, and Cridex–use this approach to compromise the operating system. To combat this, Deep Defender Version 1.0.1 blocks test-signed drivers by default, while allowing ePO administrators to selectively exclude in-house kernel driver developer’s systems as necessary.

This is just one layer of protection, of course. Security is about “defense in depth,” from network to silicon. Real-time memory monitoring allows Deep Defender to identify the Necurs rootkit as it attempts to compromise the kernel.

Trying to Hide
Being able to observe transient events in memory allows DeepSAFE to get past obfuscated file views that challenge traditional antivirus solutions.
Case in point is the Mediyes Trojan referenced in the aforementioned press articles. A quick check of our sample database shows more than 7,000 unique binaries in this family. Yet memory rules written over a year ago to cover rootkit techniques are able to proactively identify the latest signed attack, even as a zero day.

After the attacks were known, the certificate was revoked

More to Come
For some time we’ve seen malicious payloads that attempt to steal digital certificates for nefarious purposes, and we are likely seeing the fruits of that labor. With so much malware online, we are sure to see this trend of signed malware continue and increase.
P.S. Deep Defender Version 1.0.1 is currently in beta and is expected to hit the market in Q2. If you’re interested in helping protect the world beyond the OS, we’re hiring.


Is interpreted malware easier to detect than compiled malware? Is compiled code more of a security risk than interpreted code? I'm under the impression that it is due to the fact that compiled code can hide malicious code from malware scans.

No.

Compiled code is just translated into machine code, an attacker can alter instructions for both, compiled and interpreted. Whatever you could do with one, you can also do with the other.

Your decision for either compiled or interpreted should be dependent on what you actually want to do with your code. Compiled languages usually have a higher performance, while you can easily modify interpreted code. It is easy to implement and you can run/test it on the fly.

There should be no difference between interpreted and compiled code regarding security issues, and languages should not be categorized that way in my opinion.


CSRF Origin and Referer Header just check host? Note: This question is not the same as the linked possible duplicate. That question asks how checking the origin/referer header protects against CSRF. This questions is asking how to implement the specific details.

I see a lot of places that to protect against CSRF for a REST API, you should check the referer and origin headers. However, no one seems to explain the details of that. Is just checking that the host is the same sufficient? Should the scheme also be checked?

Not sure I agree with the premise that checking referer and origin headers is the best defence. In a few corner cases both of these headers will be missing. In these cases the only safe option is to block the request, which could break functionality for a few legitimate users.

If this is still the path you want to take, OWASP has a lot of good info on the technicalities:

Start with the origin header, and if it is missing use the referer header.
Again, if none of these are present, you must block.
Comparing URL:s might seem simple, but it is actually a very tricky thing to do. Make sure your comparison is sound, and e.g. that good.com.evil.com does not pass as good.com. That is just an example, I am sure there are more pitfalls out there. Preferably you should use a good well tested library for this task.
It's probably good to check that the scheme is either http:// or https://. Not sure if there are any attacks that can be used if this check is not done, but  god knows what clever tricks there are out there with data URI:s or what not.

If you want other options, consider the classics such as anti-CSRF tokens or double submit cookies. Or for an API, just using a bearer token in the authentication header does the trick.


Question about birthday attack on password Based on birthday attack, you need to generate at least 2^n/2 of possible combination to have 50% chance of finding a password. I have a list of 3000 random password make from 16 characters of upper, lower characters(That's 50^16 possible combinations) hashed into MD5. How many possible combinations i have to look up to find at least half the result of password list above?

I don't think that the birthday paradox applies here.

The birthday paradox states that in your case, if you have 4.6 × 1013 passwords, there is a 50% chance that two are the same.

However, you only have 3000 password hashes. So you would have to look up in the order of 5016/3000 passwords.

The chance that a random password is in your collection is 1-(1-1/5016)3000. If you try 1023 passwords you have a chance of
(1-(1-1/5016)3000) × 1023 ≈ 20%.


Messages encryption and decryption using Keybase.io Could you please describes to me the security benefits of encrypting and decrypting messages using Keybase.io.

Do you think that using such thing will be secure, where the encrypted message redirects through Keybase server to the reciever.

The encrypted messages doesn't have to go through their servers. Keybase just provides a means of getting a public key for a known username on x platform (for example, I have my twitter name and my github verified on keybase, people can use keybase to verify that my twitter is actually mine).
Keybase will provide the public key, which can be used to encrypt a message. Encryption can happen via the command line, or the website. The encrypted message can then be sent however you want.
From their website:

Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, an optional feature we didn't mention above.
On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason

So, keybase never sees your encrypted message. If you don't want to store your private key on keybase, you don't have to. You can handle the decryption yourself or let keybase store your private key.

Could you please describes to me the security benefits of encrypting and decrypting messages using Keybase.io.

You get to verify a users identity, so you know that the person claiming to be me on twitter is actually me (as with github etc).Encryption is easy, as keybase provides the verified public key for you.

Do you think that using such thing will be secure

If you don't store your private key on the server, yes. Unless someone hacks your twitter/github etc. and changes your key proof, you're fine. If you do choose to store your private key on the server, you take the chance of keybase being hacked. Your call on that one.

where the encrypted message redirects through Keybase server to the reciever.

It doesn't. Encryption/decryption happens in JS in your browser. You can send the encrypted message however you want.


Is splitting a REST API server from a Web server considered a security threat? I am participating in a project that involves a JavaScript SPA that provides a service and is intended to interact via REST APIs with one of our servers. Initially, I proposed to work on the two entities as two separate projects; specifically I put forth the following

The user accesses the Web app through a www.myservice.org address
The Web app contacts an api.myservice.org service for REST interactions

but I was immediately faced with rejection. I was told that the Web app, residing at www.myservice.org, should contact the REST server via something like www.myservice.org/api because doing otherwise would entail a security threat. I didn't say this was a bad idea, but I insisted on splitting the API server from the SPA-serving one for the following reasons

Scaling
Separation of concerns
Easier code management

I'm much more of a developer than a system admin and security expert, so I couldn't promptly reply their rejection. Why would having two api.myservice.org and www.myservice.org servers represent a security issue? I was vaguely told about Cross-site scripting but even then the reasoning wasn't perfectly clear to me.

It would be more accurate to say that "using two servers e.g. api.myservice.org and www.myservice.org has security implications " --in other words, would normally be blocked by default server CORS config. But there are safe and secure methods to allow this by adjusting those settings.
The alternative of configuring URL paths to point to different hosts also has security implications. Arguably in favor of your proposed method, due to SEO considerations (i.e. you don't want a search engine indexing your JS lib files).
Read more details about "Cross-Origin Resource Sharing (CORS)" at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS


How should disabling 2FA be handled by a service? Due to personal reasons I recently had to disable and re-enable 2FA on quite a few of services. Now during this action I noticed quite a few different practices when it comes to "what should a user do before being allowed to turn 2FA off".

So the question follows:
What is the most reasonable way to handle deactiviation of 2FA for personal / end-user accounts?

The options I've seen in the wild additionally to "being logged-in" include

No re-authentication
Re-authentication (without) using the password
Re-authentication (without) using one or two 2FA tokens
(No) E-Mail notification of the account owner
(No) Forced log-out of the user on all devices

Read all these points in each variation and combination, so "No-PW+1-Token+No-Email+Forced-Log-Out" is included just like "no-to-everything" as is "PW+No-Token+Email+No-Log-Out".

TL;DR It's a Security vs. Usability thing. I prefer, and advocate for, the way GitHub does it; If the user is already logged in with a 2FA'd session, then require the password when entering the "sensitive" account area (changing email address or 2FA), and then allow disabling 2FA. Once disabled, send a notification email.

This is largely a fight between the UX expert and the security expert. On one hand, if the security guy/gal can get away with it, they'll require the password, email confirmation token, 2FA token, and maybe even an SMS token on top of that. But that will just deter users who will probably keep 2FA disabled forever after going through that horror of a UX.

If the user is already logged in using 2FA, it's reasonable to assume that this session in this browser is not initiated by an attacker. Thus, requiring 2FA while still in the same session is excessive. However, requiring the password is a good practice since the machine might be shared or left unattended by the user. This exactly how GitHub does it:

If the user is not logged in: Follow regular 2FA login flow and continue below.

If the user is already logged in with a 2FA'd session:

User about to enter the danger zone to disable 2FA:

Require them to re-authenticate with the password:

Give them the option to disable 2FA with nothing else required:

Finally, and very importantly, send the user an email notification that 2FA is disabled.

Due to the nature of this change, unlike changing the password or enabling 2FA, I don't think it's necessary here to force-logout all the sessions.


Should i update the BIOS I was reading about BIOS vulnerabilities and rootkits that have flashed malicious code to the BIOS in order to maintain access after a factory reset/operating system install or a hard drive replacement i was wondering if i should update the BIOS if a update is available i read online that it is generally not a good idea to update the BIOS so from a security standpoint should i? Or is there a better method to prevent malware from gaining access to the BIOS and can said malware flash the code remotely or physical access required?

If there is an update available for your BIOS, then you should absolutely update it. Many vulnerabilities in firmware are found and only fixed through an update of the BIOS itself. Forgoing an update could leave you exposed to known vulnerabilities, including those that could allow malware to persist in the BIOS.


What should you do when you notice weird traffic? I'm not at this point yet, thankfully, but being prepared means knowing the answer before the issue arises, so here goes...

You're looking through your firewall / website logs...

And you notice a large number of requests. Someone appears to have portscanned you, or run sqlmap or DirBuster, Nessus, metasploit or whatever. Apart from breaking out in cold sweat and making occult sacrifices to the Internet gods, what are good steps to take at this point?

I'd assume you'd:

go through other logs more carefully than usual, looking for derivations from the norm,
(if it's only from one IP) do a reverse DNS query on them to see if they are associated with any domains, and, if they are, contact webmaster@, abuse@ and other RFC2142 addresses then, if they don't respond within 24 hours contact their ISP.
(if it's from multiple IPs) check if they're using IPs from known anonymizing networks, and if they are, block those anonymizers (as much as possible).
(if egregious enough / a clear attempt to break in or DOS, and not simply reconnaissance) contact the FBI (if any of the IPs are across state lines). Not sure what other law enforcement agencies you'd contact.
Temporarily block ssh logins from non-essential users while the storm is being weathered (so your attack surface is smaller).

I would do the 1st item only.  Additional logs analysis is clearly prudent to make sure no real compromise has occurred.

Blocking IPs is of minimal effectiveness.  Most cyber-criminals aren't breaking into machines from their home network, they're using another compromised machine or a proxy to hide their identity.  Blocking their jumping off point may slow them down, but that's really just a cat and mouse game.  Maybe they'll get bored and give up, so I suppose it has some value, but if you start blocking a lot of IPs, you might be blocking legitimate traffic (customers, for example).

Contacting law enforcement is something I'd save for after being certain that a compromise has occurred and that there is both substantial evidence and I can demonstrate a financial loss.  Otherwise, there's not much they're likely to do.  Prior to an actual compromise, even if that may technically be illegal, LE is so overworked that it's unlikely they'd have resources to even look at it.

My personal server gets portscanned, dirbustered, etc., multiple times a day.  I don't even blink at those reports, it's just noise at this point.


When does it make sense to deploy an embedded firewall on my IoT device? I have a typical IoT set up where a set of IoT devices running embedded Linux are connected to a cloud IoT server. The underlying carrier connection to the internet is over GSM. All communication to the server is secured with TLS implementation including the mutual authentication with server. The devices generate and store sensitive data, which is also secured with secure local storage (though that is not with TPM, rather software based secured storage).
In this scenario, does it make a good sense to also install an embedded firewall  on my device? I mean doesn’t strong encryption and certificate based authentication ensure complete security to IoT device?

I mean doesn’t strong encryption and certificate based authentication ensure complete security to IoT device?

Not at all. (Properly used) TLS only protects the communication against sniffing and modification. Mutual authentication only authenticates the IoT device against the server. None of this protects against bugs in the implementation, improper use of TLS, bugs in the server side which can be used to hijack clients, services which are exposed on the network, backdoors in some firmware you got from a third party, compromising the device with physical access etc.
But, an embedded firewall does not protect against most of these other threats either. If it makes sense to use one in your specific case depends on what the device actually does, what the threats are, what the attack surface of the device is and if a specific firewall implementation reduces the attack surface - none of this is known here.


Hydra brute-force login with a timestamp I am attempting to run a brute-force attack on my router just as a proof of concept and have hit a problem in that the POST request requires a parameter of the current timestamp. Here is my current attempt
hydra -l admin -P passwords.txt -V 192.168.0.1 http-post-form "/goform/formLogin:login_n=^USER^&login_pass=^PASS64^&curTime=TIMESTAMP:S=Logout"

I want to insert the current timestamp for the parameter curTime, how would I do this?

It depends on the desired timestamp format.
If your format is supposed to look like 2020-07-12 07:52:01 for example, then you could use (assuming that you run your command from some kind of Linux/Unix):
hydra -l admin -P passwords.txt -V 192.168.0.1 http-post-form "/goform/formLogin:login_n=^USER^&login_pass=^PASS64^&curTime=$(date '+%Y-%m-%d+%H:%M:%S' | sed s/:/%3A/g):S=Logout"

Adjust the date format string to your needs.


How can I decode a message that was encrypted with a one-time pad? How can I decrypt a message that was encrypted with a one-time pad? Would I need to get that pad, and then reverse the process? I'm confused here.

One-Time Pad is unbreakable, assuming the pad is perfectly random, kept secret, used only once, and no plaintext is known. This is due to the properties of the exclusive-or (xor) operation.

Here's its truth table:

A xor B = X

A | B | X
0 | 0 | 0
0 | 1 | 1
1 | 0 | 1
1 | 1 | 0

Number of 0s in column A = 2
Number of 1s in column A = 2
Number of 0s in column B = 2
Number of 1s in column B = 2
Number of 0s in column X = 2
Number of 1s in column X = 2

Note that it introduces no bit-skew - the number of 0s and 1s in the inputs are equal to the number of 0s and 1s in the output, i.e. two of each. Furthermore, if you know only one element from a row, you cannot predict the values of the other two, since they are equally probable.

For example, let's say we know that X is 0. There's an equal probability that A = 0 and B = 0, or A = 1 and B = 1. Now let's say we know that X is 1. There's an equal probability that A = 0 and B = 1, or A = 1 and B = 0. It's impossible to predict. So, if you only know one element, you cannot possibly determine any information about A or B.

The next interesting property is that it is reversible, i.e.

A xor A = 0
B xor B = 0

A xor 0 = A
B xor 0 = B

A xor B xor B  =  A xor 0  =  A
A xor B xor A  =  B xor 0  =  B

So, if we take any value and xor it with itself, the result is cancelled out and it always results in 0. This means that, if we xor a value A with a value B, then later xor that result with either A or B, we get B or A respectively. The operation is reversible.

This lends well to cryptography, because:

xor introduces no bitskew
xor has equally probable inputs for any given output
given any two of A, B, X we can compute the third

As such, the following is perfectly secure:

ciphertext = message xor key

but only if message is the same length as key, key is perfectly random, key is only used once, and only one element is known to an attacker. If they know the ciphertext, but not the key or message, it's useless to them. They cannot possibly break it. In order to decrypt the message, you must know the entire key and the ciphertext.

Keep in mind that the key must be completely random, i.e. every bit must have an equal probability of being 1 or 0, and be completely independent of all other bits in the key.

This actually turns out to be rather impractical, for a few reasons:

Generating perfectly random keys is hard. Software generators (and many hardware generators) often have minuscule biases and odd repeating properties. It's almost impossible to gain truly random data in anything but tiny amounts.
If the attacker knows the ciphertext and can correctly guess parts of the message (e.g. he knows it's a Windows executable, and therefore must start with MZ) he can get the corresponding key bits for the known range. These bits are useless for decrypting other parts of the message, but can reveal patterns in the key if it's poorly generated.
You must be able to distribute the key, and your key must be equally as long as your message. If you can keep your key 100% secret between those of you who are authorised to read the message, why not just keep your message 100% secret instead?

The weak link here is your random number generator. The security of the one time pad is entirely limited by the security of your generator. Since a perfect generator is almost impossible, a perfect one-time pad is almost impossible too.

The final problem is that the key can only be used once. If you use it for two different messages, and the attacker knows both ciphertexts, he can xor them together to get the xor of the two plaintexts. This leaks all sorts of information (e.g. which bits are equal) and completely breaks the cipher.

So, in conclusion, in a perfect one-time pad you need to know the ciphertext and key in order to decrypt it, but perfect one-time pads are almost impossible.


Token-based authentication - Securing the token I have developed a backend REST API for a mobile app and I am now looking to implement token-based authentication for it to avoid having to prompt the user to login on every run of the app.

What I had in mind was on the initial request the user sends their credentials using Basic authentication over SSL. Once the server authenticates the credentials it creates a secure token and sends it back to the user so they can use it in subsequent requests until the token either expires or is revoked.

I am looking for some advice as to how I can generate a token which won't be susceptible to things like MoM/Replay attacks as well as ensuring the data stored within the token cannot be extracted out.

I am going to use the following approach to generate the token which I think would prevent any data from being extracted from it. However, I still need to make sure it's not vurnerable from other attacks.

The API will only be accessible over SSL but I am not sure if I can rely solely on this from a security perspective.

The "authentication token" works by how the server remembers it.

A generic token is a random string; the server keeps in its database a mapping from emitted tokens to authenticated user names. Old tokens can be removed automatically in order to prevent the server's database from growing indefinitely. Such a token is good enough for security as long as an attacker cannot create a valid token with non-negligible probability, a "valid token" being "a token which is in the database of emitted tokens". It is sufficient that token values have length at least 16 bytes and are produced with a cryptographically strong PRNG (e.g. /dev/urandom, CryptGenRandom(), java.security.SecureRandom... depending on your platform).

It is possible to offload the storage requirement on the clients themselves. In the paragraph above, what "memory" should the server have of a token ? Namely the user name, and the date of production of the token. So, create your tokens like this:

Server has a secret key K (a sequence of, say, 128 bits, produced by a cryptographically secure PRNG).
A token contains the user name (U), the time of issuance (T), and a keyed integrity check computed over U and T (together), keyed with K (by default, use HMAC with SHA-256 or SHA-1).

Thanks to his knowledge of K, the server can verify that a given token, sent back by the user, is one of its owns or not; but the attacker cannot forge such tokens.

The answer you link to looks somewhat like that, except that it talks about encryption instead of MAC, and that's:

confused;
confusing;
potentially insecure;

because encryption is not MAC.


DLP to protect Source code for Startups My client is a small startup who wants to protect their Source code, have basic network security, USB disable etc. are in place.

Wondering what are DLP options suitable for a small startup, mainly to protect intentional or accidental Source Code exposure.

Thanks

I don't think this is as easy as simply plugging in some DLP product into some arbitrary environment.

I would say it is practically impossible to actually prevent intentional stealing of information by a insiders who needs on the one hand to have access to the code for working and on the other to have some way to communicate with externals (like surfing the web to get information). While one could probably prevent direct channels between the communication part and the code writing part by having these in physically separate networks and systems this will noticeable impact the productivity and is thus impractical for most environments. It is probably especially unacceptable for startups where a high trust in each other is often necessary to achieve the necessary flexibility and high productivity.

Accidental spilling of source code by insiders is a bit different. DLP might maybe prevent that employees post snippets of the code into some external sites like stackoverflow. But this comes at the cost of not allowing to post anything (which again impacts productivity) or by somehow inspecting every traffic (include SSL interception) and comparing posts to parts of the source code - which somehow requires the DLP to get information about the code it should protect. But the question is if leaking small snippets of the code is even a significant problem at all.

More of a problem is likely leaking major parts of the code. Accidentally leaking major parts by insiders suggests that there is some problem of how the source code is handled internally, i.e. it is more a process problem where a DLP does not really help. Thus make sure from how processes are designed and lived that there is not even a need to have source code outside the company, i.e. that there is no need to have source code available on some cloud systems in order to run your product or that source code has to be shipped to customers so that they can run your product. Unfortunately there are not enough specific information about your use case so these can only be very broad recommendations.

Leaking major parts of the code by attackers is a problem where DLP is probably the less relevant part. Instead the usual recommendations apply, i.e. proper security in the first place in order to make intrusion into your network and lateral movement inside the network sufficiently hard, proper monitoring what happens. And then make sure that it is clear who has access to the data and when and how (from which systems) etc. And make sure that it is not only clear but that it gets actually enforced and monitored against unusual usage pattern. And the more restrictive this access is the better - but more restrictions come again with a loss in flexibility and productivity. Zero-Trust concepts like BeyondCorp might help here. But if they can be implemented depends a lot on the specifics of the infrastructure and environment, used applications ... So again, these can only be broad recommendations.


Github private repo safe from scrapers? I have a question about the security of private repo's on Github. Assume you use HTTPS authenticated against SAML SSO to fetch and push changes to remote. Could an outside adversary scrape the files from the display page if they know the URL?

Someone who does not have access to a private repository sees a 404 Page not found error. So no, if an outsider knows the url he can not scrape the contents of your github repository page.


How to exploit this include_once vulnerability in PHP? I'm performing a static analysis on a PHP code and came across this situation:

include_once SYSTEM_PATH . 'languages/content-' . $_COOKIE ['lang'] . '.php';

If I try to hack with this HTTP request:

GET /en-us HTTP/1.1
Host: xxxx.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: xxx=eng.php/../../../anotherfile
Connection: keep-alive

The response is this:

ErrorException:
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

The file languages/content-eng.php exists on the server.
The file languages/../../../anotherfile.php exists on the server too (I have access to the file system).

Is there any way to exploit this vulnerability through lang cookie?

Sigh. Here is the reasoning for me posting a link in lieu of a long answer. Original post wants to inject/disaffect/exploit through the lang variable in cookie:

GET /en-us HTTP/1.1
Cookie: xxx=eng.php/../../../anotherfile

He then states he tried and failed:

ErrorException:
include_once(/export/htdocs/xxxx.com/base/languages/content-eng.php/../../../anotherfile.php): failed to open stream: No such file or directory

"No such file or directory" to me means one of a few things:

1) His directory traversal is off:

/export/htdocs/xxxx.com/base/languages/content-eng.php
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/anotherfile.php

If the structure is exactly as above, there is no directory traversal vulnerability period.

2) eng.php is not detailed enough to know what it does. This would have to be the vulnerable weak link on the chain

He is relying on an error, thinking: "Oh well I have an error, I am headed on the right track"

OP: You could fiddle with the directories a bit more. It is telling you "I can't find this file" the issue becomes "what are you finding" if you state you have access to the machine, the solution I would use would be to place tokens in folders to determine where you are landing:

/export/htdocs/xxxx.com/base/languages/**option1**/token1
/export/htdocs/xxxx.com/base/languages/**option1/option2**/token2
/export/htdocs/xxxx.com/base/languages/**option1/option2/option3**/token3

Then try another POST/GET perhaps:

Cookie: xxx=eng.php/token1
Cookie: xxx=eng.php/token2
Cookie: xxx=eng.php/token3

Cookie: xxx=eng.php/../token1
Cookie: xxx=eng.php/../token2
Cookie: xxx=eng.php/../token3

Cookie: xxx=eng.php/../../token1
Cookie: xxx=eng.php/../../token2
Cookie: xxx=eng.php/../../token3

Just because you got an error, does not mean directory traversal is present. For all you know it's is a global error you are getting. The initial link I sent was to guide you on a "known known" (variable you control) lang.

EDITING FOR SPACE CONSTRAINTS:

OP: "The base is /export/htdocs/yyy.com/base/. The anotherfile.php is in /export/htdocs/xxx.com/anotherfile.php"

Unless I am misinterpreting this:

/export/htdocs/yyy.com/base/

/export/htdocs/xxx.com/anotherfile.php

Are these on separate sites? If xxx.com is your own server/test machine, I'm under the impression you're trying an LFI exploit:

you --> modify cookie (hey, take this anotherfile.php from my machine) --> yyy.com

Again, the reasoning for my initially posting a link in lieu of an answer. If you meant the other way around (typo):

/export/htdocs/yyy.com/base/

/export/htdocs/yyy.com/anotherfile.php

Then you need to modify your insertion to ../../anotherfile or move another file into:

/export/htdocs/yyy.com/base/


What dangerous characters need to be filtered from user input prior to use in a DB2 SQL query? I'm looking to fully understand how to properly filter/escape dangerous characters from user input that will be interpolated into a DB2 SQL query.

The sanitization routing that I'm analyzing works like this:

Remove all backslashes  ( s/\\// )
Replace all single quotes with double single quotes ( s/'/''/ )

My first instinct was to examine an existing db2 sanitization function, to check for any differences. So I took a look at db2_real_escape_string which, it turns out, is quite different: it prepends backslashes to special characters in the string argument. Characters that are prepended with a backslash are \x00, \n, \r, \, ', " and \x1a.

Some specific questions I have are:

Why does db2_real_escape_string() backslash-escape quotes instead of doubling them up? This seems incorrect.
The sanitization function I'm analyzing fails to escape or filter \x00, \n, \r, \x1a, ". How could these characters be abused by an attacker? This is my primary question.
Another deficiency of my sanitization function is that it is not charset-aware, but I'm guessing that this isn't an issue because db2, in this case, is configured to use to the default charset (which I'm guessing isn't multi-byte). So AFAIK, unless a multi-byte charset like GBK was configured, multi-byte sql injection attacks like this known vulnerability in mysql GBK shouldn't be an issue.
Are there any other considerations/steps that the sanitization function I'm analyzing is missing?

I understand that using parameterized queries is the obvious solution. However, in this case, I am responsible for A) determining if the current design is exploitable and B) providing a patch for the sanitization function (if one is necessary).

edit I am basically looking to construct a proof of concept sql injection payload, given the above sanitization function and the following usage:
execute( " SELECT foo FROM bar WHERE col='" + my_sanitize($_GET['input']) + "'" )

Given the current sanitization function design (remove backslashes and double-up single quotes), is there any way to break out of single quotes as in the above usage example?

Thanks for your assistance!

"Sanitization" is fragile. You have to think of every single detail of how the database interprets "special characters", and you have to keep track of it closely, in case a new sub-version of the database introduces extra special characters. This is exhausting work and it often fails.

The (much) preferred way of inserting user data into SQL queries is to use prepared statement. This will be easier for you (the programmer), more robust, more secure, and quite possibly faster.


My machine is hacked by someone and used to attack others via ssh, how to stop it? I host my personal website on digitalocean. Nowadays, I received many abuse complaints which finally make them shutdown my machine. I feel really sad and angry.

Someone complaints that my machine is used to attack his machine via ssh. I check my machine, and find two suspects:

root@eva:~# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 566 root 3r IPv6 7494 0t0 TCP *:ssh (LISTEN)
sshd 566 root 4u IPv4 7518 0t0 TCP *:ssh (LISTEN)
php5-fpm 671 root 6u IPv4 7849 0t0 TCP localhost:9000 (LISTEN)
php5-fpm 672 www-data 0u IPv4 7849 0t0 TCP localhost:9000 (LISTEN)
php5-fpm 673 www-data 0u IPv4 7849 0t0 TCP localhost:9000 (LISTEN)
php5-fpm 674 www-data 0u IPv4 7849 0t0 TCP localhost:9000 (LISTEN)
php5-fpm 675 www-data 0u IPv4 7849 0t0 TCP localhost:9000 (LISTEN)
mysqld 759 mysql 10u IPv4 8233 0t0 TCP localhost:mysql (LISTEN)
bash 1018 root 3u IPv4 8700 0t0 TCP *:3245 (LISTEN)
bash 1018 root 8u IPv4 8783 0t0 TCP mysitename.com:57728->91.236.182.1:ircd (ESTABLISHED)
bash 1018 root 9u IPv4 8714 0t0 TCP mysitename.com->ircu.atw.hu:ircd (ESTABLISHED)
apache2 30915 root 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
apache2 30920 www-data 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
apache2 30921 www-data 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
apache2 30922 www-data 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
apache2 30923 www-data 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
apache2 30924 www-data 3u IPv4 4216829 0t0 TCP *:http (LISTEN)
sshd 30948 root 3r IPv4 4217444 0t0 TCP mysitename.com:ssh->210006025170.ctinets.com:64144    (ESTABLISHED)

what is the IRC things? they come out again after I kill them. How can I fix this and fight back? Can anybody explain the theory how I got attacked? and generally, how to react after been attacked.

ps. I did really a small amount of operations on my machine, just host my website there. Basically, I just changed the things under /etc/apache2 and /var/www

You can start by blocking all the outgoing ssh traffic form your server using iptables :

#iptables -A OUTPUT -p tcp –dport 22 -j DROP