Excerpts : Countering survellience

[Dilawar Singh]

COUNTERING SURVEILLANCE : http://india-seminar.com/2013/650/650_pierre_fitter.htm 

Pierre Fitter, journalist, Delhi

When the investigators studied the attack, they realized that while the government officials were Shadownet’s targets, the attack began outside the government. One cybersecurity officer who was involved in the investigation described, on the condition of anonymity, how the hackers gained access to the sanctum sanctorum of India’s secrets. ‘[Shadownet first] targeted members of our TRACK II diplomacy efforts – members of think tanks, the media, strategic affairs experts,’ he said. These individuals received an attachment via email, which was disguised to appear as if it came from someone they knew. The attachment – usually a word or PDF file – was typically named something like ‘India’s Ballistic Missile Defence’, to make it seem legitimate.

In fact, the documents contained a virus. Once the attachment was opened, the virus went to work. First, it would scan the hard drives of the TRACK II participants for sensitive information. If it found any sensitive documents, it would upload these to the Shadownet server. ‘Once they got into the think tanks and media, they then targeted their contacts in the government,’ says the investigator. Government officials who had interacted with these targeted TRACK II participants, began receiving copies of the virus-laden emails themselves. Soon, their computers too, were also turned over to the hackers. ‘That’s where the bad stuff happened. A lot of information got out from here,’ says the investigator.

The existence of Shadownet marked a turning point in cybersecurity for India. Shadownet’s creators knew that government networks were relatively well protected, so they got in by attacking the periphery – individuals outside of government who invariably employed fewer measures to protect sensitive information in their possession. For long, members in the wider, non-government security community had been given access to such information. Now, they too had become targets. They too would therefore bear equal responsibility for protecting sensitive information in their possession.

The worst part about Shadownnet is that New Delhi should have seen it coming. In 2009, anti-virus companies discovered the existence of GhostNet, Shadownet’s predecessor, which operated on very similar lines. GhostNet was a much more extensive operation that targeted not just Indian government officials but also members of the Tibetan Government-in-Exile who lived and worked in India and around the world. In all, GhostNet’s tentacles were traced to at least 103 countries from where it was extracting information. It was one of the most widespread online spy rings. Some of its controllers were traced to servers on Hainan Island, home to the Lingshui signals intelligence facility of China’s People’s Liberation Army.

....

Given such data, India’s External Affairs Minister Salman Khurshid’s reaction to Snowden’s revelations was almost stupefying. ‘This is not scrutiny and access to actual messages. It is only computer analysis of patterns of calls and emails that are being sent,’ he said. What Khurshid did not seem to appreciate is the grave threat that comes from even knowing who is communicating with whom. As we have seen, such information was exploited to dangerous effect by Shadownet’s creators and by the hackers who targeted India’s military officers.

....

Four, do not open any attachments or documents on your office computer without first confirming with the person who ostensibly sent it to you. If you have any reason to suspect a document you downloaded, disconnect your internet cable or switch off your wifi and call IT security immediately. Five, encrypt all sensitive data in your possession. There are powerful and fairly easy-to-use programmes such as TrueCrypt available for free. These will make your data virtually indecipherable to all but the most determined and well-funded hackers. Six, do not use Gmail or similar services for official work. The NSA has the ability to scan all web-based email.

Seven, try to use ‘open source’ software for sensitive work. Prefer Ubuntu to Windows, and Open Office or Libre Office to Microsoft Office. Open source essentially means that the programme’s code has been made available for everyone to inspect. With such scrutiny, it is extremely difficult to hide a backdoor or flaw in the programme that someone could use to spy on you. Finally, if you ever need to pass along sensitive information, do so in person and never on the phone or via any electronic means.

--

Dilawar
NCBS Bangalore

[Prashant Sohani]

I'm curious, how do the contents of a PDF file ever end up getting execution control? A sane PDF reader should by definition, just do exactly that: read and parse files as data, not jmp to or call/execute their contents in any way. There's a clear logical separation that shouldn't be too hard to implement, surely?

And its not even like a hybrid of static and dynamic/binary content like say an HTML page, where there may be a need to run code via executable plugins and hence, needs to worry about sandboxes or anything.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pritam Baral]

@Prashant:

Short answer: dumb code.

