Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Source Code Leaked For Tinba Banking Trojan

timothy posted about 2 months ago | from the small-can-be-potent dept.

Crime 75

msm1267 (2804139) writes "The source code for Tinba, known as the smallest banker Trojan in circulation, has been posted on an underground forum. Researchers say that the files turned out to be the source code for version one of Tinba, which was identified in 2012, and is the original, privately sold version of the crimeware kit. Tinba performs many of the same malicious functions as other banker Trojans, injecting itself into running processes on an infected machine, including the browser and explorer.exe. The malware is designed to steal financial information, including banking credentials and credit-card data and also makes each infected computer part of a botnet. Compromised machines communicate with command-and-control servers over encrypted channels. Tinba got its name from an abbreviation of "tiny banker," and researchers say that it's only about 20 KB in size."

cancel ×

75 comments

Sorry! There are no comments related to the filter you selected.

And 100 years ago (-1)

Anonymous Coward | about 2 months ago | (#47440909)

begain World War ONE!

Re:And 100 years ago (0)

Anonymous Coward | about 2 months ago | (#47440959)

Not yet. Today is July 13, 2014. World War I begain on July 28, 1914.

Re:And 100 years ago (0)

Anonymous Coward | about 2 months ago | (#47441001)

Wrong calendar.

Re: And 100 years ago I banged your great grandmot (-1)

Anonymous Coward | about 2 months ago | (#47441069)

Not true, but neither was your statement. Fucking moron.

Trojan man! (0)

Anonymous Coward | about 2 months ago | (#47440913)

Bank on it

20k (5, Funny)

Anonymous Coward | about 2 months ago | (#47440921)

this makes the trojan the least bloaty program on the average windows PC.

Re:20k (5, Insightful)

CaptnZilog (33073) | about 2 months ago | (#47441019)

If we could get the hired at MS maybe windows could run on a 256M machine. :P

Re:20k (2)

buckfeta2014 (3700011) | about 2 months ago | (#47441095)

With a size that small, I have to assume the security hole in windows is either really huge, or the virus is written in assembly.

Re:20k (1)

Anonymous Coward | about 2 months ago | (#47441727)

It's both.

TFA [www.csis.dk] confirms that it's written in assembly and saying that the security holes in Windows are really huge, well, that's just common knowledge.

Re:20k (-1)

Anonymous Coward | about 2 months ago | (#47441111)

And it's positively microscopic compared to the faggotry going on in Linux these days.

But you like having a big systemD up your bum, don't you?

Re:20k (0)

Anonymous Coward | about 2 months ago | (#47441675)

I think if hardware manufacturers teamed up with trojan vendors the trojans might get bigger.

Karel K., Twibright Labs [twibright.com]

Aw. (-1)

Anonymous Coward | about 2 months ago | (#47440947)

It's adorable!

Kudos to Dennis Fisher (0)

Arker (91948) | about 2 months ago | (#47440961)

For writing an article about IT-criminals in which he refers to them as IT-criminals.

Even if it does appear on a page with a prominent link to another article which misuses the term 'hackers' in its very title. I am sure that was beyond his personal control.

Also it sounds like some really good programming! 20kb compiled, and full functional. From <a href="https://www.csis.dk/en/csis/news/4303/">this report</a> it appears that it's written in assembler. Does anyone have a link to the actual code?

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47440981)

Does anyone have a link to the actual code?

No one wants to be on the cyber-terrorist watch list.

Re:Kudos to Dennis Fisher (3, Insightful)

Anonymous Coward | about 2 months ago | (#47441027)

You're already on it.

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47441149)

it appears that it's written in assembly.

Re:Kudos to Dennis Fisher (-1)

Anonymous Coward | about 2 months ago | (#47444211)

It's okay. We already know Arker is a stupid fat faggot. The fact he calls assembly language "assembler" all relates back to the stupidity that causes his autistic compulsion to wrap all of his posts in tt tags.

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47441187)

Technically it wasn't compiled, since it's written in assembly. Assembly can only be assembled. When you use a compiler it generates code that is assembled.

Re:Kudos to Dennis Fisher (-1)

Anonymous Coward | about 2 months ago | (#47441223)

Ancient compilers output assembly for later code generation. All modern compilers (gnu/gcc stuff is ancient, not modern) go straight to machine code (compile/link). There is no assembler used, though perhaps there is an IL, but no assembler. Going to assembly loses all meta-data about the compilation units which prevents any further optimization. Those using any sort of assembler to finish their C from 1989 need to get with the times. Move out of the your rut. Caution: You may need to pay money. Warning: You may stay down in your hole but know it's filling in with dirt.

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47441255)

Go back to your hole, clang troll.

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47442159)

It's a start but mainstream articles really need to specify which operating systems the code affects. Just because 99% of exploits are effective on an easily-exploited OS like Windows doesn't mean it's implied.

Although I suspect a lot of the high-profile mags specifically don't mention Windows because of pressure from Microsoft. The only reason the ultra-rare exploit for Apple or other UNIX/BSD-based OS's is mentioned is, well, because it is so rare.

Re:Kudos to Dennis Fisher (0)

Anonymous Coward | about 2 months ago | (#47442551)

That's right, just keep whining about the word "hacker", as if it matters. Don't bother focusing on anything important.

The Gay Mafia? (2, Funny)

Anonymous Coward | about 2 months ago | (#47440973)

Hold me closer Tiny Banker...

Re: The Gay Mafia? (0)

Anonymous Coward | about 2 months ago | (#47440999)

It dances away with your credit card info.

Who leaked it? (0)

Greyfox (87712) | about 2 months ago | (#47440995)

Trojan Man?

Tinba! (4, Funny)

Anonymous Coward | about 2 months ago | (#47441011)

His arms wide...

Re:Tinba! (0)

Anonymous Coward | about 2 months ago | (#47441751)

His arms wide...

Don't you mean "Tinba, its source leaked"?

Re: Tinba! (0)

Anonymous Coward | about 2 months ago | (#47442087)

Too direct. Needs to be a metaphor.

So a leak is more likely to be "Snowden and Greenwald at Hong Kong".

Asian Trojan (-1)

Anonymous Coward | about 2 months ago | (#47441059)

I guess this smallest trojan is for Asians.

Source name (-1)

Anonymous Coward | about 2 months ago | (#47441123)

If you're looking for the source, just google for "TinyBanker.rar".

Re:Source name (-1)

Anonymous Coward | about 2 months ago | (#47441629)

If you're looking for the source, just google for "TinyBanker.rar".

TinyBanker source code http://sinowal.com/TinyBanker.... [sinowal.com] [for RE only, it's public anyway]

Re:Source name (0)

Anonymous Coward | about 2 months ago | (#47442321)

SHA256 for file c196974841812ee700d9dba488d9def528374ad5729111c31ddd031723ec3f2e

Google search for that gives only a discussion on twitter. No MD5 or SHA1 results worth finding.

Re:Source name (0)

Anonymous Coward | about 2 months ago | (#47442593)

Thanks for supplying the hash. I sure as hell wouldn't want to download an untrusted version that might be backdoored.

Re:Source name (0)

Anonymous Coward | about 2 months ago | (#47444277)

Speaking as the person who supplied the hash. I still haven't opened it locally. I still have doubts what I already did with it downloading it and checking what kind of file it was. I tried unpacking it on an online unzip site and it didn't show the files. The only thing that the SHA256 gives you is a pretty good belief you have the same file that I have.

Why isn't it opensource? (0)

Anonymous Coward | about 2 months ago | (#47441225)

why isn't it opensource in the first place? if I were you, I wouldn't trust any closed source binary kit that might be used against me.

Windows DLL injection attack vector. (5, Interesting)

Animats (122034) | about 2 months ago | (#47441351)

Remind me again why Windows has the capability to "inject" a new DLL into a running process from outside the process.

Re:Windows DLL injection attack vector. (5, Insightful)

Anonymous Coward | about 2 months ago | (#47441369)

I'm sure the NSA will let us know is due course.

Re:Windows DLL injection attack vector. (-1)

Anonymous Coward | about 2 months ago | (#47441401)

Remind me again why a free, "superior" operating system couldn't gain any appreciable market share in the consumer space until an enormous publicly traded company put it on a phone.

Re:Windows DLL injection attack vector. (4, Informative)

SeaFox (739806) | about 2 months ago | (#47441479)

Remind me again why a free, "superior" operating system couldn't gain any appreciable market share in the consumer space

Because consumers will generally buy what they're convinced they should by marketing before they get off their butts and actually do research and then make choices. Windows has a major corporation pushing out advertising backing it. Whereas for much of Linux's existence it's coding was a volunteer effort, let alone having paid marketing. Why did Betamax, the superior video cassette tape format, lose to beta? The consumer space was flooded by JVC pushing licensing to anyone, unlike the more restrictive Sony -- gee, kinda like IBM/PC vs Macintosh.

Re:Windows DLL injection attack vector. (1)

stderr_dk (902007) | about 2 months ago | (#47441765)

Why did Betamax, the superior video cassette tape format, lose to beta?

Uh! I know this one! Because "Fuck Beta"?

Re:Windows DLL injection attack vector. (1)

JonathanR (852748) | about 2 months ago | (#47441889)

As it happens, the fucks were on VHS.

Re:Windows DLL injection attack vector. (1)

penix1 (722987) | about 2 months ago | (#47441957)

I am agreeing with what you said putting aside the beta/VHS blunder....

But there is a more direct way it happened that Windows got more market share... Namely, it is what comes with most, if not all, new consumer x86 based computers. It is just about impossible to get a supported Linux computer and by supported I mean one that will solve problems with the programming not just the hardware.

So to recap, it isn't solely marketing that gives MS their dominance but their partnering with OEMs and to a lesser extent their abuse of their monopoly to keep competing operating systems off new machines.

Re:Windows DLL injection attack vector. (1)

Anonymous Coward | about 2 months ago | (#47442015)

You missed the point. Notice the word "superior" was in quotes. Linux is only considered superior by Linux zealots and FOSS advocates. While the kernel itself is reliable and effect enough to be considered acceptable, the desktop environment and software ecosystem is a fucking disaster that literally screams, "this is amateur shit!", largely because it is crafted by volunteers. Note that 75% of Linux kernel development is done by paid developers.

Re:Windows DLL injection attack vector. (0)

Anonymous Coward | about 2 months ago | (#47442929)

If Linux were more popular it would have a better userland.

Re:Windows DLL injection attack vector. (0)

Anonymous Coward | about 2 months ago | (#47443295)

You evidently know nothing of the linux destop - for starters there is not A linux destop, but many, and many of them are as professional looking as you could wish for.

I have been using my linux laptops in class for over a decade; I enjoy changing the desktop to keep the students on their toes. There was one version which had half the class convinced I was running a Mac until I showed them the Asus logo on the lid.

Don't bother replying, I shan't be reading it...

Re:Windows DLL injection attack vector. (1)

Calavar (1587721) | about 2 months ago | (#47446791)

Proponents of the Linux desktop can't use the marketing excuse anymore: Ubuntu is commercially backed with plenty of advertising money, but it has not taken the desktop by storm. Why? Usability. The Linux ecosystem was designed by programmers for programmers, so Linux apps are built with a command line interface that works perfectly and a GUI that's tacked on as an afterthought.

Sure, you and I don't have a problem with messing ifconfig if the Wicd GUI crashes, but what about your grandma? Forget that, what about your non-programmer cousin? And let's not ignore the fact that the Wicd GUI, despite being a GUI, is still pretty complicated compared to the Windows network manager. If you want to connect to a network in Windows, you go to Networks and Sharing, click on the network you want, enter the password, and boom, you're done. With Wicd, the first option you see when you select a WPA network is "WPA Supplicant Driver" and below that you see "Use dBm to measure signal strength." When you enter the password, there is a box to "Use these settings for all networks sharing this essid." That's an awful lot of jargon, and it scares laypeople away.

Linux excels where usability for the layperson is not an issue. That's why it dominates the server market: sysadmins feel most at home on the terminal.

Re:Windows DLL injection attack vector. (0)

Anonymous Coward | about 2 months ago | (#47441501)

You just answered your question. Consumers don't understand what is 'superior'. They just buy what are they being told is good by 'enormous publicly traded companies'.

Re:Windows DLL injection attack vector. (1)

EvilJoker (192907) | about 2 months ago | (#47443719)

What defines "superior" and "good" vary by user. While there are many who point out that Beta had better picture quality, the feature that most users wanted was length of recording. Therefore, the "better" option was VHS.

The purpose of marketing is to sell a product, specifically the product you are marketing. There is plenty of counter-marketing, and people will generally decide based on that. While JVC (etc) were promoting a cheaper machine, with a longer recording time, Beta was promoted for picture quality. Consumers chose the former.

Most end-users are given the options of buying a Mac (ready to go), buying a Windows PC (ready to go), or building a PC, installing Linux themselves, and hoping it all goes well, and then having very little support if it doesn't. For people that just want to do e-mail and web-browsing, this is going to be a very tough sell.

Re:Windows DLL injection attack vector. (2, Interesting)

Anonymous Coward | about 2 months ago | (#47441471)

One reason could be to have the ability to extend the functionality of other programs. For example, back in the MSN Messenger/Windows Live Messenger days, there was a program called Messenger Plus!, which added lots of functionality to MSN/WLM. I don't think it would had been possible without DLL injection.

Re: Windows DLL injection attack vector. (1)

Anonymous Coward | about 2 months ago | (#47441609)

Doesn't even need to be a DLL. You can allocate memory in a remote process via virtualalloc and the put you malicious code in the other processesemory. From there you just use createremotethread and bobs your uncle, your running your code from inside another application with full access to its memory space.

Re:Windows DLL injection attack vector. (1)

Anonymous Coward | about 2 months ago | (#47441771)

Since it is useful for extending programs you do not have the source of. We use it a lot in our company to make measurement software write to an OML database without having to screenscrape its windows.

You can do this with linux too, via /dev/(k)mem, but it is much less clean.

Re:Windows DLL injection attack vector. (1)

Anonymous Coward | about 2 months ago | (#47441833)

no need for that. you just use LD_PRELOAD.

That IS a great question... apk (1)

Anonymous Coward | about 2 months ago | (#47441825)

One I've often wondered about myself. Makes NO sense coming from an EXTERNAL process (ala viruses), since yes, the DLL is sensible to have around in & of itself (to extend a program AND entire OS with an "object-oriented" if not "object request broker" style statndardized function set that's proven paradigm, via say, the LoadLibrary API function (not sure if THAT is the Win16/32/64 PE call specifically, especially out of kernelmode native API that is (even NTDLL has LoadLibrary though iirc... however, I just use it through compiler's individual commandsets mostly as is & don't GENERALLY pay attention to the "origination area" particulars, unless I require speed and minimimalizing context switching overheads between usermode & kernelmode, vs. message passing overheads etc. - I just use what works best, for what's needed @ the time (screw technical esoterica, in other words, lol!)).

HOWEVER, WHY WHAT YOU SAID?

This poster made a great point on that (missed buffer overflow usage imo but did a good job of it) -> http://yro.slashdot.org/commen... [slashdot.org] and his "Bob's Your Uncle" gave him away CLEARLY as a "limey" (but his insight shows he's a credit to the brits imo).

It *may* have to do with COM/DCOM/OLE etc. though (specifically REMOTE types though, not straight local OLE or COM, but more DCOM)... see, that is where I get "dim" on it myself (admittedly), though however?

THERE it *might* make sense to have it available!

I.E.-> to be ABLE to remotely (in distributed computing using DCOM) inject and enhance the remote OTHER running EXTERNAL process on ANOTHER remote system!

(apartment multithread types)

Since apartment type doesn't use windows messaging I noted above, AND, dealing in "out of process" execution models, vs. IN PROCESS types.

May have less overheads, better extensibility, etc.

APK

P.S.=> That's a great question of yours, & it might take a better coder than ME to answer it right is all - I can only speculate a bit here pointing out what i did... Hope I didn't sound TOO "fuzzy" there, since I am only speculating on what I DO know & use, regularly... I don't do a LOT of DCOM work is why! apk

Addendum/small correction... apk (0)

Anonymous Coward | about 2 months ago | (#47441845)

Haven't been expressing myself well today (need "consciousness fuel"/coffee, the BREAKFAST OF CHAMPIONS, lol!).

Correcting this from myself, somewhat (clarifying it to multithreaded apartment types that is):

"Since apartment type doesn't use windows messaging I noted above, AND, dealing in "out of process" execution models, vs. IN PROCESS types" - by Anonymous Coward on Sunday July 13, 2014 @06:58AM (#47441825)

Better stated/clarifying what aparment type - Message filters aren't used in multithreaded apartments types. So for DCOM based apps? DLL injection from a remote locale may make a LOT of sense.

APK

P.S.=> Still, I do "stick by" what I said earlier - that it *MAY* make a LOT of sense in doing DCOM (where the lib is not called on locally, but it's functionality COULD be injected into a local process, from a remote locale) - again, someone more well-versed in DCOM can feel absolutely free to correct me here (I don't *do* "loads of DCOM" usually, & am no expert in it either)... apk

Re:Addendum/small correction... apk (0)

Anonymous Coward | about 2 months ago | (#47442075)

What does APK stand for?

Re:Addendum/small correction... apk (1)

Anonymous Coward | about 2 months ago | (#47442129)

Another Paranoid Kook

Re:Addendum/small correction... apk (0)

Anonymous Coward | about 2 months ago | (#47442373)

Almost Perfect Knowledge. What he wrote may sounds about right. We'll see if a dcom expert shows.

It's "Always Perfect Knowledge"... apk (0)

Anonymous Coward | about 2 months ago | (#47445015)

See here, even on theory alone originally to Animats as to WHY DCOM can use it, & I was DEAD-ON RIGHT on DCOM using it legitimately to marshall libs remotely but the patch for it is/was EXPLOITABLE recently as 2010 (probably still is due to some ports NOT being checked & MetaSploit uses it) -> http://yro.slashdot.org/commen... [slashdot.org]

* :)

(Must "pat self on back", considering I was operating on THEORY ALONE originally in response to him WHY dll injection is useful & allowed... HOWEVER, apparently, there is an actual working method for utilizing DCOM for BOGUS dll injections & remote exploits, since it uses lighter weight rpc, to marshall libs AND exploit the API for it also being abused by MetaSploit... much more scary than standard DLL injection methods if you think about it!)

APK

P.S.=> After all - Animats asked WHY it's allowed & I was *fairly* sure DCOM used it & yes, it does and can marshall libs remotely for it via rpc... boy, does it (bogusly, even though a patch was issued, in 2003 & later, it's been exploited per the SYMANTEC article on MetaSploit, in 2010 (may still be in fact) DCOM's patch & RPC patch? Hey it's NOT "perfect" apparently on certain points)...apk

Quoting (loosely) "Man of Steel"... apk (0)

Anonymous Coward | about 2 months ago | (#47487757)

Lois Lane: "What the 'S' stand for?"

Superman: "It's not an 'S': On my world, it means hope..."

* :)

(I guess that just about does it, but my replies to Animats here did a FAR better job though... & him I respect - why? He's out there doing great things for others + has over time, whereas MANY here, do not... for sure & what a waste imo - you've mostly all got talent, but apparently, many here lack drive & ambition as well as self-belief... without which, you can do nothing)

APK

P.S.=> And, there you are... it somewhat fits, but it did FAR BETTER, in another reply of mine to another on another topic, here -> http://it.slashdot.org/comment... [slashdot.org] ! apk

Re:Windows DLL injection attack vector. (4, Informative)

ComputerGeek01 (1182793) | about 2 months ago | (#47442453)

Damn it, you're going to make me burn the mod points I have already spent in this thread to educate the other *nix fan boys like you. First of all Windows offers a boat load more process memory protection then most other major Linux distros out there which is why DLL injection is necessary in the first place where as in Linux I can just dump the data I want from any memory page I damn well please once I'm running on the remote system. UAC may have been a bit late to the game but it's here now. However despite this solid protections scheme Windows must still remain functional for developers, so the WinAPI is forced to offer some method of run-time debugging for most processes (it does NOT allow this for all of them; things like csrss and lsass are off limits). DLL injection is accomplished by first locating the load point of the Kernel32 DLL in the target process and then going to the offset where the exported GetProcAddress() and LoadLibrary() functions are and invoking them through CreateRemoteThread(). Before even that occurs though the strings that all three of those functions rely on have to already be present in the remote process, this is done with first allocating the memory with VirtualAllocEx() and then writing to it with WriteProcessMemory(). In order for any part of this operation to be possible the end user would have had to of allowed the infection to enable the SeDebug privilege for the malicious process in the first place. Meaning that at some point the end user f***ed the pooch all on their own without Evil Old Microsoft having done anything stupid. Further more absolutely NONE of this would be in the slightest bit relevant if the information was encrypted in process to begin with and that is the fault of the banking systems software vendor. So get off of your wooden high horse, a well documented API being utilized by incompetent third parties is not an insecure one.

Re:Windows DLL injection attack vector. (1)

Anonymous Coward | about 2 months ago | (#47444295)

Sounds like swe have a faggot M$ $hill here. Someone downmod this faggot. I disagree.

Here's a more DANGEROUS way (via DCOM) (0)

Anonymous Coward | about 2 months ago | (#47444979)

& its use of rpc -> http://yro.slashdot.org/commen... [slashdot.org]

* I hit on it "on theory alone" originally in reply to Animats -> http://yro.slashdot.org/commen... [slashdot.org] as to WHY it may be used, albeit LEGITIMATELY for DCOM marshalling of libs remotely, & yes, EVEN FOR EXPLOITS as well - albeit not just DLL injection locally, but rather REMOTELY (which is what Metaploit IS exploiting... & imo, it's FAR MORE DANGEROUS this way!)

APK

P.S.=> The "complete rundown" on it, is here (pertinent excerpts included from Symantec & MS regarding exactly how Metasploit's exploiting DLL injection remotely, using DCOM, which uses RPC (lighter weight method)) -> http://yro.slashdot.org/commen... [slashdot.org]

... apk

Re:Windows DLL injection attack vector. (1)

Nkwe (604125) | about 2 months ago | (#47444797)

Remind me again why Windows has the capability to "inject" a new DLL into a running process from outside the process.

Because if you have root you can do anything (technically possible).

Animats: Sorry for late reply (I'm correct) (0)

Anonymous Coward | about 2 months ago | (#47444949)

You asked WHY it's allowed & my post on DCOM using it maliciously (via RPC for exploits to marshall lib code into action remotely) appears "spot on" per my last post http://yro.slashdot.org/commen... [slashdot.org] per -> Metasploit Framework, Part 2 http://www.symantec.com/connec... [symantec.com]

PERTINENT QUOTE/EXCERPT:

"Now we will describe the procedure to select a specific exploit and then run it. The command use exploit_name activates the exploit environment for the exploit exploit_name. If you select the Microsoft RPC DCOM MSO3-026 exploit using the name msrpc_dcom_ms03_026, you may have noticed the prompt changes from msf> to msf msrpc_dcom_ms03_026 >. This notifies that we are working in the temporary environment of that exploit."

See this http://support.microsoft.com/k... [microsoft.com] & THIS excerpt from it (which Metasploit above IS using):

"Microsoft originally released this bulletin and patch on July 16, 2003, to correct a security vulnerability in a Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface. The patch was and still is effective in eliminating the security vulnerability. However, the "mitigating factors" and "workarounds" discussions in the original security bulletin did not clearly identify all the ports by which the vulnerability could potentially be exploited. Microsoft has updated this bulletin to more clearly enumerate the ports over which RPC services can be invoked and to make sure that customers who choose to implement a workaround before installing the patch have the information that they must have to protect their systems. Customers who have already installed the patch are protected from attempts to exploit this vulnerability and do not have to take further action. Remote Procedure Call (RPC) is a protocol that is used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program that is running on one computer to seamlessly run code on a remote computer. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol. The RPC protocol that is used by Windows includes some additional Microsoft-specific extensions. There is a vulnerability in the part of RPC that deals with message exchange over TCP/IP. The failure results because of incorrect handling of malformed messages. This particular vulnerability affects a Distributed Component Object Model (DCOM) interface with RPC, which listens on RPC-enabled ports. This interface handles DCOM object activation requests that are sent by client machines (for example, Universal Naming Convention [UNC] path requests) to the server. An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing data, changing data, deleting data, or creating new accounts with full privileges.
To exploit this vulnerability, an attacker would have to send a specially formed request to the remote computer on specific RPC ports."

So, even though I was operating on "theory only" I was pretty much "dead on right" as to HOW remote exploits can use it to inject in REMOTED code via RPC (which dcom uses, since it's "lighter weight" than other methods...)

APK

P.S.=> "Pats self on back" - not too shabby, for operating on theory alone here, regarding HOW remote exploits could use it using DCOM to "inject" dll code into a process from another completely REMOTE system no less (minus even having it around locally, which is in & of itself, pretty spooky)... apk

So where is the source then? (0)

Anonymous Coward | about 2 months ago | (#47441483)

I'm not too happy with this sort of "blog reporting", for the actual source is nowhere to be found.

I'm even less happy with the way slashdot keeps on flogging the dead horse named beta. To the point of causing outbursts in the readership, fscking stop already!

And beyond. Strongarm tactics against the readership. Time to bugger off.

Re:So where is the source then? (0)

Anonymous Coward | about 2 months ago | (#47441797)

I'm not too happy with this sort of "blog reporting", for the actual source is nowhere to be found.

Just because the source was leaked doesn't mean it isn't copyrighted anymore. That's just one reason you don't want to share it. Another (and probably more important) reason is that you don't want a bunch of script kiddies using it or someone improving it by using new exploits.

(If you really do want the source, it's not that hard to find.)

Re:So where is the source then? (1)

EvilJoker (192907) | about 2 months ago | (#47443745)

Legally, you're probably correct. However, for that to be an issue, someone would have to come forward and claim ownership of the code. This would open the author to all sorts of criminal charges.

I suspect the source is not linked, for the same reason that MythBusters won't show all of their stuff. It doesn't really improve the report, and it would only help copycats looking to exploit it for personal gain. Anyone with a professional interest would find it quickly enough anyway.

Source code (0)

Anonymous Coward | about 2 months ago | (#47441573)

The client is written in ASM and the server in PHP:
http://goo.gl/GliXKP

So 640k... (1)

JonathanR (852748) | about 2 months ago | (#47441875)

is plenty after all.

And? (1)

ledow (319597) | about 2 months ago | (#47442101)

It's not difficult to write a malicious program that can steal data as the user it runs. In fact, it's trivially easy, and your homebrew program will almost certainly avoid every antivirus signature with the minimum of tweaking and testing.

Exploiting holes is harder, but there's always a PoC code somewhere if you dig enough, especially if you are subscribed to security lists. And there you might have to do a little tweaking/testing but with VM's and debugging toolkits, it's not hard for any proficient programmer.

Quite what the news is here, I don't know. Almost every virus in existence has "variants" that aren't made by the same author - people take and either hexedit or have access to enough source-code to outright clone a virus. It's all out there if you look hard enough.

But, honestly, if you want to write one, a teenager could do it. Whether it "goes viral" is more to do with how easily it spreads and how many people you can get to run it before it gets noticed. I work in schools, and "viruses" written by the bright kids can spread through the school in a matter of days.

Given that, the number of viruses used with actual malicious intent is extremely low.

Go ahead - write a program with viral attributes and compile it with a random compiler. Guarantee you you could infect your workplace, not show up on an anti-virus signature, and do much nastier things than steal some data that passes through memory in plaintext.

Which is why we should be running a permissions-based security, or at worst a signature whitelist and NOT a signature blacklist like AV operates on. The very existence of AV still makes me laugh at humanity.

For those who are interested (1)

Fnord666 (889225) | about 2 months ago | (#47443095)

For those who are interested, here is a link [opensc.ws] to the post on opensc that contains the source code download. You will need to register for an account before downloading.

Re:For those who are interested (0)

Anonymous Coward | about 2 months ago | (#47444775)

Could someone who downloaded it here please give the sha256 checksum of your file.

Re:For those who are interested (1)

xeroized (2558611) | about 2 months ago | (#47448487)

For those who are interested, here is a link [opensc.ws] to the post on opensc that contains the source code download. You will need to register for an account before downloading.

That URL is incorrect to the source. Correct URL is: https://www.opensc.ws/leaked-s... [opensc.ws]

"Only" 20 KB? (1)

aaaaaaargh! (1150173) | about 2 months ago | (#47443575)

What's wrong with those Trojan authors nowadays? There are whole programming language implementations that run in less than 20KB!

Don't they code in assembler any more?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>