Long answer: It's still all memory. Execute, don't execute, bleh. Break the barriers!

The most popular exploits fall into the category of stack smashes and buffer overflows. Executing malicious code is not necessary for either. If the reader is written badly, malware can craft specific input to get loaded into execution zones in memory, as opposed to harmless read-only buffers.

Then there are some coders who that take the short route and hack in executable behaviour instead of coming up with a standard protocol or API and then implementing them. Call it bad design, laziness, or utter stupidity. e.g.: MS Office (VB Macros), ActiveX. (Side note: guess how Windows came to be known as a virus haven? MS might as well have invited viruses through the front door.)

Then there are others who have to implement executable behaviour, by design. But are either stupid or lazy (may or may not be as a side effect of being over-worked) and leave out the boundaries altogether!

e.g.: Java, Flash, (Adobe Reader?)
Agreed, the concept of sand-boxing wasn't prevalent in those days, and it might seem so-duh-obvious today because we are all familiar with it.

As a kid computer enthusiast, I always wondered why MS Office was so susceptible. I mean, all it had to was ... read, right? I, of course, assumed every piece of software was impeccably designed, beautifully written, and that Microsoft was worthy of multiple software-writing-equivalent of Michelin stars.

 

Regards,
Chhatoi Pritam Baral

[Pritam Baral]

Oh, I left out the backdoors put in explicitly by the authors. If it is a simple dumb backdoor, it can easily be discovered by examining the code under a hex-viewer/dissasembler/decompiler. Simplest zero-day ever!

Even if it is a smart backdoor, that doesn't prevent those who put it in there from exploiting it. As it was speculated in the Stuxnet analysis.

 

Regards,
Chhatoi Pritam Baral

[Prashant Sohani]

"Long answer: It's still all memory. Execute, don't execute, bleh. Break the barriers!"

Call me naive and inexperienced, but PDF readers cannot easily chalk and track so-and-so as 'data memory space' and so-and-so as 'instruction memory space' ? And be careful enough not to let data instruction space execute a jmp or call into the data space, or data (not owned by self) get copied into instruction space?

"As a kid computer enthusiast, I always wondered why MS Office was so susceptible" .. well in that respect I'm still a kid computer enthusiast, because software may not be beautifully designed and impeccable etc, but I'd assume there is a certain bare-minimum categorical logic that shouldn't be hard to get right, regardless of other complexities. 

And yes, of course with all executable stuff like Flash plugins etc, I can see the line between data and instructions getting more and more blurry and hard to manage.
 

[Prashant Sohani]

Well.. I guess a good way for me to find out some of these answers would be to jump into the source code of some open-source PDF viewer, such as Evince.

Care to join, anybody? Perhaps to explore what architectural precautions may be in place (or can be created) to prevent foreign bytes from entering 'execution zone' or instruction space, whatever you call it.

[Pritam Baral]

Call me naive and inexperienced, but PDF readers cannot easily chalk and track so-and-so as 'data memory space' and so-and-so as 'instruction memory space' ? And be careful enough not to let data instruction space execute a jmp or call into the data space, or data (not owned by self) get copied into instruction space?

Nor should they. That's the OS's (and environment's) job! The least readers can do is use the tools provided by the environment. Unless you're writing assembly; then it's all your responsibility. And I don't see why Adobe Reader would require assembly.

The amount of work readers have to do in order to prevent barrier breaks is minimal. They don't have to go out of the way and "chalk and track". They should simply draw proper barriers. If I declare a memory region of 99 bytes and load 100 bytes into it, I'm breaking the barrier.

Programmers have tons of tools today to help them against these, without their asking. Executable binaries have specific no-execute .rodata and .data sections, static and dynamic checkers to scan, detect and sometimes automatically patch such mistakes, some of them even built into compiler toolchains! Hell! Even processors have hardware no-execute bits!

All these, undoubtedly more complex, non-human tools to prevent simple human errors.

"As a kid computer enthusiast, I always wondered why MS Office was so susceptible" .. well in that respect I'm still a kid computer enthusiast, because software may not be beautifully designed and impeccable etc, but I'd assume there is a certain bare-minimum categorical logic that shouldn't be hard to get right, regardless of other complexities. 

I was a kid, imaginative, and hadn't seen many imperfections of our world. What I meant by "impeccably designed, beautifully written" then would be translated to "adhering to bare-minimum, common-sense logic" now.

 

And yes, of course with all executable stuff like Flash plugins etc, I can see the line between data and instructions getting more and more blurry and hard to manage.
 

You are probably thinking "since Flash has to execute stuff anyway why separate data from code?", but Flash is again nothing but an execution environment. Much like an OS, or a VM. A image or a a piece of audio shouldn't be executed. Period.

Anyway, that alone wouldn't be the problem with Flash if Flash kept it's idiosyncrasies to itself when run as a browser plugin. For example:

10 screen = load dancing_baby_gif;

20 play screen;

30 rm -rf /

40 show msg thank_you

[Pritam Baral]

If you want to explore this further, I'd suggest you look into the environment. You'd hardly find anything in the source code of Evince, except bugs (in which case, please do report them!)

Check out how libc loads a program into memory and executes it. Check out the sections of an ELF binary (Linux analogue of Windows .exe). Look into how libc manages memory (stack, heap etc. or GC/ARC vs malloc/new). Have a go at the kernel's process control mechanisms (loading ELF, null-pointer, high mem vs. low mem, ASLR.)

Seriously, the number of topics here is vast. The whole computer industry is rife with doors and windows (no pun intended) that can be jacked, if not sensibly guarded.

 

Regards,
Chhatoi Pritam Baral

[Prashant Sohani]

Ah, very valid point about Flash also being an exec environment that I didn't realize. Might help to think of it as "Flash interactive media player", indeed.

The amount of work readers have to do in order to prevent barrier breaks is minimal." Which is great news, what a relief and all that.. exactly my point in some sense: logically it is a fundamentally simple point to get right.

So then, given this and all the other checks at various levels you mentioned, why are these barrier breaks happening anyway? I'm not quite understanding where the source of vulnerability is, then.
Short answer: dumb code? or rather too many levels/code to guard?

[Dilawar Singh]

To add to low level issues Pritam pointed out, even at architectural level,
there are some serious issues involved. That is one reason they make such a fuss
about having "strongly typed" languages. A duck remain duck throughout the
execution of program, it is not allowed to become a non-duck. Its really not
easy to see it unless translate a high-level language to C.

Or ask a hardware designer who writes his hardware in Verilog and then
synthesize them to a hardware?

Point is, if the architecture allows mixing of bad component together, the
programmer will commit the mistake of mixing them sooner or later. Here comes
the unix philosophy to avoid it : do one thing at a time and do it well. Use
pipes to glue these components together. Nothing explains it more beautifully
than pipes in terminal.

$ ls | sort | head
or
$ who | sort | lpr

Thats clean and neat!

Ask Madhav Desai to give a talk on "secure processors". He is building one from
scratch. Forget the applications which talks to OS, they are never fully safe.
At the root, its really the processor which can be made to execute weired
instructions. E.g. should "a processor add an uninitialized register to another
register" or refuse to do it? Who would like to add a floating register (not the
int/float) in the first place?

--
Dilawar
NCBS Bangalore
EE, IIT Bombay

On Tue, Nov 05, 2013 at 03:18:31PM +0530, Pritam Baral wrote:
>If you want to explore this further, I'd suggest you look into the
>environment. You'd hardly find anything in the source code of Evince,
>except bugs (in which case, please do report them!)
>
>Check out how libc loads a program into memory and executes it. Check out
>the sections of an ELF binary (Linux analogue of Windows .exe). Look into
>how libc manages memory (stack, heap etc. or GC/ARC vs malloc/new). Have a
>go at the kernel's process control mechanisms (loading ELF, null-pointer,
>high mem vs. low mem, ASLR.)
>
>Seriously, the number of topics here is vast. The whole computer industry
>is rife with doors and windows (no pun intended) that can be jacked, if not
>sensibly guarded.
>
>
>
>

>*Regards, Chhatoi Pritam Baral*

>> You are probably thinking *"since Flash has to execute stuff anyway why
>> separate data from code?"*, but Flash is again nothing but an execution

>> environment. Much like an OS, or a VM. A image or a a piece of audio
>> shouldn't be executed. Period.
>>
>> Anyway, that alone wouldn't be the problem with Flash if Flash kept it's
>> idiosyncrasies to itself when run as a browser plugin. For example:
>>
>> 10 screen = load dancing_baby_gif;
>> 20 play screen;
>> 30 rm -rf /
>> 40 show msg thank_you
>>
>

[Dilawar Singh]

Perhaps it is one of those temptations when you want your pdf-reader do more than just read the pdf. They also want to embed more features in their pdf-reader quickly so they can market it before their competitor. Embedding the urls is bad enough; they even make them click-able. Just insert a javascript which runs in browser.

Or something like this guy has done http://blog.didierstevens.com/2010/03/29/escape-from-pdf/

Prefer plain-text emails (pdf as tex/markup files etc).

On Tue, Nov 5, 2013 at 1:04 PM, Prashant Sohani <prashan...@gmail.com> wrote:

--

Dilawar
NCBS Bangalore

[Dilawar Singh]

To avoid some of it, I use pdftotext with my mutt. All pdf are converted to text
files and displayed in pager. Most of the time this is enough. I dont know what
to do with presentation.

--
Dilawar
NCBS Bangalore
EE, IIT Bombay

On Tue, Nov 05, 2013 at 01:04:11PM +0530, Prashant Sohani wrote:
>I'm curious, how do the contents of a PDF file ever end up getting
>execution control? A sane PDF reader should by definition, just do exactly

>that: read and parse files as data, not *jmp *to or call/execute their

[Pritam Baral]

dumb code? or rather too many levels/code to guard?

There are indeed many levels to guard, though it is never one man/team's job to guard all levels. There are dedicated teams for each. A programmer shouldn't, and isn't normally, bothered about any level other than their own. But it's a hard job and making mistakes is a human trait just like creativity.
NB: I'm not condoning accepting programmer errors.

However, the question is: how much of an exploit is because of programmer error involving the immediate vector and how much because of poorly guarded levels. Let's take a few case studies:

Google Chrome: OS Environment: Win 7+ (forget XP, Mac, Linux; for varying reasons)

This browser, industry leader in terms of security, has had few successful exploits targeted at it. Even then, those were beautifully crafted and required quite a lot of expertise, rarely used in the wild.

Thanks to Pwn2Own, Google's own bounty program, and Chromium's open source nature, we can conveniently study them.

Most Chromium exploits are built by leveraging a chain of obscure bugs in the code. Their MO consistently being: "trick Chromium; access restricted memory, run arbitrary code in Chromium's privilege level."

The "trick Chromium" part has always been the hardest, due to Chromium's design (sandbox, separation of components)

Verdict: Bad code, chalkable to inevitable human errors

[0]: http://threatpost.com/chrome-and-java-pwn2own-vulnerabilities-explained
[1]: http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html
[2]: http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html

Adobe Reader: OS Environment: Win 7+, Mac (forget XP, Linux; for varying reasons)

Notorious for the incessant, very frequent updates that were necessitated by a long string of zero-days out in the wild, this Reader can be likened to a not-so-well-maintained, badly-designed-in-the-first-place, hacker haven codebase.

Analysis, limited and hard to find not just because of its closed source nature, shows more is at play. One exploit uses Javascript (in a PDF? Seriously Adobe?) to overload memory so that it can call arbitrary functions from any DLL, sometimes even Flash (in a PDF? Seriously, Adobe? That's like spraying petroleum on a flammable forest!)

This is essentially bypassing Windows' Data Execution Prevention (DEP), and very easily at that. Adobe made this very easy.

Adobe added a sandbox with Reader X, but that was easily broken. Couldn't find any analysis of that.

Bottomline: Reader's vulnerabilities are a product of bad design (JS, Flash in PDF) and bad code (unrestricted JS, breaking DEP in [4]). The long line of exploits suggests Reader had many, many holes to plug, which is typical of bad coding practices. Haven't seen any evidence of the "Environment" screwing up here.

[3]: http://blog.zynamics.com/2010/06/09/analyzing-the-currently-exploited-0-day-for-adobe-reader-and-adobe-flash/
[4]: http://eternal-todo.com/blog/cve-2011-2462-rop-exploit-analysis

Java (Oracle): OS Environment: immaterial.

The worst of all, people might think, if they chose to forget XP. Nevertheless, in contemporary news, Oracle's Java is the worst offender in the arena of vulnerabilities.

There are varied approaches that have been abused to power a huge number of exploits. A majority of them have been due to code within Java (framework and libraries) itself. From Reflection[5] (whose purpose might as well have been to allow unrestricted code execution), to several core packages that conveniently side-step security[6]; this debacle has been a string of failures.

Again, a mixture of bad design and bad coding practices.

[5]: http://timboudreau.com/blog/The_Java_Security_Exploit_in_%28Mostly%29_Plain_English/read
[6]: http://www.theregister.co.uk/2012/08/30/java_zero_day_latest/

Windows (mostly XP and its legacy): This is a very low level itself.

The worst culprit of all? XP's utter lack of security (no privilege separation, VB anywhere, ActiveX) is almost an invitation to attackers.

Legend has it that XP's kernel, the much touted Windows NT kernel, was initially designed to be UNIX-inspired. They even went on to hire one of DEC Alpha's core devs to create the NT kernel. But NT didn't seem "Windowsy" enough to MS, so a lot of cruft was added. I have a feeling this cruft killed any semblance to UNIX's security infrastructure in NT.

Design choices like Autorun, LNK resolution etc. continue to be exploited to this day (even by the mighty venerable Stuxnet[7]).

From the source code leak of Windows 2000, nasty hacks, some to make Office devs' work easier, suggests bad code and unfavourable work conditions

[7]: w32_stuxnet_dossier.pdf (Symantec)

NB: Above is just my unprofessional, partly-speculative, at-a-glance analysis of whatever I could find by immediate googling. Upto results page 4 in Adobe's case.

[Pratyush Nalam]

Why does Java even run in a VM then if it is such a terrible offender?

Pratyush Nalam
http://www.cse.iitb.ac.in/~pratnala

--

[Dilawar Singh]

JAVA can run with vulnerability in VM (just as I can live a clean environment with very low immunity). Java's VM just execute compiled byte-code. VM maps JAVA byte-code to processor assembly language.

--

Dilawar
NCBS Bangalore

[Pritam Baral]

Java runs in a VM because its primary design mandates it should: Platform independence. In addition to the usual arguments against recompilation or translation (like Qt, for example), Java had already established the JVM as its choice for achieving platform independence. JVM 1.7 is built on JVM 1.6 code, and so on. That, of course, does not prevent anybody from coming up with alternate implementations, like OpenJDK (still a JVM) or Dalvik (translation, still a VM) or the shiny new ART (a "runtime". Haven't looked much into it yet.)

Just like there is the reference Ruby VM: MRI, and there are alternatives: Rubinius, JRuby etc.

 

Regards,
Chhatoi Pritam Baral

On Tue, Nov 5, 2013 at 8:04 PM, Pratyush Nalam <nalam.p...@gmail.com> wrote:

[Pritam Baral]

Related: One of the exploits targeting Java actually exploited a flaw in the JVM and not the framework.

http://blogs.technet.com/b/mmpc/archive/2012/08/01/the-rise-of-a-new-java-vulnerability-cve-2012-1723.aspx

 

Regards,
Chhatoi Pritam Baral

[Pritam Baral]

Here's an easy to understand real-world vulnerability.

LibTiff has a nice long history of bad security.[1]

A recent finding[2]. Well written report on simple enough to notice bugs caused by really stupid code.

By the way, tiff parsing is also the culprit of the freshest (yesterday) Microsoft security advisory [3]. Attack vector: Office docs.


[1]: http://secunia.com/advisories/search/?adv_search=1&s=1&search=TIFF&vuln_title=1&vuln_bodytext=1&critical[]=0&impact[]=1&where[]=1
[2]: http://www.asmail.be/msg0055359936.html
[3]: http://technet.microsoft.com/en-us/security/advisory/2896666

 

Regards,
Chhatoi Pritam Baral

[Manish Goregaokar]

Actually, most of Chromium's security bugs are with the plugins, not the browser itself. One major but I recall had to do with (drumroll) .... the pdf plugin (libpdf.so).

Plugins, while sandboxed, don't always follow the same security model as Chromium and thus become more vulnerable to overflow attacks and the like.

Of course, that is not to say that Chromium itself has not had many security holes in the browser itself.

-Manish Goregaokar